Jira et RGPD : guide de conformite 2026

Jira (Atlassian) est l’outil de référence pour le suivi de tickets, la gestion de projet agile et la gestion des services informatiques (ITSM) dans les équipes techniques françaises. Des startups aux grandes entreprises, Jira est utilisé par les équipes de développement, les équipes produit, le support informatique et, de plus en plus, par des équipes non-techniques. Cette généralisation pose une question de conformité RGPD que la plupart des organisations sous-estiment : les tickets Jira contiennent souvent des données personnelles que personne n’a documentées.

Un ticket de bug peut contenir un stack trace avec des adresses email d’utilisateurs. Un ticket de support IT peut décrire le problème d’un collaborateur identifié. Un ticket de recrutement dans Jira Service Management peut contenir le CV et les coordonnées d’un candidat. L’analyse RGPD de Jira ne peut pas se limiter aux profils utilisateurs : elle doit intégrer le contenu des tickets, des commentaires et des pièces jointes.

Pour une vue d’ensemble de la conformité des outils SaaS, consultez notre guide RGPD par outil. Voir également nos analyses d’Asana et de Monday.com, deux alternatives à Jira pour la gestion de projet.

Qualification juridique : Jira comme sous-traitant

Le statut de sous-traitant au sens de l’article 28

Atlassian Corporation agit en qualité de sous-traitant au sens de l’article 28 du RGPD pour Jira Cloud. Votre organisation détermine les finalités du traitement (suivi de projets, gestion des incidents, gestion des services IT) et les moyens essentiels (quels projets sont créés, quels utilisateurs y accèdent, quelles données y sont saisies). Atlassian fournit l’infrastructure technique et traite les données selon vos instructions.

Pour Jira Data Center (version auto-hébergée), Atlassian n’est pas sous-traitant au sens du RGPD puisque les données restent sur votre infrastructure. La qualification de sous-traitant ne s’applique qu’à Jira Cloud.

Les catégories de données traitées

Jira traite plusieurs catégories de données personnelles :

• Profils utilisateurs : noms, adresses email, photos de profil, fuseau horaire, préférences
• Contenu des tickets : descriptions, commentaires, pièces jointes. C’est ici que se trouve le risque principal – les tickets peuvent contenir n’importe quelle donnée personnelle
• Métadonnées d’activité : qui a créé, modifié, commenté ou résolu un ticket, avec horodatage
• Données de recherche et de filtre : requêtes enregistrées, tableaux de bord personnalisés
• Données de Jira Service Management : demandes de service contenant potentiellement des données personnelles d’employés ou de clients

Le cas d’Atlassian Intelligence (IA)

Atlassian Intelligence utilise des modèles de langage pour assister les utilisateurs (résumé de tickets, suggestions, recherche en langage naturel). Selon la documentation d’Atlassian, cette fonctionnalité est opt-in (activation par l’administrateur), les données sont traitées au sein de l’instance, et les données ne sont pas utilisées pour l’entraînement des modèles. L’activation d’Atlassian Intelligence doit néanmoins être documentée dans le registre des traitements et faire l’objet d’une évaluation spécifique.

Analyse du DPA Atlassian

Le Data Processing Addendum (DPA) d’Atlassian couvre l’ensemble des produits cloud Atlassian, dont Jira Cloud, Confluence et Jira Service Management. Voici l’analyse au regard de l’article 28 du RGPD.

Exigence Art. 28 RGPD	Couverture dans le DPA Atlassian	Évaluation
Objet, durée, nature et finalité du traitement	Définis dans le DPA et les conditions de service	Conforme
Types de données et catégories de personnes	Décrits dans l’annexe au DPA	Conforme
Instructions documentées du responsable	Traitement sur instructions documentées	Conforme
Confidentialité du personnel	Engagement de confidentialité pour le personnel Atlassian	Conforme
Mesures de sécurité (Art. 32)	Mesures techniques et organisationnelles dans l’annexe sécurité	Conforme
Sous-traitants ultérieurs	Liste publiée avec mécanisme de notification et d’objection (30 jours)	Conforme
Assistance pour les droits des personnes	Engagement d’assistance dans le DPA	Conforme
Suppression ou restitution en fin de contrat	Suppression des données après résiliation (délai de grâce pour l’export)	Conforme
Droit d’audit	Prévu dans le DPA (via rapports SOC 2, ISO 27001 et possibilité d’audit)	Conforme
Information en cas d’instruction contrevenant au RGPD	Prévu dans le DPA	Conforme

Le DPA d’Atlassian est un document mature et régulièrement mis à jour. Le point fort est la transparence sur les sous-traitants ultérieurs, avec une liste publique et un mécanisme d’objection de 30 jours en cas de changement. Le DPA couvre l’ensemble de la gamme Atlassian Cloud, ce qui simplifie la gestion contractuelle si vous utilisez également Confluence ou Bitbucket.

Transferts internationaux et analyse d’impact sur les transferts (TIA)

Localisation de l’entreprise et des données

Atlassian Corporation est une société australienne basée à Sydney, avec des opérations significatives aux États-Unis (San Francisco). L’Australie ne dispose pas de décision d’adéquation de la Commission européenne, ce qui est un point à documenter.

Pour Jira Cloud, les données sont hébergées sur AWS dans plusieurs régions, dont l’UE (Francfort, Dublin). Atlassian propose une fonctionnalité de résidence des données permettant de fixer la localisation des données dans l’UE ou aux États-Unis.

Il faut distinguer :

• Données de contenu (tickets, pièces jointes, commentaires) : peuvent être fixées dans l’UE via la résidence des données
• Données de compte Atlassian : peuvent rester aux États-Unis ou en Australie
• Métadonnées de service : certaines métadonnées opérationnelles peuvent être traitées en dehors de l’UE

Mécanismes de transfert

Pour les transferts hors UE, Atlassian s’appuie sur :

1. EU-US Data Privacy Framework (DPF). Atlassian est certifié au DPF pour ses opérations américaines.

2. Clauses contractuelles types (CCT). Le DPA intègre les CCT 2021 comme mécanisme de transfert, couvrant les transferts vers les États-Unis et l’Australie.

Conduite de la TIA

Les éléments à évaluer :

• Cadre juridique. États-Unis : FISA Section 702, EO 12333, avec les garanties de l’EO 14086 dans le cadre du DPF. Australie : Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018 (TOLA), qui confère aux autorités des pouvoirs d’accès aux données chiffrées.
• Nature des données. Les tickets Jira contiennent des données de nature variable : de l’information technique impersonnelle à des données personnelles de clients ou d’employés. La sensibilité dépend de l’usage fait de Jira dans l’organisation.
• Mesures supplémentaires. Chiffrement en transit et au repos. Résidence des données dans l’UE pour le contenu. Les CCT et le DPF couvrent les transferts résiduels.

Sécurité informatique

Atlassian a développé un programme de sécurité ambitieux, bénéficiant de son positionnement auprès des équipes de développement et de sécurité.

Certifications et audits

• SOC 2 Type II – audit indépendant des contrôles de sécurité
• ISO 27001 – certification du système de management de la sécurité
• ISO 27018 – protection des données personnelles dans le cloud

Mesures techniques

• Chiffrement en transit : TLS 1.2+ pour toutes les communications
• Chiffrement au repos : AES-256 via AWS KMS
• Authentification : SSO SAML 2.0, SCIM pour le provisionnement automatique, MFA obligatoire via Atlassian Access
• Gestion des permissions : permissions granulaires par projet, par type de ticket, par champ
• Journalisation : journal d’audit des actions administratives et des accès (via Atlassian Access)
• Résidence des données : fixation de la localisation des données dans l’UE
• Atlassian Access : couche de sécurité et de gouvernance centralisée pour l’ensemble des produits Atlassian Cloud

Mesures organisationnelles

• Programme de gestion des vulnérabilités
• Programme de bug bounty
• Tests de pénétration réguliers (rapports publiés)
• Notification des incidents de sécurité (page de statut publique et notification DPA)

Le niveau de sécurité d’Atlassian est solide. Atlassian Access (abonnement supplémentaire) est indispensable pour les organisations souhaitant un contrôle centralisé de la sécurité et de la conformité sur l’ensemble des produits Atlassian.

Configuration recommandée pour la conformité RGPD

1. Activer la résidence des données dans l’UE. Dans les paramètres d’administration de Jira Cloud, activez la résidence des données dans l’UE. Cette fonctionnalité fixe la localisation des données de contenu (tickets, pièces jointes) dans les centres de données européens d’AWS.

2. Signer et archiver le DPA. Acceptez le DPA d’Atlassian disponible en ligne. Conservez une copie datée. Le DPA couvre l’ensemble des produits Atlassian Cloud utilisés.

3. Déployer Atlassian Access. Cet abonnement supplémentaire fournit le SSO SAML, le SCIM, le MFA obligatoire et les journaux d’audit. Il est indispensable pour une utilisation conforme de Jira Cloud en entreprise.

4. Évaluer et configurer Atlassian Intelligence. Si vous activez Atlassian Intelligence, documentez ce traitement dans votre registre et informez les utilisateurs. Si les tickets Jira contiennent des données personnelles sensibles, évaluez si l’activation de l’IA est compatible avec votre politique RGPD.

5. Auditer le contenu des projets Jira. C’est l’étape la plus importante et la plus souvent négligée. Passez en revue les projets Jira pour identifier ceux qui contiennent des données personnelles : tickets de support avec données clients, tickets de recrutement, tickets IT avec données d’employés. Documentez ces traitements dans votre registre des traitements.

6. Structurer les permissions par projet. Configurez les schémas de permission pour restreindre l’accès aux projets contenant des données personnelles. Un développeur backend n’a pas besoin d’accéder au projet de recrutement, et le recruteur n’a pas besoin de voir les tickets de production.

7. Définir des politiques de rétention. Les tickets Jira sont conservés indéfiniment par défaut. Pour les projets contenant des données personnelles, définissez une politique de durée de conservation et prévoyez une procédure de purge périodique. L’automatisation via l’API Jira ou des plugins peut faciliter cette tâche.

8. Sensibiliser les équipes techniques. Les développeurs ont tendance à coller des stack traces, des logs et des extraits de bases de données dans les tickets de bug. Ces données peuvent contenir des adresses email, des noms d’utilisateurs, des identifiants. Formez les équipes à anonymiser ou pseudonymiser les données avant de les coller dans un ticket.

9. Configurer les champs personnalisés avec discernement. Les champs personnalisés Jira permettent de structurer les données, mais ils augmentent aussi la surface de collecte de données personnelles. Évaluez chaque champ personnalisé au regard du principe de minimisation des données.

10. Mettre en place une procédure de réponse aux droits. Prévoyez comment retrouver et extraire les données personnelles d’une personne dans Jira : tickets créés, commentaires, pièces jointes. L’API Jira et la fonctionnalité de recherche JQL permettent d’automatiser cette extraction.

Points d’attention spécifiques

Les données personnelles cachées dans les tickets techniques

C’est le risque RGPD le plus sous-estimé de Jira. Les équipes de développement collent régulièrement dans les tickets des extraits de logs, des stack traces, des requêtes SQL, des dumps de bases de données pour documenter des bugs. Ces extraits contiennent fréquemment des données personnelles : adresses email, noms d’utilisateurs, adresses IP, parfois des mots de passe ou des tokens d’authentification. Ce traitement est rarement documenté dans le registre des traitements, et les données sont conservées indéfiniment dans l’historique des tickets.

La solution est double : sensibiliser les équipes à l’anonymisation des données avant insertion dans les tickets, et mettre en place des politiques de rétention pour les projets techniques.

Jira Service Management et les données RH/IT

Jira Service Management (anciennement Jira Service Desk) est de plus en plus utilisé comme portail de service interne pour les demandes IT, les demandes RH, les demandes de matériel, les demandes d’accès. Ces tickets contiennent des données personnelles d’employés : identité, poste, équipement attribué, problèmes techniques rencontrés. Chaque file d’attente de service constitue un traitement qui doit être documenté.

L’absence de décision d’adéquation pour l’Australie

Atlassian est une société australienne, et l’Australie ne bénéficie pas d’une décision d’adéquation de la Commission européenne. Les transferts de données vers l’Australie sont couverts par les CCT dans le DPA d’Atlassian. Votre TIA doit cependant évaluer le cadre juridique australien, et notamment le TOLA (Telecommunications and Other Legislation Amendment Act 2018), qui confère aux autorités la possibilité de demander l’accès à des communications chiffrées.

Les notifications Jira transitant par Slack ou d’autres outils de messagerie constituent un traitement supplémentaire – les données de tickets (noms, descriptions) sont répliquées dans un second outil.

FAQ

Jira est-il conforme au RGPD ?

Jira Cloud fournit les éléments contractuels et techniques nécessaires à une utilisation conforme : DPA Atlassian, résidence des données UE, certifications SOC 2, ISO 27001, ISO 27018, chiffrement, SSO/MFA via Atlassian Access. La conformité effective dépend de votre configuration et surtout de la gestion du contenu des tickets. Si des données personnelles sont collées dans les tickets sans contrôle, aucune mesure technique ne compensera cette lacune organisationnelle.

La résidence des données Jira garantit-elle la conformité ?

Non, la résidence des données fixe la localisation du contenu (tickets, pièces jointes) dans l’UE, ce qui réduit l’exposition aux transferts internationaux. Mais certaines métadonnées et données de compte peuvent être traitées en dehors de l’UE. Par ailleurs, la résidence des données ne résout pas les questions de durée de conservation, de gestion des droits ou de documentation des traitements. C’est une mesure nécessaire mais non suffisante.

Faut-il réaliser une AIPD pour Jira ?

Une analyse d’impact est recommandée si Jira est utilisé pour des traitements systématiques impliquant des données personnelles à grande échelle : gestion des services IT pour un grand nombre d’employés, suivi de recrutement, gestion de projets impliquant des données clients. Pour un usage standard de gestion de projet technique sans données personnelles significatives, l’AIPD n’est pas formellement requise.

Comment supprimer les données d’une personne dans Jira ?

Atlassian propose des fonctionnalités de gestion des comptes utilisateurs (suppression, anonymisation). Pour les données présentes dans le contenu des tickets (commentaires, descriptions, pièces jointes), il faut utiliser la recherche JQL pour identifier les tickets concernant une personne, puis modifier ou supprimer manuellement le contenu. Pour les requêtes d’effacement à grande échelle, l’API REST de Jira permet d’automatiser la recherche et la modification. Documentez la procédure et prévoyez un délai de traitement raisonnable.