Entraînement de vos données sur Atlassian : ce qu'il faut savoir

À compter du 17 août 2026, Atlassian commencera à collecter les métadonnées et le contenu intégré au sein des applications de ses clients provenant de Jira, Confluence et d'autres produits cloud pour entraîner ses offres d'IA, notamment Rovo et Rovo Dev. Cette annonce intervient après le récent changement de politique de GitHub concernant l'utilisation des données de Copilot pour l'entraînement de l'IA. Ces deux importants changements semblent indiquer que l'opt-out par défaut est en train de devenir la norme du secteur. Cependant, GitLab adopte la position inverse avec aucune collecte de données, aucun entraînement de l'IA sur les données clients, quel que soit votre niveau d'abonnement.

Le changement opéré par Atlassian est appliqué par défaut pour l'ensemble des clients cloud et concerne environ 300 000 organisations. Pour les clients des offres Free, Standard et Premium, la collecte de métadonnées est obligatoire et ne peut pas être désactivée. Seuls les clients de l'offre Enterprise ont la possibilité de s'y opposer. Ce changement de politique mérite une lecture attentive si vos équipes d'ingénierie, d'informatique et de gestion de programmes utilisent Atlassian, car ce sont elles qui sont le plus exposées par ce changement, et les moins susceptibles d'avoir été consultées avant sa mise en œuvre.

Bien que les enjeux de gouvernance sous-jacents soient identiques pour les changements appliqués par Atlassian et GitHub, les données concernées diffèrent. Là où le changement de GitHub portait sur le code source et les interactions des équipes de développement, celui d'Atlassian concerne les plans de projet, la documentation interne, les configurations de workflows et les métadonnées opérationnelles de Jira, Confluence et de l'ensemble de l'écosystème Atlassian. Pour les organisations qui s'appuient sur ces outils comme système de référence pour la planification et la livraison de leurs projets, les conséquences sont importantes.

Ce qui change et ce que cela signifie pour vos données

Atlassian collectera deux catégories d'informations :

• Les métadonnées : signaux opérationnels pseudonymisés tels que les story points, les dates de sprint et les valeurs d'accords de niveau de service (SLA), y compris les données issues de son Teamwork Graph et des applications tierces connectées
• Le contenu des applications : contenu généré par les utilisateurs, comme les pages Confluence, les titres, descriptions et commentaires des tickets Jira

Atlassian indique qu'un processus de pseudonymisation et d'agrégation sera appliqué avant l'entraînement des données. Les données collectées pourront être conservées jusqu'à sept ans, le contenu des applications sera supprimé dans les 30 jours suivant la désactivation de la collecte, et les modèles seront entraînés à nouveau dans un délai de 90 jours.

Certaines exclusions s'appliquent : les clients avec des clés de chiffrement gérées par le client, Atlassian Government Cloud, Isolated Cloud ou soumis aux exigences HIPAA ne sont pas concernés par la collecte de données. Toutefois, pour la grande majorité des clients cloud d'Atlassian, la collecte de données s'appliquera à moins qu'ils ne souscrivent à l'offre Enterprise et ne désactivent cette option.

Ce changement marque un revirement dans la politique d'Atlassian, qui avait affirmé que les données clients ne seraient pas utilisées pour entraîner ou améliorer ses services d'IA. Les organisations qui ont adopté Jira et Confluence pour gérer leurs workflows de planification les plus sensibles (tableaux de sprint, tickets de sécurité, analyses post-mortem d'incidents et documentation interne) contribueront bientôt au pipeline d'entraînement de l'IA d'Atlassian, sans jamais avoir donné leur consentement.

Le déficit en matière de gouvernance face à l'« opt-out par défaut »

La collecte de données activée par défaut destinée à l'entraînement de l'IA est une tendance émergente dans l'industrie logicielle. Ce modèle soulève systématiquement les mêmes questions : comment cette pratique s'insère-t-elle dans les accords de traitement des données existants ? La définition des « métadonnées » du fournisseur correspond-elle à ce que vos équipes juridiques et de sécurité considéreraient comme des données non sensibles ?

Nombreuses sont les organisations qui ne savent pas comment répondre à ces questions.

Lorsqu'un fournisseur modifie ses pratiques en matière de données par le biais d'une mise à jour des conditions d'utilisation, c'est au client qu'il incombe de le remarquer, d'en évaluer les implications et d'agir dans le délai imparti par le fournisseur.

Le caractère obligatoire de la collecte de métadonnées pour les offres Free, Standard et Premium rend la situation encore plus préoccupante. La seule solution est de passer à l'offre Enterprise, qui exige un minimum de 801 utilisateurs et une tarification sur mesure représentant des coûts supplémentaires significatifs pour les équipes qui n'en sont pas encore à ce stade. La protection des données devient, en d'autres termes, une décision d'achat.

La structure par offres introduit également un problème plus subtil. Les métadonnées telles que les story points, la vélocité des sprints, les indicateurs SLA et les classifications de tâches peuvent sembler anodines de manière isolée, mais agrégées, elles révèlent la structure des projets, les schémas de performance des équipes et la cadence de livraison. Pour les organisations qui évoluent dans des secteurs concurrentiels, cette intelligence opérationnelle a une valeur réelle, et le terme « pseudonymisé » ne signifie pas nécessairement « non sensible » dès lors que des schémas peuvent être reconstitués à grande échelle.

L'importance de ce changement pour les organisations utilisant l'écosystème Atlassian

Dans les organisations basées sur Atlassian, Jira est au cœur de la façon dont les équipes planifient, suivent et livrent leur travail. C'est la source de vérité pour la planification des sprints, le suivi des bogues, la gestion des releases, la coordination de portefeuille et l'exécution de projets transversaux.

Dans les secteurs réglementés tels que les services financiers, le secteur public et l'industrie manufacturière, Jira et Confluence contiennent des données opérationnelles sensibles qui peuvent être soumises à des exigences de conformité. Le risque se cumule pour les organisations qui, outre Jira, utilisent l'écosystème Atlassian dans son ensemble.

Lorsque vous utilisez conjointement Jira, Confluence, Bitbucket et Bamboo, les données qui alimentent désormais l'entraînement de l'IA proviennent de vos plans de projet, de votre documentation interne, des métadonnées de votre code source et de vos configurations CI/CD : autant d'éléments que les équipes de sécurité et de conformité souhaiteraient examiner avant tout partage avec le pipeline d'entraînement d'un fournisseur.

Les connecteurs Teamwork Graph d'Atlassian ajoutent une dimension supplémentaire pour les clients ayant intégré des outils tiers, tels que Slack, Figma, Google Drive, Salesforce et ServiceNow à leur environnement. Ils indexent les signaux de relation et d'activité provenant de ces applications connectées, ce qui signifie que les métadonnées collectées par Atlassian ne se limiteront pas aux produits Atlassian. Pour les équipes de sécurité et de conformité habituées à évaluer les flux de données fournisseur par fournisseur, cette portée multiplateforme complique considérablement l'analyse.

Les organisations déjà engagées dans la migration imposée par Atlassian depuis les éditions Data Center et Server vers le cloud font face à un défi supplémentaire. Avec une collecte de données par défaut destinée à l'IA au cours de cette migration, la question n'est plus seulement de savoir s'il faut migrer vers Atlassian Cloud, mais s'il faut migrer vers Atlassian Cloud tout en sachant que les données alimenteront l'entraînement de l'IA, à moins de souscrire à une offre plus onéreuse.

Ce que les secteurs réglementés doivent évaluer dès maintenant

Les implications en matière de conformité varient selon les secteurs, mais l'obligation de réévaluation est constante.

Dans les services financiers, des frameworks comme SR 11-7 et DORA exigent une supervision documentée et auditable des prestataires technologiques tiers, y compris la manière dont ces prestataires traitent les données. Dans le secteur public, les frameworks NIST 800-53 et FISMA font du contrôle des flux de données sensibles une exigence fondamentale. Dans le secteur de la santé, la loi HIPAA régit la manière dont les données liées aux patients sont traitées par des tiers.

Dans tous les secteurs, un changement substantiel dans les pratiques de données d'un fournisseur, comme Atlassian, qui est passé du non-entraînement de ses modèles sur les données de ses clients à un entraînement par défaut, déclenche une obligation de documentation et de réévaluation des risques.

Les institutions qui opèrent dans le cadre du Règlement européen sur l'intelligence artificielle font face à une dimension supplémentaire : le modèle d'opt-out s'inscrit dans les normes américaines, tandis que les régulateurs européens exigent généralement un consentement explicite pour ce type de traitement des données.

Si votre équipe de gestion des risques liés aux modèles ou de gestion des fournisseurs avait documenté les contrôles de traitement des données d'Atlassian avant cette annonce, la question n'est pas de savoir si ce changement déclenche une obligation de réévaluation, car c'est le cas. La question est de savoir si votre équipe peut agir avant le 17 août.

Ce qu'il faut attendre de vos fournisseurs de plateformes

Les directeurs techniques et les responsables de la sécurité des systèmes d'information (RSSI) des secteurs réglementés doivent adopter l'IA d'une manière qu'ils peuvent justifier auprès des régulateurs, des conseils d'administration et des clients. C'est pourquoi GitLab opère selon les principes suivants :

Des engagements inconditionnels en matière de données, et non des protections en fonction du niveau d'abonnement. Les organisations des secteurs réglementés ont besoin de savoir, avec précision, ce qu'il advient de leurs données. Un engagement qui varie selon l'offre souscrite, ou qui nécessite une action avant une date limite, introduit exactement le type de variable non maîtrisée qui préoccupe les RSSI.

Transparence et auditabilité. Les frameworks de gestion des risques liés aux modèles exigent des organisations qu'elles comprennent les systèmes d'IA qu'elles déploient, y compris les données d'entraînement et les tiers impliqués. Les fournisseurs incapables de répondre clairement à ces questions créent un risque de documentation.

Séparation entre les données clients et l'entraînement de l'IA du fournisseur. Lorsqu'un fournisseur de plateforme entraîne ses modèles sur les données d'utilisation de ses clients, les workflows et les schémas opérationnels deviennent des données d'entrée d'un système qui sert également aux concurrents. Pour les organisations dont la structure de projet ou le rythme de livraison représente un avantage compétitif, cette exposition est cruciale.

En quoi l'approche de GitLab est différente

GitLab n'entraîne pas ses modèles sur les données clients, quel que soit le niveau d'abonnement. Les fournisseurs d'IA qui alimentent les fonctionnalités de GitLab Duo sont contractuellement tenus de ne pas utiliser les données d'entrée ou de sortie des clients à leurs propres fins, un engagement que le CEO de GitLab, Bill Staples, a réaffirmé à plusieurs reprises.

Le Centre pour la transparence de l'IA de GitLab documente précisément quels modèles alimentent quelles fonctionnalités, comment les données sont traitées et quels engagements sont pris auprès des fournisseurs. Le plan de continuité de l'IA de GitLab décrit la gestion des changements apportés par les fournisseurs, y compris tout changement substantiel dans la manière dont les fournisseurs d'IA traitent les données clients. Pour les institutions qui gèrent le risque lié aux tiers en matière d'IA dans le cadre de DORA ou de frameworks similaires, la continuité et la concentration fournisseur sont des préoccupations de gouvernance actives : un plan documenté de ces deux aspects fait partie intégrante d'une suite d'outils d'IA responsables.

Pour les organisations qui exigent que le traitement de l'IA reste au sein de leur propre infrastructure, GitLab Duo Agent Platform est disponible avec les déploiements GitLab Self-Managed, y compris la prise en charge de l'intégration avec des modèles d'IA auto-hébergés. Ainsi, les prompts et le code ne quittent jamais l'environnement du client. GitLab fournit également une indemnisation en matière de propriété intellectuelle pour les données de sortie générées par GitLab Duo, sans filtre requis et sans étape d'activation. Vous décidez du lieu de résidence de vos données, quel que soit votre modèle de déploiement ou votre niveau d'abonnement.

Que votre organisation continue à utiliser Atlassian ou commence à évaluer d'autres solutions, le contrôle de vos données et leur utilisation est un sujet à aborder dès maintenant. L'échéance du 17 août approche, mais vous avez encore le temps d'essayer gratuitement GitLab Ultimate avec GitLab Duo Agent Platform dès aujourd'hui.