Un module Terraform partagé buggé qui détruit 40 environnements

La promesse du platform engineering, c'est la réutilisation : au lieu que chaque squad réécrive son infrastructure, vous publiez un module Terraform ou une chart Helm versionnée, que tout le monde consomme. C'est élégant, c'est efficace — et c'est exactement ce qui transforme une petite erreur en sinistre de grande ampleur.

Le mécanisme est implacable. Vous corrigez ou faites évoluer un module, vous taguez une nouvelle version, vous la publiez. Les pipelines CI/CD des squads consommatrices la récupèrent, parfois automatiquement via une montée de version. Si le module contient un défaut — une condition mal écrite, un count qui retourne zéro, une ressource renommée déclenchant un destroy/create — l'erreur se réplique partout où le module est consommé.

Le préjudice ne dépend plus de votre vigilance ponctuelle : il dépend du nombre d'environnements branchés sur votre module. C'est une mécanique de propagation, pas un incident isolé.

Ce qui distingue ce risque d'un bug applicatif ordinaire, c'est la vitesse et l'automatisme de la diffusion. Un développeur qui introduit un bug dans son service a, en général, une chance de le rattraper avant qu'il n'atteigne la production : revue de code, tests, déploiement progressif. Un module partagé court-circuite ces filets quand les squads consomment automatiquement la dernière version compatible. L'erreur voyage alors à la vitesse du CI/CD, sans qu'aucun humain ne l'ait validée environnement par environnement.

Cette dynamique transforme la nature de votre responsabilité. Vous n'êtes plus seulement l'auteur d'un code : vous êtes le fournisseur d'un composant d'infrastructure sur lequel des dizaines d'équipes ont fondé leur delivery. Le niveau de diligence attendu monte d'un cran, et c'est précisément ce niveau d'exigence qui sera évalué en cas de litige.

Voici un scénario réaliste, anonymisé, qui illustre la dynamique d'un sinistre en cascade.

Un ingénieur plateforme fait évoluer un module Terraform de provisioning de bases de données managées. Une refactorisation renomme la ressource principale. Sans moved block ni stratégie de migration d'état, Terraform interprète le renommage comme une suppression suivie d'une création. Le module monte de version, les pipelines des squads le récupèrent, et au prochain apply, des bases de données d'environnements de pré-production sont détruites puis recréées vides.

En quelques heures, le bug a touché chaque environnement consommant le module. Les équipes découvrent des bases vides, des migrations à rejouer, des données de test perdues. La crise se gère squad par squad, dans l'urgence.

Ce qui rend ce scénario redoutable, c'est qu'aucune étape n'a semblé anormale au moment de la publication. La refactorisation paraissait propre, le code compilait, le module passait les tests existants. Le défaut ne s'est révélé qu'à l'apply, c'est-à-dire au moment où l'état réel de l'infrastructure a été confronté à la nouvelle définition. C'est la signature des sinistres d'infrastructure-as-code : la dangerosité d'un changement ne se mesure pas à sa taille, mais à la façon dont l'outil de provisioning interprète l'écart entre l'état précédent et l'état cible.

Du point de vue assurantiel, on retiendra que le fait générateur — la publication du module défaillant — précède de plusieurs heures, parfois plusieurs jours, la matérialisation du dommage chez les consommateurs. Cette dissociation dans le temps a son importance pour le rattachement du sinistre à la bonne période de garantie.

L'enjeu financier d'un sinistre platform engineering tient dans un mot : multiplication. Le coût unitaire d'un environnement cassé peut sembler modeste ; multiplié par le nombre d'environnements impactés, il devient significatif.

On retrouve ici la signature du métier : un préjudice immatériel diffus, sans dommage matériel apparent, mais dont l'addition pèse lourd. C'est précisément ce profil que vise la garantie faute professionnelle et erreur de conception de la RC Pro.

La question centrale d'un litige sera : la conception du module était-elle défaillante au regard de l'état de l'art ? Plusieurs éléments pèsent dans la balance.

• Absence de garde-fous : un module destructeur sans validation, sans plan revu, sans protection contre la suppression accidentelle, fragilise votre position.
• Versioning et communication : une montée de version majeure non signalée comme breaking change peut être reprochée.
• Partage des responsabilités : les squads qui appliquent sans relire le plan portent aussi une part de responsabilité — la cause peut être partagée.

En pratique, le litige se joue sur la démonstration de votre diligence. La RC Pro intervient sur deux fronts : indemniser le préjudice si votre responsabilité est retenue, et financer votre défense pour faire valoir le partage de responsabilité ou l'obligation de moyens.

Cette dimension défense est sous-estimée. Dans un sinistre platform engineering, l'expertise technique du contentieux est lourde : il faut reconstituer la chaîne de propagation, analyser les états Terraform, établir qui a appliqué quoi et quand. Sans accompagnement, un prestataire seul face à un client mécontent se retrouve à supporter des frais d'expertise et de conseil avant même que la responsabilité ne soit tranchée. La garantie défense et recours prend en charge ce volet et rééquilibre le rapport de force, notamment lorsque la responsabilité est manifestement partagée entre votre module et l'usage qu'en ont fait les squads.

Reste enfin la question du périmètre déclaré. Si votre activité de conception et de maintenance de modules réutilisables n'a pas été clairement indiquée à la souscription, l'assureur peut opposer un défaut de déclaration. D'où l'importance, pour ce métier, d'un libellé d'activité qui couvre explicitement le build et le maintien de composants d'infrastructure partagés.

Réduire ce risque relève autant de l'ingénierie que de l'assurance. Quelques pratiques abaissent drastiquement la probabilité du sinistre :

1. Tests automatisés des modules (Terratest, kitchen-terraform) avant publication.
2. Versioning sémantique strict et changelog explicite des breaking changes.
3. Protections de ressources critiques : prevent_destroy, moved blocks, stratégies de migration d'état.
4. Déploiement progressif du module : un environnement canari avant la généralisation.
5. Revue de plan obligatoire dans les pipelines consommateurs.

Ces garde-fous limitent l'exposition. Pour la part de risque qui subsiste — et elle existe toujours dès qu'un code est partagé à grande échelle — la RC Pro avec garantie faute professionnelle et l'option cyber en cas de fuite associée constituent le filet de sécurité adapté à ce métier d'effet de levier.