Atlassian entraîne-t-il son IA sur vos données Jira ? Voici ce qui change le 17 août

Si vous administrez un site Jira, Confluence ou Jira Service Management, Atlassian vous a probablement déjà envoyé un e-mail au sujet de nouveaux paramètres de « contribution de données ». Voici ce que cela signifie concrètement, et ce qu'il faut faire avant le 17 août 2026.

Ce qui change : Atlassian déploie des contrôles au niveau de l'organisation dans Atlassian Administration (Security → Data contribution) qui déterminent si vos métadonnées et votre contenu applicatif sont utilisés pour entraîner les modèles d'IA d'Atlassian et améliorer ses fonctionnalités propulsées par l'IA sur Jira, Confluence, JSM et les applications Platform connectées. À partir du 17 août 2026, Atlassian commence à utiliser vos données selon les paramètres en vigueur — que vous les ayez configurés vous-même, ou qu'ils soient restés sur leur valeur par défaut.

Ce que la plupart des admins ratent : votre contrôle sur ce point dépend entièrement de votre palier d'abonnement. Seuls les clients Cloud Enterprise peuvent totalement refuser la contribution des métadonnées. Tous les autres paliers — Free, Standard, Premium — contribuent automatiquement leurs métadonnées, sans aucun moyen de désactiver cette option. Ce que vous pouvez généralement contrôler, quel que soit votre palier, c'est le contenu applicatif : vous pouvez exclure des espaces Confluence, des projets Jira ou des connecteurs Teamwork Graph spécifiques de la contribution, même si vous ne pouvez pas désactiver entièrement le paramètre.

Ce qu'il faut réellement faire : rendez-vous dans Atlassian Administration → Security → Data contribution et vérifiez ce qui est déjà configuré. Confirmez le palier d'abonnement le plus élevé actif de votre organisation (il détermine vos paramètres par défaut — même une seule licence Enterprise n'importe où dans votre organisation modifie le calcul pour tout ce qu'elle contient). Si votre organisation traite des données clients, des informations réglementées ou tout élément couvert par un accord de traitement des données, décidez délibérément si des projets ou espaces spécifiques doivent être exclus, plutôt que d'hériter passivement du paramètre par défaut.

Il ne s'agit là que d'un seul paramètre, sur une seule plateforme. Si votre organisation utilise également Slack, Notion, GitHub, Salesforce ou une demi-douzaine d'autres outils SaaS connectés, chacun prend discrètement sa propre version de cette même décision en votre nom — certains avec un interrupteur visible, d'autres (comme l'entraînement ML non génératif de Slack) sans aucun interrupteur, avec un opt-out possible uniquement par e-mail. Ce schéma — des paramètres réels, des échéances réelles, des conséquences réelles, enfouis dans un panneau d'administration que personne n'est chargé de vérifier — est exactement ce que les connecteurs de 8200.dev sont conçus pour révéler automatiquement, sur chaque plateforme que vous avez connectée, pas seulement celle qui vous a envoyé un e-mail cette semaine.

La décision que personne n'était chargé de prendre

Prenez un peu de recul par rapport à Atlassian et observez la forme du problème, car il se répète partout.

Chaque éditeur SaaS qui développe des fonctionnalités d'IA fait face à la même question : quelles données clients les modèles peuvent-ils apprendre ? Chaque éditeur y répond différemment, publie la réponse à un endroit différent, et accorde aux clients un degré de contrôle différent :

• Slack utilise par défaut les messages et le contenu des clients pour entraîner des modèles de machine learning non génératifs au niveau de la plateforme (classement de recherche, recommandations). Il n'existe aucun interrupteur d'administration dans les paramètres de l'espace de travail — se désinscrire suppose que le propriétaire de l'espace de travail écrive à l'adresse de retour d'expérience de Slack pour en faire la demande.
• Dropbox expose un paramètre « IA tierce » dont la valeur par défaut dépend de l'emplacement de votre compte : activé par défaut pour les comptes américains, désactivé par défaut dans l'UE, au Royaume-Uni et au Canada. Deux organisations avec des plans Dropbox identiques peuvent avoir des postures opposées sans jamais le savoir.
• GitHub trace la ligne selon le palier : les données des clients Business et Enterprise sont contractuellement exclues de l'entraînement des modèles, tandis que les paliers inférieurs sont couverts par des conditions produit plus larges. Une même organisation peut changer de palier et modifier silencieusement sa posture.
• Salesforce, Zendesk et Intercom ont chacun leurs propres valeurs par défaut et leurs propres parcours de désinscription — une page de configuration, un ticket de support, un paramètre d'espace de travail.
• Google Workspace, Microsoft 365, Notion et Box se situent de l'autre côté : leurs conditions garantissent contractuellement que le contenu des clients n'est pas utilisé pour entraîner des modèles, il n'y a donc aucun interrupteur car aucun n'est nécessaire. C'est une posture réellement différente — mais vous devez tout de même la connaître, et être en mesure de la présenter à un auditeur.

Remarquez ce qui est commun à tous ces cas : aucun d'entre eux n'expose une API que vous pourriez interroger pour demander « mon organisation contribue-t-elle actuellement à des données d'entraînement ? ». La posture se trouve dans des contrats, dans des e-mails, dans des valeurs par défaut régionales, dans des paliers d'abonnement. Elle est bien réelle, elle a des conséquences, et elle est invisible pour tous les tableaux de bord que consulte votre équipe sécurité.

C'est pourquoi « quelqu'un devrait vérifier ça » échoue en tant que contrôle. Il n'existe aucun endroit où vérifier. La décision revient par défaut à ce que l'éditeur a choisi, et l'éditeur a choisi selon ses propres intérêts.

Ce que cela signifie pour la conformité

Si votre organisation détient un rapport SOC 2, travaille en vue d'une certification ISO 27001, ou traite des données personnelles au titre du RGPD, la question de la contribution de données n'est pas un détail facultatif — elle s'inscrit directement dans vos obligations existantes.

Les accords de traitement des données décrivent les finalités pour lesquelles un sous-traitant peut utiliser vos données. Un éditeur qui entraîne des modèles d'IA sur votre contenu constitue une *finalité*. Si votre DPA avec un client indique que ses données sont utilisées pour fournir le service, et que l'une de vos plateformes connectées alimente discrètement ces mêmes données dans l'entraînement d'un modèle, c'est à vous — et non à l'éditeur — de combler l'écart entre ce que vous avez promis en aval et ce que vous autorisez en amont.

Les auditeurs ont commencé à poser cette question directement. Elle apparaît dans les questionnaires d'évaluation des risques fournisseurs sous une variante du type « l'un de vos sous-traitants utilise-t-il vos données pour entraîner des modèles d'IA, et comment le savez-vous ? ». Une réponse défendable comporte deux volets : la *posture* (quelles plateformes contribuent, lesquelles sont contractuellement exclues) et le *registre de décision* (qui l'a examinée, quand, et ce qui a été choisi). « Nous n'avons jamais vérifié » est la seule mauvaise réponse. Nous avons abordé plus largement ce que les auditeurs attendent désormais en matière de gouvernance de l'IA dans ce que les auditeurs exigent réellement pour la gouvernance de l'IA en 2026 — la contribution de données devient un point standard de cet examen.

La bonne nouvelle : c'est l'un des rares points de conformité où la correction est véritablement peu coûteuse. Rien ne nécessite de restructuration. Il faut *trouver* les paramètres, *décider* en connaissance de cause, et *consigner la décision*.

Une checklist d'administration pour le 17 août

Voici la revue concrète à effectuer avant l'échéance d'Atlassian, généralisée pour pouvoir l'appliquer à chaque plateforme que vous exploitez :

1. Recensez le périmètre. Listez les plateformes SaaS où le contenu ou les métadonnées de votre organisation résident réellement — pas seulement Atlassian. Si elle contient des données clients, des données réglementées ou tout élément sous accord de confidentialité, elle entre dans le périmètre.
2. Identifiez la posture de contribution de données de chaque plateforme. Pour Atlassian : Administration → Security → Data contribution. Pour les autres, le contrôle peut être une page de paramètres, un ticket de support, une désinscription par e-mail, ou une clause contractuelle sans aucun contrôle du tout.
3. Confirmez votre palier d'abonnement sur chaque plateforme où la posture en dépend. Sur Atlassian, le palier actif le plus élevé de votre organisation détermine les valeurs par défaut pour tout ce qu'elle contient. Sur GitHub, le palier détermine si l'exclusion contractuelle vous couvre.
4. Décidez délibérément. Opter pour la contribution est un choix légitime — de meilleures fonctionnalités d'IA constituent un avantage réel. Le mode d'échec n'est pas la contribution ; c'est une contribution que *personne n'a décidée*. Excluez les projets et espaces contenant des éléments sensibles, puis laissez le reste suivre son cours si c'est votre choix.
5. Consignez la décision. Une note datée — qui a examiné, ce qui a été configuré, pourquoi — transforme une valeur par défaut silencieuse en preuve de gouvernance que vous pouvez remettre à un auditeur.
6. Revérifiez selon un calendrier. Les éditeurs modifient leurs valeurs par défaut, ajoutent des fonctionnalités d'IA et déplacent des paramètres. Une posture examinée une fois en 2026 n'est pas une posture gérée en 2027.

Si cette liste ressemble à un travail que quelqu'un doit s'approprier — c'est le cas. La version honnête de ce problème, c'est qu'il est *récurrent, transversal et fastidieux*, ce qui en fait exactement le genre de contrôle qui se délite silencieusement dès qu'il dépend d'un humain qui doit s'en souvenir.

Comment 8200.dev révèle cela automatiquement

8200.dev signale désormais un constat de posture d'entraînement IA pour chaque plateforme que vous connectez. Connectez Jira, Slack, Dropbox, GitHub, Salesforce ou l'une des autres plateformes prises en charge, et l'analyse vous indique — aux côtés de vos constats sur le partage et les permissions — si cet éditeur utilise par défaut vos données pour l'entraînement de l'IA, où se trouve l'option de désinscription ou la garantie contractuelle, et à quand remonte la dernière vérification de cette posture. Les plateformes en opt-in par défaut apparaissent comme des constats exigeant une décision ; les plateformes contractuellement sûres apparaissent comme des attestations que vous pouvez présenter aux auditeurs.

Lorsqu'une plateforme expose réellement une politique d'IA lisible par API sur un axe voisin, nous la vérifions en direct : le connecteur GitHub lit la politique de correspondance de code public Copilot de votre organisation, et le connecteur GCP vérifie si Vertex AI fonctionne sans qu'aucune politique d'organisation ne le contraigne. Chaque constat est accompagné d'un plan de remédiation détaillé étape par étape, et le catalogue complet des vérifications se trouve sur la page des fonctionnalités.

Le propos n'est pas que les fonctionnalités d'IA sont dangereuses. Le propos est que la *contribution de données doit être une décision, pas une valeur par défaut* — sur Atlassian avant le 17 août, et sur chaque autre plateforme que votre organisation exploite déjà. Si vous souhaitez que cette décision soit révélée automatiquement plutôt que gardée en mémoire manuellement, consultez les offres et tarifs et connectez votre première plateforme en quelques minutes.