Gouvernance cloud

La gouvernance cloud n'est pas une couche de bureaucratie qui freine vos équipes : c'est l'ensemble des règles, des rôles et des automatismes qui permettent à vos équipes d'aller vite sans casser la conformité, les coûts ou la sécurité. La plupart des dérapages cloud (facture qui double, ressource exposée, audit raté) ne viennent pas d'un manque de talent technique, mais d'un manque de cadre partagé. Ce guide opérationnel détaille la gouvernance cloud de bout en bout sur Microsoft Azure et AWS : définition, piliers, organisation (CCoE, comité, matrice RACI), conformité française et européenne, gouvernance par le code, KPI de pilotage, feuille de route 30/60/90 jours et budget indicatif.

Qu'est-ce que la gouvernance cloud ?

La gouvernance cloud est le cadre de règles, de rôles et de processus de décision qui encadre la manière dont une organisation conçoit, déploie, exploite et finance ses ressources sur le cloud. Elle répond à trois questions de direction : qui a le droit de faire quoi ?, selon quelles règles ?, et comment s'assure-t-on que ces règles sont réellement appliquées ? Là où la gestion du cloud exécute le travail au quotidien, la gouvernance définit les garde-fous à l'intérieur desquels ce travail s'effectue.

Concrètement, une gouvernance cloud repose sur quatre composantes indissociables :

• Des règles (politiques) : ce qui est autorisé, interdit ou imposé (régions de déploiement permises, types de ressources, chiffrement obligatoire, étiquetage minimal, niveaux d'accès).
• Des rôles et des responsabilités : qui définit les règles, qui les applique, qui les contrôle, qui décide des exceptions. C'est l'objet de la matrice RACI et du Cloud Center of Excellence.
• Des processus de décision : comment on arbitre un nouveau besoin, comment on gère une exception, à quelle cadence se réunit le comité de gouvernance, comment on fait évoluer les règles.
• Des garde-fous techniques : les mécanismes qui rendent les règles effectives sans intervention humaine (Azure Policy, AWS Service Control Policies, pipelines de déploiement, alertes budgétaires).

À retenir : une politique écrite dans un document Word que personne n'applique n'est pas de la gouvernance, c'est de la documentation. La gouvernance cloud moderne se mesure à ce qui est automatiquement empêché ou détecté, pas à ce qui est recommandé.

La gouvernance cloud n'est ni un produit que l'on achète, ni un projet qui se termine. C'est une discipline continue qui évolue avec votre maturité, votre périmètre réglementaire et votre empreinte cloud. Elle s'appuie sur des cadres de référence éprouvés, le Cloud Adoption Framework (CAF) de Microsoft, le Well-Architected Framework d'AWS et ses six piliers, que ce guide traduit en décisions concrètes. L'exposé détaillé de ces frameworks d'adoption (CAF, Well-Architected, vision Gartner) et de leur mise en œuvre par une équipe dédiée relève du guide Cloud Center of Excellence (CCoE) ; ici, on en retient les décisions de gouvernance, pas la mécanique d'adoption.

Pourquoi le mot « gouvernance » fait peur (et pourquoi c'est une erreur)

Beaucoup de DSI associent la gouvernance à du contrôle qui ralentit. C'est l'inverse d'une bonne gouvernance. Une gouvernance mal conçue bloque tout par précaution et pousse les équipes à contourner les règles : c'est ainsi que naît le Shadow IT. Une gouvernance bien conçue rend les choses sûres par défaut : une équipe déploie dans une zone d'atterrissage où le chiffrement, le réseau et les accès sont déjà conformes, et n'a pas à se poser la question. La liberté est encadrée, pas supprimée. Nous revenons plus loin sur cet équilibre vélocité/contrôle avec l'approche monitor-first.

Gouvernance, gestion et management cloud : la différence

La confusion entre gouvernance et gestion (ou « management ») du cloud est la première source de malentendus dans les comités de direction. Les deux sont nécessaires, mais ne répondent pas à la même question.

| | Gouvernance cloud | Gestion / management cloud | |---|---|---| | Question | Quelles sont les règles ? | Comment on exécute le travail ? | | Horizon | Stratégique, durable | Opérationnel, quotidien | | Exemples | Politiques d'étiquetage, accès, conformité ; arbitrage budgétaire ; définition des rôles | Déploiement, supervision, sauvegardes, tickets, mises à jour | | Porté par | CCoE, comité de gouvernance, sponsor exécutif | Équipes plateforme et équipes produit/charges de travail | | Mesuré par | Taux de conformité, % de ressources taguées, score de posture | Disponibilité, MTTR, débit de déploiement |

La gouvernance définit le terrain de jeu ; la gestion joue le match. Sans gouvernance, la gestion improvise des règles différentes dans chaque équipe, et les incohérences finissent en incidents, en surcoûts ou en non-conformités.

Où se situent FinOps et sécurité ?

FinOps et sécurité ne sont pas des disciplines parallèles à la gouvernance : ce sont des domaines gouvernés. La gouvernance financière est l'application des principes de gouvernance au domaine des coûts (budgets, alertes, étiquetage, arbitrages) ; la gouvernance de sécurité applique les mêmes principes aux identités, aux accès et à la conformité. Autrement dit, FinOps et sécurité sont des piliers de la gouvernance, pas des concurrents. C'est pourquoi la gouvernance cloud s'articule naturellement avec l'optimisation des coûts cloud et la sécurisation d'infrastructure cloud.

Pourquoi la gouvernance cloud est devenue stratégique

Tant qu'une entreprise n'avait qu'un seul environnement cloud, géré par une seule équipe, la gouvernance pouvait rester informelle. Ce temps est révolu. Quatre forces ont fait basculer la gouvernance du « confort » vers la « nécessité ».

• La décentralisation des décisions. Dans le cloud, n'importe quelle équipe peut créer une ressource en quelques secondes, avec une carte bancaire. Le pouvoir d'engager des dépenses et des risques s'est diffusé hors de la DSI. Sans cadre, chaque équipe réinvente ses propres règles.
• Le Shadow IT. Des services cloud souscrits hors de tout contrôle créent des zones aveugles : données non classifiées, accès non révoqués, coûts invisibles. On ne sécurise ni ne facture ce que l'on ne voit pas.
• La dérive des coûts. La facilité de déploiement est aussi la facilité de gaspillage : ressources surdimensionnées, environnements de test jamais éteints, stockage oublié. Sans garde-fous budgétaires, la facture cloud dérive structurellement à la hausse.
• La complexité multi-cloud et hybride. Beaucoup d'organisations exploitent à la fois Azure, AWS et de l'existant on-premise. Chaque plateforme a ses propres concepts d'accès, de coûts et de conformité. Gouverner cet ensemble hétérogène avec des règles cohérentes est devenu un enjeu de direction.

Le constat qui change tout : la question n'est plus « faut-il une gouvernance cloud ? » mais « voulez-vous la concevoir maintenant, à froid, ou la subir plus tard, après un incident ou un audit raté ? ». La gouvernance rétroactive coûte toujours plus cher que la gouvernance par conception.

À cela s'ajoute un durcissement réglementaire spécifique au marché français et européen (NIS2, DORA, exigences de l'ANSSI, hébergement de données de santé) qui transforme certaines règles de bonne pratique en obligations juridiques. Nous y consacrons une section complète.

Les piliers de la gouvernance cloud

Une gouvernance cloud complète couvre sept domaines. Chacun a ses politiques, ses outils et ses indicateurs. Les traiter en silo est l'erreur la plus fréquente : ils s'arbitrent ensemble.

1. Gouvernance des coûts (FinOps)

Maîtriser et optimiser la dépense cloud : budgets par équipe ou par projet, alertes de seuil, étiquetage qui permet la refacturation interne (showback/chargeback), arbitrage entre engagement et flexibilité (réservations, Savings Plans). La gouvernance financière fixe les règles ; le consultant FinOps les met en œuvre. C'est le pilier au retour sur investissement le plus visible.

2. Gouvernance de la sécurité

Définir et faire respecter les règles d'identité, d'accès, de chiffrement et de configuration. Elle s'appuie sur le principe du moindre privilège, le RBAC/ABAC, l'authentification multifacteur et des référentiels de durcissement (CIS Benchmarks). Elle s'incarne dans des outils de posture comme Microsoft Defender for Cloud ou AWS Security Hub.

3. Gouvernance de la conformité

Garantir que l'environnement respecte les référentiels qui vous engagent : RGPD, ISO 27001, NIS2, DORA, SecNumCloud, HDS selon votre secteur. C'est ici que les politiques techniques rencontrent le droit. Un volet entier de ce guide y est consacré.

4. Gouvernance des opérations

Encadrer l'exploitation : continuité d'activité (PRA/PCA, RTO/RPO), supervision, gestion des changements, résilience. La gouvernance opérationnelle définit, par exemple, qu'aucune charge de travail critique ne part en production sans plan de reprise testé.

5. Gouvernance des données

Classifier les données (publiques, internes, confidentielles, sensibles), définir leur cycle de vie, leur localisation (souveraineté), leur chiffrement et leur droit d'accès. Microsoft Purview côté Azure outille cette classification. C'est le socle de toute conformité RGPD sérieuse.

6. Gouvernance de la gestion des ressources

Organiser la hiérarchie des ressources (groupes d'administration Azure, AWS Organizations), la nomenclature, l'étiquetage, les zones d'atterrissage. C'est la colonne vertébrale qui rend toutes les autres politiques applicables à grande échelle.

7. Gouvernance de l'IA

Domaine émergent mais désormais incontournable : encadrer l'usage de l'IA générative dans le cloud, filtrage de contenu, contrôle des données de grounding (les données qui alimentent un modèle), traçabilité des usages, conformité réglementaire des traitements. Microsoft et AWS intègrent ces garde-fous (Azure AI Content Safety, Amazon Bedrock Guardrails), mais leur configuration relève de votre gouvernance, pas du fournisseur.

À retenir : ces sept piliers ne se déploient pas tous en même temps. Une gouvernance débute presque toujours par les trois piliers à plus fort enjeu immédiat (coûts, sécurité, gestion des ressources) puis s'étend. Vouloir tout faire d'un coup est la meilleure façon de ne rien finir.

Rôles et responsabilités : qui gouverne le cloud ?

La gouvernance échoue le plus souvent non par manque d'outils, mais par flou organisationnel : personne ne sait qui décide quoi. Clarifier les rôles est le préalable à tout le reste.

Le Cloud Center of Excellence (CCoE)

Le Cloud Center of Excellence est l'équipe transverse qui porte la gouvernance cloud. Ce n'est pas une tour de contrôle qui valide chaque action : c'est une équipe qui construit les garde-fous, les outille et accompagne les équipes produit pour qu'elles soient autonomes en sécurité. Un bon CCoE produit des zones d'atterrissage prêtes à l'emploi, des modules d'infrastructure réutilisables et des politiques automatisées, plutôt que des procédures à suivre manuellement. Nous détaillons son fonctionnement dans le guide dédié au Cloud Center of Excellence (CCoE).

Les autres acteurs

• Le sponsor exécutif (DSI, parfois DG) : il porte la gouvernance au niveau direction, arbitre les conflits de priorité et donne le mandat. Sans sponsor, la gouvernance reste un projet technique sans autorité.
• Le RSSI : il définit les exigences de sécurité et de conformité, et valide leur traduction en politiques techniques.
• Le DAF / contrôle de gestion : copilote la gouvernance financière, valide les budgets et arbitre les engagements.
• L'équipe plateforme (platform team) : construit et opère les fondations communes (réseau, identités, landing zones, outillage IaC) que consomment les équipes produit.
• Les équipes charges de travail (workload teams) : déploient leurs applications à l'intérieur du cadre fourni. Elles sont responsables de leur application, pas de réinventer la sécurité du socle.

Activités de gouvernance : qui décide quoi (vue réduite)

La répartition des responsabilités se formalise dans une matrice RACI. En voici une version réduite, volontairement centrée sur les activités strictement de gouvernance, celles qui fixent les règles et arbitrent les exceptions (R = Réalise, A = Responsable final, C = Consulté, I = Informé).

| Activité de gouvernance | CCoE | Sponsor exécutif | RSSI | DAF | |---|---|---|---|---| | Définir la stratégie de gouvernance | R | A | C | C | | Définir les politiques de sécurité | C | I | A | I | | Définir les politiques de coûts (budgets) | C | A | I | A | | Arbitrer une demande d'exception | A | C | C | C | | Contrôler la conformité (audit interne) | A | I | C | C | | Arbitrer un dépassement budgétaire | C | A | I | A |

Le piège classique : confondre R et A. Plusieurs personnes peuvent réaliser (R) une tâche, mais une seule en est responsable finale (A). Quand le A est partagé ou absent, une décision n'est jamais prise, et la gouvernance se grippe.

La matrice RACI complète du silo, étendue à l'équipe plateforme et aux équipes produit (construction des landing zones, déploiement des charges, nomenclature), au dimensionnement de l'équipe et aux profils, est tenue à jour, en un seul exemplaire de référence, sur le guide Cloud Center of Excellence (CCoE).

Le comité de gouvernance cloud et sa cadence

La gouvernance vit dans des instances régulières. Un schéma éprouvé :

• Comité de gouvernance cloud (trimestriel) : sponsor exécutif, DSI, RSSI, DAF, CCoE. Décisions stratégiques, revue des KPI, arbitrages budgétaires, évolution des politiques majeures.
• Comité opérationnel (mensuel) : CCoE et équipe plateforme. Revue des exceptions, dérives détectées, nouvelles politiques techniques, dette de conformité.
• Revue de coûts (mensuelle) : CCoE, DAF, référents FinOps des équipes. Suivi des budgets, anomalies, opportunités d'optimisation.

Cette cadence est un point de départ. Une organisation en début de parcours réunit souvent ces instances plus fréquemment ; une organisation mature les espace à mesure que l'automatisation prend le relais du contrôle humain.

Conformité réglementaire : le volet français et européen

C'est ici que la gouvernance cloud cesse d'être une bonne pratique pour devenir une obligation. La plupart des contenus disponibles se limitent au RGPD et à l'ISO 27001. Le marché B2B français est concerné par un cadre bien plus dense, qu'une gouvernance sérieuse doit intégrer.

RGPD : responsable de traitement et sous-traitant

Le RGPD structure la gouvernance des données personnelles. Point souvent mal compris : dans le cloud, vous restez responsable de traitement et le fournisseur (Azure, AWS) agit comme sous-traitant au sens de l'article 28. Cela implique un contrat de sous-traitance (DPA), des garanties sur les transferts hors UE, et la traçabilité des accès. Aucune migration cloud « ne met en conformité » à elle seule : la conformité dépend de votre configuration (localisation des données, chiffrement, gestion des accès, registre des traitements).

ISO 27001

L'ISO 27001 est la norme internationale de gestion de la sécurité de l'information (SMSI). Côté cloud, elle se traduit en politiques de gestion des accès, de classification, de gestion des risques et d'amélioration continue. Architecte Cloud s'appuie sur une démarche ISO 27001 pour structurer les pratiques de gouvernance ; la certification, quand elle est requise, vise une organisation et son système de management, pas une configuration cloud isolée.

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

La directive NIS2 étend significativement le nombre d'entités soumises à des obligations de cybersécurité (secteurs « essentiels » et « importants »). Pour la gouvernance cloud, elle impose un renforcement de la gestion des risques, des mesures de sécurité, de la gouvernance de la chaîne d'approvisionnement et des obligations de notification d'incident. Beaucoup d'ETI découvrent qu'elles entrent dans le périmètre. Une gouvernance cloud anticipe cette exigence par la traçabilité, la posture de sécurité mesurée et les plans de réponse.

DORA : la résilience opérationnelle du secteur financier

Le règlement DORA (Digital Operational Resilience Act) s'applique au secteur financier et assurantiel. Il impose une résilience opérationnelle documentée et testée : gestion du risque lié aux technologies, tests de résilience, et surtout encadrement strict du risque lié aux prestataires tiers (dont les fournisseurs cloud). DORA pousse explicitement vers des stratégies de réversibilité et de sortie, un sujet sur lequel l'angle anti-lock-in d'Architecte Cloud prend tout son sens. Voir notre approche par secteur sur /secteurs/finance.

SecNumCloud et l'ANSSI

SecNumCloud est le visa de sécurité de l'ANSSI pour les services cloud de confiance, attendu notamment pour les données sensibles de certaines administrations et opérateurs. Une gouvernance cloud orientée souveraineté évalue si tout ou partie de vos charges doit reposer sur une offre qualifiée SecNumCloud, et organise la classification des données qui le justifie.

HDS : hébergement de données de santé

Tout traitement de données de santé à caractère personnel impose un hébergement chez un partenaire certifié HDS. La certification HDS vise l'hébergeur, pas votre application ni Architecte Cloud. La gouvernance consiste à garantir que les composants concernés reposent bien sur un périmètre certifié HDS, à tracer les flux et à contractualiser correctement. Voir /secteurs/sante.

À retenir : ces référentiels ne sont pas indépendants. Une donnée de santé d'un acteur financier soumis à NIS2 peut cumuler RGPD + HDS + NIS2. La gouvernance consiste précisément à cartographier ce cumul et à le traduire en politiques techniques vérifiables, secteur par secteur.

| Référentiel | S'applique à | Implication concrète sur la gouvernance | |---|---|---| | RGPD (art. 28) | Toute donnée personnelle | DPA, localisation UE, chiffrement, registre, gestion des accès | | ISO 27001 | Organisation (SMSI) | Politiques formalisées, analyse de risques, amélioration continue | | NIS2 | Entités essentielles/importantes | Gestion des risques, notification d'incident, sécurité de la chaîne | | DORA | Finance, assurance | Tests de résilience, risque tiers, stratégie de sortie/réversibilité | | SecNumCloud | Données sensibles, secteur public | Recours à une offre qualifiée ANSSI, souveraineté | | HDS | Données de santé | Hébergement chez un partenaire certifié HDS, traçabilité |

Sécurité et gestion des identités : le cœur de la gouvernance d'accès

Dans le cloud, le périmètre de sécurité n'est plus le réseau mais l'identité. Gouverner les accès est donc le levier le plus structurant. Tout repose sur le modèle de responsabilité partagée : le fournisseur sécurise le cloud (datacenters, matériel, hyperviseur), vous sécurisez ce que vous mettez dans le cloud, et les identités, les données et la configuration restent toujours de votre responsabilité, quel que soit le modèle de service.

Les principes non négociables

• Moindre privilège : chaque identité ne dispose que des droits strictement nécessaires, et rien de plus. C'est le principe directeur de toute gouvernance d'accès.
• RBAC (contrôle d'accès basé sur les rôles) : on attribue des rôles, pas des permissions individuelles. Plus simple à auditer, plus difficile à dériver.
• ABAC (contrôle d'accès basé sur les attributs) : on affine selon des attributs (étiquette de ressource, service, environnement). Utile à grande échelle, lorsque les rôles ne suffisent plus.
• MFA (authentification multifacteur) : non négociable pour tout accès, à plus forte raison administratif. Une identité sans MFA est une porte ouverte.
• Accès juste-à-temps : élever des privilèges seulement quand c'est nécessaire, pour une durée limitée (Privileged Identity Management côté Microsoft Entra ID).

Côté Azure, ces mécanismes reposent sur Microsoft Entra ID et le RBAC Azure. Côté AWS, sur IAM et IAM Identity Center. La gouvernance consiste à centraliser les identités, à automatiser le provisionnement et la révocation, et à auditer régulièrement les droits dormants. Pour aller plus loin, voir le pilier sécurisation d'infrastructure cloud et les services de cybersécurité cloud.

Gouvernance financière : maîtriser et optimiser les coûts

La gouvernance financière transforme la facture cloud d'une boîte noire en un poste piloté. Elle ne se résume pas à « dépenser moins » : elle vise à dépenser de façon visible, attribuable et arbitrée.

• Budgets et alertes : chaque équipe, projet ou environnement dispose d'un budget avec alertes de seuil (Azure Cost Management, AWS Cost Explorer / Budgets). Le dépassement déclenche un signal, pas une surprise en fin de mois.
• Étiquetage (tagging) : sans étiquetage cohérent, impossible d'attribuer un coût à un responsable. Le tagging est le prérequis absolu de toute gouvernance financière sérieuse.
• Showback / chargeback : montrer (showback) ou refacturer (chargeback) à chaque équipe sa consommation responsabilise les décisions.
• Engagements : arbitrer entre paiement à l'usage et engagements (Reserved Instances, Savings Plans) pour les charges stables, sans sur-engager. AWS ajoute les instances Spot pour les charges tolérantes à l'interruption.
• Rightsizing et extinction hors usage : redimensionner les ressources surdimensionnées, éteindre les environnements de test la nuit et le week-end.

La gouvernance financière fixe les règles ; leur application opérationnelle relève d'une démarche d'optimisation des coûts cloud et des services d'audit FinOps. Architecte Cloud est membre de la FinOps Foundation et s'appuie sur des prestataires disposant de la certification FinOps requise.

Économie observée : sur des environnements non gouvernés, les démarches FinOps permettent fréquemment de constater des réductions de facture significatives la première année (souvent de l'ordre de 20 à 35 % selon le périmètre). Ces chiffres sont constatés sur des cas représentatifs, jamais garantis : ils dépendent de votre point de départ.

Méthodologie : mettre en place une gouvernance cloud

La mise en place suit une progression logique. Brûler une étape (typiquement passer à l'automatisation sans avoir inventorié l'existant) produit une gouvernance qui sonne creux.

Étape 1 : Inventaire des actifs et état des lieux

On ne gouverne pas ce que l'on ne connaît pas. La première étape cartographie l'ensemble des abonnements, comptes, ressources, accès, coûts et non-conformités existants. C'est l'objet d'un audit d'infrastructure cloud, qui produit l'état des lieux factuel sur lequel tout le reste s'appuie.

Étape 2 : Définition des politiques

À partir de l'état des lieux et de vos exigences réglementaires, on définit les politiques : régions autorisées, étiquetage obligatoire, chiffrement, types de ressources permis, niveaux d'accès. On commence par les règles à plus fort enjeu, pas par l'exhaustivité.

Étape 3 : Construction des fondations (landing zones)

On industrialise les fondations conformes : une zone d'atterrissage (landing zone) où réseau, identités, journalisation et sécurité sont déjà en place. Voir Landing zone Azure et Landing zone AWS. C'est là que la gouvernance devient invisible et automatique : déployer dans la landing zone, c'est être conforme par défaut.

Étape 4 : Automatisation (policy-as-code)

On transforme les politiques en code exécuté à chaque déploiement, plutôt qu'en règles vérifiées à la main. C'est le sujet de la section suivante.

Étape 5 : Monitoring continu et remédiation

On supervise en permanence l'écart entre l'état souhaité et l'état réel (conformité, dérive de configuration, coûts), avec des tableaux de bord et des KPI. La gouvernance n'est jamais « terminée » : elle se pilote.

Approche monitor-first : pour ne pas casser la vélocité des équipes, on commence souvent par observer avant de bloquer. Une politique est d'abord déployée en mode « audit » (elle signale les écarts sans empêcher), puis durcie en mode « refus » une fois les équipes alignées et l'impact mesuré. C'est l'antidote au rejet de la gouvernance.

Gouvernance par le code : policy-as-code et automatisation

C'est le saut qualitatif qui sépare une gouvernance déclarative d'une gouvernance effective. La politique en tant que code (policy-as-code) consiste à exprimer les règles sous forme de code versionné, évalué automatiquement à chaque création ou modification de ressource. Une politique cesse d'être un PDF que l'on espère respecté : elle devient un contrôle qui s'exécute.

Comment ça marche, expliqué simplement

Trois points d'application complémentaires :

• Au déploiement (préventif) : un pipeline CI/CD évalue le code d'infrastructure (Terraform, Bicep) avant de l'appliquer. Une ressource non conforme est rejetée avant même d'exister.
• Au niveau de la plateforme (préventif natif) : Azure Policy et AWS Service Control Policies refusent à la source une action interdite, quel que soit l'outil utilisé.
• En continu (détectif) : la détection de dérive (drift detection) compare l'état réel à l'état déclaré dans le code et signale tout écart (une ressource modifiée manuellement « pour dépanner » et jamais remise en conformité).

L'Infrastructure as Code, socle de la gouvernance

La gouvernance par le code suppose que votre infrastructure soit elle-même décrite en code. L'Infrastructure as Code (Terraform, Bicep) rend l'environnement reproductible, auditable et versionné. Chaque changement passe par une revue (GitOps), laisse une trace, et peut être annulé. Voir Infrastructure as Code en entreprise et notre accompagnement de consultant Terraform.

Pourquoi cela parle aussi aux décideurs : policy-as-code, c'est la garantie que la règle votée en comité de gouvernance est réellement appliquée à chaque déploiement, sans dépendre de la vigilance d'un humain. C'est la différence entre une politique et une intention.

Outils et application des politiques : Azure vs AWS

La neutralité de fournisseur est au cœur de la démarche d'Architecte Cloud. Voici les leviers de gouvernance des deux plateformes, côte à côte, pour choisir en connaissance de cause, et gouverner un environnement qui combine les deux.

| Levier de gouvernance | Microsoft Azure | Amazon Web Services (AWS) | |---|---|---| | Hiérarchie d'organisation | Management groups (groupes d'administration) | AWS Organizations (OU) | | Garde-fous de politique | Azure Policy | Service Control Policies (SCP) | | Fondations conformes | Landing zone (Cloud Adoption Framework) | Control Tower / Landing Zone Accelerator | | Identités & accès | Microsoft Entra ID, RBAC Azure | IAM, IAM Identity Center | | Posture de sécurité | Microsoft Defender for Cloud | AWS Security Hub, GuardDuty | | Gestion des coûts | Azure Cost Management | Cost Explorer, Budgets | | Gouvernance des données | Microsoft Purview | Macie, Lake Formation | | Cadre d'architecture | Azure Well-Architected | Well-Architected Framework (6 piliers) | | Infrastructure as Code | Bicep, Terraform | CloudFormation, Terraform |

La logique est la même des deux côtés : une hiérarchie d'organisation, des garde-fous appliqués à cette hiérarchie, des fondations conformes, et des outils de posture pour mesurer. Gouverner du multi-cloud consiste à harmoniser ces concepts équivalents derrière des règles communes, souvent via Terraform comme langage d'infrastructure commun aux deux plateformes.

Stratégie de nommage et d'étiquetage des ressources

Le nommage et l'étiquetage (tagging) sont les fondations discrètes sans lesquelles aucune autre politique ne tient. Une ressource non taguée est un coût sans propriétaire, un actif sans contexte, un angle mort de sécurité.

Une stratégie d'étiquetage minimale couvre :

• Propriété : équipe ou personne responsable (owner, team).
• Finance : centre de coût, projet (cost-center, project), indispensable au showback/chargeback.
• Environnement : prod, staging, dev, pilote les règles de sécurité et d'extinction.
• Classification de données : public, interne, confidentiel, sensible, pilote chiffrement et accès.
• Conformité : référentiels applicables (rgpd, hds) le cas échéant.

La nomenclature de nommage (convention pour nommer abonnements, groupes de ressources, ressources) garantit lisibilité et automatisation. La gouvernance consiste à rendre l'étiquetage obligatoire via Azure Policy ou des SCP : une ressource sans les étiquettes requises est refusée ou signalée. C'est l'exemple type d'une politique simple à fort effet de levier.

Gouvernance des données : classification, cycle de vie, souveraineté

La gouvernance des données est le pilier le plus exigeant juridiquement. Elle articule quatre dimensions :

• Classification : catégoriser chaque donnée selon sa sensibilité. Sans classification, impossible d'appliquer des règles différenciées. Microsoft Purview automatise une partie de cette découverte côté Azure.
• Cycle de vie : définir la durée de conservation, l'archivage et la suppression. Le RGPD impose de ne pas conserver indéfiniment les données personnelles.
• Souveraineté : maîtriser la localisation géographique des données (régions UE, offres qualifiées SecNumCloud pour les données sensibles). Un enjeu de conformité et de souveraineté stratégique.
• Chiffrement : au repos et en transit, avec gestion des clés. La question clé est qui détient les clés, un point central pour les données les plus sensibles.

Gouvernance multi-cloud et hybride

Peu d'organisations sont mono-cloud. La réalité est multi-cloud (Azure et AWS), souvent hybride (cloud public et on-premise). Gouverner cet ensemble suppose des principes communs malgré des outils différents.

• Un référentiel de politiques commun : exprimer les règles indépendamment de la plateforme (étiquetage, chiffrement, régions), puis les décliner en Azure Policy et en SCP.
• Une couche d'identité fédérée : éviter de multiplier les annuaires. Fédérer Entra ID et IAM Identity Center plutôt que gérer deux silos d'identités.
• Une vue de coûts consolidée : agréger Azure Cost Management et AWS Cost Explorer pour un pilotage budgétaire unique.
• Terraform comme langage commun : décrire l'infrastructure des deux plateformes dans un outil unique réduit la divergence des pratiques.

Gouvernance centralisée ou fédérée ?

Un arbitrage structurant : qui décide ? La gouvernance centralisée concentre les décisions dans le CCoE (cohérence maximale, risque de goulot d'étranglement) ; la gouvernance fédérée délègue aux équipes dans un cadre commun (vélocité maximale, risque d'incohérence si le cadre est faible). La plupart des organisations matures convergent vers un modèle hybride : centraliser les garde-fous non négociables (sécurité, conformité, fondations) et fédérer le reste. Le modèle de maturité organisationnelle complet, du centralisé au fédéré puis à l'autonome, avec le dimensionnement de l'équipe par taille d'organisation, est détaillé sur le guide Cloud Center of Excellence (CCoE).

Gouvernance et continuité d'activité (PRA/PCA)

La continuité d'activité est une discipline de gouvernance opérationnelle souvent oubliée des contenus sur la gouvernance. Pourtant, décider quel niveau de résilience est exigé pour chaque charge de travail est un acte de gouvernance.

• RTO (Recovery Time Objective) : durée maximale d'interruption tolérée.
• RPO (Recovery Point Objective) : quantité maximale de données que l'on accepte de perdre.
• PRA (plan de reprise) et PCA (plan de continuité) : les dispositifs qui permettent de tenir ces objectifs.

La gouvernance fixe la règle : par exemple, aucune charge classée critique ne part en production sans PRA testé et RTO/RPO documentés. Sous DORA, ces tests de résilience deviennent une obligation pour le secteur financier. La conception et le test de ces plans relèvent de notre expertise PRA cloud et PCA cloud.

KPI de gouvernance cloud : mesurer pour piloter

Une gouvernance sans indicateurs est une gouvernance qui se raconte des histoires. Voici les KPI de pilotage à suivre. Les valeurs ci-dessous sont des ordres de grandeur constatés sur des environnements gouvernés, jamais des promesses ni des seuils contractuels.

| KPI | Ce qu'il mesure | Ordre de grandeur visé (constaté) | |---|---|---| | Taux de conformité des politiques | % de ressources conformes aux politiques actives | > 95 % en régime mature | | % de ressources taguées | Couverture de l'étiquetage obligatoire | > 98 % sur les étiquettes critiques | | Dérive de configuration (drift) | Nombre/ratio de ressources hors état déclaré | Tend vers zéro, surveillé en continu | | MTTR de remédiation | Délai moyen de retour à la conformité | De quelques heures à quelques jours selon criticité | | Couverture budgétaire | % de la dépense couverte par un budget avec alerte | Vise 100 % | | Score de posture de sécurité | Indicateur agrégé (Defender for Cloud / Security Hub) | Progression mesurée trimestre par trimestre | | Taux de couverture des engagements | % de la dépense stable couverte par réservations/Savings Plans | Selon profil de charge |

À retenir : ces KPI ne valent que comparés à eux-mêmes dans le temps. L'objectif n'est pas d'atteindre un chiffre absolu, mais de démontrer une trajectoire de progrès trimestre après trimestre : c'est ce que regarde un comité de direction, et ce que demande un auditeur NIS2 ou DORA.

Modèle de maturité de gouvernance cloud

Pour situer votre organisation et tracer un cap, ce modèle en cinq niveaux est actionnable.

1. Initial (ad hoc) : pas de règles formalisées, décisions au cas par cas, Shadow IT, coûts subis. Le point de départ le plus fréquent.
2. Réactif : quelques règles écrites, étiquetage partiel, contrôles manuels après coup. On corrige plus qu'on ne prévient.
3. Défini : politiques formalisées, landing zones, étiquetage majoritaire, KPI suivis. La gouvernance existe vraiment.
4. Géré (automatisé) : policy-as-code, conformité mesurée en continu, remédiation outillée, FinOps actif. La gouvernance s'applique seule.
5. Optimisé : amélioration continue, gouvernance fédérée mature, gouvernance de l'IA, réversibilité maîtrisée. La gouvernance devient un avantage.

L'objectif n'est pas d'atteindre le niveau 5 partout : c'est d'atteindre le niveau adapté à votre enjeu sur chaque pilier. Une PME de e-commerce et un groupe bancaire soumis à DORA n'ont pas la même cible.

Réversibilité et anti-lock-in : un objet de gouvernance

Voici l'angle que personne ne traite, et qui distingue Architecte Cloud. La réversibilité (votre capacité à reprendre la main, à changer de prestataire ou de plateforme) est un objet de gouvernance à part entière, et une exigence explicite de DORA pour le secteur financier.

Une gouvernance qui protège votre indépendance impose des règles simples mais structurantes :

• Le code d'infrastructure (IaC) vous appartient et vit dans vos dépôts Git. Vous pouvez reconstruire votre environnement sans dépendre d'un prestataire.
• Les comptes et abonnements cloud sont à votre nom, pas à celui du prestataire. Vous ne perdez jamais l'accès à vos propres ressources.
• La documentation est remise et tenue à jour. Une infrastructure non documentée est une infrastructure dont vous n'êtes pas réellement propriétaire.
• Les dépendances propriétaires sont arbitrées en connaissance de cause, et non subies par défaut.

L'engagement d'Architecte Cloud : tout ce qui est construit vous appartient. Code IaC versionné dans vos dépôts, comptes à votre nom, documentation remise. Pas d'enfermement. La gouvernance de la réversibilité n'est pas un slogan : c'est une clause contractuelle et une réalité technique.

Études de cas représentatives par secteur

Ces cas sont représentatifs, anonymisés, et illustrent la gouvernance appliquée à des contraintes réelles.

• Santé (HDS). Un éditeur de logiciel médical (ETI) devait héberger des données de santé. La gouvernance a consisté à isoler les composants concernés sur un périmètre reposant sur un partenaire certifié HDS, à classifier les données via Purview, à imposer le chiffrement et à tracer tous les accès. Résultat constaté : un dossier de conformité présentable à un audit, là où l'environnement initial était ingouvernable.
• Finance (DORA). Une fintech soumise à DORA a structuré sa gouvernance autour de la résilience : PRA testé, RTO/RPO documentés par charge, registre des prestataires tiers et stratégie de réversibilité (IaC propriétaire, comptes en propre). Voir /secteurs/finance.
• Industrie (multi-cloud). Un groupe industriel exploitant Azure et AWS a unifié sa gouvernance : politiques communes déclinées en Azure Policy et SCP, identités fédérées, vue de coûts consolidée. La dérive entre équipes a été ramenée sous contrôle. Voir /secteurs/industrie.
• Secteur public (SecNumCloud). Un organisme public a arbitré la localisation de ses données sensibles vers une offre qualifiée et formalisé sa classification. Voir /secteurs/public.

Combien coûte une gouvernance cloud ? Durée et livrables

La mise en place d'une gouvernance cloud n'est pas un coût fixe : elle dépend du nombre d'abonnements/comptes, du périmètre réglementaire, du multi-cloud et de votre point de départ. Les fourchettes ci-dessous sont indicatives, communiquées sur devis après diagnostic.

• Durée : de 3 à 15 jours d'intervention pour la conception et l'amorçage, selon le périmètre. La gouvernance se poursuit ensuite en mode continu.
• Budget indicatif : de 8 000 à 25 000 € pour la mise en place initiale (cadre, politiques, fondations, automatisation), sur devis selon le périmètre. Le pilotage continu et l'exploitation relèvent d'un dispositif distinct.

Livrables type

• Cartographie de l'existant et identification des écarts (issue d'un audit).
• Cadre de gouvernance : politiques formalisées, matrice RACI, modèle d'organisation (CCoE, comités, cadences).
• Hiérarchie d'organisation et zones d'atterrissage conformes.
• Politiques automatisées (Azure Policy / SCP), policy-as-code, détection de dérive.
• Stratégie d'étiquetage et de nommage appliquée.
• Tableau de bord de KPI de gouvernance.
• Documentation remise, code IaC dans vos dépôts.

Feuille de route 30/60/90 jours

• 0–30 jours : inventaire et état des lieux, politiques prioritaires (étiquetage, accès, chiffrement) en mode monitor-first, budgets et alertes activés, quick wins FinOps.
• 30–60 jours : zones d'atterrissage, durcissement des politiques en mode refus, mise en place du CCoE et des comités, premiers KPI.
• 60–90 jours : policy-as-code dans les pipelines, détection de dérive, gouvernance des données, plan de réversibilité, première revue de gouvernance.

Cette feuille de route est un schéma directeur, pas un engagement uniforme : son rythme dépend de votre maturité, de votre périmètre réglementaire et de la disponibilité de vos équipes.

La gouvernance cloud ralentit-elle l'innovation ?

C'est l'objection la plus fréquente, et la plus mal fondée. Une gouvernance mal conçue ralentit, c'est vrai : trop de validations manuelles, blocages systématiques, comités interminables. Mais une gouvernance bien conçue accélère, parce qu'elle rend le chemin sûr par défaut. Une équipe qui déploie dans une landing zone conforme n'a pas à négocier la sécurité à chaque projet. L'approche monitor-first, l'automatisation et la fédération des décisions sont précisément les leviers qui réconcilient gouvernance et vélocité. Bien menée, la gouvernance est ce qui permet d'aller vite sans casser. Voir aussi DevOps cloud en entreprise.

Par où commencer

La gouvernance cloud se construit dans l'ordre : d'abord savoir où vous en êtes, puis fixer les règles, puis les automatiser. Le point de départ est toujours un état des lieux factuel. Architecte Cloud (intermédiaire indépendant Azure & AWS, s'appuyant sur un réseau de prestataires expérimentés) vous accompagne de l'audit à la gouvernance continue, en langage clair pour la DSI comme pour la direction générale.

Pour situer votre maturité et identifier vos écarts prioritaires, commencez par le diagnostic en ligne. Pour cadrer un périmètre précis, contactez-nous : réponse sous 48 h ouvrées. Pour explorer les disciplines associées, voir l'ensemble de nos services, le conseil en architecture et le guide du cloud.

FAQ : Gouvernance cloud

Qu'est-ce que la gouvernance cloud ?

La gouvernance cloud est le cadre de règles, de rôles et de processus qui encadre la façon dont une organisation conçoit, déploie, exploite et finance ses ressources cloud. Elle répond à trois questions : qui a le droit de faire quoi, selon quelles règles, et comment s'assure-t-on que ces règles sont réellement appliquées. Elle repose sur des politiques, une organisation (rôles, comités), des processus de décision et des garde-fous techniques automatisés.

Quelle est la différence entre la gouvernance et la gestion du cloud ?

La gouvernance définit les règles (stratégique, durable) ; la gestion exécute le travail au quotidien (opérationnel). La gouvernance fixe par exemple la politique d'étiquetage, d'accès et de budget ; la gestion déploie, supervise et sauvegarde à l'intérieur de ce cadre. Les deux sont nécessaires : sans gouvernance, chaque équipe improvise ses propres règles ; sans gestion, rien ne tourne.

Quels sont les piliers de la gouvernance cloud ?

Une gouvernance complète couvre sept domaines : les coûts (FinOps), la sécurité, la conformité, les opérations, les données, la gestion des ressources, et désormais l'IA. Ces piliers ne se déploient pas tous en même temps : on commence généralement par les coûts, la sécurité et la gestion des ressources, puis on étend.

Pourquoi la gouvernance cloud est-elle importante ?

Parce que le cloud décentralise les décisions : n'importe quelle équipe peut créer des ressources, engager des coûts et des risques en quelques secondes. Sans cadre, cela produit du Shadow IT, une dérive des coûts et des non-conformités. La gouvernance rend l'environnement sûr et maîtrisé par défaut, et permet de répondre aux exigences réglementaires (RGPD, NIS2, DORA, HDS).

Comment mettre en place une gouvernance cloud en entreprise ?

En cinq étapes : inventorier les actifs existants (audit), définir les politiques prioritaires, construire des fondations conformes (landing zones), automatiser les politiques (policy-as-code), puis superviser en continu avec des KPI. L'approche monitor-first (observer avant de bloquer) évite de freiner les équipes. La mise en place initiale prend généralement de 3 à 15 jours selon le périmètre.

Qui est responsable de la gouvernance cloud dans une organisation ?

La responsabilité est partagée et clarifiée par une matrice RACI. Le Cloud Center of Excellence (CCoE) porte et outille la gouvernance ; un sponsor exécutif (souvent le DSI) lui donne autorité ; le RSSI définit les exigences de sécurité, le DAF copilote les coûts ; l'équipe plateforme construit les fondations et les équipes produit déploient à l'intérieur du cadre.

Quels outils utiliser pour la gouvernance cloud sur Azure et AWS ?

Côté Azure : management groups, Azure Policy, landing zone (Cloud Adoption Framework), Microsoft Entra ID, Defender for Cloud, Cost Management, Purview. Côté AWS : AWS Organizations, Service Control Policies, Control Tower / Landing Zone Accelerator, IAM Identity Center, Security Hub, Cost Explorer. Terraform sert souvent de langage d'infrastructure commun aux deux plateformes.

Quels sont les KPI d'une gouvernance cloud efficace ?

Les principaux : taux de conformité des politiques (vise plus de 95 %), pourcentage de ressources taguées (vise plus de 98 % sur les étiquettes critiques), dérive de configuration (tend vers zéro), MTTR de remédiation, couverture budgétaire (vise 100 %) et score de posture de sécurité. Ces indicateurs se lisent dans le temps : c'est la trajectoire de progrès qui compte, pas un chiffre absolu.

Comment la gouvernance cloud aide-t-elle à maîtriser les coûts ?

Par la gouvernance financière (FinOps) : budgets avec alertes, étiquetage qui permet d'attribuer chaque coût à un responsable, showback/chargeback, arbitrage des engagements (réservations, Savings Plans), rightsizing et extinction des environnements hors usage. Sur un environnement non gouverné, ces démarches permettent fréquemment de constater des réductions de facture significatives, jamais garanties car dépendantes du point de départ.

Comment assurer la conformité RGPD, ISO 27001, NIS2 dans le cloud ?

En traduisant chaque exigence en politiques techniques vérifiables : localisation et chiffrement des données (RGPD art. 28, où vous restez responsable de traitement et le fournisseur sous-traitant), gestion documentée des accès et des risques (ISO 27001), traçabilité, posture de sécurité mesurée et notification d'incident (NIS2). Aucune migration ne « met en conformité » à elle seule : la conformité dépend de votre configuration. Architecte Cloud s'appuie sur une démarche ISO 27001.

Qu'est-ce que la politique en tant que code (policy-as-code) ?

C'est le fait d'exprimer les règles de gouvernance sous forme de code versionné, évalué automatiquement à chaque déploiement de ressource. Une politique cesse d'être un document que l'on espère respecté : elle devient un contrôle qui s'exécute, soit en amont dans les pipelines CI/CD, soit nativement via Azure Policy ou les Service Control Policies AWS, soit en détection continue de dérive.

Comment gouverner un environnement multi-cloud ou hybride ?

Avec des principes communs malgré des outils différents : un référentiel de politiques exprimé indépendamment de la plateforme puis décliné en Azure Policy et SCP, une couche d'identité fédérée, une vue de coûts consolidée, et Terraform comme langage d'infrastructure commun. L'enjeu est d'harmoniser des concepts équivalents (hiérarchie, garde-fous, fondations, posture) derrière des règles cohérentes.

La gouvernance cloud ralentit-elle l'innovation ?

Une gouvernance mal conçue ralentit (validations manuelles, blocages systématiques). Une gouvernance bien conçue accélère, parce qu'elle rend le chemin sûr par défaut : déployer dans une landing zone conforme évite de renégocier la sécurité à chaque projet. L'approche monitor-first, l'automatisation et la fédération des décisions réconcilient gouvernance et vélocité.

La réversibilité fait-elle partie de la gouvernance cloud ?

Oui, et c'est un angle trop souvent oublié. La réversibilité (votre capacité à reprendre la main, à changer de prestataire ou de plateforme) est un objet de gouvernance à part entière, désormais explicitement attendu par DORA pour le secteur financier (stratégie de sortie). Elle se gouverne par des règles concrètes : code d'infrastructure (IaC) dans vos dépôts, comptes et abonnements à votre nom, documentation remise et tenue à jour, dépendances propriétaires arbitrées en connaissance de cause. Une gouvernance qui ne traite pas la réversibilité protège le fournisseur, pas vous.

Combien coûte la mise en place d'une gouvernance cloud ?

Le budget dépend du nombre de comptes, du périmètre réglementaire, du multi-cloud et du point de départ. À titre indicatif, la mise en place initiale (cadre, politiques, fondations, automatisation) se situe souvent entre 8 000 et 25 000 €, sur devis selon le périmètre, pour une durée de 3 à 15 jours d'intervention. Le pilotage continu relève d'un dispositif distinct. Le diagnostic préalable permet de cadrer précisément.