Azure et RGPD : guide de conformité 2026

Microsoft Azure est le deuxième fournisseur cloud mondial et l’infrastructure par défaut d’une grande partie des entreprises françaises déjà équipées en environnement Microsoft. La question revient systématiquement dans mes missions de conseil : « Azure, c’est américain — est-on vraiment conforme au RGPD ? »

La réponse n’est ni « oui » ni « non ». Azure fournit l’un des cadres contractuels et techniques les plus aboutis du marché — DPA détaillé, EU Data Boundary désormais finalisée, régions d’hébergement en France. Mais la conformité ne se contracte pas : elle se configure et se documente. C’est votre paramétrage, pas le badge « certifié RGPD » de Microsoft, qui détermine votre exposition.

Ce guide analyse la conformité RGPD d’Azure sous l’angle juridique et opérationnel, et identifie les points où la responsabilité reste entièrement la vôtre.

Qualification juridique : Microsoft, sous-traitant de vos données

Pour les services d’infrastructure (IaaS) et de plateforme (PaaS) — machines virtuelles, Azure SQL, Blob Storage, AKS, Azure Functions — Microsoft agit en qualité de sous-traitant au sens de l’article 28 du RGPD. Microsoft ne détermine pas les finalités des traitements : il ne décide pas quelles données vous chargez dans une base Azure SQL ni pourquoi. Vous restez le responsable de traitement.

Cette qualification a deux conséquences directes. D’abord, vous devez disposer d’un contrat de sous-traitance conforme à l’article 28(3) — Microsoft le fournit via son Data Protection Addendum (voir plus bas). Ensuite, Microsoft doit être inscrit dans votre registre des activités de traitement comme sous-traitant, avec mention des catégories de données hébergées et des régions concernées.

Attention à une nuance que beaucoup d’équipes négligent : pour certaines données de fonctionnement (logs de diagnostic, télémétrie, données de facturation), Microsoft agit en tant que responsable de traitement indépendant, et non comme votre sous-traitant. Le DPA distingue clairement ces deux casquettes. Vous n’avez pas la main sur ces traitements-là — raison de plus pour les connaître et les documenter.

Le modèle de responsabilité partagée

Comme tous les hyperscalers, Azure fonctionne selon un modèle de responsabilité partagée. Microsoft sécurise l’infrastructure physique, l’hyperviseur et les services managés ; vous restez responsable de la configuration, des accès, du chiffrement applicatif et des données elles-mêmes. La répartition se déplace selon le modèle de service : en IaaS, l’essentiel des mesures de sécurité de l’article 32 vous incombe ; en SaaS (Microsoft 365), Microsoft en assume davantage.

La quasi-totalité des incidents que j’observe ne viennent pas d’une défaillance d’Azure, mais d’un compartiment de stockage laissé ouvert, d’un groupe de sécurité réseau trop permissif ou d’un compte d’administration sans authentification multifacteur. La conformité RGPD se joue dans votre partie du partage.

Le cadre contractuel : DPA et clauses de l’article 28

Le document de référence est le Microsoft Products and Services Data Protection Addendum (DPA). Il s’applique automatiquement à tous les clients Azure sous contrat (Microsoft Customer Agreement ou Enterprise Agreement) et couvre les engagements de l’article 28 : traitement sur instructions documentées, obligation de confidentialité, mesures de sécurité, recours à des sous-traitants ultérieurs, assistance aux demandes d’exercice de droits, notification des violations et restitution ou suppression des données en fin de contrat.

Trois points méritent votre vigilance :

La liste des sous-traitants ultérieurs est publiée par Microsoft et fait l’objet d’un préavis en cas de modification. L’article 28(2) vous donne un droit d’objection : encore faut-il surveiller activement ces mises à jour, ce que personne ne fait spontanément.

Les engagements de notification de violation courent à partir du moment où Microsoft a connaissance de l’incident. Or votre propre obligation de notifier la CNIL court sous 72 heures (article 33). Anticipez la chaîne d’alerte : qui, chez vous, reçoit l’alerte Microsoft et déclenche la procédure interne ?

Le DPA ne vous dispense pas de votre analyse d’impact lorsque le traitement hébergé sur Azure présente un risque élevé. Microsoft publie d’ailleurs des modèles d’AIPD spécifiques à Azure pour faciliter cet exercice — utiles, mais ils ne remplacent pas votre analyse contextualisée.

Hébergement et transferts : ce que change l’EU Data Boundary

C’est le cœur du sujet pour une entreprise française. Deux mécanismes se combinent.

Les régions françaises

Azure dispose de deux régions en France : France Central (région parisienne) et France South (Marseille). En déployant explicitement vos ressources dans ces régions, les données client au repos restent physiquement en France. Ce choix de localisation est manuel : Azure ne sélectionne pas une région française par défaut. Vérifiez systématiquement la région de chaque ressource — c’est l’une des premières choses que j’audite.

L’EU Data Boundary

Depuis février 2025, Microsoft a finalisé son EU Data Boundary : le périmètre géographique (UE + AELE) à l’intérieur duquel sont stockées et traitées les données client, les données personnelles, mais aussi — depuis la phase 3 — les données techniques générées lors des demandes de support. Pour Azure, Microsoft 365, Dynamics 365 et Power Platform, cela signifie qu’un transfert vers les États-Unis n’est plus la situation par défaut pour ces catégories de données.

L’EU Data Boundary réduit considérablement la surface de transfert hors UE, mais ne l’élimine pas totalement : certains flux résiduels subsistent (sécurité, lutte contre les abus, certains services non régionaux). Microsoft documente ces transferts continus de façon transparente.

Le filet de sécurité juridique des transferts

Pour les flux résiduels, Microsoft s’appuie sur deux mécanismes de l’article 46. D’une part, l’entreprise est certifiée sous le Data Privacy Framework UE–États-Unis (l’accord d’adéquation entré en vigueur en juillet 2023). D’autre part, le DPA intègre les clauses contractuelles types de la Commission européenne, assorties de mesures supplémentaires, conformément à la jurisprudence Schrems II. Cette double base est l’approche standard et défendable post-Schrems II.

Un point que je rappelle toujours à mes clients du secteur public ou des OIV : Azure dans sa configuration commerciale n’est pas qualifié SecNumCloud par l’ANSSI. Pour les données les plus sensibles soumises à une exigence de souveraineté, c’est l’offre « Bleu » (coentreprise Orange–Capgemini exploitant la technologie Microsoft en environnement cloud de confiance) qui vise cette qualification. Si votre traitement relève de la doctrine « cloud au centre » de l’État, ce point est déterminant.

Configuration recommandée : la conformité par le paramétrage

Voici les réglages que je considère comme un socle minimal sur tout tenant Azure traitant des données personnelles.

Choisissez explicitement une région française ou européenne pour chaque ressource, et bloquez les autres régions via Azure Policy pour éviter les déploiements accidentels hors UE.

Activez le chiffrement au repos et en transit — il l’est par défaut sur la plupart des services, mais pour les données sensibles, envisagez des clés gérées par le client (Customer-Managed Keys via Azure Key Vault) afin de garder la maîtrise cryptographique.

Imposez l’authentification multifacteur et le moindre privilège via Entra ID (ex-Azure AD) et le contrôle d’accès basé sur les rôles (RBAC). La majorité des violations exploitables proviennent d’identités mal protégées.

Activez la journalisation (Azure Monitor, Microsoft Defender for Cloud) pour tracer les accès aux données — indispensable pour répondre à une demande de droit d’accès ou documenter un incident.

Paramétrez des durées de conservation cohérentes avec votre politique : Azure ne purge rien à votre place. Reportez-vous à vos durées de conservation par finalité et automatisez la suppression (lifecycle management sur le stockage, rétention sur les bases).

Inscrivez Microsoft dans votre registre et conservez la version applicable du DPA et de la liste des sous-traitants ultérieurs. En cas de contrôle CNIL, c’est cette documentation qui fait la différence. C’est précisément le type de cartographie sous-traitants que Legiscope tient à jour automatiquement, plutôt que dans un tableur oublié.

Azure face aux alternatives cloud

Azure offre un cadre RGPD solide, comparable à celui d’AWS ou de Google Cloud : DPA conforme, CCT, régions européennes, certifications ISO 27001/27018/27701. Sur la résidence des données, l’EU Data Boundary place Microsoft parmi les hyperscalers les plus avancés.

La vraie ligne de partage n’est pas « conforme / non conforme », mais « souveraineté ». Si votre exigence est la résistance aux lois extraterritoriales américaines (CLOUD Act), aucun hyperscaler américain n’y répond pleinement, malgré l’EU Data Boundary. Les acteurs européens comme OVHcloud ou Scaleway — ou les offres qualifiées SecNumCloud — relèvent alors d’une logique différente. Le choix dépend de votre analyse de risque, pas d’une réponse générique.

Ce qu’il faut retenir

• Microsoft Azure est sous-traitant au sens de l’article 28 pour vos données applicatives, mais responsable indépendant pour certaines données de diagnostic et de facturation : connaissez les deux casquettes.
• Le DPA Microsoft fournit le cadre article 28 (CCT incluses), mais ne vous dispense ni du registre, ni de l’AIPD, ni de la surveillance de la liste des sous-traitants ultérieurs.
• L’EU Data Boundary (finalisée en février 2025) maintient données client, personnelles et de support au sein de l’UE/AELE, réduisant fortement — sans l’éliminer — la surface de transfert hors UE.
• La conformité se configure : région française, chiffrement, MFA, RBAC, journalisation et durées de conservation sont à votre charge, pas à celle de Microsoft.
• Azure commercial n’est pas SecNumCloud : pour une exigence de souveraineté, regardez l’offre « Bleu » ou un cloud européen qualifié.

FAQ

Azure est-il conforme au RGPD ?

Azure fournit un cadre permettant la conformité — DPA conforme à l’article 28, clauses contractuelles types, EU Data Boundary, régions françaises et certifications. Mais la conformité dépend de votre configuration : aucun cloud n’est « conforme RGPD » indépendamment de la façon dont vous l’utilisez.

Où sont stockées les données sur Azure pour un client français ?

Si vous déployez vos ressources dans les régions France Central (Paris) ou France South (Marseille), les données au repos restent en France. Sans choix explicite, Azure utilise la région que vous sélectionnez à la création — vérifiez-la systématiquement et verrouillez-la via Azure Policy.

Le CLOUD Act s’applique-t-il malgré l’EU Data Boundary ?

Oui. Microsoft étant une société de droit américain, le CLOUD Act peut théoriquement s’appliquer indépendamment de la localisation physique des données. L’EU Data Boundary améliore la résidence des données et la transparence, mais ne neutralise pas le risque extraterritorial. Pour une exigence de souveraineté forte, orientez-vous vers une offre qualifiée SecNumCloud.

Quel contrat signer avec Microsoft pour être en règle ?

Le Microsoft Products and Services Data Protection Addendum (DPA) s’applique automatiquement à votre contrat Azure et couvre les exigences de l’article 28. Conservez la version applicable, suivez les mises à jour de la liste des sous-traitants ultérieurs et inscrivez Microsoft dans votre registre des traitements.