ZDR de Rovo : ce que cela change après le 17 août 2026

Dans le contexte de Rovo, le ZDR signifie que les fournisseurs de modèles de langage utilisés par Atlassian ne conservent pas vos données d’entrée et de sortie, et ne les utilisent pas pour entraîner ou améliorer leurs services.

« The LLM providers we use do not retain your inputs and outputs, or use them to improve their services. »

Autrement dit, lorsqu’un utilisateur interroge Rovo Chat, Rovo Search ou un agent Rovo, les données sont traitées pour produire une réponse, mais pas conservées par le fournisseur LLM tiers.

Le fonctionnement de Rovo repose sur un circuit relativement clair :

La documentation Atlassian précise que Rovo peut s’appuyer sur plusieurs types de modèles :

Atlassian utilise donc une architecture multi-modèles pour choisir le meilleur traitement selon le cas d’usage.

Le ZDR de Rovo couvre les éléments suivants :

« Customer data, including data submitted to or generated by Rovo and Atlassian Intelligence, is never used to train, fine-tune, or improve AI models or services. »

Le terme « Zero Data Retention » peut prêter à confusion. Il ne signifie pas :

• qu'Atlassian ne stocke absolument rien ;
• qu'aucune journalisation n'existe ;
• que tout le contenu connecté à Rovo disparaît instantanément après chaque requête ;
• que tous les flux de données Atlassian sont couverts par la même promesse.

« For Chat and agents, we retain your inputs and outputs for 30 days for safety and security purposes. »

Donc :

Le ZDR n’est qu’une partie du dispositif global. Rovo s’appuie aussi sur plusieurs garde-fous complémentaires.

Rovo respecte les permissions des produits Atlassian et des connecteurs tiers. Un utilisateur ne voit en principe que ce qu’il est déjà autorisé à voir dans les systèmes sources.

Quand une application tierce est déconnectée, Atlassian indique que le contenu indexé depuis cette source est supprimé dans un délai pouvant aller jusqu’à 30 jours.

Rovo supporte la résidence des données pour plusieurs catégories de données. Cela améliore le contrôle géographique du stockage, même si cela ne doit pas être confondu avec le ZDR.

Pour les organisations ayant des exigences élevées, Atlassian propose une option Atlassian-hosted LLMs. Lorsqu’elle est activée, les prompts et le contexte ne sont plus envoyés vers des LLM externes. Le traitement se fait alors dans la frontière cloud Atlassian.

Avant le 17 août 2026, le message est relativement simple :

• vous utilisez Rovo ;
• les fournisseurs LLM ne retiennent pas les inputs/outputs ;
• vos données ne sont pas utilisées pour entraîner les modèles dans le cadre de cet usage ;
• Atlassian conserve certains échanges pendant 30 jours pour des raisons de sécurité ;
• le ZDR est donc la règle de fonctionnement pour le flux d'usage standard de Rovo.

Pour beaucoup d’organisations, c’est ce point qui a servi de base de confiance pour envisager l’adoption de Rovo.

À partir du 17 août 2026, Atlassian commencera à utiliser, selon vos réglages d’administration, certaines données issues de vos produits cloud pour améliorer ses apps et expériences AI pour tous les clients.

Cela concerne deux familles de données :

• Metadata : signaux dé-identifiés et agrégés, comme des scores de lisibilité, story points, classifications, métriques SLA et patterns fréquents.
• In-app data : contenu réel créé par les utilisateurs, comme les titres, descriptions, commentaires, noms de workflows ou contenus de pages.

Beaucoup de lecteurs entendent « Rovo est en ZDR », puis « Atlassian va utiliser des données client pour améliorer son AI », et pensent qu’il y a contradiction.

En réalité, les deux affirmations peuvent être vraies en même temps :

• Flux A : usage de Rovo → ZDR côté fournisseurs LLM, pas d'usage pour entraînement dans ce cadre. Inchangé après le 17 août.
• Flux B : Data Contribution → certaines données peuvent être utilisées par Atlassian selon vos réglages pour améliorer les apps et expériences AI. Nouveau à partir du 17 août.

C’est exactement cette coexistence qu’il faut expliquer clairement dans toute communication interne, note DPO, ou article de gouvernance AI.

La première action recommandée est de vérifier les réglages dans Atlassian Administration → Security → Data contribution.

Sur tous les plans, il est possible d’agir au moins sur l’in-app data. C’est la catégorie la plus sensible car elle correspond au contenu réel produit dans Jira, Confluence et autres apps concernées.

Quelle que soit la taille ou le secteur, la priorité est de vérifier l’état des réglages avant le 17 août 2026 et de s’assurer que la décision de contribuer ou non les données est explicite et documentée, pas le résultat d’une configuration par défaut passée inaperçue.

La contribution des metadata n’est pas désactivable selon la documentation actuelle. En revanche, l’in-app data peut être désactivé.

Le contrôle est plus large, car il est possible de gérer à la fois les metadata et l’in-app data. C’est l’option la plus adaptée pour les organisations qui veulent une gouvernance fine.

Le sujet ne doit pas être traité uniquement comme une question produit. Il faut aussi l’examiner sous l’angle :

• de la protection des données ;
• de la résidence des données ;
• des sous-traitants impliqués ;
• du rôle d'Atlassian comme processeur ou responsable de traitement selon le flux concerné.

L’un des points qui surprend le plus dans la documentation Atlassian concerne la durée de conservation pouvant aller jusqu’à 7 ans. Il faut être très précis : cela ne vise pas les données brutes identifiables en tant que telles.

Atlassian indique que :

« Data that is de-identified and aggregated at a customer level such that it is no longer associated with individual customers (including common patterns), may be retained for up to seven years. »

Autrement dit, ce qui peut être conservé jusqu’à 7 ans correspond à des données dé-identifiées et agrégées, notamment des patterns communs. Ce point relève du mécanisme de Data Contribution, pas du ZDR de l’usage standard de Rovo.

Pour les organisations qui souhaitent réduire au maximum le risque que leurs données soient utilisées dans le cadre de la Data Contribution, la bonne approche consiste à traiter le sujet comme un chantier de gouvernance : vérifier les réglages, documenter les décisions, impliquer les bonnes parties prenantes et suivre les évolutions contractuelles d’Atlassian.

La mesure la plus importante est de vérifier le paramètre In-app data contribution dans Atlassian Administration → Security → Data contribution.

L’in-app data correspond au contenu le plus sensible : titres et contenus de pages Confluence, titres, descriptions et commentaires de tickets Jira, noms de workflows, statuts personnalisés, etc. Selon la documentation Atlassian, tous les clients, sur tous les plans, peuvent désactiver la contribution de l’in-app data.

Les possibilités de contrôle dépendent du plan le plus élevé actif dans l’organisation Atlassian.

Atlassian permet d’inclure ou d’exclure certaines données d’apps, d’espaces ou de connecteurs Teamwork Graph. Cette granularité est utile, mais elle peut aussi créer des exceptions difficiles à suivre.

Une bonne pratique consiste à adopter une règle simple : désactivation par défaut, puis inclusion uniquement des espaces ou apps explicitement validés. Cela évite qu’un espace contenant des informations sensibles soit inclus par erreur.

• Identifier les espaces Confluence sensibles : RH, finance, juridique, sécurité, direction, clients stratégiques.
• Identifier les projets Jira sensibles : incidents de sécurité, support client, données réglementées, projets confidentiels.
• Vérifier les connecteurs Teamwork Graph : Slack, Google Drive, SharePoint, Notion, Asana, Miro ou autres sources connectées.
• Documenter chaque exception : propriétaire, raison, date de validation et date de revue.

Les réglages de Data Contribution ne doivent pas être vérifiés une seule fois. Atlassian précise que les nouvelles apps ajoutées à une organisation suivent les réglages existants, avec un délai de 30 jours avant utilisation des données de la nouvelle app. Les changements de plan peuvent aussi modifier les possibilités de contrôle, notamment en cas de passage d’Enterprise vers un plan inférieur.

Il est donc recommandé de mettre en place une revue régulière :

• revue initiale avant le 17 août 2026 ;
• revue après chaque ajout d'app Atlassian ou de connecteur ;
• revue après tout changement de plan ;
• revue trimestrielle ou semestrielle par l'équipe admin, sécurité ou conformité.

Pour les organisations européennes ou soumises au RGPD, la Data Contribution ne doit pas être traitée uniquement comme un réglage technique. Elle peut impliquer des questions de base légale, de rôle d’Atlassian, de sous-traitance, de résidence des données et de conservation.

Les clients devraient donc impliquer :

L’objectif n’est pas de bloquer toute utilisation de Rovo, mais de prendre une décision consciente, documentée et alignée avec le niveau de risque de l’organisation.

Pour les clients ayant des exigences fortes de conformité, certaines questions doivent être clarifiées directement avec Atlassian, idéalement par écrit :

• La résidence des données exclut-elle ou non les données des pipelines de Data Contribution ?
• Quels sous-traitants peuvent recevoir ou traiter les données contribuées ?
• Dans quels pays ces traitements peuvent-ils avoir lieu ?
• Quelle est la base légale utilisée par Atlassian pour ce traitement ?
• Comment Atlassian documente-t-il la dé-identification, l'agrégation et la conservation jusqu'à 7 ans des patterns communs ?

La meilleure protection reste la minimisation des données. Même avec de bons réglages, Jira et Confluence ne devraient pas devenir des dépôts incontrôlés de données sensibles.

Quelques règles utiles :

• Éviter de stocker des données de santé, financières, secrets industriels ou données personnelles sensibles dans des champs libres.
• Utiliser des espaces ou projets dédiés avec permissions strictes lorsque ces données sont nécessaires.
• Limiter les pièces jointes sensibles.
• Mettre en place des règles de classification ou de nommage.
• Former les utilisateurs à ne pas coller de données confidentielles dans les prompts Rovo ou dans des pages ouvertes trop largement.

Le ZDR de Rovo et les réglages de Data Contribution Atlassian ne couvrent pas automatiquement les applications Marketplace tierces ni les outils externes connectés. Chaque app peut avoir ses propres conditions, ses propres sous-traitants et ses propres politiques d’AI ou de rétention.

Les clients devraient maintenir un inventaire des apps et vérifier régulièrement :

• si l'app utilise de l'AI ou des LLM ;
• si elle envoie des données hors de l'environnement Atlassian ;
• si elle utilise les données client pour entraîner ou améliorer des modèles ;
• sa politique de rétention de données.

Prendre une capture d’écran ou exporter les réglages depuis Atlassian Administration → Security → Data contribution est une bonne pratique de base. En cas de question interne ou d’audit externe, vous disposez d’une preuve datée de votre configuration.

Il est recommandé de :

• documenter les réglages avant le 17 août 2026, puis après chaque modification ;
• conserver ces preuves dans un espace de documentation sécurisé, accessible à l'équipe conformité ;
• horodater chaque capture avec la date, le plan en vigueur et le nom de l'administrateur responsable.

• Le ZDR de Rovo est réel : les fournisseurs LLM ne retiennent pas les inputs/outputs et ne les utilisent pas pour entraîner leurs modèles.
• Atlassian conserve néanmoins certains échanges pendant 30 jours pour la sécurité des fonctions Chat et Agents.
• Le ZDR ne signifie pas zéro stockage partout, mais zéro rétention côté fournisseurs LLM dans le flux standard d'usage.
• À partir du 17 août 2026, le ZDR reste valable pour l'usage de Rovo.
• Ce qui change après cette date, c'est l'activation d'un mécanisme séparé de Data Contribution permettant à Atlassian d'utiliser certaines données pour améliorer ses apps et expériences AI selon vos réglages.
• Le vrai risque de confusion consiste à mélanger ces deux flux alors qu'ils répondent à des logiques différentes.

Le ZDR de Rovo reste un argument fort de confiance : dans le fonctionnement standard du produit, les fournisseurs de LLM n’ont pas le droit de conserver vos prompts et vos réponses ni de les utiliser pour entraîner leurs services. C’est le cœur de la promesse de confidentialité de Rovo.

Mais après le 17 août 2026, parler uniquement du ZDR ne suffira plus. Il faudra systématiquement expliquer qu’il existe désormais un avant/après dans la gouvernance des données : non pas parce que le ZDR de Rovo est remis en cause, mais parce qu’Atlassian a introduit un mécanisme parallèle de Data Contribution qui peut permettre à Atlassian d’utiliser certaines données à l’amélioration de ses produits AI.

La bonne lecture est donc la suivante : avant, le ZDR décrivait presque à lui seul la logique de traitement AI visible pour l’utilisateur Rovo ; après, il faudra distinguer clairement usage de Rovo et Data Contribution.