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.

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.

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.

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.