Jira et RGPD : tickets, Rovo et données partagées

Un ticket Jira peut contenir un identifiant client, un extrait de journal ou une pièce jointe RH. L’évaluation doit donc porter sur le contenu et ses copies, pas seulement sur la liste des comptes. En 2026, elle doit aussi intégrer les paramètres de contribution des données d’Atlassian.

Qualifier le déploiement et le contrat

Pour Jira Cloud, examinez les opérations confiées à Atlassian et votre propre rôle : responsable pour vos finalités, éventuellement sous-traitant pour celles d’un client. En auto-hébergement, les accès de support, pièces jointes envoyées au fournisseur, extensions et services connectés restent à analyser. La présence du logiciel sur votre serveur ne prouve pas l’absence de traitement extérieur.

Le DPA Atlassian applicable à partir du 17 août 2026 couvre les produits et les services de support concernés. Ses sections 1–2 distinguent client responsable ou sous-traitant et instructions documentées. Les sections 4 et 7 organisent les changements de sous-traitants et les audits, avec des modalités et limites à confronter à votre besoin. L’annexe 1 distingue également certaines activités propres d’Atlassian. Archivez le texte applicable à votre contrat et ses annexes.

L’Art. 28(3) impose notamment instructions, confidentialité, assistance et informations de contrôle. Un DPA publié ne vaut pas validation de tous vos usages. Consultez notre méthode d’audit prestataire pour consigner les pièces examinées et les questions non résolues. RGPD, chapitre IV.

Réduire les données dans les tickets

Pour chaque projet, identifiez la finalité et les personnes concernées. Une file d’attente technique ne constitue pas automatiquement un traitement distinct : le registre doit décrire les activités de traitement de façon cohérente avec l’Art. 30(1). Plusieurs files peuvent servir la même finalité ; un projet unique peut au contraire réunir des usages très différents.

L’Art. 5(1)(c) impose de limiter les données au nécessaire. Avant d’ajouter un journal, retirez les secrets, identifiants inutiles et détails personnels sans rapport avec le problème. Une pseudonymisation conserve généralement un caractère personnel ; elle ne doit pas être présentée comme une anonymisation garantie. RGPD, chapitre II.

Exemple hypothétique : un incident de livraison concerne un client identifié. Le ticket de développement peut décrire le scénario avec une référence interne et des données fictives, tandis que les coordonnées restent dans l’outil de support accessible aux seules personnes chargées de répondre. Le développeur obtient l’information utile sans recevoir tout le dossier.

Vérifier accès, intégrations et notifications

Contrôlez les permissions réellement obtenues par un membre, un invité et un compte technique. Un projet confidentiel ne doit pas dépendre du seul fait que son nom est peu visible. Vérifiez les recherches, tableaux de bord, pièces jointes, exports et notifications automatiques.

Atlassian propose aujourd’hui Guard ; le nom Access encore présent dans certaines anciennes procédures a été remplacé. Les fonctionnalités et licences doivent être comparées à vos exigences, sans affirmer qu’un abonnement précis constitue en lui-même une obligation RGPD. Documentation Atlassian sur Guard.

Les applications Marketplace et les intégrations ont leur propre périmètre. Une notification vers Slack, un export vers un outil de reporting ou une application d’assistance peut reproduire les données du ticket. Recensez le destinataire, ses permissions et la procédure de suppression de ses copies. Un retrait de l’intégration ferme un accès futur sans démontrer à lui seul un effacement passé.

Localisation : couvrir le contenu, les applications et les sauvegardes

La documentation Atlassian de résidence distingue les données pouvant être fixées dans une région des éléments hors périmètre. Jira, Rovo et les applications Marketplace ne doivent pas être supposés partager automatiquement un engagement unique.

Examinez également Atlassian Backup and Restore : la documentation précise que les nouvelles sauvegardes suivent le périmètre de résidence pris en charge depuis le 28 avril 2026, tandis que les anciennes ne sont pas automatiquement déplacées lors d’un changement de région. Conservez l’historique utile à votre décision.

Les accès et destinataires hors EEE restent soumis au chapitre V. Le mécanisme invoqué doit couvrir l’entité et l’opération effectives ; la localisation du siège d’un groupe ne suffit pas à décrire tous ses flux. Les Art. 44–46 et le guide CNIL d’analyse des transferts fournissent le cadre. RGPD, chapitre V.

Revoir Rovo et la contribution des données

Atlassian décrit Rovo comme utilisant des modèles hébergés en interne et par des prestataires tiers. Ses engagements de non-entraînement par les fournisseurs tiers ne signifient pas que les données restent toujours dans votre instance. Les contrôles disponibles et les modèles utilisés doivent être vérifiés pour l’offre concernée. Centre de confiance IA Atlassian.

Depuis le 17 août 2026, Atlassian décrit aussi une utilisation de données contribuées, dé-identifiées et agrégées, pour améliorer ses applications et expériences. Cette contribution est distincte du traitement d’une requête Rovo. FAQ officielle sur la contribution.

Les paramètres de contribution dépendent du plan actif le plus élevé de l’organisation, essais compris. Selon le tableau général, la contribution du contenu est activée par défaut en Free/Standard et désactivée en Premium/Enterprise ; les possibilités de désactiver les métadonnées diffèrent. Des situations particulières peuvent présenter d’autres valeurs.

Relevez les paramètres réels, les espaces inclus et les connecteurs concernés. Évaluez la compatibilité avec les instructions des clients et l’information des personnes. Vérifiez de nouveau après un changement d’offre : un réglage conservé dans une ancienne capture peut ne plus décrire votre situation.

Organiser conservation, droits et incidents

Définissez une durée selon l’usage : suivi courant d’un incident, dossier RH, preuve de résolution ou contentieux. Fermer un ticket ne prouve pas sa suppression. Intégrez commentaires, pièces jointes, historiques, exports et sauvegardes à la procédure.

Pour une demande d’accès, cherchez les identifiants pertinents et vérifiez le périmètre des résultats. Une recherche JQL ne doit pas être présumée retrouver chaque donnée dans les fichiers et systèmes liés. Protégez les droits des tiers dans la réponse, conformément à l’Art. 15(4), sans refuser globalement l’accès pour ce seul motif. La méthode de réponse au droit d’accès complète ce travail. RGPD, chapitre III.

Le sous-traitant alerte sans délai indu selon l’Art. 33(2). Le responsable apprécie ses propres obligations de notification ; une page de statut publique ne remplace pas une procédure d’incident. Une AIPD est obligatoire avant un traitement susceptible d’engendrer un risque élevé, Art. 35(1). La fiche de revue des changements du registre aide à relier ces décisions aux évolutions du service.

Grille d’audit d’un espace Jira

Cette grille sert de point de départ pour une revue trimestrielle. Elle ne remplace ni votre registre ni l’analyse de votre contrat Atlassian.

Pour la durée, appuyez-vous sur la logique de nos repères sur la conservation des données personnelles : une durée se justifie par la finalité, pas par la commodité de l’outil.

Cas où vous traitez les données de vos clients dans Jira

Exemple hypothétique : une société de services informatiques utilise Jira comme outil de support pour ses clients. Elle reçoit dans les tickets des extraits de bases de données, des noms d’utilisateurs finaux et des journaux d’application. Pour ces données, elle agit en principe comme sous-traitante de ses clients et Atlassian devient sous-traitant ultérieur. Elle doit alors respecter les instructions de chaque client, obtenir l’autorisation requise pour recourir à un sous-traitant ultérieur (Art. 28(2) et 28(4)) et répercuter sur Atlassian des obligations équivalentes. Si elle active la contribution des données ou un assistant d’IA sans en informer ses clients, elle risque d’agir hors instructions, ce qui expose à l’Art. 28(10) : le sous-traitant qui détermine finalités et moyens est considéré comme responsable du traitement pour ce traitement.

Concrètement : listez les clients dont les données entrent dans Jira, vérifiez ce que leurs contrats autorisent en matière de sous-traitance ultérieure et d’IA, puis alignez les réglages. Notre article sur l’article 28 du RGPD détaille le contenu du contrat de sous-traitance, et les clauses contractuelles types précisent le cadre des transferts lorsqu’ils sont nécessaires. Pour les flux vers les États-Unis, vérifiez le statut de l’importateur au regard du Data Privacy Framework et conservez la date de votre vérification.

Erreurs fréquentes

• Considérer la sécurité comme déjà réglée par l’éditeur. L’Art. 32 pèse aussi sur vous pour la configuration : permissions, authentification forte, revue des comptes inactifs. Voir notre analyse de l’article 32 du RGPD.
• Laisser des invités sur d’anciens projets. Les comptes d’intervenants externes survivent souvent à la mission.
• Joindre des extraits de production non nettoyés. Une capture d’écran de back-office suffit à diffuser des données de clients dans un outil de développement.
• Oublier la mise à jour du registre. L’activation d’une fonction d’IA ou d’une nouvelle application est un changement à documenter ; la revue des changements du registre donne une méthode.
• Ne pas dater les captures de paramètres. Les paramètres d’un fournisseur évoluent ; une preuve sans date prouve peu.

Ce qu’il faut retenir

• Évaluez les tickets, les pièces jointes et les intégrations, en plus des comptes.
• L’auto-hébergement n’exclut pas les flux de support ou de services connectés.
• Résidence, Rovo et contribution des données correspondent à des périmètres distincts.
• Documentez les réglages réels et leur évolution après un changement d’offre.
• Si vous traitez les données de clients, vérifiez que la contribution des données et les fonctions d’IA respectent leurs instructions (Art. 28).
• Conservez des preuves datées : captures de paramètres, inventaire des applications, résultat des revues.

FAQ

Un abonnement Guard garantit-il la conformité ?

Non. Il peut fournir des contrôles utiles ; leur nécessité et leur configuration dépendent des risques et des usages.

Supprimer le compte efface-t-il les données de la personne dans Jira ?

Il faut examiner aussi les tickets, commentaires, pièces jointes et copies externes. La procédure doit distinguer données à effacer et éléments conservés pour une obligation ou un motif justifié.

Le non-entraînement des modèles tiers couvre-t-il toute réutilisation ?

Non. Examinez séparément les paramètres de contribution des données et les finalités annoncées par Atlassian.

Faut-il informer ses clients avant d’activer Rovo ou la contribution des données ?

Si vous traitez leurs données en qualité de sous-traitant, vos instructions viennent d’eux : vérifiez ce que le contrat autorise avant toute activation, et informez-les si le contrat ou l’Art. 28(2) l’exige. Dans le doute, demandez une autorisation écrite.

À quelle fréquence revoir ses réglages Jira ?

Aucun texte ne fixe une fréquence. Une revue trimestrielle, et une revue à chaque changement d’offre ou d’application, constituent un repère raisonnable, à adapter au niveau de risque.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.