Cloud non documenté : reprendre la main

Une infrastructure cloud non documentée, c'est un système d'information dont personne ne possède la carte complète : pas d'Infrastructure as Code, pas de schéma d'architecture à jour, pas d'inventaire fiable, et un savoir critique logé dans la mémoire d'une seule personne, ou parti avec un prestataire. Tant que rien ne casse, l'angle mort reste invisible. Le jour où il faut diagnostiquer un incident, faire évoluer une brique, prouver une conformité ou changer de fournisseur, l'addition tombe d'un coup. Ce dossier explique comment qualifier le problème, le distinguer du shadow IT, mesurer votre dette, puis reprendre méthodiquement la main sur un environnement Azure ou AWS hérité, outil par outil, étape par étape.

Qu'est-ce qu'un cloud non documenté ?

Définition. Un cloud non documenté est un ensemble de ressources Azure, AWS ou GCP construites et exploitées sans artefacts de référence à jour : ni Infrastructure as Code, ni diagramme d'architecture, ni schéma réseau, ni inventaire des ressources, ni runbooks. La connaissance de son fonctionnement repose sur le savoir tacite d'une ou deux personnes plutôt que sur des documents partagés et versionnés. Le système marche, mais personne ne peut le reconstruire, l'auditer, le sécuriser ni le transmettre de façon fiable.

La nuance importe : un cloud non documenté n'est pas un cloud mal conçu. Beaucoup de plateformes non documentées sont techniquement saines. Le problème n'est pas la qualité de la construction, mais l'absence de traçabilité : on ne sait plus pourquoi telle décision a été prise, quelles ressources existent réellement, combien elles coûtent, comment on les redéploie ni qui peut intervenir.

Concrètement, une infrastructure documentée s'appuie sur six familles d'artefacts. Quand une seule survit, souvent un vieux schéma périmé, on parle de cloud non documenté :

• Le code d'infrastructure (IaC) : la définition déclarative des ressources (Terraform, Bicep, OpenTofu) qui sert à la fois de source de vérité et de moyen de redéploiement.
• Le diagramme d'architecture : la vue logique des composants et de leurs interactions (passerelles, services applicatifs, bases de données, files de messages).
• Le schéma réseau : VPC/VNet, sous-réseaux, peering, règles de filtrage, points d'entrée publics, liaisons privées.
• L'inventaire des ressources : la liste exhaustive et datée de ce qui tourne, par compte/abonnement, région et environnement.
• Les runbooks : les procédures d'exploitation (déploiement, sauvegarde, restauration, rotation des secrets, gestion d'incident).
• Les décisions d'architecture (ADR) : la trace écrite des choix structurants et de leurs raisons.

Quand ces artefacts manquent, le cloud devient une boîte noire opérationnelle. Pour cadrer le travail de reconstitution, notre audit d'infrastructure cloud commence toujours par établir lesquels de ces six artefacts existent réellement.

Symptômes d'un cloud non documenté

Vous êtes probablement concerné si plusieurs de ces signaux sont présents :

• Une seule personne sait comment l'environnement est câblé, et elle répond « il vaut mieux ne pas y toucher ».
• Les ressources ont été créées à la main dans la console (click-ops), sans code pour les recréer.
• Personne ne sait dire, sans aller fouiller, combien d'instances, de bases ou de buckets tournent réellement.
• Il n'existe aucun schéma à jour ; le dernier date d'avant deux migrations.
• Les secrets (mots de passe, clés API, chaînes de connexion) sont éparpillés et non recensés.
• Une évolution simple demande des jours de « rétro-ingénierie » avant de pouvoir agir.
• Le prestataire historique détient les comptes, les accès et le savoir, et vous ne savez pas comment reprendre la main.

Shadow IT applicatif vs cloud IaaS/PaaS non documenté : ne pas confondre

C'est la confusion la plus répandue, et elle conduit à appliquer les mauvais remèdes. Deux problèmes très différents se cachent souvent derrière l'expression « cloud non maîtrisé ».

Le shadow IT applicatif désigne l'usage de services SaaS non approuvés par les équipes métier : un service de partage de fichiers souscrit par le marketing, un outil de gestion de projet payé sur une carte bleue, une instance de CRM ouverte hors DSI. Le risque porte sur la donnée qui sort du périmètre maîtrisé et sur la conformité. On le détecte par l'analyse des flux et des journaux de proxy, avec des outils de Cloud Discovery comme Microsoft Defender for Cloud Apps, qui révèle les applications cloud réellement utilisées dans l'organisation.

Le cloud IaaS/PaaS non documenté est un autre sujet : ce sont vos propres ressources Azure, AWS ou GCP (machines virtuelles, bases de données managées, conteneurs, fonctions, réseaux, IAM) qui tournent dans vos abonnements, mais sans Infrastructure as Code, sans inventaire ni schéma. Ici la donnée ne « sort » pas : c'est la capacité à exploiter, sécuriser et reconstruire votre propre plateforme qui est perdue. On ne le traite pas avec un outil de Cloud Discovery applicatif, mais avec une rétro-documentation et un passage à l'IaC.

| Critère | Shadow IT applicatif (SaaS) | Cloud IaaS/PaaS non documenté | |---|---|---| | Nature de l'actif | Applications SaaS tierces souscrites hors DSI | Ressources Azure/AWS/GCP dans vos comptes | | Risque dominant | Fuite de données, conformité, perte de contrôle de la donnée | Perte de maîtrise opérationnelle, sécurité, FinOps | | Qui crée le problème | Équipes métier (achat sur carte bleue) | Click-ops, prestataire, CI/CD, auto-scaling | | Outil de détection | Cloud Discovery (Defender for Cloud Apps, proxy) | Inventaire cloud (Resource Graph, AWS Config) | | Remède | Catalogue d'apps approuvées, CASB, gouvernance achat | Rétro-documentation, IaC, landing zone, tagging |

Cette page traite avant tout le second cas (le cloud IaaS/PaaS que vous possédez mais que personne ne maîtrise) parce que c'est précisément celui qu'aucune ressource francophone ne traite de bout en bout. Les deux sujets peuvent coexister : une revue de gouvernance cloud les adresse conjointement.

Pourquoi un cloud devient-il non documenté ? Les causes réelles

La non-documentation est rarement un choix. C'est l'effet cumulé de contraintes courantes.

• Click-ops dans la console. Créer une ressource à la main dans le portail Azure ou la console AWS est plus rapide qu'écrire du code la première fois. Mais chaque clic non tracé est une ligne de documentation perdue, et un élément que personne ne saura recréer à l'identique.
• Départ du sachant ou du prestataire. Quand la personne qui a tout construit garde le fonctionnement « dans sa tête », son départ emporte la documentation vivante. Le bus factor tombe à un, puis à zéro. C'est la cause la plus brutale, car elle se déclenche sans préavis.
• Contrainte de temps projet. En phase de lancement, livrer la fonctionnalité prime. La documentation est repoussée « à plus tard », et plus tard n'arrive jamais. La pression du time-to-market est un accélérateur majeur.
• Croissance non gouvernée. Des migrations successives, des rachats, des « petits ajouts » accumulés finissent par produire un paysage que plus personne n'embrasse en entier.
• CI/CD et auto-scaling. Des pipelines déploient des ressources éphémères, des groupes d'auto-scaling créent et détruisent des instances, des fonctions serverless se multiplient. Sans inventaire dynamique ni étiquetage discipliné, l'infrastructure réelle diverge en permanence de ce que les équipes croient connaître.
• Shadow IT et comptes orphelins. Des équipes ouvrent des abonnements ou des comptes hors du contrôle de la DSI. Ces actifs n'apparaissent dans aucun inventaire central.

Comprendre la cause oriente la remédiation : un environnement victime de turnover a surtout besoin de rétro-documentation ; un environnement victime de click-ops a besoin d'un passage à l'Infrastructure as Code ; un environnement verrouillé par un prestataire a besoin d'une stratégie de reprise en main et de réversibilité.

Quelle est l'ampleur du phénomène ?

Le sujet n'est pas marginal : il est structurel à l'adoption rapide du cloud. Les cabinets d'analyse documentent depuis des années un écart croissant entre ce que les entreprises déploient et ce qu'elles maîtrisent réellement.

• Gartner estime qu'une part majoritaire des incidents de sécurité cloud provient non pas de failles des fournisseurs, mais d'erreurs de configuration et de mauvaise gestion côté client, ce qui suppose, par construction, des ressources mal suivies. Gartner souligne aussi que la plupart des dépassements budgétaires cloud tiennent à des ressources non optimisées et non suivies.
• Forrester et l'écosystème FinOps documentent une proportion significative de dépense cloud gaspillée (ressources surdimensionnées, allumées en permanence ou orphelines), de l'ordre de 20 à 30 % des budgets selon les organisations non gouvernées.
• Les retours de terrain convergent : dans un environnement non gouverné, il est courant de découvrir lors de l'inventaire des ressources que personne ne savait actives : abonnements oubliés, environnements de test jamais éteints, instances héritées d'un projet clos.

Ces ordres de grandeur sont des repères de marché, pas une promesse appliquée à votre cas. La seule mesure fiable de votre exposition est un inventaire réel de vos comptes. C'est précisément ce que produit un audit FinOps couplé à un inventaire technique.

Les risques d'un cloud non documenté

Risques de sécurité : on ne protège que ce qu'on recense

La sécurité repose sur l'inventaire. Une ressource inconnue est une ressource non protégée.

• Surface d'attaque inconnue. Des machines, des buckets ou des points d'entrée publics oubliés échappent aux scans de vulnérabilité et aux campagnes de correctifs.
• Ressources exposées. Un stockage rendu public « le temps d'un test », une base accessible depuis Internet, un port ouvert sans raison : sans cartographie, ces expositions persistent dans l'angle mort.
• Comptes orphelins et IAM non maîtrisé. Des identités (IAM côté AWS, Entra ID côté Azure) sur-privilégiées, des comptes de service sans propriétaire, des clés d'accès jamais révoquées persistent parce que personne ne sait à quoi ils servent et n'ose les supprimer. Le départ d'un prestataire laisse fréquemment des accès Global Admin ou root actifs.
• Secrets non maîtrisés. Clés API en clair, chaînes de connexion dans le code, comptes de service sans rotation : sans registre des secrets, l'exposition est invisible.

La cartographie est le préalable de toute remédiation. C'est l'objet d'un audit de sécurité cloud et, plus largement, d'une démarche de sécurisation de l'infrastructure cloud.

Risques financiers : les ressources fantômes que vous payez sans le savoir

L'absence de documentation se traduit directement en facture. En l'absence de FinOps, la discipline de pilotage économique du cloud, les ressources s'accumulent sans contrôle.

• Ressources orphelines : disques détachés, adresses IP publiques non associées, snapshots périmés, passerelles NAT inutiles, instances arrêtées mais non supprimées, facturées en pure perte (le détail chiffré figure plus bas).
• Dérive des coûts. Sans étiquetage des ressources, impossible d'imputer les coûts par projet, environnement ou équipe, donc impossible de piloter le budget ni de détecter une dérive avant la facture.
• Doublons. Faute d'inventaire, on recrée ce qui existe déjà ; on surdimensionne par prudence ; on ne souscrit aucun engagement (Savings Plans / Reserved Instances) faute de visibilité sur l'usage stable.

La remise en ordre documentaire est souvent le déclencheur d'un gain financier mesurable : on découvre, en cartographiant, ce qu'on payait sans le savoir. C'est le point de départ d'une démarche d'optimisation des coûts cloud.

Risques de conformité : sans carte, l'audit est impossible

Pour les secteurs régulés, la documentation cesse d'être une commodité : elle devient une exigence opposable lors d'un audit.

• RGPD. La tenue d'un registre des traitements suppose de savoir où sont hébergées les données, qui y accède, et selon quelle répartition de responsabilité entre responsable de traitement et sous-traitant (article 28). Une infrastructure non cartographiée rend cette démonstration impossible.
• ISO 27001. La démarche impose un inventaire des actifs et une maîtrise documentaire du système d'information. Sans cartographie, pas de certification crédible.
• HDS (hébergement de données de santé). La traçabilité et la maîtrise de l'environnement sont au cœur du référentiel ; l'hébergement doit s'appuyer sur un hébergeur/partenaire certifié HDS, et la cartographie des flux et des accès est exigée.
• DORA. Le règlement sur la résilience opérationnelle numérique (finance et assurance) exige une connaissance fine de ses systèmes, la gestion des risques liés aux prestataires tiers, des tests de résilience et des dispositifs de réversibilité, tout cela suppose une infrastructure documentée.

Notre audit de conformité cloud relie chaque exigence réglementaire aux artefacts de documentation à produire. Les enjeux varient par secteur : voir nos approches santé, finance, industrie et SaaS.

Risques opérationnels et continuité d'activité

Sans carte, chaque intervention est une exploration. Les dépendances invisibles transforment un changement anodin en incident. Le diagnostic d'incident s'allonge mécaniquement, ce qui dégrade le RTO réel. Et on ne reconstruit pas ce qu'on n'a pas documenté : un PRA/PCA suppose de savoir exactement quoi redéployer, dans quel ordre, avec quelles dépendances. Sans IaC ni runbooks de restauration, les objectifs de RTO (délai de reprise) et de RPO (perte de données tolérée) ne sont que théoriques.

Si votre plateforme cumule incidents à répétition et difficulté à diagnostiquer, le problème de documentation rejoint celui d'une infrastructure cloud instable.

Tableau de synthèse : risque, impact, remédiation

| Risque | Impact concret | Remédiation prioritaire | |---|---|---| | Surface d'attaque inconnue | Ressources exposées hors scans et patchs | Inventaire exhaustif + audit de sécurité | | Comptes / accès orphelins | Accès root/Global Admin actifs sans propriétaire | Revue IAM, rotation des clés, MFA | | Ressources fantômes (FinOps) | Surcoût mensuel récurrent | Inventaire orphelins + nettoyage + tagging | | Cartographie indisponible | Audit RGPD/ISO/HDS impossible | Rétro-documentation, registre des actifs | | Bus factor de 1 | Évolution et exploitation paralysées au départ | IaC versionnée, runbooks, transfert de savoir | | PRA non reconstructible | Reprise après sinistre incertaine | IaC redéployable, runbooks de restauration testés | | Drift IaC / réalité | Le code ne reflète plus l'infra | Détection de drift, réconciliation |

Les ressources orphelines : le coût FinOps chiffré

Les ressources orphelines sont la part la plus tangible, et la plus rapidement récupérable, du gaspillage d'un cloud non documenté. Elles continuent d'être facturées alors que plus personne ne les utilise. Voici les plus fréquentes et leur mécanisme de facturation.

| Ressource orpheline | Pourquoi elle persiste | Pourquoi elle coûte | |---|---|---| | Disques managés détachés | Une VM supprimée laisse son disque | Le disque (Azure Managed Disk / AWS EBS) est facturé même détaché, au Go provisionné | | Adresses IP publiques non attachées | IP réservée puis VM supprimée | Une IP publique réservée mais non associée est facturée à l'heure | | Snapshots obsolètes | Sauvegardes manuelles jamais purgées | Stockage facturé au Go, indéfiniment, sans politique de rétention | | Passerelles NAT inutiles | Sous-réseau abandonné, NAT laissée active | Facturée à l'heure et au volume traité, c'est l'un des postes les plus coûteux | | Instances arrêtées non supprimées | « On verra plus tard » | VM arrêtée : le calcul cesse mais le disque OS reste facturé | | Load balancers sans backend | Service retiré, équilibreur oublié | Facturé à l'heure tant qu'il existe | | Environnements de test jamais éteints | Projet clos sans nettoyage | Calcul + stockage facturés 24/7 | | Clusters / nœuds sous-utilisés | Surdimensionnement par prudence | Capacité réservée largement supérieure à l'usage réel |

En mission de reprise, ces ressources sont systématiquement les premières identifiées par un inventaire croisé avec la facturation. Leur suppression produit un gain immédiat, sans risque pour la production, car par définition elles ne servent plus. C'est aussi le test grandeur nature de la qualité de votre inventaire : si vous ne pouvez pas dire en cinq minutes combien d'IP publiques non attachées vous facturez, votre cloud n'est pas documenté.

L'identification se fait via AWS Cost Explorer et AWS Trusted Advisor côté AWS, Azure Cost Management et Azure Advisor côté Azure, croisés avec l'inventaire technique. La méthode complète relève de l'optimisation des coûts cloud.

Comment savoir ce qui tourne réellement : l'inventaire outillé par hyperscaler

On ne documente pas à l'aveugle : on commence par extraire l'état réel, compte par compte, région par région. Chaque hyperscaler fournit ses propres outils natifs.

Sur Microsoft Azure

• Azure Resource Graph Explorer : le pivot de l'inventaire. Une seule requête (langage KQL) interroge toutes les ressources de tous les abonnements d'un tenant. Il révèle les ressources par type, région, étiquette, et donc aussi les orphelines (disques non attachés, IP non associées). C'est l'outil de référence pour photographier un parc Azure inconnu.
• Azure CLI (az resource list, az account list) : complète, abonnement par abonnement, et liste les abonnements eux-mêmes, utile pour débusquer ceux qu'on avait oubliés.
• Azure Policy : au-delà de l'inventaire, il identifie les ressources non conformes (sans étiquette obligatoire, sans chiffrement, dans une région interdite) et sert ensuite de garde-fou anti-récidive.
• Azure Cost Management + Azure Advisor : croisent l'usage et la facturation pour faire remonter le gaspillage et les recommandations de rightsizing.
• Microsoft Defender for Cloud : posture de sécurité, ressources exposées, recommandations de durcissement.

Sur AWS

• AWS Resource Explorer : recherche transverse des ressources à travers les régions et les comptes, la photographie rapide d'un compte AWS inconnu.
• AWS Config (idéalement en aggregator multi-comptes via AWS Organizations) : enregistre l'inventaire et l'historique de configuration de chaque ressource, détecte les écarts de conformité et conserve la chronologie des changements.
• AWS Cost Explorer : analyse de la dépense par service, compte, étiquette ; identification des postes anormaux.
• AWS Trusted Advisor : recommandations prêtes à l'emploi sur les ressources sous-utilisées, les IP inutilisées, les volumes orphelins et les risques de sécurité.
• AWS CloudTrail : journal des appels d'API. Indispensable pour comprendre qui a créé quoi et quand, la reconstitution de l'historique d'un compte hérité.
• Tag Editor / Resource Groups Tagging API : regroupement et complétion du tagging.

Le multi-comptes : là où se cache l'invisible

L'inventaire doit couvrir tous les comptes et abonnements, pas seulement le principal. C'est dans les abonnements secondaires, les comptes de filiales et les environnements de test que se logent les ressources non recensées. Côté AWS, l'agrégation au niveau de l'organisation (AWS Organizations) est indispensable ; côté Azure, la gestion multi-abonnements via Resource Graph et les groupes d'administration. Nos missions d'audit Azure et d'audit AWS s'appuient systématiquement sur ces référentiels.

Comment documenter une infrastructure cloud existante : la méthode de rétro-documentation

Une fois l'état réel extrait, la rétro-documentation reconstitue les artefacts manquants. Elle suit cinq étapes, applicables à Azure comme à AWS.

1. Inventaire exhaustif des ressources sur tous les comptes/abonnements (section précédente).
2. Cartographie des dépendances et du réseau : reconstituer qui appelle quoi, quels flux existent, quelles ressources dépendent d'autres. On reconstruit le schéma réseau : VNet/VPC, sous-réseaux, peering, passerelles, règles de filtrage (NSG côté Azure, security groups et NACL côté AWS), points d'entrée publics et liaisons privées.
3. Génération des diagrammes d'architecture depuis l'état réel, plutôt qu'à la main, pour garantir la fidélité et la régénération future.
4. Reconstitution de l'Infrastructure as Code : décrire l'existant en code déclaratif (étape détaillée ci-dessous).
5. Runbooks, ADR et registre des secrets : documenter comment on opère et pourquoi on a choisi, et migrer les secrets vers un coffre (Azure Key Vault, AWS Secrets Manager / Parameter Store).

À l'issue de ces cinq étapes, l'environnement n'est plus une boîte noire : il est inventorié, cartographié, codé, opérable et transmissible. C'est exactement le livrable d'une mission de remise en ordre du cloud.

Rétro-documentation en Infrastructure as Code : importer l'existant

C'est l'étape qui transforme une documentation morte en socle vivant. L'objectif : que le code soit la documentation, et qu'il permette de redéployer. Plusieurs outils permettent de générer de l'IaC à partir de ressources déjà créées à la main.

• terraform import rapatrie une ressource existante dans un état Terraform, sans la recréer. On importe progressivement, puis on écrit la configuration correspondante. Sur les versions récentes de Terraform, le bloc import déclaratif et terraform plan -generate-config-out génèrent une première ébauche de configuration à nettoyer.
• aztfexport (anciennement aztfy, outil Microsoft) exporte des ressources Azure existantes en configuration Terraform et dans le state, par groupe de ressources, par requête Resource Graph ou par ressource. C'est l'accélérateur de référence pour passer un parc Azure click-ops sous Terraform.
• terraformer (projet communautaire, multi-fournisseurs) génère du code Terraform et le state à partir de ressources existantes sur AWS, Azure, GCP et d'autres, utile pour amorcer un import massif.
• Export Bicep/ARM : côté Azure, on peut exporter un modèle ARM depuis une ressource ou un groupe de ressources, puis le décompiler en Bicep (bicep decompile) comme point de départ, avant nettoyage pour le rendre maintenable.

L'IaC obtenue doit être versionnée dans Git, dans VOS dépôts, avec un state sécurisé (backend distant, verrouillage) et un découpage en modules réutilisables. Le passage à l'IaC règle simultanément la dette documentaire (le code est la documentation), la dette de configuration et le bus factor (le savoir devient partageable). Cette mécanique est au cœur de nos missions de conseil en architecture et d'infrastructure DevOps.

L'import IaC n'est pas un copier-coller magique. Le code généré est verbeux et reflète l'existant tel quel, défauts compris. Le travail de valeur consiste à le refactoriser en modules propres, à externaliser les variables, à séparer les environnements et à valider que terraform plan ne propose aucun changement une fois l'import terminé, preuve que le code décrit fidèlement la réalité.

Détecter et corriger le drift entre IaC et réalité

Reprendre un cloud en IaC ne suffit pas : il faut s'assurer que le code et la réalité ne divergent plus. Le drift d'infrastructure est l'écart qui apparaît dès qu'une modification est faite « vite fait » dans la console, hors du code.

• terraform plan compare l'état souhaité (le code) à l'état enregistré (state). S'il propose des changements alors que personne n'a touché au code, c'est un signal de drift.
• terraform plan -refresh-only (ou terraform apply -refresh-only) interroge le cloud réel et met à jour le state sans rien modifier : c'est le moyen propre de détecter un drift sans l'appliquer, et de décider ensuite s'il faut aligner le code sur la réalité ou la réalité sur le code.
• AWS Config et les règles de conformité signalent en continu les ressources qui s'écartent d'une configuration de référence, une détection de drift au niveau de la gouvernance, complémentaire de Terraform.
• Azure Policy en mode audit révèle les ressources créées hors standard.

La discipline cible : toute modification passe par le code et une pull request. La console est réservée au diagnostic, pas à la modification. C'est ce qui transforme un cloud repris en cloud durablement maîtrisé, et c'est l'un des piliers d'une gouvernance cloud saine.

Reprendre une infrastructure créée par un ancien prestataire

C'est le scénario le plus délicat, parce qu'il est autant contractuel et humain que technique. Un intégrateur, un freelance ou une ESN a construit la plateforme, l'exploite, mais ne vous a remis ni le code, ni les schémas, ni parfois les accès. La reprise se mène dans un ordre précis.

1. Récupérer la propriété des comptes. Vérifier que les abonnements Azure / comptes AWS sont à votre nom (votre tenant, votre organisation, votre moyen de paiement) et non sur ceux du prestataire. Si ce n'est pas le cas, c'est la première bataille : sans propriété des comptes, vous ne possédez pas votre cloud.
2. Reprendre les accès d'administration. Identifier et reprendre les rôles Global Admin (Entra ID) ou les accès root et administrateurs IAM Identity Center (AWS), activer le MFA, créer vos propres identités d'administration, puis révoquer les accès du prestataire sortant une fois la transition assurée.
3. Inventorier avant de couper. Avant toute révocation, photographier l'environnement (Resource Graph / AWS Config) pour ne pas perdre ce que seul le prestataire connaissait.
4. Récupérer le code et les secrets. Exiger la remise du code IaC, des pipelines CI/CD, des registres et des secrets. À défaut, les reconstituer par rétro-documentation et migrer les secrets vers votre coffre.
5. Encadrer par une clause de réversibilité. Formaliser ce qui est dû et son format (voir ci-dessous).

C'est le cœur d'une mission de remise en ordre du cloud, souvent prolongée par une infogérance cloud d'entreprise qui, elle, vous laisse toujours propriétaire.

Réversibilité : récupérer la propriété d'un cloud confié à un tiers

La documentation n'est pas qu'une bonne pratique technique : c'est un enjeu de propriété. La réversibilité, c'est votre capacité à reprendre votre système d'information ou à changer de prestataire sans perte de maîtrise. Elle suppose, par contrat, que le prestataire vous remette :

• Le code IaC complet (Terraform/Bicep) dans vos dépôts.
• Les diagrammes, schémas réseau, runbooks et ADR à jour.
• L'inventaire des ressources et le registre des secrets.
• Les comptes cloud à votre nom, avec les accès administrateur.

Une clause de documentation et de réversibilité transforme une bonne intention en obligation. Elle précise les artefacts dus, leur format, leur fréquence de mise à jour et les conditions de transfert en fin de contrat. C'est la meilleure protection contre le lock-in prestataire.

Notre principe est constant : tout ce qui est construit vous appartient. Code dans vos dépôts, comptes à votre nom, documentation remise. La réversibilité n'est pas une option de sortie, c'est une condition d'entrée. Vous ne dépendez de nous que parce que vous le choisissez, jamais parce que vous y êtes contraint.

Cet angle structure aussi notre approche de la gouvernance cloud : définir qui détient quoi, et garantir que le client reste propriétaire de son patrimoine numérique.

Plan de remise en conformité : remédier sans couper le service

Une fois l'inventaire et la cartographie obtenus, la remédiation se priorise. On ne corrige pas tout en même temps : on classe par criticité × coût × risque, et on agit sans interruption de service.

1. Quick wins sans risque (semaine 1). Suppression des ressources orphelines confirmées (IP non attachées, disques détachés, snapshots périmés), activation du MFA, révocation des accès orphelins évidents. Gain FinOps et sécurité immédiat, aucun impact production.
2. Sécurisation prioritaire (semaines 1–2). Fermeture des expositions publiques injustifiées, durcissement IAM/Entra ID, mise sous coffre des secrets, chiffrement manquant. Priorité aux ressources exposées à Internet.
3. Reprise de propriété (en parallèle). Transfert des comptes, reprise des accès d'administration, révocation du prestataire sortant.
4. Rétro-documentation et IaC (semaines 2–4). Reconstitution du socle IaC sur le périmètre critique d'abord, runbooks de restauration, schémas.
5. Mise en conformité (selon secteur). Alignement sur les exigences RGPD/ISO 27001/HDS/DORA applicables, production des preuves documentaires.

La règle d'or : inventorier avant de supprimer, et ne jamais couper une ressource dont l'usage n'est pas formellement écarté. Une instance « inutile » peut porter un flux nocturne qu'on ne voit pas en journée. La réversibilité de chaque action (snapshot avant suppression, fenêtre de réversion) protège la production.

Cette priorisation est l'objet d'un audit d'infrastructure cloud, qui débouche sur une feuille de route chiffrée.

Gouvernance cloud : éviter la récidive

Documenter une fois ne sert à rien si le cloud redevient une boîte noire six mois plus tard. La gouvernance installe les garde-fous qui maintiennent l'ordre par construction. Voici la checklist anti-récidive.

• Landing zone. Poser une structure de comptes normalisée : Cloud Adoption Framework et landing zone côté Azure, AWS Control Tower / Landing Zone Accelerator côté AWS. Tout nouvel environnement naît dans un cadre standard (réseau, sécurité, journalisation, facturation).
• Tagging obligatoire. Définir un schéma d'étiquettes (propriétaire, projet, environnement, centre de coût) et le rendre obligatoire : une ressource sans étiquette est non conforme, donc visible et corrigeable.
• Garde-fous de configuration. Azure Policy côté Azure, SCP (Service Control Policies) côté AWS : interdire les régions non autorisées, imposer le chiffrement, bloquer les configurations dangereuses, refuser la création de ressources sans tag.
• Tout en IaC, console en lecture seule. Aucune création manuelle en production ; toute modification passe par le code et une pull request. Détection de drift active.
• Revue d'accès périodique. Recertification régulière des identités et des privilèges (Entra ID / IAM Identity Center), suppression des comptes orphelins, rotation des secrets.
• Documentation vivante. Diagrammes régénérés, CMDB ou registre des actifs alimenté automatiquement, runbooks versionnés, pas un PDF figé qui périme en trois mois.
• Alignement Well-Architected. Revue périodique selon le Well-Architected Framework (6 piliers AWS) ou Azure Well-Architected, dont une AWS Well-Architected Review structure l'évaluation.

Cette discipline est le cœur d'une mission de gouvernance cloud. Sur les environnements conteneurisés, elle s'étend au RBAC, aux network policies et à l'admission control, traités dans notre audit Kubernetes.

Documentation vivante : sortir du PDF figé

Le piège classique : produire une belle documentation… périmée trois mois plus tard. La seule documentation fiable est celle qui vit au même rythme que l'infrastructure.

Infrastructure as Code rend le code lui-même documentaire : il décrit l'état souhaité, se versionne dans Git, et tout écart se détecte via terraform plan. La revue de code devient le moment où la documentation est validée.

Documentation as Code applique le même principe au reste : runbooks, ADR, diagrammes générés et schémas sont stockés en Markdown/texte dans le même dépôt Git que le code, revus en pull request, et régénérés automatiquement à chaque changement. Ainsi :

• L'historique Git trace qui a changé quoi et quand, une traçabilité directement utile à la conformité.
• La documentation suit le cycle de vie du code, pas un cycle parallèle qui dérive.
• Le bus factor s'effondre : le savoir est dans le dépôt, accessible à toute l'équipe.

Une CMDB ou un registre d'actifs alimenté depuis l'inventaire automatique, des diagrammes générés (depuis l'état réel ou le code), et des runbooks versionnés complètent le dispositif. L'objectif n'est pas un livrable mort, mais une mécanique où la documentation reste à jour par construction.

Distinguer les artefacts de documentation et leur rôle

Les pages généralistes mélangent souvent ces objets. Chacun a une fonction précise et n'en remplace aucun autre.

| Artefact | Répond à la question | Format type | Rôle principal | |---|---|---|---| | Inventaire | Qu'est-ce qui tourne ? | Export Resource Graph / AWS Config | Recensement exhaustif, base sécurité et FinOps | | Diagramme d'architecture | Comment les composants s'articulent ? | Schéma logique (généré, draw.io) | Compréhension d'ensemble, onboarding | | Schéma réseau | Comment les flux circulent ? | Schéma réseau | Sécurité réseau, diagnostic | | Infrastructure as Code | Comment recréer l'infra ? | Terraform / Bicep dans Git | Source de vérité, reproductibilité, anti-drift | | Runbook | Comment exécuter une opération ? | Procédure pas-à-pas | Exploitation, gestion d'incident | | ADR | Pourquoi ce choix ? | Note de décision datée | Mémoire des arbitrages | | DAT | Vue de référence consolidée | Document de synthèse | Référence projet, conformité | | CMDB | Référentiel central des actifs | Base de configuration | Gouvernance, lien ITSM |

Outils de découverte et de cartographie comparés

Aucun outil ne couvre tout. La bonne approche combine génération automatique (pour l'inventaire et les diagrammes) et écriture maîtrisée (pour les ADR et runbooks).

| Outil | Cas d'usage | Cloud | Force | Limite | |---|---|---|---|---| | Azure Resource Graph | Inventaire et requêtes multi-abonnements | Azure | Rapide, exhaustif, inclus | Pas de diagramme natif | | AWS Config / Resource Explorer | Inventaire + historique + recherche transverse | AWS | Suivi du drift, conformité | Paramétrage, coût à l'usage | | Azure Policy / AWS SCP | Garde-fous et détection de non-conformité | Azure / AWS | Anti-récidive, préventif | Évalue, ne cartographie pas | | aztfexport | Export Azure existant en Terraform | Azure | Officiel Microsoft, par RG ou requête | Code à refactoriser | | terraformer | Export multi-cloud en Terraform | Azure + AWS + GCP | Couvre de nombreux services | Communautaire, à valider | | terraform import / -generate-config-out | Reconstituer l'IaC ressource par ressource | Azure + AWS | Source de vérité versionnée | Travail initial conséquent | | bicep decompile | Convertir ARM exporté en Bicep | Azure | Natif, point de départ | Code à nettoyer | | Cloudockit | Génération automatique de diagrammes + docs | Azure + AWS | Documentation complète automatisée | Outil commercial | | Defender for Cloud Apps | Cloud Discovery du shadow IT SaaS | Multi | Révèle les apps non approuvées | Sujet SaaS, pas l'IaaS | | draw.io (diagrams.net) | Schémas manuels versionnables | Indépendant | Gratuit, exportable | Manuel, à maintenir |

En pratique, une combinaison efficace : Resource Graph / AWS Config pour l'inventaire, aztfexport / terraform import pour le socle IaC, un générateur (Cloudockit) pour les diagrammes de départ, draw.io pour les schémas affinés versionnés, et Azure Policy / SCP pour verrouiller la récidive.

Qui est responsable ? Matrice DSI, RSSI, DAF

Un cloud non documenté n'est jamais le problème d'une seule fonction. La reprise réussie suppose que chacun assume sa part, dans le cadre du modèle de responsabilité partagée (le fournisseur sécurise le socle, vous sécurisez vos configurations, vos accès et vos données).

| Acteur | Ce qu'il porte | Sa question clé | |---|---|---| | DSI | Inventaire, IaC, exploitation, gouvernance technique | « Sait-on reconstruire la plateforme sans une personne précise ? » | | RSSI | Surface d'attaque, IAM, conformité sécurité, revue d'accès | « Connaît-on et maîtrise-t-on toutes les ressources exposées ? » | | DAF | Pilotage du budget cloud, FinOps, contrats prestataires | « Paie-t-on des ressources fantômes ? Sommes-nous réversibles ? » | | Direction générale | Arbitrage risque / coût / délai, dépendance prestataire | « Sommes-nous propriétaires et autonomes de notre cloud ? » |

Notre rôle est de traduire l'enjeu technique en langage de décision (coûts, risques, délais) pour que la DSI et la direction parlent le même langage. C'est la vocation de notre conseil en architecture.

Étude de cas représentative : reprise d'un environnement Azure hérité

Cas représentatif, anonymisé. Une ETI de services (DSI réduite) hérite d'une plateforme Azure construite par un freelance parti sans transmission. Aucun IaC, schéma datant de deux ans, secrets éparpillés, bus factor passé de 1 à 0.

Avant. Quatre abonnements, dont un découvert pendant l'inventaire. Aucune capacité à diagnostiquer un incident sans le freelance. Accès Global Admin du prestataire toujours actifs. PRA théorique, jamais testé. Facture cloud en hausse sans explication.

Démarche (mission type de 2 à 7 jours, selon périmètre).

1. Inventaire via Azure Resource Graph sur les quatre abonnements → mise au jour de ressources orphelines et d'un environnement de test jamais éteint.
2. Reprise de la propriété des abonnements et des accès Global Admin, MFA activé, révocation du prestataire.
3. Cartographie des dépendances et reconstruction du schéma réseau, génération des diagrammes.
4. Reconstitution de l'IaC en Bicep/Terraform via aztfexport et import, versionnée dans le dépôt Git du client ; vérification d'un plan sans changement.
5. Runbooks essentiels (restauration, rotation des secrets), migration des secrets vers Key Vault, DAT de référence.

Après (résultats observés sur ce type de mission). Bus factor remonté au niveau de l'équipe interne. Réduction mesurable de la facture mensuelle par arrêt des ressources orphelines identifiées. PRA enfin testable car l'infra est redéployable depuis le code. Conformité documentaire prête pour un futur audit.

Les ordres de grandeur de gain FinOps et de réduction de risque varient fortement selon l'état initial : ils sont à confirmer par un diagnostic, jamais garantis a priori.

Combien de temps, quel budget, quels livrables ?

| Élément | Détail | |---|---| | Durée indicative | 2 à 7 jours ouvrés, selon le nombre de comptes/abonnements, de ressources et la cible (inventaire seul ou IaC complet) | | Budget indicatif | 4 000 à 10 000 €, fourchette donnée à titre indicatif, sur devis après cadrage du périmètre | | Livrables | Inventaire exhaustif · schéma d'architecture · schéma réseau · socle IaC versionné dans vos dépôts · runbooks essentiels · registre des secrets · DAT de synthèse · feuille de route de remédiation priorisée | | Ce qui fait varier le prix | Multi-cloud (Azure + AWS), nombre de comptes, profondeur de l'IaC (inventaire vs reconstitution complète), reprise de propriété auprès d'un prestataire, exigences de conformité (HDS, DORA, ISO 27001) |

Le budget ci-dessus est une fourchette de cadrage, pas un tarif ferme. Le périmètre exact se définit lors du diagnostic en ligne ou d'un échange. Pour les environnements lourds, la reprise s'enchaîne souvent avec une mission de remise en ordre ou de gouvernance.

Reprenez la main sur votre cloud. Lancez un diagnostic en ligne ou contactez-nous : nous répondons sous 48 h ouvrées. Vous repartez avec une vision claire de votre dette documentaire et un plan de remédiation chiffré.

Pourquoi Architecte Cloud

Intermédiaire indépendant d'expertise et d'infogérance sur Microsoft Azure et AWS, nous portons un parti pris simple : votre infrastructure vous appartient. Code IaC dans vos dépôts, comptes à votre nom, documentation remise, réversibilité réelle. Pas d'enfermement.

• Une expertise cloud éprouvée sur de nombreux projets Azure et AWS, portée par un réseau de prestataires reconnus.
• Microsoft Azure Partner (Solutions Partner for Infrastructure), AWS Partner (Advanced Tier Services).
• Prestataires et experts qualifiés disposant des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Pro, CISSP, Azure Security Engineer, FinOps Certified Practitioner).
• Démarche ISO 27001, membre de la FinOps Foundation.
• Recommandations traduites en langage clair (coûts, risques, délais) pour la DSI comme pour la direction générale.

Pour aller plus loin : nos services, notre approche par secteur, le guide du cloud et à propos.

FAQ : Cloud non documenté

Qu'est-ce qu'une ressource cloud non documentée ?

C'est une ressource Azure, AWS ou GCP (machine, base, conteneur, fonction, IP, réseau, identité) qui tourne dans vos comptes sans être décrite par un artefact de référence à jour : ni Infrastructure as Code, ni inventaire, ni schéma. Elle existe et elle est facturée, mais personne ne peut dire avec certitude à quoi elle sert, qui l'a créée ni comment la recréer.

Quelle est la différence entre shadow IT et cloud non documenté ?

Le shadow IT applicatif désigne des applications SaaS tierces souscrites hors DSI : le risque porte sur la donnée qui sort. Le cloud non documenté désigne vos propres ressources IaaS/PaaS, dans vos comptes, sans IaC ni inventaire : le risque porte sur votre capacité à exploiter, sécuriser et reconstruire votre plateforme. On détecte le premier par du Cloud Discovery (Defender for Cloud Apps), le second par un inventaire cloud (Resource Graph, AWS Config).

Comment savoir ce qui tourne réellement dans mon compte Azure ou AWS ?

Sur Azure, Azure Resource Graph Explorer interroge toutes les ressources de tous les abonnements en une requête. Sur AWS, AWS Resource Explorer et AWS Config (en aggregator multi-comptes) recensent l'inventaire et l'historique de configuration. On croise ensuite ces données avec la facturation (Cost Management, Cost Explorer) pour repérer les ressources payées mais non référencées.

Comment documenter une infrastructure cloud existante ?

Par rétro-documentation en cinq étapes : inventaire exhaustif (Resource Graph, AWS Config), cartographie des dépendances et du réseau, génération des diagrammes, reconstitution de l'Infrastructure as Code (aztfexport, terraform import), puis rédaction des runbooks, ADR et registre des secrets. L'ensemble est versionné dans Git pour rester vivant.

Comment faire l'inventaire de ses ressources cloud ?

On extrait l'état réel sur tous les comptes et abonnements, pas seulement le principal. Côté Azure : Resource Graph et Azure CLI. Côté AWS : Resource Explorer, AWS Config en aggregator d'organisation, Trusted Advisor. On agrège au niveau de l'organisation pour ne pas manquer de comptes, puis on croise avec la facturation pour détecter les ressources orphelines.

Comment reprendre une infrastructure cloud créée par un ancien prestataire ?

Dans cet ordre : vérifier que les comptes sont à votre nom, reprendre les accès d'administration (Global Admin / root / IAM Identity Center) et activer le MFA, inventorier avant toute coupure, récupérer ou reconstituer le code IaC et les secrets, puis révoquer les accès du prestataire. Une clause de réversibilité encadre le transfert des artefacts et de la propriété.

Quels sont les risques d'un cloud non documenté ?

Quatre familles : sécurité (ressources exposées, comptes orphelins, surface d'attaque inconnue), finances (ressources fantômes facturées, dérive des coûts), conformité (audit RGPD/ISO 27001/HDS impossible faute de cartographie) et opérations (diagnostic d'incident ralenti, PRA non reconstructible, bus factor de 1). Ces risques restent invisibles jusqu'à l'incident, le départ ou l'audit.

Comment importer une infrastructure existante dans Terraform ?

Avec terraform import ressource par ressource, ou plus rapidement avec aztfexport (Azure) ou terraformer (multi-cloud) qui génèrent code et state à partir de l'existant. Sur Terraform récent, le bloc import et plan -generate-config-out produisent une ébauche de configuration. On refactorise ensuite en modules, et on valide qu'un terraform plan ne propose aucun changement.

Combien coûtent les ressources cloud orphelines ou fantômes ?

Cela dépend de leur nombre et de leur type, mais les postes récurrents sont les disques détachés, les IP publiques non attachées, les snapshots non purgés, les passerelles NAT inutiles (souvent les plus coûteuses), les instances arrêtées non supprimées et les environnements de test jamais éteints. Dans un parc non gouverné, le gaspillage cloud constaté par le marché se situe couramment entre 20 et 30 % du budget. Le chiffre exact se mesure par inventaire croisé avec la facturation.

Qu'est-ce que le drift d'infrastructure et comment le détecter ?

Le drift est l'écart entre votre code IaC et l'état réel du cloud, créé dès qu'on modifie une ressource à la main dans la console. On le détecte avec terraform plan (qui signale des changements non voulus) ou terraform plan -refresh-only (qui aligne le state sur le réel sans rien modifier), et avec AWS Config ou Azure Policy au niveau de la gouvernance. La parade durable : toute modification passe par le code et une pull request.

Quels outils pour cartographier automatiquement une architecture cloud ?

Pour l'inventaire : Azure Resource Graph, AWS Config et Resource Explorer. Pour l'IaC : aztfexport, terraformer, terraform import. Pour les diagrammes : des générateurs comme Cloudockit produisent des schémas depuis l'état réel, complétés par draw.io pour l'affinage versionnable. Pour le shadow IT SaaS, distinct, Defender for Cloud Apps fait du Cloud Discovery.

Comment éviter que des ressources cloud échappent de nouveau au contrôle ?

Par la gouvernance : une landing zone (Cloud Adoption Framework côté Azure, Control Tower côté AWS), un tagging obligatoire, des garde-fous (Azure Policy, SCP) qui bloquent les configurations non conformes, le « tout en IaC » avec console en lecture seule, une revue d'accès périodique et une documentation vivante régénérée automatiquement. La discipline anti-drift complète le dispositif.

Combien de temps et quel budget pour documenter un cloud existant ?

À titre indicatif, comptez 2 à 7 jours ouvrés et une fourchette de 4 000 à 10 000 €, sur devis selon le périmètre. Le prix varie avec le nombre de comptes, la profondeur de l'IaC visée (inventaire seul ou reconstitution complète), la présence d'une reprise de propriété auprès d'un prestataire et les exigences de conformité (HDS, DORA, ISO 27001).

Comment récupérer les accès administrateur d'un cloud géré par un tiers ?

En reprenant d'abord la propriété du tenant Azure ou de l'organisation AWS, puis en (re)créant vos propres comptes d'administration (Global Admin / utilisateurs IAM Identity Center), en activant le MFA, en inventoriant l'environnement, et enfin en révoquant les accès du prestataire une fois la transition assurée. Une clause de réversibilité contractuelle sécurise ce transfert et la remise des secrets.