Votre équipe conformité a posé la question. Peut-être même bloqué le projet. “Est-ce que migrer Jira et Confluence vers le Cloud est compatible avec DORA ? Avec le RGPD ? Avec Solvency II ?”
La réponse courte : oui. La réponse utile : pas automatiquement, et pas sans travail de cadrage spécifique. Cet article détaille ce que chaque réglementation exige réellement dans le contexte d’une migration Atlassian, ce qu’Atlassian Cloud couvre nativement, et ce que votre organisation doit adresser elle-même.
L’incertitude réglementaire bloque les migrations
Dans les organisations financières et assurantielles, les projets de migration Cloud ne sont pas bloqués par la technique. Ils sont bloqués par l’absence de réponse claire à une question simple : “Comment démontrer à notre régulateur que cette migration est conforme ?”
Cette question reste sans réponse parce que trois réglementations se superposent, chacune avec ses propres exigences sur les prestataires ICT, la localisation des données, et la résilience opérationnelle. Et personne dans l’organisation ne maîtrise à la fois le cadre réglementaire et l’architecture Atlassian Cloud.
Résultat : le projet reste en attent et la fin de support en mars 2029 se rapproche beaucoup trop vite.
DORA : ce que le règlement exige de votre relation avec Atlassian
Le Digital Operational Resilience Act (DORA) est en vigueur depuis le 17 janvier 2025. Il s’applique à toutes les entités financières de l’UE : banques, assureurs, sociétés d’investissement, prestataires de paiement.
Dans le contexte d’une migration Atlassian Cloud, DORA impose des obligations concrètes sur votre relation contractuelle avec Atlassian en tant que prestataire ICT tiers.
Registre des arrangements ICT tiers (Article 28). Vous devez maintenir un registre de tous vos prestataires ICT, incluant Atlassian et ses sous-traitants. Ce registre doit documenter la nature des services, la localisation du traitement, et la criticité de chaque arrangement. Atlassian publie sa liste de sous-traitants (sub-processors), mais c’est à vous de l’intégrer dans votre registre et de la maintenir à jour.
Gestion des risques liés aux tiers ICT (Articles 28 à 30). Vous devez évaluer le risque de concentration. Si Jira, Confluence et JSM sont tous chez Atlassian Cloud, quelle est votre exposition en cas d’incident majeur chez ce prestataire ? DORA exige une analyse documentée de ce risque et des mesures de mitigation (plans de continuité, stratégies de sortie).
Stratégie de sortie (Article 28, paragraphe 8). Vous devez disposer d’un plan de sortie documenté. En cas de défaillance d’Atlassian ou de décision de changement de prestataire, comment récupérez-vous vos données ? Atlassian offre des capacités d’export (API REST, export natif), mais votre stratégie de sortie doit être formalisée, testée, et validée par votre fonction de contrôle.
Tests de résilience opérationnelle (Articles 24 à 27). Pour les entités identifiées comme significatives, des tests avancés (TLPT) peuvent inclure les services Cloud. Votre migration doit anticiper cette exigence en documentant les scénarios de test applicables à l’environnement Atlassian Cloud.
Ce qu’Atlassian couvre nativement : certifications SOC 2 Type II et ISO 27001, SLA de disponibilité documentés, rapport de résilience publié annuellement, processus de notification d’incidents.
Ce que vous devez adresser vous-même : registre ICT, analyse de concentration, stratégie de sortie formalisée, intégration dans votre cadre de gestion des risques tiers, contractualisation conforme DORA.
RGPD : au-delà de la localisation des données
Le RGPD est en vigueur depuis 2018, mais une migration Cloud remet ses exigences sur la table. Deux dimensions sont spécifiques à une migration Atlassian.
Résidence des données. Atlassian propose la data residency pour Jira, Confluence et JSM sur les éditions Premium et Enterprise. Vos données au repos (attachments, contenu des pages et tickets) sont stockées dans la région choisie (EU inclus). Les métadonnées de plateforme (identités, configuration) peuvent résider hors UE. Cette distinction est importante pour votre DPO : les données personnelles dans les tickets Jira (noms, emails, données clients) sont couvertes par la data residency. Les identités Atlassian Account ne le sont pas systématiquement.
Sous-traitants et transferts. Atlassian maintient un Data Processing Addendum (DPA) et une liste de sub-processors. Votre équipe conformité doit valider que ces sub-processors sont compatibles avec votre politique de transferts internationaux, en particulier depuis l’invalidation du Privacy Shield (Schrems II). Atlassian s’appuie sur les Standard Contractual Clauses (SCC) pour les transferts hors UE.
Droit à l’effacement et portabilité. Si vos instances Jira contiennent des données personnelles de clients (cas fréquent en JSM), vous devez pouvoir répondre aux demandes d’effacement et de portabilité. Atlassian offre des outils de gestion des données personnelles (GDPR tools dans l’administration), mais le processus opérationnel doit être défini et documenté par votre équipe.
Ce qu’Atlassian couvre nativement : DPA conforme, data residency EU (Premium/Enterprise), outils RGPD d’administration, SCC pour transferts hors UE, chiffrement au repos et en transit.
Ce que vous devez adresser vous-même : cartographie des données personnelles dans vos instances, processus de réponse aux droits des personnes, validation des sub-processors, documentation de conformité pour votre registre des traitements.
Solvency II : les exigences spécifiques aux assureurs
Solvency II, complété par les guidelines EIOPA sur l’externalisation vers le Cloud, impose des exigences supplémentaires aux compagnies d’assurance qui migrent des fonctions critiques ou importantes vers un prestataire Cloud.
Classification de la fonction externalisée. Jira et Confluence sont-ils des fonctions “critiques ou importantes” au sens de Solvency II ? La réponse dépend de votre usage. Si Jira gère vos processus de souscription, de gestion des sinistres, ou de conformité réglementaire, il est probable que oui. Cette classification déclenche des obligations renforcées de gouvernance et de supervision.
Notification au superviseur. L’externalisation de fonctions critiques vers le Cloud doit être notifiée à votre autorité de supervision (ACPR en France, NBB en Belgique, FINMA en Suisse). Cette notification inclut l’analyse des risques, les mesures de mitigation, et les arrangements contractuels.
Droits d’audit et d’accès. Solvency II exige que vous conserviez un droit d’audit sur votre prestataire Cloud. Atlassian ne permet pas d’audits physiques de ses datacenters, mais offre des alternatives : certifications indépendantes (SOC 2, ISO 27001), rapports de transparence, et accès aux audit logs de votre organisation (édition Enterprise).
Plan de continuité. Vous devez démontrer que la continuité de vos fonctions critiques est assurée en cas d’indisponibilité du prestataire. Atlassian publie des SLA de disponibilité (99,9% pour Premium, 99,95% pour Enterprise avec SLA financier), mais votre plan de continuité doit documenter les scénarios de dégradation et les procédures de basculement.
Ce qu’Atlassian couvre nativement : certifications tierces en lieu d’audit physique, SLA de disponibilité avec compensation financière (Enterprise), architecture multi-région, rapport de disponibilité public.
Ce que vous devez adresser vous-même : classification de la fonction externalisée, notification au superviseur, plan de continuité intégrant les scénarios Atlassian, droits d’audit contractualisés.
Qu’est ce que votre projet de migration doit inclure ?
Ces trois réglementations convergent sur un point : la migration technique ne suffit pas. Votre projet doit inclure un volet de conformité structuré qui produit les livrables attendus par vos fonctions de contrôle et vos régulateurs.
Concrètement, cela signifie :
- Une analyse de risques documentée couvrant DORA, RGPD, et Solvency II (si applicable)
- Un registre des arrangements ICT tiers mis à jour avec Atlassian et ses sub-processors
- Une stratégie de sortie formalisée et testable
- Une cartographie des données personnelles dans vos instances
- Un choix d’édition Cloud (Premium ou Enterprise) justifié par vos exigences réglementaires
- Un dossier de notification pour votre superviseur (secteur assurance)
- Des processus opérationnels documentés pour les droits RGPD
Sans ces livrables, votre migration est techniquement réussie mais réglementairement incomplète. Et c’est exactement ce que votre régulateur relèvera lors du prochain contrôle.
Comment nous abordons ce sujet
En tant qu’Atlassian Platinum Solution Partner et Cloud Specialized, nous accompagnons des organisations réglementées dans leurs migrations Atlassian Cloud. Notre approche intègre le volet conformité dès la phase d’assessment, pas comme un ajout tardif.
Pendant les 8 premières semaines de notre Assessment Cloud Atlassian Enterprise, nous produisons l’analyse de conformité en parallèle de l’analyse technique. Votre CISO et votre équipe compliance reçoivent les réponses dont ils ont besoin pour débloquer le projet, documentées dans un format que vos fonctions de contrôle peuvent valider.
Nous ne remplaçons pas votre DPO ou votre responsable conformité. Nous leur fournissons les éléments techniques et architecturaux dont ils ont besoin pour produire leur analyse. La décision de conformité reste la leur. Notre rôle est de s’assurer qu’ils disposent des bonnes informations pour la prendre.
Et après ?
Si votre projet de migration est bloqué par des questions de conformité, c’est normal. Ces questions sont légitimes et complexes. Mais elles ont des réponses concrètes.
Un premier échange de 30 minutes avec notre équipe suffit pour identifier les points de blocage spécifiques à votre contexte réglementaire et déterminer si un assessment structuré est la bonne prochaine étape.
