Reprendre une infrastructure cloud existante

Reprendre une infrastructure cloud existante, c'est prendre en charge l'exploitation d'une plateforme Azure ou AWS déjà en production, souvent mal documentée, sans Infrastructure as Code, héritée d'un prestataire sortant ou d'un développeur parti. L'enjeu n'est pas de tout reconstruire, mais de récupérer les accès, cartographier l'existant, remettre sous contrôle et reprendre l'exploitation sans interrompre le service. Ce dossier décrit le parcours complet de reprise, étape par étape, avec les durées, les coûts indicatifs, les pièges et les livrables, pour un décideur (DSI, RSSI, DAF) comme pour l'équipe technique qui devra opérer ensuite.

Reprendre une infrastructure cloud existante : définition

Définition. Reprendre une infrastructure cloud existante consiste à prendre en charge opérationnellement une plateforme Azure ou AWS déjà en production : récupérer et sécuriser les accès, auditer l'existant (ressources, dépendances, sécurité, coûts, conformité), reconstituer la documentation et le code d'infrastructure manquants, puis assurer l'exploitation et la supervision. C'est un projet de take-over, distinct d'une migration on-premise vers le cloud : ici, la plateforme tourne déjà. Il faut en reprendre le contrôle sans rupture de service.

Cette opération porte plusieurs noms selon les contextes : reprise en main, transfert d'infogérance, take-over cloud, changement de prestataire, réversibilité entrante. Le point commun : vous n'êtes pas à l'origine de la construction, mais vous devenez responsable de son fonctionnement, de sa sécurité et de son coût.

La reprise se distingue nettement d'une migration classique. Une migration cloud d'entreprise part d'un existant connu (souvent on-premise) pour le porter vers une cible neuve que vous concevez. Une reprise part d'une cible déjà construite par d'autres, dont vous ignorez l'historique, les choix et les angles morts. La difficulté n'est pas technique au sens du build : elle est dans la réconciliation entre ce qui existe réellement et ce que vous croyez exister.

Les étapes de la reprise, dans l'ordre

Un take-over maîtrisé suit toujours la même séquence ordonnée. Chaque étape conditionne la suivante :

1. Sécuriser les accès : récupérer et reprendre le contrôle des comptes d'administration, du tenant, des coffres de secrets et du registrar DNS avant toute autre action.
2. Auditer l'existant : inventorier les ressources, cartographier les dépendances, évaluer la posture de sécurité, les coûts et la conformité.
3. Remettre sous IaC : reconstituer le code d'infrastructure (Terraform, Bicep) et la documentation à partir de l'existant.
4. Transférer l'administration : basculer les abonnements, comptes et engagements vers votre gouvernance.
5. Assurer le run : mettre en place la supervision, la gestion d'incidents et la continuité d'activité.

Le reste de ce dossier détaille chacune de ces étapes, plus les arbitrages (reprendre ou reconstruire), les coûts, les délais et les clauses contractuelles qui sécurisent l'opération.

Pourquoi reprendre : les signaux qui déclenchent un take-over

On ne décide pas de reprendre une infrastructure par confort. Une reprise répond presque toujours à un événement déclencheur. Les plus fréquents :

• Le prestataire historique part : fin de contrat, désaccord, défaillance, rachat. Le savoir et les accès risquent de partir avec lui.
• Un sachant unique quitte l'entreprise : le développeur ou l'administrateur qui « connaissait tout » démissionne, et personne ne sait redéployer ni dépanner.
• La facture cloud dérape : la dépense augmente sans explication, et personne ne maîtrise les leviers. C'est souvent le déclencheur pour la direction financière (voir aussi optimisation des coûts cloud).
• Un incident révèle la fragilité : une panne, une fuite de données, une faille exploitée. On découvre alors qu'il n'y a ni sauvegarde testée, ni plan de reprise, ni documentation.
• Un audit de conformité échoue (RGPD, HDS, DORA, ISO 27001) : un contrôle révèle des écarts impossibles à corriger faute de maîtrise de l'existant.
• Une levée de fonds ou une acquisition : la due diligence technique exige une infrastructure gouvernée, documentée et auditable.

Dans tous ces cas, le besoin est le même : reprendre le contrôle d'une plateforme que vous n'avez pas construite, vite, et sans casser ce qui fonctionne.

Grille des red flags : reconnaître une infra héritée à risque

Avant même de chiffrer une reprise, il faut savoir lire les signaux de danger. Voici la grille que nous appliquons lors d'un premier contact. Plus la liste cochée est longue, plus la reprise sera lourde, et plus elle est urgente.

| Domaine | Signal d'alerte (red flag) | Risque associé | |---|---|---| | Accès | Compte root / Global Admin partagé, sans MFA | Reprise impossible ou prise d'otage des accès | | Identité | Aucune séparation des rôles, droits Owner distribués largement | Mouvement latéral, erreur fatale, fraude | | IaC | Tout créé à la console (click-ops), aucun code | Impossible de redéployer ou de versionner | | Documentation | Pas de schéma, pas de runbook, pas d'inventaire | Surcoût de rétro-ingénierie, dépendance au sachant | | Sauvegardes | Sauvegardes absentes ou jamais restaurées (« testées ») | Perte de données irréversible sur incident | | Réseau | Ports d'administration ouverts sur Internet, pas de segmentation | Surface d'attaque exposée | | Secrets | Clés API et mots de passe en clair, dans le code ou un tableur | Compromission, non-conformité | | Coûts | Aucun étiquetage (tagging), ressources orphelines | Gaspillage, refacturation impossible | | Continuité | Pas de PRA/PCA, RTO/RPO non définis | Indisponibilité longue sur sinistre | | Contrat | Aucune clause de réversibilité avec le sortant | Transfert bloqué ou très coûteux |

À retenir. Une infrastructure peut fonctionner parfaitement et cocher pourtant la moitié de cette grille. Le risque n'est pas visible tant que rien ne casse. La reprise consiste précisément à transformer ces angles morts en éléments maîtrisés et documentés.

Étape 1 : Récupérer et sécuriser les accès

C'est la première chose à faire, avant tout audit technique. Tant que vous ne contrôlez pas les accès de plus haut niveau, vous ne maîtrisez rien : un tiers peut encore modifier, exfiltrer ou couper l'environnement. La sécurisation des accès est aussi le moment le plus sensible d'une reprise, car elle se fait souvent en coordination, parfois en tension, avec le prestataire sortant.

Inventaire des accès et secrets à récupérer

La règle est simple : tout ce qui permet d'administrer, de se connecter ou de modifier l'infrastructure doit être recensé, repris à votre nom, puis ce qui appartenait au sortant doit être révoqué. Voici la liste exhaustive que nous déroulons systématiquement.

Comptes et identités d'administration :

• Compte Global Administrator du tenant Microsoft Entra ID (ex-Azure AD) et comptes Owner des abonnements Azure.
• Compte root AWS, utilisateurs et rôles IAM / IAM Identity Center disposant de droits d'administration.
• Comptes de service (service accounts), identités managées et principaux d'application (service principals).
• Accès aux consoles d'administration : portail Azure, console AWS, Partner Center, AWS Organizations.

Secrets et clés :

• Coffres de secrets : Azure Key Vault, AWS Secrets Manager, HashiCorp Vault.
• Clés d'accès API, jetons, certificats, chaînes de connexion aux bases de données.
• Clés SSH, mots de passe d'administration des machines, comptes de bases de données.

Périmètre réseau et noms de domaine :

• Compte du registrar (bureau d'enregistrement) des noms de domaine.
• Gestion DNS (zones Azure DNS, Route 53, ou DNS externe) : souvent l'angle mort le plus dangereux.
• Certificats TLS/SSL, autorités de certification, configuration des passerelles.

Outils d'exploitation périphériques :

• EDR / antivirus managé, RMM (outil de supervision et d'administration à distance).
• Firewall et VPN, ticketing, supervision, dépôts de code (GitHub, GitLab, Azure DevOps).

Pourquoi le DNS et le registrar d'abord. Qui contrôle le DNS contrôle la résolution de vos domaines, donc votre messagerie, vos certificats et la disponibilité de vos services. C'est aussi le levier qu'un prestataire non coopératif peut retenir le plus longtemps. Ce point est traité en priorité absolue dès le premier jour de reprise.

Reprise en main et révocation

Une fois les accès recensés, l'ordre des opérations compte. On reprend d'abord le contrôle au plus haut niveau (compte root AWS, Global Admin Entra ID), on active le MFA sur ces comptes, on crée vos propres comptes d'administration nominatifs, puis on révoque méthodiquement les accès du prestataire sortant et des personnes parties. Chaque révocation est tracée, datée et validée avec vous.

Cette étape s'articule étroitement avec la sécurisation de l'infrastructure cloud : reprendre les accès, c'est aussi l'occasion de corriger immédiatement les configurations les plus dangereuses (comptes partagés, absence de MFA, droits Owner trop larges).

Quand le prestataire sortant ne coopère pas

Le cas existe : un prestataire qui refuse la réversibilité, retarde la remise des accès, ou conserve la propriété de comptes créés à son nom. La procédure de reprise en main forcée s'appuie sur plusieurs leviers :

• Le rattachement de propriété cloud : sur Azure comme sur AWS, le propriétaire du tenant / du compte de facturation peut, par les mécanismes natifs, reprendre la main administrative même sans la collaboration du prestataire, à condition de prouver la propriété juridique.
• Le transfert de registrar : un nom de domaine se transfère via un code d'autorisation, et les litiges relèvent de procédures encadrées par l'AFNIC ou l'ICANN.
• La reconstruction sélective : pour les briques dont l'accès reste verrouillé, on reconstruit à côté plutôt que de négocier sans fin (voir l'arbitrage reprendre vs reconstruire plus bas).
• Le terrain contractuel : une clause de réversibilité et une clause d'audit, quand elles existent, transforment une négociation en obligation. Quand elles n'existent pas, la reprise coûte plus cher : c'est l'un des principaux surcoûts d'un take-over.

Étape 2. L'audit de reprise : état des lieux de l'existant

Une fois les accès sécurisés, on ouvre le capot. L'audit de reprise vise à reconstituer une image fidèle et datée de la plateforme : ce qui tourne, comment c'est relié, ce que ça coûte, où sont les risques. Sans cette base, toute action ultérieure se fait à l'aveugle. C'est le cœur de notre audit d'infrastructure cloud, adapté ici au cas d'une plateforme héritée.

Inventaire complet des ressources et des coûts

On dresse l'inventaire exhaustif, abonnement par abonnement et compte par compte :

• Abonnements et comptes : tous les abonnements Azure, tous les comptes AWS, leur rattachement de facturation, leur statut.
• Ressources de calcul, stockage, réseau, bases de données : machines virtuelles, conteneurs, clusters AKS / EKS, fonctions serverless, comptes de stockage, buckets, bases managées.
• Coûts actuels : ventilation via Azure Cost Management et AWS Cost Explorer, identification des postes les plus lourds et des engagements en cours.
• Sauvegardes : existence, périmètre, fréquence, et surtout, sont-elles testées ? Une sauvegarde jamais restaurée n'est pas une sauvegarde.

Cartographie technique et dépendances cachées

L'inventaire dit ce qui existe ; la cartographie dit comment c'est relié. On produit :

• Un schéma d'architecture : la vue logique des composants (passerelles, applications, bases, files de messages).
• Une matrice de flux : qui parle à qui, sur quels ports, dans quel sens (base de la sécurité réseau).
• Un diagramme d'urbanisation applicative : la répartition des applications, leurs interdépendances, leurs criticités.
• L'identification des dépendances cachées : c'est ici que se logent les mauvaises surprises. Un cron sur une machine oubliée, une clé API codée en dur, un service tiers indispensable mais non documenté, un certificat qui expire bientôt. Ces dépendances cachées sont la première cause d'incident lors d'une bascule.

Posture de sécurité et conformité

On évalue la posture de sécurité au regard de référentiels reconnus, sans complaisance :

• Configurations permissives : groupes de sécurité ouverts, stockage public, chiffrement absent, journalisation désactivée. On s'appuie sur Microsoft Defender for Cloud (Azure) et AWS Security Hub (AWS), comparés aux CIS Benchmarks.
• Modèle de responsabilité partagée : on clarifie précisément ce que le fournisseur sécurise et ce qui reste à votre charge, distinction souvent floue dans les infrastructures héritées.
• Conformité réglementaire : RGPD (rôle de responsable de traitement / sous-traitant au sens de l'article 28), exigences sectorielles (voir plus bas), traçabilité des accès et des traitements.

Évaluation FinOps de l'existant

Une infrastructure non gouvernée gaspille presque toujours. L'audit FinOps repère les leviers de réduction de facture :

• Ressources orphelines : disques non rattachés, adresses IP réservées inutilisées, snapshots anciens, environnements de test laissés allumés.
• Surdimensionnement (rightsizing) : machines trop grandes pour leur charge réelle.
• Absence d'engagements : aucune réservation ni Savings Plans alors que des charges stables tournent 24/7 à prix fort.
• Étiquetage absent : sans tagging, impossible d'attribuer les coûts ni de piloter. La remise en place du tagging est un livrable systématique.

Les gains FinOps constatés sur une infrastructure héritée non optimisée sont souvent significatifs ; ils financent fréquemment une partie du coût de la reprise. Le détail relève de notre approche optimisation des coûts cloud.

Étape 3. Reverse-engineering : remettre l'infra sous Infrastructure as Code

C'est le volet le plus technique, et celui qu'aucun concurrent ne relie clairement au cas business de la reprise. Une infrastructure héritée a presque toujours été construite à la console, sans code. Pour la maîtriser durablement, il faut la rétro-documenter en Infrastructure as Code : reconstituer le code qui décrit ce qui existe déjà.

Importer l'existant dans Terraform ou Bicep

Le principe : on ne reconstruit pas, on importe. Les ressources déjà déployées sont rattachées à un code qui devient leur source de vérité.

• Sur Azure comme AWS, terraform import (ou les blocs import déclaratifs des versions récentes de Terraform / OpenTofu) rattache une ressource existante à une définition de code et à l'état Terraform (tfstate).
• Côté Azure, Bicep offre une approche déclarative native ; des outils permettent d'exporter l'existant vers du Bicep à réviser.
• Le fichier d'état (tfstate) devient l'inventaire vivant : il faut le stocker de façon sécurisée et versionnée (backend distant chiffré, jamais sur un poste).

Réconcilier le drift et gérer les cas limites

Importer ne suffit pas. Deux difficultés majeures se présentent :

• Le drift d'infrastructure : l'écart entre l'état réel et le code. Sur une infra héritée, le drift est massif au départ. On le détecte via terraform plan, puis on réconcilie : soit on aligne le code sur le réel, soit on corrige le réel pour qu'il respecte la cible.
• Les ressources non importables : certaines ressources ne se gèrent pas par import, typiquement les secrets et clés générés (par exemple aws_iam_access_key, dont la partie secrète n'est révélée qu'à la création). Pour celles-ci, la bonne pratique est la rotation : on les recrée proprement sous IaC plutôt que de tenter un import impossible.

Mise sous version dans vos dépôts

Le code reconstitué est versionné dans vos dépôts (GitHub, GitLab, Azure DevOps), à votre nom, avec un historique. C'est un point de principe chez nous, au cœur de notre engagement d'autonomie : le code d'infrastructure vous appartient, il ne reste pas dans les outils du prestataire. C'est la condition d'une réversibilité réelle et la base d'une gouvernance cloud durable. Le détail méthodologique de cette rétro-documentation est traité dans notre dossier sur le cloud non documenté.

Pourquoi l'IaC est non négociable. Sans code, votre infrastructure reste une boîte noire : impossible à redéployer à l'identique, à auditer, à faire évoluer en sécurité ou à transmettre. La mise sous IaC transforme un savoir tacite et fragile en un actif documenté, versionné et transférable. C'est l'inverse exact de la dette dont vous héritez.

Étape 4 : Le transfert administratif Azure et AWS

Reprendre l'exploitation suppose aussi de reprendre la gestion administrative et contractuelle des comptes cloud. Ce volet, purement opérationnel, est rarement explicité pour les décideurs. Il est pourtant déterminant pour la facturation, les engagements et la propriété.

Côté Azure :

• Changement de partenaire CSP dans Partner Center : si vos abonnements sont achetés via un revendeur (modèle CSP), le transfert vers un nouveau partenaire (ou vers un contrat direct) se planifie pour éviter toute coupure de facturation.
• Transfert d'abonnements entre tenants ou répertoires, en préservant les ressources et les rattachements.
• Réservations et Savings Plans : ces engagements pluriannuels doivent être transférés ou réaffectés sans les perdre.

Côté AWS :

• AWS Organizations : déplacement de comptes membres d'une organisation à une autre, ou mise en place d'une organisation gouvernée quand il n'en existait pas.
• Reprise du compte de gestion (management account) et clarification de la facturation consolidée.
• Transfert ou réaffectation des Savings Plans et Reserved Instances.

L'objectif n'est pas seulement de changer un nom sur une facture : c'est de passer d'un compte mal géré à un compte gouverné, à votre nom, sous votre contrôle. Ce scénario de reprise cloud-to-cloud gouvernée, souvent absent des contenus de migration classiques, est précisément l'un de nos terrains. Pour les bascules de charges sous-jacentes, voir nos dossiers migration de serveurs vers Azure et migration de serveurs vers AWS.

Étape 5 : Plan de transition daté, double-run et bascule sans interruption

Une reprise se mène par phases datées, pas en un grand soir. Voici le déroulé type, dont la durée totale s'étale de 1 à 4 semaines pour une infrastructure de taille moyenne bien cadrée, et jusqu'à 6 à 8 semaines pour un environnement complexe ou peu documenté.

| Phase | Contenu | Durée indicative | |---|---|---| | 1. Audit & accès | Sécurisation des accès, inventaire, cartographie, posture sécurité/FinOps | 1 à 2 semaines | | 2. Transfert | Mise sous IaC, transfert administratif, documentation | 1 à 3 semaines | | 3. Bascule | Double-run, validation, bascule de l'exploitation | quelques jours à 1 semaine | | 4. Run | Supervision, gestion d'incidents, optimisation continue | en continu |

La phase de double-run (coexistence)

Entre l'ancien et le nouveau prestataire, on ménage une période de coexistence (un double-run) pendant laquelle les rôles sont répartis par écrit : qui supervise, qui peut intervenir en production, qui valide les changements, qui détient l'astreinte. Cette répartition formelle évite le scénario le plus dangereux d'une reprise : la zone grise où chacun pense que l'autre s'en occupe.

Cette phase tampon sert aussi de filet : si un comportement inattendu apparaît après la reprise, l'environnement et la connaissance du sortant restent accessibles le temps de stabiliser.

Bascule sans interruption et plan de rollback

La bascule de l'exploitation se programme hors heures ouvrées pour les opérations sensibles, avec un plan de rollback écrit : conditions de déclenchement, étapes de retour arrière, responsable de la décision. L'objectif est une bascule sans interruption de service : dans la grande majorité des reprises, le changement de prestataire est transparent pour les utilisateurs, car il porte sur la gestion de l'infrastructure, pas sur les charges elles-mêmes.

Continuité d'activité durant la reprise (PRA/PCA)

Reprendre une infrastructure ne suspend pas le risque opérationnel : au contraire, c'est une période de vigilance accrue. On vérifie ou on met en place dès le début un dispositif de continuité :

• PRA (plan de reprise d'activité) et PCA (plan de continuité d'activité), avec des objectifs explicites de RTO (durée maximale d'interruption acceptable) et RPO (perte de données maximale acceptable).
• La vérification (souvent la découverte) de l'état réel des sauvegardes et de leur restaurabilité.

Le détail de cette démarche relève de nos dossiers PRA cloud et PCA cloud.

Reprendre ou reconstruire ? L'arbitrage

Toute infrastructure héritée ne mérite pas d'être reprise telle quelle. Quand la dette technique est trop lourde, reconstruire peut coûter moins cher et moins de risques que réparer. C'est une décision d'ingénierie et de gestion, que nous traduisons toujours en termes de coûts, de risques et de délais.

| Critère | Plutôt reprendre | Plutôt reconstruire | |---|---|---| | État de l'existant | Sain mais non documenté | Dégradé, instable, non sécurisable en l'état | | Sécurité | Écarts corrigeables par remédiation | Conception fondamentalement permissive | | Coût | Reprise + remédiation < reconstruction | Reconstruction ≤ remédiation lourde | | Délai | Continuité prioritaire, pas de fenêtre de coupure | Fenêtre de bascule disponible | | Dépendances | Connues et maîtrisables | Inextricables ou bloquées par le sortant | | Risque | Maîtrisable en double-run | Risque de transmettre la dette |

En pratique, la décision est rarement binaire : on reprend la majorité de l'environnement et on reconstruit sélectivement les briques les plus dégradées ou les plus verrouillées. Cet arbitrage chiffré fait partie des livrables de l'audit de reprise.

Étape 6. Gouvernance post-reprise : ne pas hériter à nouveau de la dette

Reprendre une infrastructure sans poser de cadre, c'est se condamner à reproduire dans deux ans la situation qu'on vient de corriger. La reprise se conclut donc par la mise en place d'une gouvernance qui empêche la dette de se reformer :

• Landing zone : un socle gouverné selon le Cloud Adoption Framework (Azure) ou via AWS Control Tower / Landing Zone Accelerator (AWS). Structure de comptes, réseau, identité et sécurité normalisés.
• Policy-as-Code : des garde-fous automatiques avec Azure Policy et les Service Control Policies (SCP) AWS, qui interdisent par construction les configurations dangereuses (stockage public, régions non autorisées, absence de chiffrement).
• RBAC et moindre privilège : des rôles clairs sur Entra ID et IAM Identity Center, et (pour les clusters) un RBAC Kubernetes et des network policies sur AKS / EKS.
• Cadre Well-Architected : alignement sur l'Azure Well-Architected et le Well-Architected Framework AWS (et ses 6 piliers) pour objectiver la qualité de la plateforme.

Cette gouvernance s'inscrit dans notre approche de gouvernance cloud et, pour les organisations matures, de Cloud Center of Excellence.

Étape 7. Le run : supervision, infogérance et transfert de connaissances

La reprise n'est pas finie quand la bascule est faite : elle commence vraiment quand l'exploitation tourne. C'est l'objet de notre infogérance cloud d'entreprise.

Supervision et gestion d'incidents

• Monitoring continu via les outils natifs (Azure Monitor, CloudWatch) et, pour la sécurité, Microsoft Defender for Cloud, AWS Security Hub et, selon le besoin, Microsoft Sentinel en SIEM.
• Gestion d'incidents avec des objectifs de MTTR (temps moyen de résolution) suivis et améliorés dans le temps.
• Supervision 24/7 quand la criticité le justifie, avec astreinte et procédures d'escalade.

Documentation continue et transfert de connaissances

La documentation n'est pas un livrable ponctuel, c'est une pratique continue. À l'issue de la reprise et tout au long du run, vous recevez :

• Des runbooks : procédures de déploiement, sauvegarde, restauration, rotation des secrets, gestion d'incident.
• L'historique des tickets et des changements, pour la traçabilité.
• Une documentation tenue à jour, remise et versionnée chez vous, pas conservée dans nos outils.

Notre principe d'autonomie. Tout ce que construisent ou documentent les prestataires de notre réseau vous appartient et reste accessible : code IaC dans vos dépôts, comptes cloud à votre nom, documentation remise. Cette réversibilité par conception est l'exact opposé de la situation dont vous héritez, et elle signifie que vous pourriez, demain, reprendre la main ou changer de prestataire sans subir le blocage que vous avez vécu.

Réversibilité : le sujet à ne plus jamais négliger

Si vous lisez ce dossier, c'est souvent parce qu'une réversibilité a été mal pensée, ou pas pensée du tout. Ne reproduisez pas l'erreur. La réversibilité est la capacité à récupérer vos données, votre code et vos accès, et à confier votre infrastructure à un autre acteur, sans dépendance technique ni rétention.

Elle se prépare contractuellement, dès l'entrée :

• Clause de réversibilité : obligation, pour le prestataire, de restituer l'infrastructure dans des formats standards et exploitables (IaC, documentation, exports de données), dans des délais définis.
• Clause d'audit : droit de vérifier à tout moment l'état réel de la plateforme et de sa documentation.
• Formats de livraison : code Terraform/Bicep, schémas, inventaires, exports de données dans des formats ouverts, pas de format propriétaire opaque.
• Plan de réversibilité comme livrable : un document vivant qui décrit, à froid, comment quitter le prestataire si besoin.

Ces exigences évitent le vendor lock-in (enfermement fournisseur) et s'inscrivent dans le cadre du Data Act européen, qui renforce les droits des clients cloud à la portabilité et à la sortie (cloud exit). Pour les acteurs financiers, DORA impose en outre des exigences explicites de réversibilité et de maîtrise des risques liés aux prestataires tiers.

Conformité sectorielle pendant la reprise

La reprise est aussi le bon moment pour remettre la conformité d'aplomb, un sujet quasi absent des contenus concurrents sur la réversibilité et l'infogérance.

• Santé : si vous traitez des données de santé, l'hébergement doit être assuré par un hébergeur certifié HDS. La reprise vérifie ce rattachement et, le cas échéant, le rétablit. Voir le secteur santé.
• Finance & assurance : DORA impose résilience opérationnelle, tests, maîtrise des risques liés aux prestataires tiers et réversibilité. Voir le secteur finance.
• Secteur public : exigences de souveraineté et, pour les données sensibles, qualification SecNumCloud de l'hébergeur. Voir le secteur public.
• Tous secteurs : RGPD (responsable de traitement / sous-traitant, art. 28), démarche ISO 27001, CIS Benchmarks comme socle de configuration.

Selon votre activité (industrie, distribution ou éditeurs SaaS), les priorités de remédiation diffèrent, et l'audit de reprise les hiérarchise.

Combien ça coûte, combien de temps : durée, budget et livrables

Mettons les chiffres sur la table, avec la transparence qui est notre marque. Les montants ci-dessous sont des fourchettes indicatives, établies sur devis après cadrage : le coût réel dépend de la taille de l'infrastructure, de son état de documentation et de la coopération du sortant.

| Scénario | État de l'existant | Durée indicative | Budget indicatif | |---|---|---|---| | Infra documentée avec IaC | Code et docs à jour, simple transfert | 1 à 2 semaines | 10 000 à 18 000 € | | Infra documentée sans IaC | Schémas présents, à mettre sous code | 2 à 4 semaines | 18 000 à 30 000 € | | Infra non documentée, sans IaC | Boîte noire, rétro-ingénierie complète | 4 à 8 semaines | 25 000 à 40 000 € |

Le surcoût de la documentation manquante. Le principal facteur de coût d'une reprise n'est pas la taille de l'infrastructure : c'est l'absence de documentation et d'IaC. Reconstituer la connaissance perdue (cartographier, importer en Terraform, réconcilier le drift, rédiger les runbooks) représente l'essentiel de l'effort. C'est pourquoi une infra non documentée coûte structurellement plus cher à reprendre qu'une infra plus grande mais propre.

Ce que vous recevez (livrables) :

• Rapport d'audit de reprise (inventaire, cartographie, posture sécurité, analyse FinOps, conformité).
• Code d'infrastructure (Terraform / Bicep) versionné dans vos dépôts.
• Schéma d'architecture, matrice de flux, diagramme d'urbanisation.
• Runbooks et documentation d'exploitation remis et tenus à jour.
• Plan de réversibilité et registre des accès.
• Plan de transition daté et plan de rollback.

Les fourchettes ci-dessus sont indicatives et sur devis : le chiffrage ferme intervient après le diagnostic. Pour le situer sur votre cas, démarrez par notre diagnostic en ligne ou contactez-nous.

Étude de cas représentative : reprise d'une infra Azure héritée

Cas représentatif (anonymisé). Une PME de services (ETI, secteur distribution) hérite de sa plateforme Azure après le départ du développeur qui l'avait construite seul. Aucun IaC, aucun schéma, Global Admin unique sans MFA, facture en hausse continue.

Déroulé : sécurisation des accès et création de comptes d'administration nominatifs en 3 jours ; audit et cartographie en 1 semaine ; mise sous Terraform (avec réconciliation du drift et rotation des secrets non importables) en 2 semaines ; bascule de l'exploitation en double-run sur une semaine.

Résultats constatés : facture mensuelle réduite d'environ un tiers par rightsizing, suppression de ressources orphelines et mise en place de réservations ; une dizaine d'écarts de sécurité critiques remédiés (stockage public, MFA, droits Owner excessifs) ; documentation et code remis dans les dépôts du client. Reprise menée sans interruption de service.

Ces résultats sont représentatifs et constatés sur un cas type ; ils ne constituent pas un engagement de résultat. Chaque infrastructure héritée est différente, et le diagnostic préalable conditionne ce qui est réellement atteignable.

Pourquoi confier votre reprise à Architecte Cloud

La reprise d'une infrastructure existante est un exercice de confiance : vous donnez à un nouvel acteur les clés de ce qui fait tourner votre organisation. Notre positionnement répond précisément à cette exigence.

• Indépendant : conseil sans parti pris entre Azure et AWS, coûts clairs, aucun engagement caché.
• Autonomie par conception : code IaC dans vos dépôts, comptes à votre nom, documentation remise, réversibilité réelle, pas d'enfermement.
• Expertise du réseau : des prestataires et experts qualifiés, disposant des certifications requises, Microsoft Azure Solutions Partner (Infrastructure), AWS Partner (Advanced Tier Services), Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer, FinOps Certified Practitioner, engagés dans une démarche ISO 27001 et membres de la FinOps Foundation.
• Langage clair : chaque recommandation traduite en coûts, risques et délais, pour la DSI comme pour la direction générale.

Pour aller plus loin selon votre besoin : conseil en architecture, migration cloud, infrastructure & DevOps, cybersécurité cloud, audit FinOps, ou le guide du cloud. Pour en savoir plus, voir la page à propos.

FAQ : Reprendre une infrastructure cloud existante

Comment reprendre une infrastructure cloud existante mal documentée ?

On procède dans l'ordre : d'abord sécuriser les accès (comptes d'administration, tenant, secrets, DNS), puis auditer et cartographier l'existant pour reconstituer l'inventaire et les dépendances, ensuite remettre l'infrastructure sous Infrastructure as Code (Terraform ou Bicep) et rédiger la documentation manquante, enfin transférer l'administration et assurer l'exploitation. La rétro-documentation est l'essentiel de l'effort quand rien n'existe au départ.

Combien de temps prend la reprise d'une infrastructure cloud par un nouveau prestataire ?

De 1 à 4 semaines pour une infrastructure de taille moyenne correctement documentée, et jusqu'à 6 à 8 semaines pour un environnement complexe, non documenté et sans IaC. La durée dépend surtout de l'état de la documentation et de la coopération du prestataire sortant, pas seulement de la taille.

Combien coûte la reprise en main d'une infrastructure Azure ou AWS existante ?

À titre indicatif et sur devis, une reprise se situe généralement entre 10 000 et 40 000 € selon le périmètre. Une infra documentée avec IaC se rapproche du bas de la fourchette ; une boîte noire sans documentation ni code, qui exige une rétro-ingénierie complète, du haut. Le chiffrage ferme intervient après le diagnostic de reprise.

Comment changer de prestataire d'infogérance cloud sans interruption de service ?

En planifiant une phase de double-run où les rôles des deux prestataires sont répartis par écrit, en préparant un plan de rollback, et en programmant les opérations sensibles hors heures ouvrées. Comme la reprise porte sur la gestion de l'infrastructure et non sur les charges elles-mêmes, la bascule est, dans la grande majorité des cas, transparente pour les utilisateurs.

Qu'est-ce que la réversibilité cloud et comment la mettre en œuvre ?

La réversibilité est votre capacité à récupérer vos données, votre code et vos accès, et à changer de prestataire sans dépendance. Elle se met en œuvre par une clause de réversibilité, une clause d'audit, des formats de livraison standards (IaC, exports ouverts) et un plan de réversibilité livrable. Le Data Act européen et, en finance, DORA renforcent ces droits à la portabilité et à la sortie.

Quels accès et identifiants récupérer auprès du prestataire sortant ?

Les comptes d'administration de plus haut niveau (root AWS, Global Admin Entra ID, Owner des abonnements), les comptes et clés de service, les coffres de secrets (Key Vault, Secrets Manager), les clés API et certificats, l'accès au registrar et au DNS, et les outils périphériques (EDR, RMM, firewall, VPN, ticketing, dépôts de code). Une fois repris, les accès du sortant doivent être révoqués et tracés.

Comment importer une infrastructure cloud existante dans Terraform ?

Avec terraform import ou les blocs d'import déclaratifs, qui rattachent chaque ressource existante à une définition de code et à l'état Terraform (tfstate). On détecte ensuite le drift avec terraform plan et on réconcilie. Certaines ressources ne sont pas importables (par exemple les clés secrètes générées comme aws_iam_access_key) et se traitent par rotation : on les recrée proprement sous IaC.

Que faire si l'infrastructure cloud n'a aucune documentation ni Infrastructure as Code ?

C'est le cas le plus fréquent en reprise. On reconstitue la connaissance par un travail de rétro-ingénierie : inventaire exhaustif, cartographie des flux et dépendances, import de l'existant en Terraform ou Bicep, puis rédaction des runbooks. C'est le poste de coût principal, mais il transforme une boîte noire fragile en un actif documenté et transférable.

Comment auditer une infrastructure cloud existante avant de la reprendre ?

L'audit de reprise inventorie les ressources et les coûts (Azure Cost Management, AWS Cost Explorer), cartographie l'architecture et les dépendances, évalue la posture de sécurité face aux CIS Benchmarks via Defender for Cloud et Security Hub, analyse les leviers FinOps et vérifie la conformité. Il produit une image fidèle et datée qui conditionne toutes les actions suivantes.

Faut-il reprendre ou reconstruire une infrastructure cloud héritée ?

On reprend quand l'existant est sain mais non documenté, et que les écarts de sécurité sont corrigeables par remédiation. On reconstruit quand la conception est fondamentalement permissive, les dépendances inextricables, ou quand reconstruire coûte moins cher et moins de risques qu'une remédiation lourde. En pratique on reprend la majorité et on reconstruit sélectivement les briques les plus dégradées.

Quels sont les risques de reprendre une infrastructure cloud existante ?

Les principaux risques sont les dépendances cachées qui surgissent à la bascule, la zone grise de responsabilité entre les deux prestataires, l'absence de sauvegardes testées, et un prestataire sortant non coopératif. On les maîtrise par une cartographie soignée, une répartition écrite des rôles en double-run, un plan de rollback et une sécurisation prioritaire des accès.

Comment transférer un abonnement Azure ou un compte AWS vers un autre partenaire ?

Côté Azure, le transfert passe par Partner Center pour un changement de partenaire CSP, et par le transfert d'abonnements entre tenants, en préservant réservations et Savings Plans. Côté AWS, on déplace les comptes membres entre organisations via AWS Organizations et on clarifie la facturation consolidée. L'objectif est de passer d'un compte mal géré à un compte gouverné, à votre nom.

Qui est responsable de la sécurité pendant la transition entre deux prestataires cloud ?

La responsabilité se répartit selon le modèle de responsabilité partagée (le fournisseur sécurise l'infrastructure sous-jacente, vous restez responsable des configurations et des données) et, pendant le double-run, selon une matrice écrite qui désigne explicitement qui supervise, qui intervient et qui valide. Sans cette répartition formelle, la transition crée une zone grise dangereuse.