Refactoriser l'infrastructure en toute sécurité avec Terraform et un agent de code

Introduction

J’ai récemment traversé une série de refactorings d’infrastructure sur des systèmes en production — de Cloud Run vers des machines virtuelles, puis vers un cluster Kubernetes managé, et finalement vers GKE Autopilot. Chaque étape portait le risque de perte de données, de bris de service ou de snapshots manqués.

Ce qui a rendu tout ça gérable, c’est un partenariat avec un agent de code, en utilisant terraform plan comme langage commun.

Le problème : l’agent n’a pas le state

Le truc avec les agents de code et Terraform : l’agent n’a pas votre state Terraform dans son contexte. Il ne sait pas ce qui tourne en production. Quand vous lui demandez de réécrire votre infrastructure, il va joyeusement produire du Terraform propre et idiomatique qui, si appliqué, détruirait votre base de données de production pour la recréer vide.

Ce n’est pas un bug — c’est la nature de l’outil. L’agent optimise pour le code qu’il voit, pas pour l’état qu’il ne voit pas. C’est pour ça qu’il faut une méthode.

La méthode : planifier, analyser, décomposer

Le workflow qui a émergé naturellement est une boucle :

1. Écrire l’infrastructure idéale. Demander à l’agent de réécrire le Terraform pour correspondre à l’architecture cible. Ne pas se soucier de la migration pour l’instant — juste décrire où on veut arriver.

2. Lancer terraform plan. C’est là que la réalité frappe. Le plan révèle chaque breaking change — chaque ressource qui sera détruite, chaque volume qui sera effacé, chaque service qui tombera.

# google_container_cluster.primary will be destroyed
- resource "google_container_cluster" "primary" {
    - name     = "my-cluster"
    - location = "us-central1"
    ...
  }

# google_container_cluster.primary will be created
+ resource "google_container_cluster" "primary" {
    + name     = "my-cluster"
    + location = "northamerica-northeast1"
    ...
  }

3. Analyser les impacts avec l’agent. Donner la sortie du plan à l’agent. Il excelle à scanner des centaines de lignes et remonter les risques : « Ceci va détruire un disque persistant », « Cette base de données va être recréée », « Cette politique de snapshots va être supprimée avant que la nouvelle soit en place. » Sur un gros refactoring, un humain va survoler et manquer des choses. L’agent lit chaque ligne.

4. Replanifier la stratégie de migration. En se basant sur l’analyse d’impact, décomposer le refactoring en étapes incrémentales et sécuritaires. Chaque étape adresse un breaking change sans causer de perte de données. L’agent aide à réécrire le Terraform pour introduire des blocs moved, des règles de cycle de vie, des états intermédiaires ou des étapes de migration de données selon les besoins.

5. Répéter jusqu’à ce que le plan ne montre que les changements prévus.

L’exécution : un commit par étape

Une fois la stratégie de migration solide, chaque étape incrémentale devient son propre commit dans une branche de release. On les applique un par un :

1. Commit A : Ajouter les politiques de snapshots et prendre les backups
2. Commit B : Créer le nouveau cluster à côté de l’ancien
3. Commit C : Migrer les volumes persistants avec des blocs moved
4. Commit D : Basculer le trafic vers le nouveau cluster
5. Commit E : Décommissionner les anciennes ressources

Chaque commit a sa propre révision de terraform plan, son propre terraform apply, et sa propre validation. Si quelque chose plante au commit C, on n’a pas touché au système en cours au-delà de ce que les commits A et B ont changé de façon sécuritaire.

C’est le méta-plan : une séquence de petits terraform apply sécuritaires qui, ensemble, accomplissent la migration complète sans jamais mettre les données de production à risque.

Mon parcours de migration

Cloud Run vers machines virtuelles

L’agent a réécrit l’infra pour les VMs. Le plan montrait qu’il allait détruire les services Cloud Run et leur stockage associé. On a décomposé : d’abord provisionner les VMs et migrer les données, puis décommissionner Cloud Run.

Machines virtuelles vers Kubernetes managé

Bond plus important — les définitions de machines individuelles sont devenues des node pools et des persistent volume claims. La sortie du plan était dense : des dizaines de créations, des dizaines de destructions. L’agent a signalé un volume persistant qui serait détruit au lieu d’être migré et un schedule de snapshots supprimé trop tôt. Chaque alerte est devenue un commit séparé dans la séquence de migration.

Changement de modèle de gestion Kubernetes

Même orchestrateur, modèle différent. La vraie valeur ici était de détecter les drifts — des changements de comportement subtils qui n’apparaîtraient pas comme des erreurs dans le plan mais pourraient causer des interruptions de service au runtime.

Pourquoi ça fonctionne

• L’agent compense son propre angle mort. Il ne voit pas le state, mais il peut analyser la sortie du plan qui reflète le state. terraform plan comble le fossé.
• Lecture exhaustive. Sur un refactoring qui touche des centaines de ressources, l’agent lit chaque ligne. Les humains survolent.
• Itération sécuritaire. terraform plan ne change rien. On peut le lancer cent fois pendant que l’agent ajuste le code.
• Exécution incrémentale. Des commits séparés dans une branche de release signifient que chaque étape est révisable, réversible et validée indépendamment.

Conclusion

Les agents de code sont imprudents avec Terraform par défaut — ils ne voient pas le state, donc ils ne craignent pas de détruire des ressources de production. Mais jumelés avec terraform plan et un workflow discipliné de planifier-analyser-décomposer, ils deviennent des partenaires puissants pour l’ingénieur DevOps qui, lui, voit le state et craint les pertes de données.

La méthode est simple : écrire l’infra idéale, laisser le plan révéler les conséquences, décomposer la migration en commits sécuritaires, et les appliquer un par un. L’agent s’occupe de l’analyse exhaustive et de l’itération du code. Vous vous occupez des décisions de jugement. Ensemble, vous livrez des changements d’infrastructure qui auraient autrement été trop risqués à tenter.