Atlassian utilise les données de Jira et Confluence pour entraîner ses IA

Ce lundi 17 août, Atlassian met en route un changement discret mais costaud : l'éditeur de Jira et Confluence peut désormais utiliser les données de ton organisation pour améliorer ses applications et entraîner ses IA pour tous ses clients. Traduction : les tickets que ton équipe écrit, les pages de documentation, les statuts personnalisés, tout ça peut finir dans les modèles d'Atlassian. Il reste des réglages à faire, mais tout le monde ne peut pas tout couper. Voici ce qui change concrètement et ce que tu peux encore sauver.

Ce qui change ce lundi

Jusqu'ici, Atlassian utilisait déjà les métadonnées et le contenu de tes apps, mais seulement pour améliorer ta propre expérience, par exemple affiner les recherches dans ton Confluence. À partir d'aujourd'hui, les conditions d'utilisation évoluent : ces données peuvent servir à améliorer les apps et les IA pour l'ensemble des clients. Les produits concernés dès le premier jour : Jira, Confluence et Jira Service Management, plus les apps de la plateforme (Rovo, Home, Teams, Projects, Assets, Goals, Analytics, Administration) et certains connecteurs Teamwork Graph. Les données venant d'apps sans réglage dédié, comme Bitbucket ou Loom, ne sont pas collectées pour l'instant. C'est écrit noir sur blanc dans les nouvelles conditions, en vigueur depuis ce jour.

Logo officiel d'Atlassian.

Source : Wikimedia Commons (logo officiel d'Atlassian)

Ce que ça veut dire pour tes données

Atlassian distingue deux familles. Les métadonnées d'abord : des caractéristiques calculées à partir de ton contenu, comme le nombre de story points d'un ticket, le score de complexité d'une page Confluence ou les valeurs de SLA d'un incident. S'y ajoutent des « motifs communs » tirés des recherches, des résultats et des conversations Rovo : des mots ou des sujets fréquents chez de nombreux clients. Tout ça est censé être désidentifié et agrégé avant usage, avec retrait des noms et des adresses e-mail.

Les données in-app sont bien plus sensibles : ce sont les contenus que tes équipes écrivent. Titres et corps des pages Confluence, titres, descriptions et commentaires des tickets Jira, noms d'émoticônes ou de statuts personnalisés. Dans un service support, cela veut dire le texte des demandes : réinitialisation de mot de passe, incident de sécurité, dossier RH. La désidentification enlève le nom de l'auteur, pas la nature de l'information : un ticket qui décrit un produit pas encore lancé reste sensible, même anonymisé, comme on le voyait avec l'outil de Proton qui te montrait ce que ChatGPT sait de toi.

Qui peut couper quoi

Le réglage se trouve dans Atlassian Administration, section Sécurité, entrée Data contribution settings. Il se règle au niveau de l'organisation, et c'est le palier le plus élevé, essai compris, qui fait foi. En gratuit et en Standard, métadonnées et données in-app sont activées par défaut, et tu peux désactiver les données in-app. En Premium, les métadonnées restent toujours actives mais les données in-app sont éteintes par défaut. En Entreprise, les données in-app sont éteintes par défaut et c'est la seule offre qui permet aussi de couper les métadonnées.

Les organisations soumises à des règles de conformité strictes (santé, cloud gouvernemental, clés de chiffrement gérées par le client) sont exclues d'office. Si tu décides de couper, le contenu in-app doit être retiré des jeux de données sous trente jours et les attributs sous quatre-vingt-dix jours, avec réentraînement des modèles concernés. À nuancer : les données agrégées et désidentifiées peuvent être conservées jusqu'à sept ans.

Logo officiel de Jira.

Source : Wikimedia Commons (logo officiel de Jira)

Le réflexe à garder

Si ton entreprise utilise Jira ou Confluence dans le cloud, ouvre Atlassian Administration et regarde ce que ton plan expose vraiment : les réglages disponibles varient selon l'offre. Décide séparément pour les métadonnées et les données in-app, note la décision et la date, ton prochain audit te remerciera, et remets une vérification au calendrier parce que les conditions peuvent encore bouger.

Ce qui ne change pas : Atlassian affirme ne pas vendre ces données, le RGPD reste applicable et les installations Data Center ne sont pas concernées. Mais le principe est là : quand le défaut est « on », c'est le client qui porte le poids de la protection. Un réglage à cocher, c'est aussi une clause qu'on peut modifier plus tard. On en parlait déjà quand Fastmail promettait de garder tes mails en Europe : la localisation et l'usage des données, c'est une décision, pas une fatalité.

Atlassian n'est ni le premier ni le dernier à transformer les données de ses clients en carburant IA. La différence, c'est que la bascule se fait par défaut et que l'opt-out dépend de ton abonnement. Cinq minutes dans les réglages, une décision documentée, et tu sais où tu mets les pieds. Parce qu'avec tes données, la vraie question n'est pas de savoir si l'IA va les utiliser, c'est de savoir qui a décidé qu'elle le ferait.