Une zone d’atterrissage que vous ne pouvez pas appliquer vous-même n’est que le dépôt de quelqu’un d’autre
Une zone d’atterrissage n’est réelle que si votre équipe peut l’exploiter sans les gens qui l’ont bâtie. L’épreuve est concrète : un ingénieur qui n’a pas participé à l’engagement original peut-il cloner le dépôt et provisionner un nouveau compte, en héritant de chaque garde-fou, rôle et paramètre de journalisation par défaut, sans appeler le consultant ? Si la réponse est non, vous n’avez pas acheté une fondation ; vous avez loué une dépendance.
La plupart des engagements de zone d’atterrissage sont vendus et évalués sur la force d’un diagramme : la structure de l’organisation, les OU, la topologie réseau, la centralisation de la journalisation. Le diagramme, c’est la partie facile. La partie qui détermine si vous en avez eu pour votre argent est invisible sur toute diapositive : votre équipe peut-elle l’exploiter ?
Le seul test d’acceptation qui compte
Oubliez la revue d’architecture un instant et faites plutôt ce test. Choisissez un ingénieur qui n’a pas participé à la construction. Remettez-lui le dépôt. Demandez-lui de provisionner le compte no 51 — un tout nouveau compte qui démarre à l’intérieur de chaque garde-fou, avec les rôles de base, les SCP, la journalisation et l’échafaudage réseau, tous appliqués automatiquement.
S’il peut le faire à partir du dépôt et d’un README en un après-midi, vous possédez une zone d’atterrissage. S’il doit faire de la rétro-ingénierie sur du click-ops, ou ouvrir un billet auprès de celui qui l’a bâtie, vous possédez un diagramme et une dépendance.
Pourquoi tant de « zones d’atterrissage » échouent à ce test
- Dérive de console. Le diagramme dit une chose ; la moitié a été cliquée à la main durant la livraison et n’est jamais revenue dans le code. Le dépôt ne peut pas reproduire l’environnement parce que l’environnement n’a jamais été entièrement dans le dépôt.
- Plateformes sur mesure. Un consultant bâtit une abstraction personnalisée astucieuse que lui seul comprend. Ça fait une belle démo et c’est immaintenable dès qu’il part. Une fondation devrait être ennuyeuse : du Terraform/OpenTofu standard, votre CI, des contrôles natifs de l’infonuagique.
- Aucun patron de provisionnement de comptes. Les premiers comptes ont été bâtis amoureusement à la main. Il n’y a aucun chemin de « provisionnement » reproductible, alors le compte no 51 demande autant de travail que le compte no 2 — ce qui est exactement le problème que vous aviez confié en sous-traitance.
Ce que « vous le possédez » doit signifier en pratique
La propriété n’est pas une clause de licence ; c’est un fait opérationnel. Concrètement :
- La structure de l’organisation et des comptes est du Terraform dans votre contrôle de version, dans vos comptes.
- Il y a un module de provisionnement de comptes que votre équipe exécute pour créer des comptes qui héritent de la base par défaut.
- Les garde-fous (SCP / politiques d’organisation) sont du code que vous pouvez lire, modifier et soumettre en PR.
- Le transfert n’est pas une présentation — c’est votre équipe qui provisionne un vrai compte, modifie un garde-fou et exécute une procédure de secours (break-glass), pendant que nous observons, puis que nous partons.
Ce dernier point est tout l’enjeu. La phase de transfert existe pour prouver que la dépendance a disparu. Si un engagement de zone d’atterrissage ne se termine pas avec vos propres ingénieurs qui l’exploitent sans aide, il ne s’est pas terminé — il a simplement été mis en pause jusqu’à la prochaine facture.
C’est pourquoi chaque engagement de zone d’atterrissage que nous menons se termine par ce transfert en direct où vous l’exploitez vous-même. Le livrable, c’est l’indépendance de votre équipe, pas notre diagramme.