La méthode en 90 jours
Un DSI sur deux que nous rencontrons a la même phrase au bout de dix minutes : “Notre contrat d’infogérance arrive à échéance et on se demande quoi faire.” Souvent il enchaîne : “On voudrait reprendre la main, mais on n’a plus la connaissance technique en interne.”
C’est le piège classique de l’externalisation longue durée. Sur le papier, vous avez une clause de réversibilité. Dans les faits, le savoir-faire a migré chez le prestataire, la documentation est obsolète, et personne en interne ne sait plus comment l’infrastructure tient debout.
Reprendre la main est pourtant possible — à condition de le faire méthodiquement, par couches, sans essayer de tout récupérer d’un coup. Cet article décrit la trame en 90 jours que nous appliquons. Elle ne vise pas à remplacer un prestataire par un autre. Elle vise à vous remettre en position de choisir.
Pourquoi la réversibilité contractuelle ne suffit pas
L’ANSSI le rappelle dans ses recommandations sur l’hébergement des SI sensibles : la clause de réversibilité est essentielle pour éviter la dépendance à une offre unique. Mais une clause, aussi bien rédigée soit-elle, ne reconstitue pas un savoir-faire.
Le vrai problème n’est pas juridique, il est cognitif. Quand un prestataire opère votre infrastructure pendant cinq ou dix ans, le savoir opérationnel se déplace progressivement de vos équipes vers les siennes — sans que personne n’en prenne acte.
Trois choses se produisent simultanément :
- La documentation s’érode. Les procédures vivent dans les outils du prestataire — ses runbooks, son ITSM, ses scripts. Vous n’y avez accès que via des tickets.
- Les dépendances cachées se multiplient. Petits scripts cron, intégrations bricolées, certificats renouvelés à la main : autant de fragilités que personne n’a inventoriées.
- Vos équipes perdent leur réflexe opérationnel. Elles ne savent plus diagnostiquer un incident sans appeler le N2 du prestataire — parce qu’elles ne le font plus depuis longtemps.
Reprendre la main suppose donc trois mouvements en parallèle : reconstituer le savoir, codifier les procédures, et remonter en compétence interne. C’est précisément ce que la méthode en 90 jours organise.
Les 3 phases en un coup d’œil
| Phase | Durée | Posture | Livrable clé |
|---|---|---|---|
| Cartographier et codifier | Jours 1–30 | Observer, ne pas toucher | Carte SI + dépôt Git initialisé |
| Industrialiser et basculer | Jours 31–60 | Agir sur un pilote choisi | Périmètre codifié et co-exploité |
| Étendre et professionnaliser | Jours 61–90 | Généraliser par criticité croissante | Gouvernance autonome définie |
Jours 1 à 30 — Cartographier et codifier l’existant
La première phase ne touche à rien. Elle observe.
Reconstituer la cartographie réelle du SI
L’ANSSI recommande un inventaire des actifs à jour comme socle de toute sécurisation. La plupart des organisations en ont une — incomplète, obsolète, ou les deux. La première étape, c’est de la reconstruire : actifs matériels et logiciels, flux de données, applications, bases, et surtout dépendances entre composants. Pas pour faire un livrable PowerPoint — pour comprendre comment l’infrastructure tient vraiment debout.
Identifier les dépendances cachées
C’est là que l’expérience compte. Les vrais points de fragilité ne sont jamais dans le contrat — ils sont dans les scripts oubliés, les certificats expirant à des dates non documentées, les comptes de service partagés entre plusieurs applications, les intégrations bricolées avec des outils externes. Une cartographie sérieuse les fait remonter.
Récupérer les actifs critiques
Quatre éléments doivent être sécurisés en priorité : accès admin sur tous les systèmes, inventaire complet des comptes et secrets, sauvegardes et leur procédure de restauration testée, documentation d’exploitation existante (même imparfaite). Ce sont vos billets de sortie. Sans eux, aucune reprise n’est possible.
Initialiser le dépôt Git
À partir du jour 1, tout ce qui est récupéré ou produit va dans Git : configurations, procédures, runbooks, inventaires. Pas dans un wiki, pas dans un drive partagé — dans Git. C’est le principe du GitOps : Git devient la source de vérité unique de votre exploitation. Chaque changement est versionné, daté, auditable. C’est aussi votre garantie de réversibilité réelle : si demain vous changez encore de partenaire, votre exploitation part avec vous.
À la fin du mois 1, vous avez une carte de votre SI, une liste de dépendances cachées, vos secrets sous contrôle, et un dépôt Git qui contient les premières pierres de votre nouvelle exploitation.
Jours 31 à 60 — Industrialiser et basculer par couches
La deuxième phase passe à l’action — mais sur un périmètre choisi, pas sur l’ensemble.
Choisir un périmètre pilote
L’erreur classique consiste à vouloir reprendre la main sur toute l’infrastructure en même temps. C’est ingérable, et c’est ce qui fait échouer la plupart des projets de réversibilité. On choisit au contraire un périmètre représentatif mais limité : un environnement non critique, une application bien délimitée, ou une famille de serveurs homogène. L’objectif est d’aller jusqu’au bout du processus sur ce périmètre, pour valider la méthode avant d’étendre.
Codifier les procédures
Sur le périmètre pilote, chaque action manuelle qu’effectuait le prestataire devient un script. Provisioning d’un serveur, déploiement d’une application, sauvegarde, redémarrage de service, rotation de certificat : tout est traduit en code dans Ansible, Terraform ou équivalent. Les runbooks deviennent exécutables, pas descriptifs.
Mettre en place l’observabilité
Avant de basculer quoi que ce soit, vous devez voir. Métriques, logs et alertes sur le périmètre pilote, dans une stack que vous maîtrisez — Prometheus, Grafana, Loki en open source si vous partez de zéro. Cette observabilité reste la vôtre, indépendamment du prestataire actuel.
Co-exploiter pendant la transition
Pas de rupture brutale. Sur le périmètre pilote, vous opérez en parallèle du prestataire : il continue à intervenir, vous montez en compétence en condition réelle, vous mesurez les écarts. C’est la phase la plus délicate politiquement — le prestataire sortant a peu d’incitations à vous aider — mais c’est aussi la plus sécurisante opérationnellement.
À la fin du mois 2, vous avez un périmètre entièrement codifié, observé et opérationnel sous votre maîtrise. Vous savez ce que ça coûte vraiment, combien de temps ça prend, et où sont vos angles morts.
Jours 61 à 90 — Étendre et professionnaliser
La troisième phase généralise — sans précipitation.
Étendre par couches
Avec la méthode validée sur le pilote, vous l’appliquez aux périmètres suivants par ordre de criticité croissante : d’abord les environnements de dev et de test, puis les applications secondaires, puis le cœur du SI. Chaque extension réutilise les modules, scripts et runbooks déjà écrits. C’est exactement le principe de l’IaC : votre code se capitalise.
Faire monter vos équipes en compétence
La réversibilité technique ne vaut rien sans la compétence interne. Pendant ces 30 jours, vos équipes ne se contentent plus d’observer — elles écrivent, déploient, opèrent. Avec accompagnement, formation, revues de code régulières. L’objectif n’est pas qu’elles fassent seules en jour 91 — c’est qu’elles soient en position de choisir quoi internaliser et quoi déléguer.
Formaliser la nouvelle gouvernance
À ce stade, vous changez la nature de la conversation avec votre infogéreur historique — ou avec un nouveau partenaire. Vous ne lui demandez plus de “tout faire”. Vous lui confiez les couches que vous choisissez de déléguer, sur la base d’un cadre que vous maîtrisez. La clause de réversibilité du prochain contrat sera concrète, parce que vous avez désormais le code, la doc et les compétences pour l’activer.
À la fin du mois 3, vous avez repris la main. Pas sur tout — sur l’essentiel. Et surtout, vous êtes en position de décider de la suite : internaliser davantage, choisir un partenaire différent, conserver votre infogéreur mais en redéfinissant le périmètre.
Les pièges à éviter
Trois pièges récurrents font dérailler les projets de réversibilité.
Vouloir tout récupérer d’un coup. L’ambition de tout reprendre en quelques semaines mène à l’échec. La règle est l’inverse : commencer petit, valider, étendre.
Négliger la documentation comme livrable contractuel. La clause de réversibilité doit exiger des livrables concrets : accès admin, inventaire, sauvegardes, procédures d’exploitation. Sans ces livrables, négocier la sortie devient un rapport de force.
Sous-estimer la dimension humaine. Vos équipes doivent vouloir remonter en compétence. Si elles vivent la réversibilité comme une charge supplémentaire, le projet s’enlise. La codification dans Git, l’automatisation, l’IA sur le diagnostic — c’est aussi ce qui rend le métier intéressant à nouveau.
Pour aller plus loin
Notre audit Run gratuit commence précisément par cet exercice : cartographie de votre périmètre actuel, identification des dépendances cachées, évaluation du degré de dépendance au prestataire, et trame d’un plan de reprise progressive.
Nous ne sommes pas un nouveau prestataire qui veut vous enfermer. Nous installons le dispositif Run as Code chez vous, dans votre Git, avec vos équipes — et nous restons à vos côtés tant que c’est utile. Pas plus.
Réserver votre audit Run gratuit →
Sources
- ANSSI — Recommandations pour l’hébergement des SI sensibles dans le cloud, cyber.gouv.fr
- ANSSI — Guide de cartographie du système d’information, cyber.gouv.fr
- DevOps.com — From Legacy to GitOps: A Roadmap for Enterprise Modernization, septembre 2025
Cloud Inspire — Le Build est devenu facile. Le Run reste un métier.
Exploitation opérée depuis la France et la Côte d’Ivoire. Stack open source, souveraine, maîtrisée bout-en-bout.