Elle a migré vers le cloud il y a 5-8 ans. Elle a licencié ou perdu ses ingénieurs systèmes, ses administrateurs réseau, ses DBA. Elle a une équipe DevOps compétente sur AWS ou GCP — mais sans aucune culture bare-metal. Elle paie des egress fees croissants. Elle a lu les CGV et découvert la juridiction californienne. Elle veut sortir.

Elle ne peut pas. Pas seule. Ses DevOps savent déployer sur EKS. Ils ne savent pas configurer un switch physique, dimensionner un plan d'adressage IP, choisir une baie de stockage, installer un hyperviseur, configurer le monitoring bare-metal. La compétence a disparu avec les ingénieurs qui partaient. C'est "Le Départ du Dernier Qui Sait" appliqué à l'échelle organisationnelle.

L'Interface Souveraine est une architecture. Elle ne s'implémente pas seule — il faut des ingénieurs pour l'écrire.
La Sortie Douce est un principe. Elle ne s'exécute pas seule — il faut des ingénieurs pour migrer.
Le Socle du Fer est une formation. Elle prend 6 à 26 semaines — et l'organisation n'a pas 26 semaines de runway avant sa prochaine facture AWS.

L'infogéreur est l'ingénieur qui manque. Il a la compétence bare-metal que l'organisation a abandonnée. Il connaît le chemin de migration parce qu'il l'a fait des dizaines de fois. Et — différence fondamentale avec un hyperscaler — son modèle économique n'est pas de créer une nouvelle dépendance mais de rendre l'organisation capable.

Dès la signature du contrat, une réunion réunit trois parties : les équipes Ecritel (chef de projet migration + ingénieurs systèmes), les équipes de l'ancien hébergeur, et les équipes du client. L'objectif n'est pas de critiquer l'existant — c'est de le comprendre précisément.

Deux scénarios pour l'accès à l'existant :
Scénario A — Export par l'ancien hébergeur : l'ancien hébergeur produit les exports de données (bases de données, systèmes de fichiers, configurations), les schémas réseau, les listes de services. Ecritel reçoit et travaille sur les exports.
Scénario B — Accès root direct : quand l'ancien hébergeur ne coopère pas ou quand le délai le requiert, les équipes Ecritel demandent l'accès root direct aux machines et réalisent elles-mêmes l'inventaire et les exports. Elles prennent la responsabilité opérationnelle des opérations réalisées sur l'infrastructure existante.

L'inventaire couvre tous les types d'OS (Linux distributions, Windows Server, BSD selon les cas), toutes les bases de données (MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, Redis — chaque moteur a ses procédures d'export et de migration spécifiques), les middlewares, les configurations réseau (VLAN, firewall rules, load balancers), les certificats, les crons, les scripts d'exploitation. Rien n'est supposé — tout est vérifié et documenté.

L'étude de l'existant produit la cartographie de dépendances — quels services dépendent de quels autres, dans quel ordre ils doivent être migrés pour ne pas casser la chaîne.

La migration ne se fait pas en une nuit. Elle est phasée selon les dépendances et les risques. Chaque phase a un planning, des critères de succès et une procédure de rollback. Des réunions de suivi sont organisées tout au long du projet — hebdomadaires pendant la migration active, bi-mensuelles pendant la stabilisation. Le client surveille l'avancement. Il teste le bon fonctionnement étape par étape. Il valide avant qu'on passe à la phase suivante. Cette validation n'est pas passive — c'est de la formation in situ.

À l'issue de la migration, les équipes Ecritel rédigent le Dossier d'Architecture Technique (DAT) — la photographie exhaustive de l'infrastructure mise en place : schémas réseau, configurations détaillées, procédures d'exploitation, procédures de backup et de restauration, contacts d'escalade. Ce document appartient au client. C'est le premier Runbook de la nouvelle infrastructure. Et selon le type de contrat, des COPIL (Comités de Pilotage) sont organisés — chez Ecritel ou chez le client — pour présenter les SLA, les indicateurs de performance, les incidents du mois, les évolutions prévues.

La documentation comme acte de transmission : le DAT rédigé par l'infogéreur n'est pas un document bureaucratique — c'est le premier acte de transmission. Les DevOps du client qui lisent le DAT apprennent comment leur infrastructure fonctionne. Ceux qui participent à sa rédaction apprennent encore plus vite.

Les COPIL comme formation déguisée : quand l'infogéreur présente les SLA mensuels, il explique ce qui s'est passé, pourquoi, comment c'a été résolu. Les équipes techniques du client qui assistent à ces réunions font de la formation continue sans qu'on appelle ça de la formation.

L'astreinte partagée : dans certains contrats, les ingénieurs de l'infogéreur sont disponibles pour les équipes du client lors des incidents — non pas pour les remplacer mais pour les accompagner dans la résolution. Un incident à 3h du matin résolu avec l'ingénieur de l'infogéreur en ligne apprend plus qu'une journée de formation en salle.

Le knowledge transfer formel : dans les contrats bien rédigés, une phase de knowledge transfer est explicitement planifiée — sessions de formation sur l'infrastructure spécifique du client, remise des procédures d'exploitation, accompagnement des premières opérations réalisées en autonomie par les équipes internes.

Vécu chez Ecritel : un client dispose de deux machines — prod et préprod. Il veut pouvoir passer la préprod en prod sans transférer le code, juste en inversant les rôles. Solution proposée : un fichier FTP déposé par le client avec machine1=prod ; machine2=preprod. Un script lit le fichier toutes les X minutes et reconfigure automatiquement le backend HAProxy. Le client reste en infogérance totale mais est complètement autonome sur ses déploiements, sans aucune intervention de l'infogéreur à chaque cycle.

Ce que cela illustre : l'infogéreur a écrit le script. Il a adapté l'infrastructure au besoin métier. L'inverse du cloud : "adaptez votre architecture à nos services."

Ecritel a accompagné des clients pour obtenir le CSP en Chine depuis Paris. Des infrastructures ont été synchronisées entre la Chine et la France via Unison ou lsync pour les images. Des configurations pseudo-L2 à l'international ont été mises en place pour assurer la continuité réseau entre sites distants. Des liens fibre dédiés peuvent raccorder les bureaux du client ou un autre site — ce que le cloud ne peut pas faire physiquement. Et le trafic est inclus dans le contrat ou à des tarifs très raisonnables. Pas d'egress fees découverts en fin de mois.

Vous décrochez le téléphone. Un technicien répond. Il connaît votre infrastructure. Il peut agir immédiatement ou escalader à un ingénieur — inclus dans le contrat standard, pas dans un plan Premium surfacturé. Pour les clients en housing, des gestes de proximité physique sont possibles : un technicien peut intervenir en salle pour câbler, redémarrer, inspecter. Ce n'est pas comparable au support AWS — formulaire, ticket, délai mesuré en jours, plan Premium à plusieurs dizaines de milliers d'euros pour avoir un humain au téléphone.

Managed AWS / Google Managed Services / Azure Managed Services : ils gèrent votre infrastructure cloud pour vous — mais sur AWS, GCP ou Azure. La dépendance à l'hyperscaler est maintenue, parfois renforcée. La juridiction reste californienne. Les egress fees restent. Le lock-in applicatif reste. Ce ne sont pas des infogéreurs souverains — ce sont des sous-traitants de l'hyperscaler.

Infogéreurs souverains (Ecritel, DRI, OVH, Scaleway, Claranet, Infomaniak) : ils gèrent votre infrastructure sur leur propre datacenter ou sur de l'infrastructure neutre, sous droit français ou européen. Leurs contrats sont résiliables. La documentation produite vous appartient. Les données restent en Europe sous juridiction européenne. Et leurs certifications (HDS pour la santé, SecNumCloud pour les OIV, ISO 27001 pour la sécurité générale) couvrent des exigences réglementaires que les hyperscalers peinent à satisfaire complètement.

HDS (Hébergement de Données de Santé) : obligatoire pour héberger des données de santé en France. Les principaux infogéreurs français sont certifiés HDS. AWS et GCP le sont aussi — mais sous des conditions contractuelles qui peuvent entrer en tension avec le RGPD et le CLOUD Act.

SecNumCloud (ANSSI) : le label de souveraineté cloud français. Exige que les sociétés exploitantes soient de droit français, sans possibilité de prise de contrôle extra-européenne. AWS et GCP ne peuvent pas l'obtenir. C'est le label qui fait la différence pour les OIV (Opérateurs d'Importance Vitale) et les administrations publiques sensibles.

ISO 27001 : standard international de management de la sécurité de l'information. La plupart des infogéreurs sérieux sont certifiés. Condition minimale pour les marchés publics et les grands comptes.

Trois questions pour qualifier un infogéreur :
1. Avez-vous une expérience documentée de migrations depuis AWS/GCP/Azure ? (Demandez des références.)
2. Quelle est votre politique de documentation ? (Le DAT et toute la documentation produite appartiennent-ils au client dès la fin de mission ?)
3. Comment organisez-vous le knowledge transfer vers nos équipes internes ? (S'il n'y a pas de réponse précise, c'est un signal d'alerte.)