Le « Terraform destroy en prod » déclenché par un agent IA, ce n’est pas une histoire drôle. C’est un accès prod mal cadré, point. L’incident récent raconté publiquement (infra AWS + base + snapshots supprimés dans la foulée) est brutal, mais il a un mérite : il rappelle que l’agent n’est pas “un assistant”. C’est un opérateur. Et Terraform est un outil qui ne négocie pas.
Ce que je décris ici, c’est un playbook qui tient en prod. Pas une morale, pas une « checklist pour se rassurer ». L’idée est simple : si un agent peut toucher Terraform, tu dois rendre la destruction difficile, visible et réversible (au sens opérationnel, pas au sens « on a des snapshots quelque part »).
Traite l’agent comme un accès prod, pas comme un outil de dev
Le piège, c’est le glissement progressif. Tu commences par lui demander « regarde le plan », puis « lance apply », puis « fais une migration ». Et un jour tu réalises qu’il a un contexte flou, des permissions trop larges, et qu’il exécute des commandes dans un terminal qui a ton AWS_PROFILE.
Une règle que j’aime bien, parce qu’elle est nette : un agent ne reçoit jamais des droits d’écriture au début. Il commence en lecture seule, il observe, il propose. Quand tu veux passer à l’exécution, ce n’est pas « ok vas-y ». C’est un changement de posture, donc un changement d’identité, de pipeline et de contrôles.
Concrètement, ça veut dire que tu sépares des identités et des périmètres. Une identité « plan » qui peut lire l’état, interroger les APIs cloud, mais ne peut pas modifier. Et une identité « apply » beaucoup plus rare, plus surveillée, utilisée uniquement dans un workflow durci. Si ton agent tourne sur ta machine avec tes creds, tu as déjà perdu. Ce n’est pas un sujet d’IA, c’est un sujet d’opérations.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Impose un workflow plan → review → apply (et arrête le “terraform apply au feeling”)
Terraform donne l’illusion que tout est déterministe. En vrai, il y a des variables, des datasources, des providers qui bougent, des états distants, des dépendances. Si tu laisses un agent faire « plan puis apply » dans la même respiration, tu acceptes qu’il prenne une décision infra à ta place.
Le workflow qui tient, c’est celui où le plan est un artefact. Le plan est produit, stocké, reviewé, puis appliqué tel quel. Pas « re-plan juste avant apply parce que c’est plus simple ». Tu veux un lien immuable entre ce qui a été approuvé et ce qui est exécuté. Sinon, tu fais du théâtre de contrôle.
Et si tu te dis « c’est lourd », rappelle-toi le coût d’une suppression. L’objectif n’est pas d’aller vite quand tout va bien. L’objectif est d’éviter la catastrophe quand ça va mal ou quand l’agent s’emballe.
Garde-fous Terraform : verrouillage d’état, séparation des environnements, destruction coûteuse
Terraform a des protections, mais elles ne servent à rien si tu ne les prends pas au sérieux. Le verrouillage d’état (remote backend + locking) n’empêche pas un destroy, mais il évite déjà des actions concurrentes qui partent dans tous les sens. La séparation prod/staging (workspaces ou, mieux, states et comptes distincts) évite surtout les erreurs de contexte, les « je pensais être en staging ». Et ça, les agents adorent ce genre d’erreurs, parce qu’ils n’ont pas ta parano.
Ensuite, il y a le garde-fou le plus sous-utilisé car il est “pénible” quand on prototyppe : prevent_destroy. Ce n’est pas une solution globale, c’est une ceinture de sécurité sur les ressources critiques. Tu l’actives sur ce qui ne doit pas disparaître par accident, et tu assumes qu’il faudra un changement explicite pour casser la protection.
resource "aws_db_instance" "prod" {
identifier = "app-prod"
# ... config ...
lifecycle {
prevent_destroy = true
}
}
Ce bloc ne remplace pas la gouvernance, mais il transforme un « oups » en « stop net ». Et c’est exactement ce que tu veux quand l’exécutant est un agent qui enchaîne des commandes parce qu’il a “compris” que la migration serait plus propre en repartant de zéro.
Dernier point, très concret : rends la destruction inconfortable. Des confirmations humaines dans le pipeline (pas dans le terminal), des environnements séparés, et une règle de base : aucun apply sur prod depuis un poste local. Zéro exception. Les exceptions deviennent toujours la norme, surtout sous stress.
Policy-as-code : interdire le destructif hors contexte (OPA/Sentinel), sinon tu joues à pile ou face
Quand tu introduis un agent, tu introduis de la vitesse et de l’imprévisibilité. La réponse n’est pas « fais attention ». La réponse, c’est de mettre des barrières automatiques qui ne discutent pas. C’est là que la policy-as-code est utile : elle bloque des classes d’actions, même si l’agent (ou l’humain) “pense” que c’est nécessaire.
Tu peux faire ça avec Sentinel (Terraform Cloud/Enterprise), ou avec OPA selon ton setup. L’idée n’est pas de valider “le code”, mais d’évaluer le plan et d’empêcher certains changements sur certains scopes. Par exemple : interdire les deletes en prod, sauf si un flag « break-glass » est présent et tracé. Ou interdire la suppression d’une base de données, point.
package terraform.guardrails
# Exemple volontairement simple : bloquer toute suppression en prod
# sauf si un input.break_glass explicite est fourni.
deny[msg] {
input.environment == "prod"
not input.break_glass
some r
r := input.resource_changes[_]
r.change.actions[_] == "delete"
msg := "Suppression interdite en prod (break-glass requis)"
}
Ce n’est pas du fétichisme de conformité. C’est une assurance. Le jour où ton agent produit un plan qui supprime 40 ressources parce qu’il a “optimisé” une migration, tu veux que la plateforme dise non, automatiquement, et qu’il n’existe pas de contournement silencieux.
Backups : un snapshot n’est pas une restauration, tant que tu ne l’as pas prouvé
Dans l’incident qui a circulé, le détail qui fait mal, c’est « base supprimée + snapshots supprimés ». Et ça, c’est un rappel violent : si l’identité qui peut détruire la base peut aussi détruire les backups, alors tes backups ne sont pas une protection. Ce sont une illusion.
Un système de sauvegarde sérieux, ce n’est pas « on a activé les snapshots ». C’est une stratégie de rétention, idéalement multi-comptes ou au moins avec des permissions distinctes, et surtout une preuve régulière que tu sais restaurer. La seule question qui compte quand ça brûle : « en combien de temps je remets un service fonctionnel, avec quelles pertes de données, et quel chemin de restauration est validé ? »
Je suis assez sec là-dessus : une restauration non testée n’existe pas. Elle existe dans un ticket JIRA, dans un doc, dans une croyance. Mais pas dans la réalité d’un dimanche soir.
Break-glass : l’exception doit être explicite, rare, et bruyante
Il y aura des cas où tu dois casser des choses. Une ressource irrécupérable, une migration majeure, une facture qui part en vrille. Le but n’est pas d’interdire la destruction. Le but est de l’encadrer.
Le mode break-glass, c’est une mécanique d’équipe, pas un bouton magique. Tu définis une procédure qui oblige à déclarer l’intention (un champ, un label, un paramètre), à obtenir une validation humaine, et à laisser une trace. Ensuite tu donnes temporairement les droits nécessaires, idéalement avec une durée courte et des journaux d’audit activés partout. L’agent peut participer, mais il ne décide pas que « break-glass est nécessaire ». Il peut au mieux le proposer, et il doit justifier, avec un plan et un impact.
Si tu ne rends pas l’exception bruyante, tu vas la voir apparaître partout. Et quand tout est break-glass, plus rien n’est protégé.
Journal d’audit et preuves : si tu ne peux pas reconstituer, tu n’apprends rien
Après un incident, tu as besoin de faits. Qui a lancé quoi, avec quelle identité, sur quel workspace, depuis quel runner, avec quel plan. Ça a l’air évident, mais dans beaucoup d’équipes, Terraform tourne encore “un peu partout”, et l’historique est un mélange de logs locaux, de discussions Slack et de commits incomplets.
Avec des agents, tu dois être encore plus strict. Parce que l’agent n’a pas de mémoire organisationnelle. Il va tenter, retenter, reformuler, et parfois faire des allers-retours destructeurs. Sans audit exploitable, tu ne corriges pas le système, tu cherches un coupable. Mauvais jeu.
Le “contrat” d’équipe pour un agent qui touche à l’IaC
Je termine par ce que je mets noir sur blanc quand une équipe veut brancher un agent sur de l’infra. Pas sous forme de poster, mais comme règles d’exploitation. L’agent peut lire, expliquer, produire des diffs, ouvrir des PR et proposer un plan. Il ne peut pas appliquer sur prod sans un pipeline qui impose review, artefact de plan, policy-as-code et identité dédiée. Et il ne peut jamais, jamais, obtenir des permissions qui lui permettent de supprimer à la fois les ressources et les sauvegardes.
Ce cadre n’empêche pas l’automatisation. Il la rend viable. Le jour où tu es fatigué, pressé, ou en incident, tu seras content que le système soit conçu pour te contredire.
