Audit de conformité cloud

Un audit de conformité cloud ne consiste pas à cocher des cases pour rassurer un comité. Il s'agit de démontrer, preuves à l'appui, que vos données, vos identités et vos configurations résistent à la fois à une attaque et à un contrôle d'une autorité. Cette page est le guide de référence pour comprendre, cadrer et réussir un audit de conformité cloud sur Microsoft Azure comme sur AWS, en multi-cloud comme en cloud hybride : méthode complète, tous les référentiels (RGPD, ISO 27001, NIS2, DORA, SecNumCloud, HDS), l'outillage concret, les livrables, la fourchette de prix et les non-conformités les plus fréquentes.

Qu'est-ce qu'un audit de conformité cloud ?

Un audit de conformité cloud est l'examen méthodique d'un environnement hébergé sur une plateforme de cloud public (Microsoft Azure, AWS) ou hybride, confronté à un ou plusieurs référentiels réglementaires et normatifs (RGPD, ISO 27001/27017/27018, NIS2, DORA, SecNumCloud, HDS, CIS Benchmarks). Son objectif n'est pas seulement technique : il s'agit de prouver que votre infrastructure, votre organisation et vos contrats respectent les obligations qui s'appliquent à votre activité, et de documenter cette preuve de façon opposable.

Là où un audit d'infrastructure classique part de l'inventaire des serveurs, l'audit de conformité cloud s'ancre dans des 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. Il croise trois plans indissociables (technique, organisationnel et juridique) qu'un audit purement informatique laisse souvent de côté.

À retenir. La conformité n'est pas un état figé : c'est la capacité à démontrer, à tout moment, l'écart entre votre posture réelle et le référentiel applicable, et à le réduire de façon priorisée.

Audit de conformité, audit de sécurité, audit de configuration : ne pas confondre

Ces trois démarches se recouvrent partiellement mais ne répondent pas à la même question. Les confondre conduit à acheter le mauvais livrable.

| Critère | Audit de conformité cloud | Audit de sécurité cloud | Audit de configuration | |---|---|---|---| | Question posée | « Suis-je conforme aux obligations qui m'engagent (RGPD, NIS2, DORA, HDS…) ? » | « Mon environnement est-il bien protégé contre les menaces ? » | « Mes ressources sont-elles paramétrées selon les bonnes pratiques ? » | | Référentiel | Réglementaire + normatif (RGPD, ISO 27001, NIS2, DORA, SecNumCloud) | CIS Benchmarks, Well-Architected, ANSSI, ISO 27001 | CIS Benchmarks, baselines fournisseur | | Portée | Technique + organisationnelle + juridique/contractuelle | Surtout technique + posture | Strictement technique | | Sortie | Matrice de conformité + écarts + preuves + plan d'action | Matrice de risques + remédiation | Liste d'écarts de configuration | | Finalité | Démontrer la conformité, réduire le risque juridique | Réduire le risque d'incident | Durcir les paramètres |

L'audit de configuration est un sous-ensemble de l'audit de sécurité, lui-même un volet de l'audit de conformité. Pour la démarche purement défensive, voyez notre page dédiée à l'audit de sécurité cloud ; la conformité y ajoute la couche normative et contractuelle.

Pourquoi réaliser un audit de conformité cloud ?

La motivation n'est jamais « cocher une case ». Elle se résume à quatre enjeux, que nous formulons toujours en langage de décision : juridique, financier, réputationnel, opérationnel.

• Risque juridique et sanctions. Le RGPD prévoit des amendes pouvant 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 ; l'ANSSI, dans le cadre de NIS2, dispose désormais de pouvoirs de supervision et de sanction étendus. La non-conformité n'est plus un risque théorique.
• Risque financier. Au-delà des amendes, une 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 faille de conformité, c'est aussi des coûts de remédiation en urgence, toujours supérieurs à ceux d'une mise en conformité planifiée.
• Risque réputationnel. Une fuite de données ou une sanction publiée par la CNIL 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 cloud.

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

Le modèle de responsabilité partagée : qui est responsable de la conformité ?

C'est le concept fondateur, et le plus mal compris, de la conformité cloud. Le fournisseur sécurise le cloud lui-même ; vous restez responsable de ce que vous mettez dans le cloud. Cette frontière conditionne directement qui doit prouver quoi lors d'un audit.

• AWS distingue la « sécurité du cloud » (responsabilité d'AWS : datacenters, matériel, hyperviseur, réseau physique) de la « sécurité dans le cloud » (votre responsabilité : configuration, données, IAM, chiffrement, conformité applicative).
• Azure formule la même logique : Microsoft sécurise l'infrastructure physique et la couche de virtualisation ; vous restez responsable de vos données, identités, terminaux et configurations.

La règle invariante sur les deux plateformes : les données et les identités sont toujours de votre responsabilité, quel que soit le modèle de service. Un hébergeur peut être certifié HDS ou détenir une attestation SecNumCloud ; cela ne rend pas votre configuration conforme pour autant. La certification du fournisseur couvre la couche dont il a la charge, pas vos buckets ouverts, vos rôles surprivilégiés ou vos sauvegardes absentes.

Erreur classique. « Notre hébergeur est certifié, donc nous sommes conformes. » Faux. La certification du fournisseur est une condition nécessaire, jamais suffisante. L'audit de conformité porte précisément sur votre moitié de la responsabilité partagée.

| Couche de service | Vous prouvez la conformité de… | Le fournisseur prouve la conformité de… | |---|---|---| | IaaS (VM, EC2) | OS invité, patchs, réseau virtuel, IAM, chiffrement, données | Hôte physique, hyperviseur, réseau physique | | PaaS (Azure SQL, RDS, Blob, S3) | Configuration du service, IAM, chiffrement, données | OS, runtime, patchs de la plateforme | | SaaS | Paramétrage, gestion des accès, données | Application et infrastructure sous-jacente |

Les référentiels et normes applicables au cloud

Le paysage normatif français et européen s'est densifié. Tous ces référentiels ne s'appliquent pas à tous ; l'une des premières missions de l'audit est de déterminer lesquels vous engagent réellement. Voici la cartographie complète.

RGPD (Règlement général sur la protection des données)

Socle transversal. Pour le cloud, deux articles structurent l'audit :

• Article 28 (sous-traitance) : votre fournisseur cloud est un sous-traitant au sens du RGPD. Vous devez disposer d'un DPA (Data Processing Agreement) conforme, encadrant les finalités, la durée, les mesures de sécurité, le recours à des sous-traitants ultérieurs et la localisation des données.
• Transferts hors UE et CLOUD Act : si votre fournisseur est soumis au droit américain (CLOUD Act), vos données peuvent théoriquement faire l'objet d'une demande d'accès extraterritoriale. L'audit examine la localisation effective des données, les garanties contractuelles et l'opportunité d'une offre souveraine.

ISO 27001, 27017, 27018, 27005

• ISO 27001 : norme de référence du système de management de la sécurité de l'information (SMSI). Cadre organisationnel.
• ISO 27017 : code de bonnes pratiques de sécurité spécifique au cloud (partage des responsabilités, suppression d'actifs en fin de contrat, isolation des environnements virtuels).
• ISO 27018 : protection des données à caractère personnel dans le cloud public. Quasiment absente des audits concurrents, elle est pourtant centrale pour un prestataire qui héberge des données clients.
• ISO 27005 : méthode de gestion des risques, complémentaire à EBIOS Risk Manager (méthode de l'ANSSI).

NIS2 (directive européenne sur la cybersécurité)

Transposée en droit français, NIS2 élargit considérablement le périmètre des entités concernées. Elle distingue les entités essentielles (énergie, santé, transport, banque, infrastructures numériques…) et les entités importantes (services postaux, fabrication, recherche…). Les obligations portent sur la gestion des risques, la notification d'incidents, la sécurité de la chaîne d'approvisionnement et la responsabilité des dirigeants. L'ANSSI en est l'autorité de supervision.

DORA (résilience opérationnelle du secteur financier)

Règlement européen applicable aux banques, assurances, sociétés de gestion et à leurs prestataires tiers critiques (dont les fournisseurs cloud). DORA impose une gestion du risque lié aux TIC, des tests de résilience opérationnelle, une supervision des prestataires tiers et des exigences de réversibilité. Concrètement, un audit DORA appliqué au cloud examine vos RTO/RPO, vos PRA/PCA, la cartographie de vos prestataires critiques et vos clauses de sortie.

SecNumCloud et EUCS

• SecNumCloud : qualification de l'ANSSI attestant un haut niveau de sécurité et d'immunité aux lois extraterritoriales. Visa de référence pour les données sensibles et le secteur public.
• EUCS (European Cybersecurity Certification Scheme for Cloud Services) : schéma européen porté par l'ENISA, destiné à harmoniser la certification cloud à l'échelle de l'UE. Son articulation avec SecNumCloud reste en cours de stabilisation ; un audit anticipe cette convergence.

HDS (Hébergement de Données de Santé)

Obligatoire dès que vous traitez des données de santé à caractère personnel. La certification HDS vise l'hébergeur, pas votre application : Azure et AWS disposent d'offres hébergées chez des partenaires certifiés HDS, mais c'est votre configuration (chiffrement, traçabilité, gestion des accès, localisation) qui détermine si l'usage est conforme. Sujet majeur en France, presque absent des audits concurrents, nous y consacrons une section dédiée plus bas.

CSA STAR / Cloud Controls Matrix, SOC 2, CIS Benchmarks

• CSA STAR et la Cloud Controls Matrix (CCM) : référentiel de contrôles cloud de la Cloud Security Alliance, utile pour structurer une matrice d'audit indépendante du fournisseur.
• SOC 2 : rapport d'attestation très demandé par les grands comptes anglo-saxons et les clients d'éditeurs SaaS.
• CIS Benchmarks : référentiels techniques de durcissement, déclinés spécifiquement pour Azure et AWS, le socle concret de la partie technique de l'audit.

| Référentiel | Qui est concerné | Nature | Autorité / cadre | |---|---|---|---| | RGPD | Tout traitement de données personnelles | Réglementaire | CNIL | | NIS2 | Entités essentielles & importantes | Réglementaire | ANSSI | | DORA | Secteur financier & assurance + prestataires TIC | Réglementaire | ACPR / AMF | | HDS | Traitement de données de santé | Réglementaire | Ministère de la Santé / organismes accrédités | | SecNumCloud | Données sensibles, secteur public | Qualification | ANSSI | | EUCS | Services cloud (UE, en déploiement) | Certification | ENISA | | ISO 27001/27017/27018 | Tout organisme volontaire | Norme | Organismes certificateurs | | CSA STAR / CCM | Fournisseurs & clients cloud | Référentiel | Cloud Security Alliance | | SOC 2 | Prestataires de services (B2B) | Attestation | Auditeurs habilités |

Les trois volets indissociables d'un audit de conformité cloud

Un audit qui ne couvre qu'un seul plan produit une fausse assurance. La conformité réelle repose sur trois volets, audités conjointement.

1. Le volet technique

L'examen des configurations effectives de votre environnement : identités, réseau, chiffrement, journalisation, sauvegardes. C'est la partie outillée (CSPM, scans automatisés). Elle répond à : « ce qui est déployé est-il conforme ? »

2. Le volet organisationnel

La gouvernance, les processus, les rôles et responsabilités (RSSI, DPO, DSI), les politiques (PSSI), la gestion des habilitations, la sensibilisation, la cartographie des actifs et la classification des données. Une configuration parfaite sans processus de maintien n'est conforme qu'un instant.

3. Le volet juridique et contractuel

L'examen des contrats cloud : DPA conforme à l'article 28, clauses de réversibilité, localisation des données, sous-traitants ultérieurs, exposition au CLOUD Act, niveaux de service. C'est le volet le plus souvent oublié, et celui qui engage le plus en cas de contrôle.

Ces trois volets ne se vendent pas séparément sans risque. Un rapport qui valide la technique mais ignore le DPA laisse une faille de conformité béante. Notre méthode les traite ensemble.

Méthodologie : comment se déroule un audit de conformité cloud ?

Notre démarche suit une trame éprouvée sur plus de 120 projets, alignée sur les bonnes pratiques d'analyse de risque (EBIOS Risk Manager, ISO 27005). Elle se déroule en cinq étapes.

1. Cadrage et périmètre. Définition des référentiels applicables, des comptes et abonnements concernés, des données et de leur sensibilité, des interlocuteurs (DSI, RSSI, DPO). On délimite ce qui est dans le périmètre, et ce qui n'y est pas.
2. Inventaire et cartographie. Recensement exhaustif des actifs cloud (comptes, ressources, identités, flux, données), classification des données, identification des « zones d'ombre » (comptes orphelins, ressources non taguées). Cette étape est décisive sur un cloud non documenté.
3. Analyse et collecte de preuves. Confrontation des configurations et des processus aux référentiels, via outillage automatisé (CSPM) et revue manuelle. Chaque écart est documenté, daté et tracé pour constituer une preuve opposable.
4. Évaluation des écarts et hiérarchisation. Chaque non-conformité est cotée par criticité (impact × probabilité) et reliée à l'obligation qu'elle enfreint. C'est ce qui distingue un audit utile d'une liste d'alertes brute.
5. Restitution. Présentation des résultats en langage clair (coûts, risques, délais), remise des livrables et discussion du plan d'action avec les décideurs.

Cette trame est commune au pilier audit d'infrastructure cloud, dont l'audit de conformité est une déclinaison orientée référentiels.

Les domaines techniques audités

Le volet technique s'organise en grands domaines, chacun mappé sur des contrôles concrets (CIS Benchmarks Azure et AWS).

Identités et accès (IAM)

Le domaine le plus à risque. On audite : politique de MFA généralisée, principe du moindre privilège, rôles et permissions, comptes de service, clés d'accès et leur rotation, comptes inactifs ou orphelins, séparation des environnements, approche Zero Trust. Sur Azure, l'examen porte sur Microsoft Entra ID (Conditional Access, PIM) ; sur AWS, sur IAM Identity Center et les politiques IAM.

Réseau et exposition

Surface d'exposition publique, segmentation, groupes de sécurité, accès SSH/RDP ouverts, points de terminaison privés, pare-feu applicatifs, exposition involontaire de bases managées.

Données et chiffrement

Chiffrement au repos et en transit, gestion des clés (Azure Key Vault, AWS KMS), classification, localisation, masquage, anonymisation lorsqu'elle est requise.

Sauvegardes, PRA et PCA

Existence et test des sauvegardes, immuabilité, objectifs RTO/RPO documentés et testés, plan de reprise (PRA) et de continuité (PCA), exigence renforcée par DORA pour le secteur financier.

Supervision, journalisation et logs

Activation et centralisation des journaux, conservation conforme, intégration SIEM, détection d'anomalies, traçabilité des accès aux données sensibles. Une journalisation absente, c'est l'impossibilité de prouver, et une non-conformité directe au RGPD comme à HDS.

Gouvernance, cartographie des actifs et classification des données

Aucune conformité durable sans gouvernance. Avant même d'auditer les configurations, il faut savoir ce que l'on possède. La cartographie des actifs cloud recense comptes, abonnements, ressources, identités, flux de données et leur criticité. La classification des données (publiques, internes, confidentielles, données personnelles, données de santé) conditionne les exigences applicables : on ne protège pas un bucket de logs anonymes comme une base de dossiers médicaux.

Le tagging FinOps (étiquetage systématique des ressources) sert ici un double objectif rarement relié à la conformité : il permet d'attribuer chaque ressource à un propriétaire, donc d'éliminer les comptes orphelins et les ressources fantômes, qui sont à la fois un gaspillage budgétaire et un angle mort de conformité (ressources non supervisées, non patchées, non auditées). C'est pourquoi nous croisons systématiquement la posture de conformité et la posture FinOps (voir notre audit FinOps et la optimisation des coûts cloud).

Un actif que vous ne connaissez pas est un actif que vous ne pouvez ni sécuriser, ni rendre conforme. La cartographie n'est pas une formalité : c'est le fondement de l'audit.

Conformité Azure vs conformité AWS : les services natifs côte à côte

C'est l'un de nos différenciateurs : peu de prestataires traitent les deux plateformes ensemble, alors que la majorité des environnements sont aujourd'hui mixtes. Les concepts sont communs, les outils diffèrent.

| Domaine | Microsoft Azure | AWS | |---|---|---| | Posture & CSPM | Microsoft Defender for Cloud (Secure Score, réglementations intégrées) | AWS Security Hub (security standards, scores) | | Conformité par politiques | Azure Policy (Policy as Code, initiatives, denied/audit) | AWS Config (rules, conformance packs) | | Gouvernance multi-comptes | Management Groups + Cloud Adoption Framework (landing zone) | AWS Control Tower / Landing Zone Accelerator | | Identités | Microsoft Entra ID (Conditional Access, PIM) | IAM Identity Center, IAM policies | | Gestion des clés | Azure Key Vault | AWS KMS | | Journalisation | Azure Monitor, Log Analytics | CloudTrail, CloudWatch | | Benchmarks | CIS Microsoft Azure Foundations Benchmark | CIS Amazon Web Services Foundations Benchmark |

Sur Azure, Defender for Cloud propose des tableaux de bord de conformité réglementaire prêts à l'emploi (RGPD, ISO 27001, SOC, etc.) et Azure Policy permet d'appliquer des règles en Policy as Code qui bloquent ou auditent les déploiements non conformes. Côté AWS, Security Hub agrège les écarts par standard, AWS Config évalue les ressources contre des conformance packs, et Control Tower gouverne les comptes multiples via des garde-fous (guardrails).

Pour un audit ciblé sur une seule plateforme, voyez nos pages dédiées : audit Azure et audit AWS. Pour la revue alignée sur les six piliers AWS, l'AWS Well-Architected Review.

Audit de conformité multi-cloud et hybride

La majorité des organisations exploitent plusieurs fournisseurs et conservent des actifs on-premise. L'enjeu devient l'orchestration : maintenir une cartographie unifiée des contrôles entre providers, alors que chaque plateforme parle son propre langage. Concrètement, l'audit multi-cloud :

• établit une matrice de contrôles commune (alignée CSA CCM ou CIS) traduite ensuite en règles natives par plateforme ;
• consolide les écarts dans un référentiel unique pour éviter les angles morts entre Azure, AWS et l'on-premise ;
• examine les flux inter-cloud et hybrides (interconnexions, chiffrement des transits, identités fédérées) ;
• vérifie la cohérence des politiques de conservation et de localisation des données entre environnements.

Sur Kubernetes, qu'il soit géré (AKS, EKS) ou auto-hébergé, la conformité ajoute ses propres contrôles : RBAC, network policies, admission control, Pod Security, gestion des secrets. C'est l'objet de notre audit Kubernetes.

Outillage et automatisation : CSPM, Policy as Code, scans

L'audit moderne combine outillage automatisé et expertise humaine. L'outil détecte vite et à l'échelle ; l'expert interprète, hiérarchise et relie l'écart technique à l'obligation réglementaire.

• CSPM (Cloud Security Posture Management) : surveillance continue de la posture. Defender for Cloud (Azure), Security Hub (AWS) en sont les implémentations natives.
• Policy as Code : règles de conformité versionnées (Azure Policy, AWS Config rules, Open Policy Agent), qui empêchent la dérive avant le déploiement.
• Scans automatisés : ScoutSuite (audit multi-cloud open source), Prowler (AWS/Azure, mappé sur de nombreux référentiels), évaluations contre les CIS Benchmarks.
• Outils GRC : Vanta, Drata pour la collecte continue de preuves et le pilotage des contrôles dans le temps.

L'outil ne remplace pas le jugement. Un scan signale un bucket public ; seul l'expert sait si ce bucket contient des données personnelles, donc si l'écart est mineur ou critique au regard du RGPD.

Les livrables d'un audit de conformité cloud

Un audit utile produit des documents exploitables par chaque public, du technicien au comité de direction. Nos livrables :

| Livrable | Destinataire | Contenu | |---|---|---| | Rapport exécutif | Direction, COMEX, DAF | Synthèse en langage clair : niveau de conformité, risques majeurs, coûts et délais de remédiation, décisions à prendre | | Rapport technique | DSI, RSSI, équipes | Matrice de conformité détaillée, écarts par domaine, preuves, recommandations techniques mappées CIS/ISO | | Plan d'action priorisé | DSI, chefs de projet | Remédiations cotées par criticité, quick wins immédiats, feuille de route, estimation d'effort | | Matrice de contrôles | RSSI, DPO | Tableau de correspondance contrôles ↔ référentiels (RGPD, ISO, NIS2…) avec statut conforme / écart |

À cela s'ajoute une restitution orale auprès des décideurs, où nous traduisons chaque constat en arbitrage : ce qui doit être corrigé immédiatement, ce qui peut être planifié, ce qui relève d'un risque accepté en connaissance de cause.

Remédiation et plan d'action priorisé

Un audit sans plan d'action est un constat stérile. La remédiation s'organise par niveaux de priorité, fondés sur la criticité (impact × probabilité × portée réglementaire).

• Quick wins : corrections immédiates, à faible effort et fort impact (activer la MFA manquante, fermer un bucket public, faire tourner des clés exposées). Souvent réalisables en quelques heures.
• Remédiations structurantes : revue des rôles IAM, mise en place du chiffrement systématique, centralisation des journaux, automatisation par Policy as Code. Quelques jours à quelques semaines.
• Feuille de route : chantiers organisationnels et contractuels (refonte du DPA, mise en place d'un PRA testé, démarche de qualification SecNumCloud ou de certification). Plusieurs mois.

Nous pouvons accompagner la remédiation (voir nos services de sécurisation de l'infrastructure cloud et de cybersécurité cloud), ou vous laisser la conduire en autonomie : tout ce qui est produit (code IaC Terraform/Bicep, politiques, documentation) vous est remis dans vos dépôts. C'est l'objet de notre engagement de réversibilité, détaillé plus bas.

Conformité continue vs audit ponctuel

Un audit ponctuel photographie un instant. Or la conformité se dégrade en continu : chaque déploiement, chaque nouvelle ressource, chaque changement de configuration peut introduire un écart. La réponse moderne est la conformité continue (GRC) : preuves collectées en permanence, contrôles automatisés, Policy as Code qui bloque la dérive à la source, et tableaux de bord de posture (Secure Score, Security Hub) suivis dans le temps.

Concrètement, on combine un audit approfondi périodique (le point de référence opposable) et une surveillance continue entre deux audits. Cette logique s'intègre naturellement à une démarche d'infogérance cloud entreprise, où la conformité devient un état maintenu plutôt qu'un événement subi.

Combien coûte un audit de conformité cloud ? Durée et budget

Aucun concurrent français ne chiffre cet exercice. Nous le faisons, en toute transparence, dans la limite de ce qui est honnête : un prix ferme sans cadrage n'existe pas. Le budget dépend du nombre de comptes et d'abonnements, du volume de référentiels visés, du multi-cloud, et de la profondeur du volet juridique.

| Périmètre | Durée indicative | Budget indicatif (sur devis) | |---|---|---| | Audit ciblé (un compte, un référentiel, quick assessment) | 2 à 3 jours | à partir de ~5 000 € | | Audit standard (environnement mono-cloud, RGPD + ISO/CIS) | 4 à 6 jours | 7 000 – 10 000 € | | Audit complet (multi-cloud / hybride, plusieurs référentiels, volet juridique) | 6 à 10 jours | 10 000 – 12 000 € et plus |

Budget indicatif, sur devis selon le périmètre. Ces fourchettes sont des ordres de grandeur, établis sur des missions représentatives. Le devis ferme est remis après un cadrage gratuit, sans engagement. Nous n'appliquons aucun coût caché.

La durée d'un audit de conformité cloud s'étend en moyenne de 2 à 7 jours ouvrés pour la phase d'analyse, hors restitution et hors remédiation. Un audit n'est jamais un investissement perdu : le coût d'une mise en conformité planifiée est systématiquement inférieur à celui d'une remédiation en urgence après contrôle ou incident.

Pour lancer un cadrage, commencez par notre diagnostic en ligne, il pose en quelques minutes les bases du périmètre.

HDS : la conformité du cloud de santé

Sujet majeur en France, presque totalement absent des audits concurrents. Dès qu'une organisation héberge ou traite des données de santé à caractère personnel pour le compte d'un tiers, l'Hébergement de Données de Santé (HDS) s'impose.

Point essentiel, souvent mal compris : la certification HDS vise l'hébergeur, pas votre application ni votre configuration. Azure et AWS proposent des services hébergés chez des partenaires certifiés HDS, mais cela ne suffit pas. La conformité réelle dépend de votre usage :

• chiffrement systématique des données de santé au repos et en transit ;
• traçabilité complète des accès (qui a consulté quoi, quand) ;
• gestion stricte des habilitations et MFA ;
• localisation des données et maîtrise de la sous-traitance ultérieure ;
• conformité du DPA et des engagements de réversibilité.

Notre audit vérifie l'alignement entre vos obligations HDS et votre configuration effective sur Azure ou AWS, et identifie précisément ce qui relève de l'hébergeur certifié et ce qui reste de votre responsabilité. Pour aller plus loin, voyez notre page secteur santé.

DORA appliqué concrètement au cloud financier

Pour les banques, assurances et sociétés de gestion, DORA n'est pas une option. Appliqué au cloud, il se traduit par des contrôles très concrets :

• Tests de résilience opérationnelle : votre PRA est-il documenté, testé, et les résultats tracés ?
• RTO/RPO : sont-ils définis par criticité d'application et tenus lors des tests ?
• Supervision des prestataires tiers critiques : votre fournisseur cloud, en tant que prestataire TIC critique, fait-il l'objet d'un suivi contractuel conforme (registre, audits, droit d'audit, plan de sortie) ?
• Réversibilité : disposez-vous d'une stratégie de sortie crédible si le prestataire devient indisponible ou non conforme ?

Notre audit cartographie vos dépendances cloud critiques et confronte vos dispositifs aux exigences DORA. Voyez aussi notre page secteur finance.

Réversibilité et autonomie : l'angle que le marché évite

La plupart des prestataires d'audit livrent un rapport et créent, au passage, une dépendance. Notre position est inverse, et c'est un différenciateur que ni un prestataire d'audit généraliste ni un intégrateur lié à un fournisseur ne porte facilement.

• Tout ce qui est construit vous appartient. Le code Infrastructure as Code (Terraform, Bicep) produit pendant la remédiation est versionné dans vos dépôts.
• Les comptes cloud sont à votre nom. Pas d'enfermement par un compte de revente intermédiaire.
• La documentation est remise. Cartographie, matrices de contrôles, procédures : vous repartez avec les moyens de maintenir la conformité sans nous.
• La réversibilité est auditée elle-même. Un audit de conformité examine votre capacité à sortir d'un fournisseur, exigence explicite de DORA et bonne pratique RGPD/SecNumCloud.

L'indépendance vis-à-vis d'Azure et d'AWS rend cet engagement crédible : nous recommandons ce qui sert votre conformité, pas ce qui nous lie à un fournisseur. C'est l'esprit de notre démarche, détaillée sur la page à propos.

Les non-conformités cloud les plus fréquentes

Sur la grande majorité des audits, les mêmes écarts reviennent. En voici le palmarès, avec leur criticité typique.

| Non-conformité | Pourquoi c'est grave | Criticité | |---|---|---| | Bucket / conteneur de stockage public | Exposition directe de données, potentiellement personnelles | Critique | | MFA absente sur des comptes à privilèges | Compromission par vol d'identifiants | Critique | | Compte / ressource orphelin non supervisé | Angle mort : non patché, non audité, oublié | Élevée | | Clés d'accès non rotées ou en clair dans un dépôt | Fuite d'identifiants durable | Élevée | | Journalisation désactivée ou non conservée | Impossibilité de prouver, non-conformité RGPD/HDS | Élevée | | Rôle IAM surprivilégié (wildcard *) | Escalade de privilèges, violation du moindre privilège | Élevée | | Chiffrement absent au repos ou en transit | Non-conformité directe sur données sensibles | Élevée | | DPA absent ou non conforme (art. 28) | Faille juridique en cas de contrôle | Élevée | | Sauvegardes non testées / pas de PRA | Non-reprise après incident, écart DORA | Moyenne à élevée |

Aucune de ces non-conformités n'est exotique. Ce sont des erreurs de configuration et de gouvernance ordinaires, précisément ce qu'un audit méthodique détecte et corrige avant qu'un tiers ne le fasse.

Erreurs fréquentes lors d'un audit de conformité cloud

Côté démarche cette fois, voici les pièges qui ruinent la valeur d'un audit :

• Confondre la certification du fournisseur avec sa propre conformité. Le piège n°1, déjà évoqué.
• Auditer la technique en ignorant le contractuel. Un rapport sans revue du DPA et de la réversibilité est incomplet.
• Produire une liste d'alertes sans hiérarchisation. 800 écarts non priorisés paralysent au lieu d'aider à décider.
• Auditer une fois et oublier. Sans conformité continue, la photo est périmée en quelques semaines.
• Oublier les actifs non documentés. L'audit doit commencer par la cartographie, sinon il valide un périmètre tronqué. Si votre cloud est dans ce cas, lisez cloud non documenté : que faire ? et remettre de l'ordre dans son cloud.
• Choisir un auditeur juge et partie. Un prestataire qui audite ce qu'il a lui-même intégré manque d'indépendance.

Pourquoi confier votre audit de conformité à Architecte Cloud

Nous sommes un intermédiaire indépendant qui cadre votre besoin et vous met en relation avec des prestataires et experts qualifiés sur Microsoft Azure et AWS. Notre légitimité repose sur des éléments vérifiables :

• 12 ans d'expertise, de nombreux projets accompagnés, un réseau de clients établi, une satisfaction client élevée.
• Prestataires et experts qualifiés du réseau, disposant des certifications requises : Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer, FinOps Certified Practitioner.
• Microsoft Azure Partner (Solutions Partner, Infrastructure) et AWS Partner (Advanced Tier Services).
• Démarche ISO 27001 interne et recours, lorsque c'est requis, à des partenaires d'hébergement certifiés HDS.
• Indépendance vis-à-vis des fournisseurs : nous conseillons sans parti pris Azure/AWS.
• Autonomie et réversibilité : ce qui est construit vous appartient.

Pour une vue d'ensemble de notre offre, voyez nos services, notre approche du conseil en architecture et le guide du cloud.

Prêt à savoir où vous en êtes vraiment ? Lancez votre diagnostic de conformité en ligne ou contactez-nous pour un devis. Réponse sous 48 h ouvrées.

FAQ : Audit de conformité cloud

Qu'est-ce qu'un audit de conformité cloud ?

C'est l'examen méthodique d'un environnement cloud (Azure, AWS, hybride) confronté aux référentiels réglementaires et normatifs qui s'appliquent à votre activité (RGPD, ISO 27001, NIS2, DORA, SecNumCloud, HDS). Il couvre trois volets indissociables (technique, organisationnel et juridique) et produit une matrice de conformité, des preuves et un plan d'action priorisé.

Pourquoi réaliser un audit de conformité cloud ?

Pour quatre raisons : réduire le risque juridique (sanctions CNIL/ANSSI, amendes RGPD jusqu'à 20 M€ ou 4 % du chiffre d'affaires mondial), le risque financier (contrats bloqués, remédiation d'urgence), le risque réputationnel, et gagner en maîtrise opérationnelle. Un rapport d'audit récent est aussi devenu un argument commercial exigé par les grands comptes et les assureurs cyber.

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

L'audit de sécurité répond à « suis-je bien protégé ? » et vise les menaces. L'audit de conformité répond à « suis-je en règle ? » et vise les obligations réglementaires et normatives. La conformité englobe la sécurité technique mais y ajoute les volets organisationnel et juridique/contractuel (DPA, réversibilité, localisation des données).

Quelles normes et réglementations s'appliquent au cloud ?

Selon votre activité : RGPD (transversal), NIS2 (entités essentielles et importantes), DORA (finance et assurance), HDS (données de santé), SecNumCloud et EUCS (données sensibles, souveraineté), ainsi que les normes volontaires ISO 27001, 27017, 27018, CSA STAR et SOC 2. L'audit commence par déterminer lesquelles vous engagent réellement.

Combien coûte un audit de conformité cloud ?

Le budget indicatif s'échelonne d'environ 5 000 € pour un audit ciblé à 12 000 € et plus pour un audit complet multi-cloud avec volet juridique. Le prix dépend du nombre de comptes, des référentiels visés et de la profondeur attendue. Il est toujours établi sur devis après un cadrage gratuit, sans coût caché.

Combien de temps dure un audit de conformité cloud ?

La phase d'analyse dure en moyenne 2 à 7 jours ouvrés, selon le périmètre : 2 à 3 jours pour un audit ciblé, jusqu'à 10 jours pour un audit complet multi-cloud. La restitution et la remédiation s'ajoutent ensuite à ce calendrier.

Quels sont les livrables d'un audit de conformité cloud ?

Un rapport exécutif (pour la direction), un rapport technique détaillé (pour la DSI/RSSI), une matrice de contrôles reliant chaque exigence à son statut, et un plan d'action priorisé par criticité avec quick wins et feuille de route. Le tout complété par une restitution orale en langage clair (coûts, risques, délais).

Qu'est-ce que le modèle de responsabilité partagée dans le cloud ?

Le fournisseur (AWS, Azure) sécurise le cloud lui-même (datacenters, matériel, hyperviseur) ; vous restez responsable de ce que vous mettez dans le cloud (données, identités, configurations). Une certification du fournisseur ne rend pas votre configuration conforme : l'audit porte précisément sur votre part de responsabilité.

Quelle est la fréquence recommandée pour un audit de conformité cloud ?

Nous recommandons un audit approfondi annuel pour les entités essentielles ou les environnements critiques, et tous les 18 à 24 mois pour les contextes moins exposés, complété par une surveillance continue (CSPM, Policy as Code) entre deux audits. Tout changement majeur d'architecture justifie un audit complémentaire.

Comment auditer la conformité d'un environnement multi-cloud ou hybride ?

En établissant une matrice de contrôles commune (alignée CSA CCM ou CIS) traduite ensuite en règles natives par plateforme (Azure Policy, AWS Config), puis en consolidant les écarts dans un référentiel unique. L'audit examine aussi les flux inter-cloud, les identités fédérées et la cohérence des politiques de localisation et de conservation des données.

Quelles sont les non-conformités cloud les plus fréquentes ?

Les plus courantes : stockage objet laissé public, MFA absente sur des comptes à privilèges, comptes et ressources orphelins non supervisés, clés d'accès non rotées ou exposées, journalisation désactivée, rôles IAM surprivilégiés, chiffrement manquant et DPA non conforme à l'article 28 du RGPD. Toutes sont détectables et corrigeables par un audit méthodique.

Quels outils utiliser pour auditer la conformité d'une infrastructure cloud ?

Les outils CSPM natifs (Microsoft Defender for Cloud, AWS Security Hub), la conformité par politiques (Azure Policy, AWS Config), les scans open source (ScoutSuite, Prowler) évalués contre les CIS Benchmarks, et les plateformes GRC (Vanta, Drata) pour la conformité continue. L'outillage ne remplace pas le jugement de l'expert qui relie l'écart technique à l'obligation réglementaire.