Atlassian active par défaut l’utilisation des données clients pour l’entraînement de l’IA

 (letsdatascience.com)
5 points par GN⁺ 2026-04-21 | 1 commentaires | Partager sur WhatsApp
  • Les métadonnées clients et les contenus in-app des produits Atlassian Cloud comme Jira et Confluence seront utilisés par défaut à partir du 17 août 2026 pour l’entraînement de Rovo et Rovo Dev
  • Les paramètres par défaut varieront selon l’offre : sur Free, Standard et Premium, la contribution des métadonnées sera toujours activée, tandis que seule l’offre Enterprise conservera la désactivation par défaut des métadonnées et des données in-app ainsi que le contrôle associé
  • Les données collectées incluent des métadonnées comme le score de lisibilité, les story points et les valeurs de SLA, ainsi que des données in-app comme le corps des pages, les descriptions de tickets, les commentaires et les noms de workflows
  • Des mesures de protection comme la suppression des identifiants directs et l’agrégation seront appliquées, mais les données de contribution pourront être conservées jusqu’à 7 ans ; après suppression ou opt-out, les données in-app seront retirées sous 30 jours et les modèles réentraînés sous 90 jours
  • Ce changement de politique rompt avec la position antérieure de non-utilisation et modifie la provenance des données des outils de travail ainsi que le niveau de contrôle selon le prix, avec un impact accru sur les décisions de confidentialité, de gouvernance et de conformité

Aperçu du changement

  • Atlassian prévoit, à partir du 17 août 2026, d’utiliser par défaut pour l’entraînement de l’IA les métadonnées clients et les contenus in-app de Jira, Confluence et d’autres produits Atlassian Cloud
    • Les fonctionnalités IA visées sont explicitement Rovo et Rovo Dev
    • L’ampleur de l’impact est estimée à environ 300 000 clients
  • Avec la modification de la politique de contribution des données, les paramètres par défaut varieront selon l’offre
    • Les offres inférieures ne permettent pas de désactiver la collecte des métadonnées
    • L’offre Enterprise conserve le contrôle sur la collecte des métadonnées et des données in-app
  • La durée de conservation des données de contribution collectées pourra aller jusqu’à 7 ans
    • Après suppression ou opt-out, les données in-app seront retirées sous 30 jours
    • Les modèles entraînés à partir de ces données seront réentraînés sous 90 jours pour retirer cette contribution

Détails techniques

  • Atlassian distingue les données collectées en deux catégories : métadonnées et données in-app
    • Les métadonnées incluent des signaux désidentifiés
    • Les données in-app incluent du contenu généré par les utilisateurs
  • Détail des éléments inclus dans la catégorie des métadonnées
    • Scores de lisibilité et de complexité
    • Classification des tâches
    • Indicateurs de similarité sémantique
    • Story points
    • Dates de fin de sprint
    • Valeurs de SLA de Jira Service Management
  • Détail des éléments inclus dans la catégorie des données in-app
    • Titres et corps de pages dans Confluence
    • Titres, descriptions et commentaires des tickets Jira
    • Noms d’emojis personnalisés
    • Noms de statuts personnalisés
    • Noms de workflows
  • Atlassian précise l’application, avant l’entraînement, de la suppression des identifiants directs, de l’agrégation des données et d’autres mesures de protection

Paramètres par défaut selon l’offre et exclusions

  • Les paramètres par défaut sont déterminés en fonction de l’offre active la plus élevée de l’organisation
  • Clients Free et Standard

    • Contribution des métadonnées toujours activée

      • Impossible de désactiver la collecte des métadonnées
      • La contribution des données in-app est activée par défaut, mais peut être modifiée
      • Clients Premium
      • Contribution des métadonnées toujours activée
      • La contribution des données in-app est désactivée par défaut
      • Clients Enterprise
      • Les métadonnées et les données in-app sont toutes deux désactivées par défaut
      • Opt-out possible pour les métadonnées
      • Groupes de clients explicitement exclus de l’ensemble de la collecte
      • Clients utilisant les customer-managed encryption keys
      • Clients utilisant Atlassian Government Cloud
      • Clients utilisant Atlassian Isolated Cloud
      • Clients soumis à des obligations HIPAA

Contexte et importance

  • Cette politique marque un changement de cap par rapport à la position précédente
    • Atlassian indiquait auparavant ne pas utiliser les données clients pour l’entraînement ou l’amélioration de services IA
  • Tendance sectorielle avancée pour expliquer ce changement
    • Les fournisseurs SaaS collectent des signaux d’usage interne et des contenus pour amorcer les modèles, les affiner et les évaluer
    • En parallèle, ils promettent aussi des analyses fondées sur la désidentification et l’agrégation
  • Bénéfices concrets mis en avant par Atlassian
    • Amélioration de la pertinence de la recherche
    • Meilleurs résumés
    • Suggestions de modèles
    • Optimisation des workflows agentiques
  • Impact du point de vue des praticiens
    • Évolution de la provenance des données utilisées par les modèles dans les outils de travail
    • Évolution du niveau de contrôle des données selon le prix et des critères de conformité et d’achat

Risques et arbitrages

  • La collecte obligatoire des métadonnées pour les clients non Enterprise suscite des inquiétudes en matière de confidentialité et de gouvernance, indépendamment de la suppression des identifiants
    • Des télémétries comme les story points et les indicateurs SLA peuvent révéler la structure des projets et des schémas de performance
  • La conservation pendant 7 ans de données désidentifiées élargit la surface d’exposition au fil du temps
    • Cela crée une charge supplémentaire pour les clients qui exigent des audits sur la conservation longue durée des données
  • Une voie d’exclusion existe pour les clients à haute sécurité et ceux utilisant des customer-managed keys
    • Mais elle peut nécessiter de passer à une offre plus coûteuse ou à un mode de déploiement spécialisé

Points à surveiller

  • Les organisations doivent vérifier leurs tenants Atlassian
    • Vérifier l’offre active la plus élevée par tenant
    • Identifier les paramètres par défaut de contribution des données
  • Mise à jour nécessaire des paramètres d’administration pendant la période de déploiement
  • Si un opt-out complet est nécessaire, il faut envisager une migration vers Enterprise ou vers un déploiement isolé
  • Points d’attention côté produit
    • Il faudra vérifier comment Atlassian met réellement en œuvre la procédure de réentraînement sous 90 jours
    • Il faudra vérifier si les fournisseurs de LLM en aval utilisés par Rovo affirment ne pas conserver les entrées
  • Si ce modèle se diffuse dans l’ensemble du SaaS d’entreprise, des réactions clients et une surveillance réglementaire sont possibles

Base de l’évaluation

  • Ce changement aura un impact concret pour des milliers d’utilisateurs en entreprise et pour les praticiens chargés de la gouvernance des données et de la gestion de la provenance des modèles
  • Il ne s’agit pas d’un jalon de modèle de pointe ni d’un jalon réglementaire
  • Il est évalué comme un changement de politique produit qui modifie concrètement les pipelines de données des équipes et leurs options de conformité

À lire aussi

1 commentaires

 
GN⁺ 2026-04-21
Réactions sur Hacker News

  • J’ai l’impression qu’Atlassian enchaîne les erreurs. J’utilise encore souvent leurs produits, mais je tombe bien trop fréquemment sur des bugs de niveau P0. Les workers Bitbucket auto-hébergés sont particulièrement obsolètes, surtout côté Docker, au point qu’il a fallu empiler les rustines. Dans JIRA, il faut toujours recharger la page pour réordonner de nouveaux tickets, et ça dure depuis des années. Les nouvelles fonctionnalités ajoutées à JIRA et Bitbucket ces dernières années marchaient elles aussi mal. J’ai aussi testé les fonctions IA via l’essai gratuit, et elles ne marchaient pas du tout ; en plus, impossible de résilier en ligne, j’ai dû ouvrir plusieurs tickets au support, et entre-temps le formulaire de contact du support a lui aussi cassé plusieurs fois. Je me demande si cette gravité croissante des pannes fonctionnelles vient de la dette technique, d’une fuite des talents, ou des deux. Quand on regarde la communauté, on voit des centaines voire des milliers de bugs accompagnés de contournements

    • Pour moi, empêcher la résiliation en ligne d’un essai gratuit ne s’explique que par une tromperie envers le client. Ce serait pourtant très simple à interdire par la loi, mais les pouvoirs publics n’ont pas l’air de s’y intéresser. Atlassian ressemble à une grande entreprise typique qui vend davantage au supérieur hiérarchique de l’utilisateur qu’à l’utilisateur lui-même. J’ai l’impression qu’au-delà d’une certaine taille, quand la pression concurrentielle sur la qualité baisse, la corruption interne et l’incompétence se propagent facilement
    • En tant qu’ancien employé, je dirais que la réponse, c’est un mélange de faible capacité d’ingénierie, de priorités dispersées et de réorganisations sans intérêt. Les pipelines et workers Bitbucket ont en réalité été créés au départ par deux personnes, et il est fort possible qu’une seule les ait véritablement maintenus activement sur les dix dernières années. Avec les licenciements récents, ça a probablement empiré. Ce bureau a désormais même disparu physiquement, et toutes les personnes de l’époque sont parties
    • Pour moi, la cause tient en un mot : Featureitis. On continue d’empiler des fonctionnalités sans réfléchir. Vu l’époque, il est même possible qu’on y ait ajouté du code généré par IA. Même sur des projets de taille moyenne, pousser uniquement de nouvelles fonctions mène à un état similaire ; plusieurs projets que j’ai connus ont pris la même direction, parce que seul comptait le fait de cocher des fonctionnalités dans un backlog gigantesque
    • J’ai toujours trouvé que la recherche de Jira était à un niveau d’inutilité affligeant. C’est peut-être la pire partie de toute la plateforme, et c’est démoralisant de voir qu’ils continuent à se concentrer sur des fonctions que je n’utiliserai jamais
    • En ce moment, je trouve Jira beaucoup trop instable à cause de problèmes de synchronisation. Sur le board de sprint, la fenêtre modale d’un ticket se fermait toute seule et il fallait sans cesse la rouvrir ; récemment encore, un ticket refusait d’apparaître sur le board quoi que je fasse, puis un epic est soudainement apparu plus tard, et ensuite les tickets individuels sont revenus eux aussi. Si c’est ça la valeur ajoutée de ce qu’on appelle le vibe coding, ça laisse songeur

  • J’aimerais pouvoir citer une meilleure source, mais l’essentiel est qu’actuellement les clients gratuits comme payants sont inscrits par défaut à la contribution de leurs données pour l’entraînement de l’IA. Cela couvre tout le contenu, comme les pages Confluence et les tickets Jira. La documentation d’assistance Atlassian explique comment désactiver cela, mais sur nos instances ce réglage n’apparaît tout simplement pas

    • D’après l’annonce reçue par mail, j’ai compris que le réglage d’opt-out serait déployé progressivement dans l’Admin portal à partir de mai. Il sera d’abord appliqué à Jira, Confluence, Jira Service Management et aux applications Atlassian Platform, puis apparaîtra progressivement dans Atlassian Administration jusqu’au 19 mai 2026, avec une nouvelle notification avant le 17 août 2026
    • J’ai fouillé toutes sortes de pages de réglages, y compris Atlassian Administration > Security, mais impossible de trouver la section Data contribution. On en vient donc à se demander si, pour l’instant, l’activation par défaut est automatique alors qu’en pratique il n’existe aucun moyen réel de la désactiver
    • J’ai été choqué par l’étendue décrite dans la FAQ. Sous l’étiquette de contenu généré par l’utilisateur, cela inclut les titres et le corps des pages Confluence, les titres et descriptions des tickets Jira, les commentaires, les noms d’emojis personnalisés, les noms de statuts personnalisés, et même les noms de workflows ; le périmètre est énorme
    • Je m’inquiète de voir des informations sensibles comme les données clients, des tickets privés, des correctifs de CVE sous embargo, ou des données de santé sensibles être mélangées à l’entraînement du modèle puis potentiellement ressortir plus tard chez la mauvaise personne
    • Pour une explication officielle du changement, je pense que le plus direct est de consulter la FAQ Atlassian

  • J’ai vu passer une rumeur selon laquelle Anthropic discuterait d’un rachat d’Atlassian, probablement pour les données d’entraînement. Il y a même un post Reddit qui évoque déjà des mouvements de data poisoning

    • Si c’est vrai, je sais qu’au moins deux entreprises ne pourront plus utiliser les produits Atlassian. Ce serait perçu comme un signal montrant qu’ils prennent beaucoup trop à la légère les exigences de confidentialité et de conformité réglementaire
    • J’ai l’impression qu’après une première phase où l’IA générait du code à partir de code source aspiré sur des plateformes comme GitHub, on entre maintenant dans une phase où elle régénère des documents de spécification aspirés depuis des outils comme Atlassian. On en vient alors à se demander quelle sera la prochaine source : les slogans de mission d’entreprise, voire les éléments de langage destinés à faire de l’argent
    • Si le cours de l’action continue de baisser, un tel rachat pourrait vraiment finir par se produire

  • J’ai l’impression que, dans l’enterprise SaaS, le schéma du collecte par défaut plutôt que du consentement explicite devient de plus en plus normalisé. Mais ici, le problème est particulièrement grave, car il ne s’agit pas seulement de métadonnées : cela couvre tout le contenu des applications, et en plus le réglage d’opt-out ne s’affiche même pas. On peut débattre de la politique elle-même, mais ces deux éléments combinés donnent l’impression d’une friction intentionnellement introduite. Il faut aussi distinguer cela du data residency : beaucoup d’acheteurs assimilent l’ancrage régional à une garantie complète de confidentialité, alors qu’en réalité cela ne concerne que le lieu de stockage, pas qui peut accéder aux données ni dans quel but

    • Ce qui m’a semblé encore plus sournois, c’est la formulation citée dans l’article de The Register selon laquelle, même si l’on résilie le contrat immédiatement, le nouveau réglage de data contribution ne prendra pas effet avant le 17 août 2026. Autrement dit, la structure ne laisse pratiquement même pas le temps d’évaluer de vraies alternatives

  • Je pense que beaucoup d’autres entreprises comme GitHub, Figma, Adobe ou Vercel activent aussi ce type de choses par défaut. Donc, dans la pratique, il vaut sans doute mieux partir du principe que toute entreprise à qui l’on confie ses données peut les utiliser pour l’entraînement de modèles

    • Cette année sera peut-être celle du self-hosted. Je laisse encore dans le cloud les éléments publics pour lesquels la confidentialité compte peu, comme un blog ouvert, mais j’ai déjà rapatrié sur mon propre réseau les données que je ne veux ni voir servir à l’entraînement de modèles ni être revendues pour de la publicité

  • Si la rumeur du rachat par Anthropic est vraie, Atlassian pourrait être vu comme une occasion d’acheter d’un seul coup un jeu de données à fort signal autour du travail en entreprise

    • J’en viens presque à imaginer, sur un ton sarcastique, que Broadcom rachète Atlassian et lui fasse subir le traitement VMware, ce qui réglerait peut-être le problème pour toujours
    • Je ne pense pas que les données présentes chez Atlassian constituent un jeu de données propre ou naturel. Cela ressemble plutôt à un espace conçu de façon infernalement mauvaise, où le travail réel des développeurs se fait engloutir sous toutes sortes de bruit
    • Si cette rumeur n’en est encore qu’au stade des spéculations de forum, je n’y croirai pas avant d’avoir une source fiable. Ça ressemble aussi à une histoire destinée à faire monter le titre avant de s’en délester

  • Je me demande si Atlassian inclut aussi le code et le contenu de dépôts Bitbucket privés dans le périmètre de collecte. La formulation de la politique et de la FAQ est ambiguë, et j’aimerais obtenir une réponse claire par oui ou par non

    • Quand j’avais regardé il y a quelques mois, j’avais compris qu’ils n’utilisaient pas le code des dépôts privés pour entraîner l’IA, mais après cette annonce, je pense de toute façon migrer vers mon propre serveur. Le stockage cloud est pratique, mais vivre avec l’angoisse permanente que quelqu’un vienne s’approprier mes données n’en vaut pas la peine
    • Si la formulation est ambiguë, alors en pratique la réponse est déjà connue

  • Avant, on disait que si l’on ne payait pas, c’est qu’on était le produit. Maintenant, même les entreprises paient pour devenir elles-mêmes le produit, et c’est encore plus absurde

  • Je tiens vraiment à souligner que l’option data residency d’Atlassian ne protège pas contre ce problème. Le fait de lier les données à une région précise n’empêche pas qu’elles soient utilisées pour l’entraînement

  • Du coup, il paraît plus clair encore qu’Atlassian voulait réduire le support de Data Center en mode on-prem