Atlassian commence à entraîner Rovo avec vos données Jira et Confluence dès aujourd'hui

Sophie Laurent Responsable Juridique & Conformité, YuSMP Group · Cadres réglementaires européens, RGPD, DORA, NIS2 et conformité IA Act pour les équipes logicielles

En bref

Quelles données Atlassian collecte

Atlassian sépare la collecte en deux catégories avec des droits d'opt-out différents.

Les métadonnées couvrent des signaux dérivés : scores de lisibilité, classifications de types de tâches, story points, dates de fin de sprint, valeurs SLA et scores de similarité sémantique produits par le Teamwork Graph. Atlassian indique que ces données sont dé-identifiées avant utilisation et que des garanties sont en place pour empêcher la réidentification. La société soutient que les métadonnées sont déjà agrégées et anonymisées, ce qui explique pourquoi elle traite l'opt-out comme une fonctionnalité Premium/Enterprise plutôt qu'un droit de base.

Les données in-app sont plus sensibles : titres et contenus des pages Confluence, titres, descriptions et commentaires des tickets Jira, noms de statuts personnalisés et noms de workflows. Cette catégorie peut inclure des noms de clients, des feuilles de route produit, des résultats d'audits de sécurité et d'autres informations de projet confidentielles selon l'usage que font vos équipes de Jira et Confluence.

Les données sont conservées au maximum sept ans. Après un opt-out, les données in-app sont supprimées sous 30 jours et les métadonnées sous 90 jours.

Droits d'opt-out par niveau d'abonnement

La structure à niveaux signifie que les organisations les plus susceptibles de détenir des données réglementées — celles abonnées en Free ou Standard, souvent des PME, des start-ups ou des équipes FinTech et HealthTech soucieuses des coûts — ont le moins de contrôle. Les clients Enterprise, qui disposent généralement d'équipes de conformité dédiées et d'un examen juridique, bénéficient d'un contrôle total par défaut. Cette asymétrie mérite d'être signalée dans votre processus de gestion des fournisseurs : un outil utilisé pour la planification de feuille de route ou le suivi du backlog de sécurité peut être sur un abonnement qui ne correspond pas à la sensibilité de son contenu.

Ce que cela signifie pour les équipes françaises

Pourquoi la question RGPD n'est pas anodine

L'article 6, paragraphe 4 du RGPD établit un test de compatibilité : lorsqu'un responsable du traitement souhaite traiter des données pour un nouvel objectif non couvert par le consentement ou la base légale d'origine, il doit évaluer si cette réutilisation est compatible. Entraîner un assistant IA commercial sur des données de gestion de projet est un objectif fondamentalement différent de l'usage opérationnel pour lequel les données ont été créées. Les équipes logicielles françaises — et leurs clients dont les données figurent dans des tickets Jira — peuvent avoir besoin de revoir si leur base légale actuelle couvre cette réutilisation ou si une mise à jour de l'analyse d'impact relative à la protection des données (AIPD) est requise.

Les équipes recherchant des conseils structurés pour cette analyse devraient envisager une revue formelle AI Act et RGPD, notamment si Jira ou Confluence traite des données personnelles de personnes concernées établies dans l'UE.

Implications DORA et NIS2

En vertu de l'article 28 de DORA, les entités financières de l'UE doivent tenir un registre de toutes les dispositions de services TIC tiers. Le changement de politique d'Atlassian constitue une mise à jour substantielle de la nature du traitement des données dans le cadre de cet accord. L'entrée de registre pour Atlassian doit désormais mentionner le statut de contribution à l'entraînement IA, la date de vérification du paramètre et l'approbateur responsable. Une clause de stratégie de sortie abordant les données utilisées pour l'entraînement de modèles — et pas seulement l'extraction de données en fin de contrat — est désormais une bonne pratique à ajouter à tout accord Atlassian.

Pour les équipes soumises aux obligations de sécurité NIS2, le changement élargit la dimension de risque de la chaîne d'approvisionnement : vos données opérationnelles d'incidents, les enregistrements de violations de SLA et les définitions de workflows alimentent désormais un modèle IA du fournisseur. La documentation dans votre cartographie fournisseurs est l'étape minimale requise ; les équipes opérant des infrastructures critiques devront peut-être escalader auprès de leur RSSI avant que les effets par défaut d'aujourd'hui ne s'appliquent.

Considérations pour les équipes américaines : PI et confidentialité

Les équipes logicielles opérant sous SOC 2 ou des obligations de confidentialité contractuelles doivent vérifier si leurs instances Jira et Confluence contiennent des données couvertes par des NDA clients, des résultats d'audits de sécurité ou des spécifications produit non publiées. Atlassian indique que les données sont dé-identifiées, mais la définition de la dé-identification n'élimine pas le risque d'exposition de la propriété intellectuelle pour du contenu technique très spécifique.

Que faire maintenant

• Connectez-vous à Atlassian Administration dès aujourd'hui. Accédez à Sécurité → Contribution de données et consignez vos paramètres actuels. C'est la vérification la plus rapide, prend moins de deux minutes et constitue la base de toute action de conformité ultérieure.
• Identifiez votre niveau d'abonnement et l'écart. Si votre organisation est en Free ou Standard et détient des données réglementées, confidentielles ou appartenant à des clients dans Jira ou Confluence, la collecte de métadonnées est inévitable sans mise à niveau d'abonnement. Décidez si ce compromis est acceptable ou si une montée en gamme est justifiée.
• Classifiez la sensibilité du contenu. Les projets Jira et les espaces Confluence varient considérablement en sensibilité. Un backlog produit orienté vers le public est différent d'un tracker de vulnérabilités de sécurité. Classifiez les espaces et projets contenant des données réglementées et prenez-le en compte dans votre décision d'opt-out.
• Effectuez le test de compatibilité de l'article 6, paragraphe 4 du RGPD. Documentez si votre base légale actuelle s'étend à l'entraînement de modèles IA. Si vous avez une AIPD datant d'avant 2024, elle ne couvre presque certainement pas la réutilisation pour l'IA. Mettez-la à jour ou commandez un avenant.
• Mettez à jour les registres DORA et NIS2. Consignez le changement dans votre registre TIC tiers. Notez la date, le paramètre choisi, le niveau d'abonnement et l'administrateur responsable. Cette trace vous protège en cas de contrôle par une autorité de supervision.
• Révisez les contrats clients. Si vous développez des logiciels pour des clients et utilisez Jira pour gérer ce travail, vérifiez si un contrat interdit d'alimenter des données de projet vers des systèmes IA tiers. Prenez les mesures correctives — opt-out ou renégociation — avant que l'obligation contractuelle et les paramètres par défaut du fournisseur ne divergent.

Questions fréquentes