Infrastructure as code : le seul test qui prouve qu'elle existe vraiment

Le test est simple : pouvez-vous détruire un environnement complet et le reconstruire à l'identique à partir de votre dépôt, sans intervention manuelle ?

Tant que la réponse est non, vous avez des fichiers Terraform, pas une infrastructure décrite en code. La différence n'est pas sémantique : elle détermine ce qui se passe le jour où vous en avez besoin.

Les trois raisons habituelles de l'échec

La dérive de configuration. Quelqu'un a modifié une ressource dans la console pour régler un incident, sans reporter le changement dans le code. Six mois plus tard, personne ne sait quelles différences existent entre le code et la réalité.

Le correctif est organisationnel avant d'être technique : les accès en écriture à la console sont retirés en production, et une détection de dérive tourne chaque nuit avec une alerte quand un écart apparaît.

Les ressources créées à la main et jamais reprises. Un bucket créé pour un besoin ponctuel, une règle de pare-feu ajoutée dans l'urgence, un enregistrement DNS posé par quelqu'un qui a quitté l'entreprise. Elles n'existent nulle part dans le code et l'environnement reconstruit ne fonctionne pas sans elles.

Les données et les secrets. Un environnement reconstruit vide n'est pas un environnement fonctionnel. La procédure de reconstruction doit inclure le rechargement d'un jeu de données et la récupération des secrets depuis un coffre — et cette partie est presque toujours absente des runbooks.

Ce que le test révèle vraiment

Il ne mesure pas la qualité de votre code Terraform. Il mesure votre capacité à répondre à quatre situations qui finissent toujours par arriver :

• La reconstruction après un incident majeur ou une compromission.
• La création d'un environnement de test réaliste, sans bricolage.
• Le changement de région ou de fournisseur, pour une raison réglementaire ou commerciale.
• L'audit : prouver que la production correspond à ce qui a été validé.

Comment y arriver progressivement

Vous n'avez pas besoin de tout reprendre. La progression qui fonctionne :

1. Mettre l'existant sous état géré, même imparfaitement, en important les ressources créées à la main.
2. Fermer l'écriture manuelle en production, avec une procédure d'exception documentée pour les urgences — et l'obligation de reporter dans le code sous quarante-huit heures.
3. Activer la détection de dérive quotidienne, avec une alerte nominative.
4. Tester la reconstruction sur l'environnement de recette, une fois par trimestre, chronomètre en main.

Cette dernière étape est la seule qui compte vraiment. Une reconstruction jamais testée est une hypothèse, pas une capacité.

Le chiffre à connaître

Combien de temps prend la reconstruction complète de votre environnement le plus critique ? Si vous ne connaissez pas ce chiffre, vous ne connaissez pas votre délai réel de reprise après un incident majeur, quel que soit ce qui figure dans votre plan de continuité.