Conformité cloud : RGPD, ISO 27001, HDS, DORA

La conformité cloud n'est pas une case à cocher pour rassurer un comité de direction : c'est la capacité à prouver, à tout instant et face à un contrôle, que vos données et vos configurations respectent les obligations qui vous engagent. Sur Microsoft Azure comme sur AWS, l'enjeu n'est pas seulement technique, il est juridique, contractuel et opérationnel. Cette page est le guide de référence français : définitions, modèle de responsabilité partagée détaillé par service, panorama complet des normes et réglementations (RGPD, ISO 27001, SecNumCloud, HDS, NIS2, DORA, CLOUD Act), bonnes pratiques, checklist auditable, outillage natif Azure/AWS, fourchettes de coûts et roadmap de mise en conformité.

Qu'est-ce que la conformité cloud ?

La conformité cloud (cloud compliance) désigne l'ensemble des mesures techniques, organisationnelles et contractuelles qui permettent à une organisation de respecter, et surtout de démontrer qu'elle respecte, les lois, réglementations, normes et engagements contractuels applicables à ses données et à ses systèmes hébergés sur une plateforme de cloud public (Microsoft Azure, AWS, Google Cloud) ou hybride.

Concrètement, être conforme dans le cloud signifie pouvoir répondre, preuves à l'appui, à trois questions :

• Que dit la loi pour mon activité ? Un acteur de la santé est soumis à l'hébergement certifié HDS ; une banque relève de DORA ; un opérateur essentiel relève de NIS2 ; toute organisation traitant des données personnelles relève du RGPD.
• Mon environnement réel respecte-t-il ces exigences ? Chiffrement, gestion des accès, journalisation, localisation des données, contrats de sous-traitance.
• Puis-je le prouver de façon opposable ? Documentation, registres, journaux d'audit conservés, attestations de l'hébergeur, matrice de conformité tenue à jour.

La conformité cloud se distingue de l'informatique traditionnelle par plusieurs réalités propres au cloud : provisionnement à la demande, ressources éphémères, API exposées, configurations déclaratives (Infrastructure as Code) et, surtout, un modèle de responsabilité partagée entre le fournisseur et vous. Ce dernier point est la source de la majorité des malentendus, et des non-conformités.

À retenir. La conformité n'est pas un état figé que l'on atteint une fois pour toutes. C'est la capacité à mesurer, en continu, l'écart entre votre posture réelle et le référentiel applicable, puis à le réduire de façon priorisée et documentée.

Conformité, sécurité et gouvernance cloud : trois notions à ne pas confondre

Ces trois termes se recouvrent partiellement, mais répondent à des questions différentes. Les confondre conduit à mal cadrer un projet, et à payer pour le mauvais livrable.

| Notion | Question posée | Référentiel | Finalité | |---|---|---|---| | Sécurité cloud | Mon environnement est-il protégé contre les menaces ? | CIS Benchmarks, Well-Architected, MITRE ATT&CK | Réduire le risque d'incident | | Conformité cloud | Est-ce que je respecte les obligations qui m'engagent ? | RGPD, ISO 27001, NIS2, DORA, HDS, SecNumCloud | Démontrer la conformité, réduire le risque juridique | | Gouvernance cloud | Comment garder le contrôle dans la durée ? | Cloud Adoption Framework, politiques internes | Maîtriser coûts, accès, configurations |

La sécurité protège ; la conformité prouve ; la gouvernance maintient. Une organisation peut être techniquement sécurisée sans être conforme (par exemple un environnement bien durci mais sans contrat de sous-traitance art. 28 ni localisation maîtrisée des données). Inversement, des cases administratives cochées ne valent rien si la configuration réelle est défaillante. La conformité durable repose sur une bonne gouvernance cloud : sans cadre de gouvernance, la conformité dérive dès le premier déploiement non maîtrisé.

Le modèle de responsabilité partagée : qui sécurise quoi ?

Le malentendu le plus coûteux dans le cloud tient en une phrase : « C'est dans le cloud, donc c'est le fournisseur qui s'en occupe. » Faux. Le fournisseur (CSP, Cloud Service Provider) est responsable de la sécurité du cloud ; vous êtes responsable de la sécurité dans le cloud. La frontière exacte se déplace selon le modèle de service, la part du fournisseur s'élargit d'IaaS vers SaaS, mais une constante traverse les trois modèles : vos données, vos identités et la configuration de vos services restent toujours votre responsabilité. Aucun fournisseur ne porte à votre place le RGPD, la classification de vos données ou l'attribution des droits d'accès.

Le tableau complet couche × modèle (IaaS / PaaS / SaaS) et le principe générique « qui sécurise quoi » sont détaillés sur notre pilier sécurisation d'infrastructure cloud. Ici, l'angle est différent : non pas « qui gère la machine », mais ce qui relève de votre conformité service par service : la zone exacte où se logent les non-conformités constatées.

Matrice de responsabilité partagée détaillée par service

C'est ici que la plupart des guides s'arrêtent à la théorie. Voici qui fait quoi, service par service, sur les briques les plus utilisées. La colonne « Vous » liste ce qui relève de votre conformité et qui, négligé, génère l'essentiel des non-conformités constatées.

| Service (Azure / AWS) | Fournisseur (CSP) | Vous (client) | |---|---|---| | Stockage objet (Blob Storage / S3) | Durabilité physique, chiffrement de l'infrastructure | Politique d'accès (jamais public par défaut), chiffrement avec clé gérée, journalisation des accès, rétention | | Base managée (Azure SQL / RDS) | Patch du moteur, sauvegarde de l'infrastructure, haute disponibilité | Chiffrement transparent + en transit (TLS), règles de pare-feu, comptes et droits, audit des requêtes | | Kubernetes managé (AKS / EKS) | Plan de contrôle, disponibilité de l'API | RBAC, network policies, admission control, Pod Security, chiffrement des secrets, durcissement des images | | Serverless (Azure Functions / Lambda) | Runtime, isolation, mise à l'échelle | Rôles IAM au moindre privilège, secrets hors du code, chiffrement des variables, journalisation | | Identité (Entra ID / IAM Identity Center) | Disponibilité du service d'annuaire | Politiques d'accès conditionnel, MFA, revue des droits, principe du moindre privilège | | Réseau (VNet / VPC) | Backbone physique, isolation des locataires | Segmentation, groupes de sécurité, chiffrement en transit, exposition publique maîtrisée |

Le piège du stockage objet. La majorité des fuites de données cloud médiatisées proviennent de buckets S3 ou de conteneurs Blob laissés ouverts. Le fournisseur a bien chiffré le disque sous-jacent, mais l'exposition publique relève à 100 % de votre configuration. Aucune certification de l'hébergeur ne vous couvre sur ce point.

Pour bâtir une architecture où cette répartition est claire et automatiquement contrôlée, voyez notre pilier sécurisation d'infrastructure cloud et la page DevSecOps cloud.

Normes et référentiels internationaux

La conformité cloud s'appuie sur un socle de normes et de référentiels reconnus. Tous ne sont pas des lois : certains sont des normes volontaires qui structurent la confiance, d'autres des cadres techniques. Les connaître permet de choisir le bon objectif.

Les normes ISO

• ISO/IEC 27001 : la norme de référence pour un système de management de la sécurité de l'information (SMSI). Elle ne porte pas spécifiquement sur le cloud, mais sur l'organisation qui le gère : analyse de risque, politiques, contrôles, amélioration continue. C'est le socle attendu par la plupart des grands comptes.
• ISO/IEC 27017 : code de bonne pratique spécifique aux services cloud, qui complète l'ISO 27001 avec des contrôles propres au cloud (responsabilité partagée, isolation, retrait des actifs).
• ISO/IEC 27018 : code de conduite pour la protection des données personnelles (PII) dans le cloud public. Pertinente pour démontrer une démarche alignée avec le RGPD côté sous-traitant.

Chez Architecte Cloud, nous menons une démarche ISO 27001 sur nos propres processus et nous aidons nos clients à aligner leurs architectures sur ces contrôles. Une certification vise une organisation, pas une configuration figée : méfiez-vous de tout prestataire qui vous vend une infrastructure « certifiée ISO ».

SOC 2, NIST, CSA, CIS

• SOC 2 : rapport d'audit américain (Trust Services Criteria : sécurité, disponibilité, confidentialité, intégrité, vie privée). Très demandé dans l'écosystème SaaS B2B, notamment à l'export.
• NIST SP 800-53 : catalogue de contrôles de sécurité du gouvernement fédéral américain, socle de FedRAMP. Référence technique riche, mais ancrée dans le contexte US.
• CSA Cloud Controls Matrix (CCM) : matrice de contrôles de la Cloud Security Alliance, pensée pour le cloud et cartographiée vers la plupart des autres référentiels. Excellent outil de pilotage transverse.
• CIS Benchmarks : guides de durcissement très opérationnels, déclinés par fournisseur (CIS AWS Foundations, CIS Azure Foundations) et par technologie (Kubernetes, Linux). C'est la base technique d'un audit de configuration sérieux.

Réglementations applicables : ce que la loi impose vraiment

Au-delà des normes volontaires, certaines réglementations sont opposables : leur non-respect expose à des sanctions. Voici les principales qui concernent un environnement cloud opéré depuis la France.

RGPD : les articles 28 et 32 au cœur du sujet

Le Règlement général sur la protection des données (RGPD) s'applique dès que vous traitez des données personnelles. Deux articles structurent la conformité cloud :

• Article 28 : encadre la relation entre responsable de traitement (vous) et sous-traitant (le fournisseur cloud, ou votre infogérant). Il impose un contrat de sous-traitance précisant l'objet, la durée, la nature du traitement, les obligations de sécurité, le sort des données en fin de contrat et les conditions de recours à des sous-traitants ultérieurs. Sans ce contrat, vous êtes en faute, même avec une infrastructure techniquement irréprochable.
• Article 32 : impose des mesures techniques et organisationnelles appropriées : chiffrement, pseudonymisation, confidentialité, intégrité, disponibilité, résilience, et capacité à restaurer les données. C'est l'article qui justifie chiffrement, sauvegardes testées, journalisation et plans de continuité.

Les sanctions peuvent atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. La CNIL contrôle, met en demeure et sanctionne.

Les réglementations internationales à connaître

• HIPAA : protection des données de santé aux États-Unis. Concerne les organisations traitant des données de patients américains. En France, l'équivalent fonctionnel passe par la certification HDS (voir plus bas).
• PCI DSS : norme de sécurité des données de l'industrie des cartes de paiement. Obligatoire pour tout acteur stockant, traitant ou transmettant des données de cartes bancaires.
• SOX (Sarbanes-Oxley) : contrôle interne et fiabilité financière des sociétés cotées aux États-Unis.
• FedRAMP : programme d'autorisation des services cloud pour le gouvernement fédéral américain. Sans portée directe en France, mais utile à connaître pour les fournisseurs internationaux.

Le cadre réglementaire français et européen : là où le contexte change tout

C'est le grand angle mort des guides traduits de l'anglais. Un acteur français ou européen ne se contente pas du RGPD et de référentiels américains : il évolue dans un cadre réglementaire dense, en pleine montée en puissance, qui peut imposer des choix d'architecture et même de fournisseur. C'est ici qu'Architecte Cloud apporte l'essentiel de sa valeur.

SecNumCloud : la qualification de l'ANSSI

SecNumCloud est un référentiel et une qualification délivrée par l'ANSSI (Agence nationale de la sécurité des systèmes d'information) attestant qu'un service cloud atteint un niveau d'exigence élevé en matière de sécurité et de protection contre les législations extraterritoriales. Sa particularité essentielle : un service qualifié SecNumCloud doit être immunisé contre les lois extraterritoriales non européennes (CLOUD Act américain, FISA 702), via des critères de gouvernance, d'actionnariat et de localisation.

SecNumCloud est progressivement rendu obligatoire pour certaines données sensibles de l'État et des opérateurs critiques, dans le cadre de la doctrine « Cloud au centre » de l'État français. Des offres comme celles d'OVHcloud, Outscale (3DS Outscale) ou des coentreprises de « cloud de confiance » (Bleu : Microsoft/Capgemini/Orange ; S3NS : Google/Thales) visent cette qualification.

HDS : l'hébergement des données de santé

La certification HDS (Hébergeur de Données de Santé) est obligatoire pour héberger des données de santé à caractère personnel en France. Point crucial de vocabulaire et de conformité : c'est l'hébergeur qui est certifié HDS, pas votre application ni votre configuration. Azure et AWS disposent de régions/services certifiés HDS, et il existe des hébergeurs français certifiés HDS.

Les prestataires de notre réseau conçoivent des architectures de santé hébergées chez un partenaire certifié HDS. Ils ne sont pas hébergeurs : notre rôle est d'orienter vers des prestataires qui garantissent que l'architecture, les flux et les contrats respectent les exigences HDS de bout en bout, la certification reste celle de l'hébergeur.

Pour les projets santé, voyez notre approche dédiée au secteur de la santé.

NIS2 : la directive qui élargit le périmètre

La directive NIS2 étend très largement le périmètre des entités soumises à des obligations de cybersécurité. Elle distingue les entités essentielles et les entités importantes (énergie, santé, transport, eau, infrastructures numériques, administration, mais aussi de nombreux secteurs jusqu'ici exclus, avec des seuils de taille). Points marquants pour le cloud :

• Obligations de gestion des risques, de notification d'incident dans des délais courts, et de sécurisation de la chaîne d'approvisionnement (y compris vos fournisseurs cloud).
• Responsabilité des dirigeants : les organes de direction peuvent être tenus personnellement responsables et sanctionnés.
• Sanctions administratives significatives, supervisées par l'ANSSI en France.

DORA : la résilience opérationnelle de la finance

Le règlement européen DORA (Digital Operational Resilience Act) s'applique au secteur financier et assurantiel (banques, assureurs, sociétés de gestion, prestataires de services de paiement, et certains prestataires informatiques tiers critiques). Il impose, appliqué au cloud :

• Un cadre de gestion du risque lié aux TIC et un registre d'information recensant tous les contrats avec des prestataires tiers (dont votre fournisseur cloud).
• La gestion du risque lié aux tiers : clauses contractuelles renforcées, droit d'audit, stratégies de sortie et de réversibilité.
• Des tests de résilience, jusqu'aux tests de pénétration fondés sur la menace (TLPT) pour les entités les plus importantes.
• Des exigences de continuité (PRA/PCA, RTO/RPO) appliquées aux services cloud.

Pour les acteurs financiers, voyez notre page secteur finance.

EUCS et EU AI Act : ce qui arrive

• EUCS : futur schéma européen de certification de cybersécurité pour les services cloud, en cours de finalisation. Il vise à harmoniser les niveaux d'exigence à l'échelle de l'UE.
• EU AI Act : règlement européen sur l'intelligence artificielle, dont plusieurs échéances s'échelonnent à partir de 2026. Il introduit des obligations pour les systèmes d'IA selon leur niveau de risque, un enjeu émergent pour les charges d'IA hébergées dans le cloud, encore ignoré par la plupart des guides.

CLOUD Act, FISA 702 et souveraineté numérique

Le CLOUD Act (États-Unis) permet aux autorités américaines de demander à un fournisseur soumis au droit américain l'accès à des données qu'il détient, y compris stockées en Europe. Le FISA 702 autorise une surveillance à des fins de renseignement. C'est le cœur du débat sur la souveraineté numérique : héberger des données dans une région européenne d'un hyperscaler américain ne suffit pas à les soustraire au droit américain.

Conséquences pratiques pour votre conformité :

• Pour les transferts hors UE de données personnelles, le RGPD impose un cadre : clauses contractuelles types (SCC), analyse d'impact des transferts, mesures techniques supplémentaires (chiffrement avec clés que vous maîtrisez).
• Pour les données les plus sensibles, le recours à un cloud souverain / de confiance (OVHcloud, Scaleway, 3DS Outscale, ou les coentreprises Bleu et S3NS) ou à un service qualifié SecNumCloud peut devenir un choix structurant.

Notre position indépendante. Nous ne vendons aucun cloud. Pour la plupart des charges, Azure et AWS, bien configurés, avec chiffrement et clés maîtrisées, répondent au RGPD. Pour des données régaliennes ou ultra-sensibles, le cloud de confiance s'impose. Le bon arbitrage est une décision éclairée par les risques, pas un dogme. C'est ce que nous documentons pour vous, chiffres et contraintes à l'appui.

SecNumCloud, HDS, ISO 27001 : quelles différences ?

| Référentiel | Nature | Délivré par | Objet | Caractère | |---|---|---|---|---| | ISO 27001 | Norme internationale | Organisme certificateur | Management de la sécurité de l'information | Volontaire | | HDS | Certification française | Organisme accrédité | Hébergement de données de santé | Obligatoire pour la santé | | SecNumCloud | Qualification ANSSI | ANSSI | Sécurité + immunité extraterritoriale | Volontaire, parfois imposé (État) |

Les trois ne sont pas concurrents : une architecture santé peut viser un hébergeur certifié HDS dont le socle s'appuie sur une démarche ISO 27001, tout en évaluant l'opportunité d'un service SecNumCloud selon la sensibilité.

Pourquoi la conformité cloud est-elle importante ?

La motivation n'est jamais « cocher une case ». Elle se résume à quatre risques, que nous formulons toujours en langage de décision.

• Risque juridique et sanctions. RGPD jusqu'à 20 M€ ou 4 % du CA mondial ; sanctions NIS2 et DORA ; responsabilité personnelle des dirigeants sous NIS2. La non-conformité n'est plus théorique.
• Risque financier. Au-delà des amendes, la non-conformité bloque les contrats : un grand compte, un assureur cyber ou un appel d'offres public exigent de plus en plus une preuve d'audit récente. Une remédiation en urgence coûte toujours plus cher qu'une mise en conformité planifiée.
• Risque réputationnel. Une fuite de données ou une sanction publiée laisse une trace durable. Pour un éditeur SaaS ou un acteur de la santé, la confiance est le capital principal.
• Maîtrise opérationnelle. Un environnement conforme est un environnement gouverné : actifs cartographiés, accès maîtrisés, journalisation active. La conformité est un effet de bord d'une bonne gouvernance.

Nous vendons la maîtrise, pas la peur. Un bon accompagnement ne dramatise pas : il transforme une inquiétude diffuse (« sommes-nous en règle ? ») en un plan d'action daté, priorisé et chiffré.

Les principaux défis de la conformité cloud

Atteindre la conformité est une chose ; la maintenir en est une autre. Les difficultés récurrentes que nous observons sur le terrain :

• Manque de visibilité. On ne protège que ce que l'on voit. Sans inventaire à jour des ressources, des comptes et des flux, impossible de prouver quoi que ce soit. Le cloud crée et détruit des ressources en permanence.
• Dérive de configuration (drift). Une ressource conforme au jour J ne le reste pas. Une modification manuelle, un déploiement non contrôlé, et la configuration s'écarte de la cible. Le drift est la première cause de non-conformité silencieuse.
• Multi-cloud. Azure et AWS n'ont ni le même vocabulaire, ni les mêmes outils, ni les mêmes valeurs par défaut. Maintenir une conformité homogène sur deux plateformes exige une approche transverse.
• Shadow IT. Des équipes ouvrent des comptes cloud ou des services SaaS hors du contrôle de la DSI. Ces ressources échappent à toute politique de conformité.
• Complexité réglementaire. RGPD, NIS2, DORA, HDS, SecNumCloud, EU AI Act : le cadre se densifie et évolue. Suivre, interpréter et appliquer correctement demande une veille permanente.
• Réversibilité et dépendance. Une architecture trop liée à un fournisseur complique la mise en conformité DORA (stratégie de sortie) et la souveraineté.

Bonnes pratiques pour atteindre et maintenir la conformité

La conformité durable repose sur un socle de pratiques techniques et organisationnelles. Voici celles qui produisent le plus d'effet.

Chiffrement des données et gestion des clés

Le chiffrement est une exigence directe de l'art. 32 du RGPD et un prérequis de la plupart des référentiels : au repos comme en transit, il doit non seulement être activé, mais vérifié et prouvé sur chaque ressource. Azure et AWS l'activent souvent par défaut, mais le défaut technique ne vaut pas preuve de conformité. Le point qui engage réellement votre conformité est la maîtrise des clés : qui peut déchiffrer vos données, et le fournisseur peut-il y être contraint par une loi extraterritoriale ? Selon la sensibilité, l'arbitrage va de la clé gérée par le fournisseur au BYOK, jusqu'au HYOK pour soustraire les données les plus sensibles au CLOUD Act (voir plus bas).

Le détail technique (chiffrement at-rest/in-transit, CMK/BYOK/HYOK, Azure Key Vault et AWS KMS) est traité sur notre pilier chiffrement et gestion des clés.

IAM et moindre privilège : l'angle de la preuve

La majorité des incidents de conformité passent par les accès, et un auditeur ne se contente pas d'un principe affiché : il demande la preuve. Trois exigences reviennent dans tous les référentiels : le moindre privilège (chaque identité, humaine ou machine, ne dispose que des droits strictement nécessaires), le MFA généralisé sans comptes racine utilisés au quotidien, et des revues d'accès périodiques documentées, avec suppression des comptes dormants et zéro secret en clair dans le code. Chacune doit laisser une trace opposable (journaux d'accès, attestations de revue) : c'est ce qui distingue une posture conforme d'une simple intention.

La mise en œuvre technique (accès conditionnel Entra ID, politiques IAM, PIM, RBAC cloud, revues automatisées et CIEM) est détaillée sur notre pilier gestion des identités et des accès.

Classification des données, journalisation et sauvegardes

• Classification : on n'applique pas les mêmes contrôles à une donnée publique et à une donnée de santé. Sans classification, on sur-protège l'inutile et on sous-protège l'essentiel. C'est le préalable de toute matrice de conformité, et il vous appartient en propre, aucun fournisseur ne le fait à votre place.
• Journalisation, angle rétention et preuve : au-delà de l'activation de CloudTrail (AWS) et des journaux Azure (Activity Log / journaux de ressources), ce qui engage votre conformité est la durée de conservation : combien de temps gardez-vous les journaux d'audit, et pouvez-vous les produire lors d'un contrôle ? Une rétention de 90 jours est souvent insuffisante ; la durée attendue se déduit du référentiel applicable (RGPD, NIS2, DORA), pas du défaut technique.
• Sauvegardes et continuité, angle DORA / art. 32 : la conformité exige de pouvoir restaurer : sauvegardes testées, PRA/PCA avec des objectifs RTO/RPO définis et alignés sur vos obligations. La méthode de durcissement (règle 3-2-1, copies immuables, redondance multi-région) est détaillée sur notre pilier sauvegarde, redondance et continuité d'activité.

Conformité par fournisseur : Azure, AWS, Google Cloud et Kubernetes

Chaque plateforme propose des services certifiés et des outils natifs de conformité. Aucune n'est « conforme » dans l'absolu : elles fournissent les briques, vous restez responsable de l'usage.

• Microsoft Azure : large couverture de certifications (ISO 27001/27017/27018, SOC 2, HDS sur les régions concernées). Outillage : Azure Policy, Microsoft Defender for Cloud, Microsoft Purview. Les fondations de gouvernance reposent sur le Cloud Adoption Framework (landing zones). Voyez notre expertise architecte Azure.
• AWS : couverture comparable (ISO, SOC, HDS). Outillage : AWS Control Tower, AWS Config, AWS Security Hub, AWS Audit Manager. Le Well-Architected Framework (6 piliers, dont la sécurité) cadre les bonnes pratiques.
• Google Cloud : certifications équivalentes, outillage propre (Security Command Center). Moins courant sur le marché français B2B que les deux précédents, mais présent via S3NS pour le cloud de confiance.
• Kubernetes : la conformité des charges conteneurisées est souvent oubliée. Elle repose sur le RBAC, les network policies, l'admission control, les Pod Security Standards, le chiffrement des secrets et le durcissement des images (CIS Kubernetes Benchmark). Voyez notre page dédiée à la sécurité Kubernetes.

Outils et automatisation : du contrôle ponctuel à la surveillance continue

La conformité ne tient pas par la volonté : elle tient par l'automatisation. Vérifier manuellement des centaines de ressources est illusoire et non reproductible.

Le mapping des outils natifs vers les exigences

Plutôt que d'imposer un outil tiers, nous privilégions d'abord les capacités natives, souvent suffisantes et sans coût de licence additionnel. Voici comment elles répondent aux exigences de conformité.

| Exigence | Microsoft Azure | AWS | |---|---|---| | Appliquer des règles (Policy as Code) | Azure Policy | AWS Config Rules, AWS Control Tower (guardrails) | | Posture de sécurité & conformité | Microsoft Defender for Cloud (tableaux de bord réglementaires) | AWS Security Hub (standards CIS, PCI DSS) | | Inventaire & dérive de configuration | Azure Policy + Resource Graph | AWS Config | | Gouvernance des données (classification, DLP) | Microsoft Purview | Macie, tags de données | | Préparation d'audit (collecte de preuves) | Defender for Cloud + exports | AWS Audit Manager | | Journalisation | Azure Activity Log / journaux de ressources | CloudTrail |

CSPM, CNAPP et Policy as Code : ce qu'il faut en retenir côté conformité

Côté conformité, ces outils ne sont pas une fin mais un moyen de surveiller la posture en continu. Un CSPM (Cloud Security Posture Management) détecte automatiquement les écarts (buckets ouverts, chiffrement manquant, MFA absent), les priorise et autorise parfois une remédiation automatique (rétablir le chiffrement, retirer une exposition publique) ; une plateforme CNAPP combine cette surveillance avec la protection des charges et des identités sur des environnements complexes ou multi-cloud. La définition complète de la taxonomie (CSPM, CWPP, CASB, CNAPP, CIEM) figure sur notre pilier CSPM, CWPP, CNAPP.

Le passage d'une conformité corrective à une conformité préventive repose sur le Policy as Code : les règles de conformité sont écrites comme du code, versionnées dans vos dépôts et appliquées automatiquement à chaque déploiement (Azure Policy, AWS Config, Open Policy Agent). Son industrialisation dans la chaîne CI/CD relève du Policy as Code dans une démarche DevSecOps ; côté conformité, ce qui compte est que chaque exigence opposable se traduise en règle automatiquement contrôlée, traçable et reprenable par vos équipes.

Notre principe : tout ce qui est construit vous appartient. Les politiques de conformité (Azure Policy, AWS Config, code Terraform/Bicep) sont versionnées dans vos dépôts, documentées et reprenables par vos équipes. Pas d'enfermement, réversibilité réelle.

Audit de conformité cloud : interne ou externe ?

Évaluer son niveau de conformité passe par un audit. Deux approches, complémentaires.

• Audit interne : mené par vos équipes ou un partenaire, en continu, pour piloter la posture et préparer les contrôles. Souple, fréquent, orienté amélioration.
• Audit externe : mené par un tiers indépendant, pour produire une preuve opposable (certification, attestation, exigence client ou réglementaire). Plus formel, périodique.

Un audit de conformité sérieux croise trois plans : technique (configurations, accès, chiffrement, journalisation), organisationnel (politiques, rôles, procédures) et juridique/contractuel (contrats art. 28, localisation des données, registres). Il aboutit à une matrice de conformité (exigence par exigence : conforme / écart / preuve) et à un plan d'action priorisé.

Pour la démarche complète, méthode et livrables d'un audit, voyez notre audit d'infrastructure cloud et notre offre de diagnostic.

Checklist de conformité cloud actionnable

Voici une checklist de premier niveau, auditable, que nous utilisons en début de cadrage. Chaque point se vérifie et se prouve.

Données

• [ ] Données classifiées (publiques, internes, sensibles, santé/personnelles)
• [ ] Localisation des données connue et maîtrisée (région, transferts hors UE encadrés par SCC)
• [ ] Chiffrement au repos activé et vérifié sur stockage, bases, sauvegardes
• [ ] Chiffrement en transit (TLS) sur tous les flux
• [ ] Gestion des clés définie (gérée par le fournisseur / BYOK / HYOK selon sensibilité)

Accès et identités

• [ ] MFA généralisé, comptes racine non utilisés au quotidien
• [ ] Moindre privilège appliqué, revues d'accès périodiques
• [ ] Aucun secret en clair dans le code ou les variables d'environnement
• [ ] Comptes dormants supprimés

Configuration et surveillance

• [ ] Aucun stockage objet exposé publiquement par erreur (buckets S3 / conteneurs Blob)
• [ ] Journaux d'audit activés (CloudTrail / Azure Activity Log) avec rétention suffisante
• [ ] Surveillance continue de la dérive de configuration (CSPM / Config / Policy)
• [ ] Politiques de conformité appliquées en Policy as Code

Organisation et contrats

• [ ] Contrat de sous-traitance art. 28 RGPD signé avec chaque sous-traitant
• [ ] Registre des traitements et registre d'information (DORA) à jour
• [ ] PRA/PCA documentés et testés, RTO/RPO définis
• [ ] Stratégie de réversibilité / sortie documentée
• [ ] Pour la santé : hébergement chez un partenaire certifié HDS

Misconfigurations les plus fréquentes

Sur le terrain, les mêmes écarts reviennent, et chacun est une non-conformité potentielle :

• Buckets de stockage ouverts au public par une politique d'accès trop permissive.
• Journaux d'audit désactivés ou à rétention trop courte (90 jours là où il en faudrait davantage).
• Chiffrement non vérifié : activé sur le service mais non contrôlé sur toutes les ressources.
• Comptes sans MFA, rôles IAM trop larges, clés d'accès anciennes jamais renouvelées.
• Absence de contrat art. 28 avec un sous-traitant pourtant en production.
• Données personnelles transférées hors UE sans cadre de transfert.

Conformité par persona sectoriel

Les exigences ne sont pas les mêmes selon votre activité. Quelques profils représentatifs que nous accompagnons.

• Santé (HDS). Hébergement chez un partenaire certifié HDS, chiffrement renforcé, traçabilité des accès aux données de patients, contrats stricts. Voyez le secteur santé.
• Finance et assurance (DORA). Registre d'information des prestataires, droit d'audit, tests de résilience, stratégie de sortie, PRA/PCA. Voyez le secteur finance.
• Industrie. Souvent concernée par NIS2 (entité essentielle ou importante), continuité des systèmes industriels, sécurisation de la chaîne d'approvisionnement. Voyez le secteur industrie.
• Secteur public. Doctrine « Cloud au centre », SecNumCloud pour les données sensibles, RGPD renforcé. Voyez le secteur public.
• SaaS et scale-up. SOC 2 et ISO 27001 demandés par les clients grands comptes, conformité RGPD multi-clients, parfois HDS si données de santé. Voyez le secteur SaaS.

Combien coûte la mise en conformité cloud ? Durée et livrables

La transparence sur les coûts fait partie de notre méthode. Les fourchettes ci-dessous sont indicatives : le budget exact dépend du périmètre (un ou plusieurs comptes, mono ou multi-cloud), des référentiels visés et de l'état de départ. Tout est précisé sur devis après cadrage.

Fourchette indicative

Pour une prestation de mise en conformité cloud telle que nous la cadrons (Azure et/ou AWS, du diagnostic au plan d'action outillé), le budget se situe généralement entre 7 000 et 18 000 €, pour une durée de 3 à 10 jours selon le périmètre. Cette fourchette couvre l'analyse, la matrice de conformité, le plan d'action priorisé et la mise en place des contrôles automatisés de base.

Ordres de grandeur complémentaires utiles à connaître :

• Une démarche de certification (ISO 27001, par exemple) mobilise davantage de temps interne et un organisme certificateur : c'est un projet de plusieurs mois.
• Un socle SecNumCloud ou HDS induit un surcoût d'hébergement et d'exploitation généralement observé de l'ordre de 20 à 50 % par rapport à une offre standard, selon les contraintes, à arbitrer au regard de la sensibilité réelle des données.
• À l'échelle d'un budget cloud annuel, l'investissement de conformité se raisonne en pourcentage maîtrisé, à comparer au risque évité (amende, perte de contrat, incident).

Le bon raisonnement n'est pas « combien coûte la conformité ? » mais « combien coûte la non-conformité ? ». Une amende RGPD, un appel d'offres perdu ou une remédiation en urgence dépassent largement le coût d'une mise en conformité planifiée.

Roadmap de mise en conformité par phases

Une mise en conformité réussie suit une trajectoire, pas un grand soir. Exemple représentatif d'une migration santé vers un hébergement certifié HDS menée sur environ 9 mois :

1. Cadrage et classification (semaines 1-3). Périmètre, référentiels applicables, classification des données, registre des traitements.
2. Diagnostic d'écart (semaines 3-6). Matrice de conformité, identification des non-conformités, priorisation.
3. Conception de l'architecture cible (mois 2-3). Choix de l'hébergement (partenaire certifié HDS), chiffrement, IAM, journalisation, PRA/PCA, IaC.
4. Mise en œuvre (mois 3-7). Construction de l'architecture conforme en Infrastructure as Code, mise en place des contrôles automatisés (Policy as Code).
5. Migration et tests (mois 6-8). Migration des données, tests de restauration, validation des objectifs RTO/RPO, tests de réversibilité.
6. Documentation et passage en exploitation (mois 8-9). Preuves, procédures, transfert de compétences, surveillance continue.

Livrables

• Matrice de conformité : exigence par exigence (conforme / écart / preuve), par référentiel applicable.
• Plan d'action priorisé, daté et chiffré, distinguant le critique du cosmétique.
• Architecture cible documentée et code Infrastructure as Code (Terraform/Bicep) versionné dans vos dépôts.
• Politiques de conformité (Azure Policy / AWS Config) en Policy as Code.
• Documentation contractuelle : trame de contrat art. 28, registre, stratégie de réversibilité.
• Restitution en langage clair pour la DSI et la direction générale.

Pourquoi Architecte Cloud pour votre conformité

Notre valeur tient à une combinaison rare sur ce sujet : la profondeur réglementaire française et la maîtrise technique multi-cloud, sans parti pris.

• Indépendance. Nous ne revendons aucun cloud ni aucun éditeur de sécurité. Notre conseil Azure-vs-AWS est neutre : nous recommandons ce qui sert votre conformité et votre budget, pas notre catalogue.
• Expertise multi-cloud. Une expertise cloud éprouvée sur de nombreux projets Azure et AWS. Nous mobilisons des prestataires et experts qualifiés disposant des certifications requises (CISSP, Azure Security Engineer, Azure Solutions Architect Expert, AWS DevOps Engineer Pro, FinOps Certified Practitioner), partenaires Microsoft Azure et AWS.
• Démarche ISO 27001 sur nos propres processus, partenariats avec des hébergeurs certifiés HDS, membre de la FinOps Foundation.
• Autonomie et réversibilité. Tout ce qui est construit vous appartient : comptes à votre nom, IaC dans vos dépôts, documentation remise. Pas d'enfermement.
• Langage clair. Nos restitutions parlent autant à la DSI qu'à la direction générale : coûts, risques, délais. Nous vendons la maîtrise et la sérénité.

Pour aller plus loin, voyez nos services de conseil en architecture, de cybersécurité cloud, de migration cloud, ainsi que le guide du cloud et la page à propos.

Prêt à savoir où vous en êtes ? Notre diagnostic mesure votre écart réel face aux référentiels qui vous engagent, puis le traduit en plan d'action priorisé. Lancez votre diagnostic de conformité ou contactez-nous, réponse sous 48 h ouvrées.

FAQ : Conformité cloud

Qu'est-ce que la conformité cloud (cloud compliance) ?

La conformité cloud désigne l'ensemble des mesures techniques, organisationnelles et contractuelles permettant de respecter, et de prouver que l'on respecte, les lois, normes et engagements applicables aux données et systèmes hébergés dans le cloud. Elle repose sur trois piliers : connaître ses obligations (RGPD, ISO, HDS, NIS2, DORA), les appliquer techniquement, et pouvoir le démontrer de façon opposable.

Quelle est la différence entre conformité cloud et sécurité cloud ?

La sécurité cloud protège votre environnement contre les menaces ; la conformité cloud prouve que vous respectez vos obligations légales et normatives. On peut être techniquement sécurisé sans être conforme (par exemple sans contrat de sous-traitance art. 28 ni localisation maîtrisée des données), et inversement. Les deux sont complémentaires et s'appuient sur une bonne gouvernance.

Qui est responsable de la conformité dans le cloud ?

La conformité reste votre responsabilité, en tant que responsable de traitement. Le fournisseur cloud est responsable de la sécurité du cloud (matériel, hyperviseur, réseau physique) ; vous êtes responsable de la sécurité dans le cloud (données, identités, configurations). Quelle que soit la formule (IaaS, PaaS, SaaS), vos données et vos accès relèvent toujours de vous.

Quelles sont les principales normes et certifications de conformité cloud ?

Côté normes internationales : ISO 27001 (management de la sécurité), ISO 27017 et 27018 (cloud et données personnelles), SOC 2, NIST 800-53, CSA CCM, CIS Benchmarks. Côté réglementations : RGPD, HIPAA, PCI DSS, SOX, FedRAMP. Côté français et européen : SecNumCloud (ANSSI), HDS (santé), NIS2, DORA et le futur schéma EUCS.

Qu'est-ce que la qualification SecNumCloud de l'ANSSI ?

SecNumCloud est un référentiel et une qualification délivrée par l'ANSSI attestant qu'un service cloud atteint un niveau de sécurité élevé et, surtout, qu'il est immunisé contre les lois extraterritoriales non européennes (CLOUD Act, FISA 702) grâce à des critères de gouvernance, d'actionnariat et de localisation. Elle est progressivement imposée pour certaines données sensibles de l'État.

Quelle est la différence entre SecNumCloud, HDS et ISO 27001 ?

ISO 27001 est une norme internationale volontaire de management de la sécurité. HDS est une certification française obligatoire pour héberger des données de santé, c'est l'hébergeur qui est certifié. SecNumCloud est une qualification ANSSI ajoutant l'immunité extraterritoriale, parfois imposée pour les données de l'État. Ces référentiels sont complémentaires, pas concurrents.

Le RGPD impose-t-il d'utiliser un cloud souverain en France ?

Non, le RGPD n'impose pas un cloud souverain. Il impose un cadre de protection (art. 28 et 32) et encadre les transferts hors UE (clauses contractuelles types, mesures techniques). Toutefois, le CLOUD Act expose les données détenues par des fournisseurs soumis au droit américain, même stockées en Europe. Pour des données très sensibles, un cloud souverain ou un service SecNumCloud peut devenir un choix structurant, c'est un arbitrage par les risques.

AWS, Azure et Google Cloud sont-ils conformes au RGPD ?

Ces fournisseurs proposent des services et des contrats permettant une utilisation conforme au RGPD (clauses de sous-traitance, localisation en régions européennes, chiffrement). Mais la conformité ne se délègue pas : elle dépend de votre configuration, de vos contrats et de l'encadrement des transferts hors UE. Une plateforme « compatible RGPD » mal configurée n'est pas conforme.

Comment auditer la conformité de son infrastructure cloud ?

Un audit de conformité croise trois plans : technique (configurations, accès, chiffrement, journalisation), organisationnel (politiques, procédures) et juridique (contrats art. 28, localisation, registres). Il aboutit à une matrice de conformité par exigence et à un plan d'action priorisé. Il peut être interne (pilotage continu) ou externe (preuve opposable). Des outils CSPM et les services natifs (AWS Config, Azure Policy, Defender for Cloud) automatisent la collecte.

Quels sont les risques et sanctions en cas de non-conformité cloud ?

Le RGPD prévoit jusqu'à 20 M€ ou 4 % du chiffre d'affaires mondial. NIS2 et DORA ajoutent des sanctions administratives, et NIS2 introduit une responsabilité personnelle des dirigeants. S'ajoutent les risques financiers (contrats perdus, remédiation d'urgence), réputationnels (fuite ou sanction publiée) et opérationnels.

Combien coûte la mise en conformité d'une infrastructure cloud ?

Pour une prestation de mise en conformité cloud (diagnostic, matrice, plan d'action, contrôles de base), le budget indicatif se situe généralement entre 7 000 et 18 000 €, pour 3 à 10 jours selon le périmètre, sur devis après cadrage. Un socle SecNumCloud ou HDS induit un surcoût d'hébergement souvent observé de l'ordre de 20 à 50 %. Le bon raisonnement compare ce coût au risque évité.

Qu'est-ce que la directive NIS2 et concerne-t-elle le cloud ?

NIS2 est une directive européenne qui élargit fortement le périmètre des entités soumises à des obligations de cybersécurité (entités essentielles et importantes). Elle concerne le cloud à plusieurs titres : gestion des risques, notification d'incidents, sécurisation de la chaîne d'approvisionnement (dont vos fournisseurs cloud) et responsabilité des dirigeants, sous la supervision de l'ANSSI en France.

Qu'est-ce que le règlement DORA et qui est concerné ?

DORA est un règlement européen sur la résilience opérationnelle numérique du secteur financier et assurantiel (banques, assureurs, sociétés de gestion, prestataires de paiement, certains prestataires informatiques tiers). Appliqué au cloud, il impose un registre d'information des prestataires, la gestion du risque tiers, des stratégies de sortie et de réversibilité, et des tests de résilience pouvant aller jusqu'aux tests de pénétration fondés sur la menace.

Qu'est-ce que le CLOUD Act et quel impact sur mes données ?

Le CLOUD Act est une loi américaine permettant aux autorités d'accéder, via un fournisseur soumis au droit américain, à des données qu'il détient, y compris stockées en Europe. Combiné au FISA 702, il fonde le débat sur la souveraineté numérique. Pour s'en prémunir sur les données les plus sensibles, on recourt au chiffrement avec clés maîtrisées (HYOK), au cadre de transfert RGPD, ou à un cloud souverain qualifié SecNumCloud.

Comment héberger des données de santé dans le cloud en conformité ?

L'hébergement de données de santé en France exige un hébergeur certifié HDS, la certification vise l'hébergeur, pas votre application. Azure et AWS disposent de régions et services certifiés HDS, et il existe des hébergeurs français certifiés. La conformité globale exige en plus un chiffrement renforcé, une traçabilité des accès, des contrats stricts (art. 28 RGPD) et des PRA/PCA testés.