Azure et RGPD : vérifier l’architecture et les garanties

Une analyse RGPD d’Azure doit partir de l’architecture réellement déployée : services utilisés, données, régions, accès et dépendances. Le choix d’une région française apporte une information utile, mais ne décrit ni tous les flux ni toutes les garanties applicables.

Identifier les rôles et les obligations contractuelles

Pour l’hébergement réalisé selon vos instructions, examiner la sous-traitance. Votre propre organisation peut déterminer les finalités ou fournir une application pour le compte d’un client. Les qualifications changent alors dans la chaîne. La CNIL recommande de distinguer fourniture, amélioration du service et sécurité du cloud, en documentant le raisonnement selon les faits. Il ne faut pas considérer tous les journaux comme relevant automatiquement d’un responsable indépendant. CNIL, qualifications cloud, 28 mai 2026.

Le dossier contractuel doit comprendre l’offre, le contrat applicable, les Product Terms, le DPA et les conditions propres aux services. Les versions du DPA sont disponibles dans le centre documentaire Microsoft. Comparez leur périmètre aux ressources effectivement utilisées, aux prestations de support et aux offres tierces.

L’article 28(3) impose des garanties précises : instructions, confidentialité, sécurité, assistance, sort des données et contrôle. La présence d’un document intitulé DPA ne suffit pas à conclure que toutes les exigences de votre projet sont remplies. Notre audit des preuves du prestataire donne une trame de vérification.

Répartir les tâches sans effacer les responsabilités légales

En IaaS, le client administre notamment ses systèmes et applications ; en PaaS, davantage de composants sont gérés par Microsoft. Les identités, paramètres et données nécessitent toujours des décisions du client dans son périmètre. Microsoft précise explicitement que son schéma de responsabilité partagée est un guide de gouvernance, sans conclusion juridique ni modification du contrat. Modèle de responsabilité partagée Azure.

Établissez une matrice nominative : qui configure, qui surveille, qui corrige et qui démontre le résultat ? Par exemple, « sauvegarde fournie par le service » laisse ouvertes les questions de la rétention choisie, du contrôle des restaurations et du traitement d’une suppression individuelle.

Vérifier l’EU Data Boundary service par service

Les engagements EU Data Boundary concernent un périmètre défini dans l’UE et l’AELE, avec des conditions et des exceptions documentées. Les services Azure régionaux déployés dans une région couverte et les services non régionaux ne s’analysent pas de manière identique. Les données des services professionnels bénéficient d’un engagement de stockage au repos, à distinguer d’une localisation exclusive de toutes les opérations. Présentation Microsoft EU Data Boundary.

La documentation des services non régionaux prévoit des réglages particuliers. Pour Azure Resource Manager, elle décrit une configuration au niveau du tenant et des restrictions importantes : elle vise de nouveaux tenants sans abonnements ni ressources existants et limite ensuite les mouvements de ressources. Il faut donc vérifier ce point avant de promettre une simple bascule d’un environnement ancien. Configuration des services Azure non régionaux.

Pour chaque transfert identifié, retenir le mécanisme qui couvre effectivement l’opération. Une décision d’adéquation relève de l’Art. 45(1) ; les clauses types adoptées par la Commission de l’Art. 46(2)(c). RGPD, chapitre V. Le Data Privacy Framework ne doit donc pas être présenté comme une seconde garantie de l’article 46. Voir notre guide des transferts hors UE, notamment pour la qualification des accès d’assistance.

Cas pratique : dossier de réception d’une application métier

Exemple entièrement hypothétique, sans essai réel d’Azure : Réparelec, PME de maintenance d’appareils, fait développer un portail de suivi des interventions. Elle détermine les finalités du suivi client ; l’intégrateur réalise le développement et l’exploitation pour son compte. Le projet utilise Azure App Service, une base Azure SQL et un espace Blob Storage pour les photos utiles au diagnostic. Les coordonnées des clients et les échanges nécessaires aux interventions sont des données personnelles, même si l’application porte principalement sur des équipements.

La dirigeante refuse une recette limitée à « toutes les ressources sont dans une région française ». Elle demande cette fiche de décision, qui complète l’inventaire technique de son intégrateur :

Le nom des responsables est ajouté dans la version interne : la gérante arbitre les finalités et les durées, l’intégrateur configure les mécanismes, la personne chargée de la conformité examine les preuves. Aucun acteur ne signe à la place des autres une affirmation générale « Azure est conforme ».

L’Art. 32(1) demande des mesures adaptées aux risques, incluant selon les besoins restauration et évaluation de leur efficacité. La fiche ci-dessus est une proposition pratique ; le règlement ne prescrit pas universellement ces huit lignes ni une option payante précise. RGPD, Art. 28 et 32.

Une résidence mal démontrée bloque la promesse commerciale

L’intégrateur voulait utiliser le tenant historique de Réparelec et annonçait que l’activation ultérieure d’un paramètre suffirait pour tout placer dans l’EU Data Boundary. Confrontée aux conditions d’Azure Resource Manager décrites plus haut, cette affirmation n’est pas retenue. Le dossier distingue les services déjà configurés, les conditions qui restent à satisfaire et les flux exclus de la promesse envisagée.

La direction ne commande pas pour autant une migration improvisée : elle demande un chiffrage et un parcours documenté pour l’architecture compatible avec son besoin. Les restrictions de déplacement mentionnées par Microsoft doivent être traitées avant de choisir la solution. Si une exigence du client porte sur une localisation plus stricte que les engagements effectivement démontrés, le projet reste en attente ou l’architecture change. Une mention commerciale ne peut pas combler l’écart.

Pour le support, Réparelec prévoit d’abord des données fictives et un exemple minimal reproduisant l’erreur. Si des données réelles deviennent nécessaires, elle vérifie le canal, le destinataire, le périmètre et les garanties avant de les transmettre. Un fichier joint à une demande d’assistance mérite son propre examen ; il ne relève pas automatiquement de la seule région choisie pour la base métier.

Conservation : examiner l’effet réel des règles

Azure Blob Storage dispose de règles de cycle de vie permettant des suppressions. Lorsque la suppression réversible est activée, une suppression par cette politique peut placer l’objet dans un état récupérable jusqu’à l’expiration prévue. Les anciennes versions demandent également une gestion appropriée. Documentation des politiques de suppression Azure.

Exemple hypothétique : une application supprime un justificatif à son échéance mais une version précédente et un export de diagnostic restent accessibles. Il faut examiner ces copies avant de déclarer l’effacement terminé. La politique doit concilier récupération nécessaire, durée justifiée et accès restreints ; notre guide de preuve d’exécution de l’effacement aide à consigner le résultat.

Prévoyez aussi la sortie : format exploitable, périmètre des données, dépendances techniques, retrait des accès et devenir des copies. La cartographie des sous-traitants doit inclure l’intégrateur ou l’infogérant lorsque ses opérations le justifient.

Que faire si un intervenant conserve un accès indu ?

Lors de la réception fictive, l’équipe vérifie le compte d’un intervenant de l’intégrateur dont la mission vient de prendre fin. Le compte n’apparaît plus dans le groupe prévu par la procédure, mais une attribution de droits directe lui permet encore d’ouvrir les pièces jointes. Le départ a été coché comme terminé sur le tableau RH ; l’accès réel contredit cette conclusion.

La gérante refuse la mise en service avec des données clients. L’administrateur retire l’attribution restante et recherche les autres accès du même intervenant, y compris les comptes techniques ou secrets qu’il aurait pu connaître. Il évite de supprimer indistinctement des identités utilisées par le service : le traitement des accès doit préserver la continuité tout en révoquant effectivement les pouvoirs injustifiés.

L’équipe recommence ensuite le contrôle avec ce compte, puis avec un utilisateur métier qui doit continuer à accéder à ses dossiers autorisés. Elle vérifie les pièces jointes autant que l’écran principal. Si le résultat reste ambigu ou si le prestataire ne fournit pas d’explication, la recette reste non acceptée ; le projet ne passe pas en production sur une simple déclaration de correction.

Si cette découverte intervient après ouverture à de vrais clients, l’action ne s’arrête pas au retrait des droits. L’entreprise recherche la période concernée, les données accessibles et les consultations connues, préserve les traces utiles et apprécie l’éventuelle violation de données ainsi que les suites des Art. 33 et 34. Des journaux incomplets ne prouvent pas l’absence d’accès. La qualification RGPD par opération et le contrat permettent d’organiser les échanges avec les prestataires ; ils ne permettent pas de repousser l’analyse de l’incident jusqu’à la résolution d’un désaccord commercial.

Avant réception définitive, la dirigeante conserve les écarts corrigés et ceux qui restent ouverts. Une exception doit nommer le risque, le périmètre et la décision prise ; écrire « accepté par le métier » ne transforme pas une obligation légale non satisfaite en option. Le même dossier sera repris lors d’un ajout de service, d’un changement de sous-traitant ou de la sortie de l’hébergement.

Ce qu’il faut retenir

• Qualifier les rôles par opération : l’éditeur d’une application peut lui-même être sous-traitant de ses clients.
• Le modèle de responsabilité partagée organise les tâches techniques ; il ne tranche pas à lui seul la responsabilité juridique.
• Vérifier séparément les services régionaux, les services non régionaux et les données d’assistance.
• Une règle de suppression peut laisser des versions ou une récupération temporaire selon les options activées.

FAQ

Une région française suffit-elle pour un projet sensible ?

Non. Il faut examiner les opérations, les accès et les exigences propres au secteur ou à l’organisme. Si une qualification est requise, vérifier l’offre et son périmètre exacts. L’ANSSI rappelle que SecNumCloud qualifie une offre et ne garantit pas automatiquement la sécurité de l’application du client. FAQ ANSSI SecNumCloud.

Une clé gérée par le client empêche-t-elle tout accès du fournisseur ?

Il faut vérifier quand et où le service déchiffre les données et qui peut obtenir l’accès nécessaire. La maîtrise d’une clé au repos ne démontre pas, seule, que le fournisseur ne peut jamais traiter les données en clair.

Faut-il une AIPD pour tout déploiement Azure ?

L’article 35(1) la requiert lorsque le traitement est susceptible d’engendrer un risque élevé. Le fournisseur ne décide pas à votre place du risque de votre application. Notre méthode d’analyse d’impact permet de documenter les caractéristiques du traitement et les mesures retenues.

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.