Retour d’experience sur l’automatisation de déploiements avec un agent LLM et sur les gardes-fous qu’il a fallu inventer en cours de route
L’idée est venue d’un frustration banale. Sur mon projet terraform , je passais beaucoup de temps à refaire la même chose : lire un plan qui échoue , comprendre pourquoi , corriger des lignes de configurations , toujours trop long.
Un agent LLM sait faire ca , mais la question était se savoir s’il pouvait le faire sans supervision , dans un pipeline , sur une infrastructure qui coûte de l’argent réel.
Trois mois plus tard , la réponse est oui , mais pas du tout dans le périmètre que j’imaginais au départ.
Le Montage:
Rien de complexe, un VPS à 12 euro par mois , la CLI de l’agent installée dessus , et un runner Gitlab qui l’invoque sur un déclencheur précis: quand un terraform plan échoue sur une MR.
l’agent recoit trois choises: la sortie d’erreur , le diff de la MR, et un accès en lecture du dépôt.Il produit une proposition de correctif sous forme de patch, qu’il pousse sur une branche dédiée.
Ce qui a bien marché:
- les erreurs de typage et de reference. Un var.instance_type mal orthographié, un output référencé qui n'existe plus après un refactor, un module dont la signature a changé. L'agent corrige ça avec un taux de réussite que j'estime autour de 85 %. Ce sont des erreurs mécaniques, à contexte local, exactement ce qu'un LLM traite bien.
- Les messages d’erreur opaques. C'est le gain que je n'avais pas anticipé. Certaines erreurs de provider AWS sont d'une inutilité remarquable , un InvalidRequestException sans description, par exemple. L'agent, lui, va lire le corps de la requête dans les logs de debug et repérer le paramètre malformé. Il ne « comprend » pas mieux que moi, mais il lit trois cents lignes de log en deux secondes sans se lasser.
- À 19h un vendredi , ma qualité de diagnostic s’effondre. Celle de l’agent, non.
Ce qui a cassé
Il a proposé de détruire une base de données.
C'est l'incident qui a tout recadré. Un cluster Aurora avait été créé manuellement en urgence quelques semaines plus tôt, sans que le code correspondant soit versionné. Le plan proposait donc logiquement de supprimer une ressource orpheline sauf que la ressource, elle, était bien vivante et servait la production.
L'agent a fait exactement ce qu'on lui demandait : rendre le plan cohérent. Son correctif était techniquement irréprochable. Il aurait détruit la base.
La leçon n'est pas « l'IA est dangereuse ». Elle est plus embarrassante : l'agent a révélé une dette que nous avions, pas créé un problème nouveau. L'écart entre l'infrastructure réelle et le code versionné existait avant lui. Il l'a simplement rendu actionnable, et donc dangereux.
Le non-déterminisme est incompatible avec la CI.
Deux exécutions sur la même erreur ne donnent pas le même patch. Parfois la variation est cosmétique. Parfois l'agent choisit une approche structurellement différente, ajouter un lifecycle plutôt que corriger la ressource, par exemple. Sur un pipeline, où l'on attend qu'un même input produise un même output, c'est déroutant.
Je n'ai pas résolu ce point. Je l'ai contourné en n'autorisant jamais l'agent à modifier l'état du système : il propose, un humain dispose.
Le coût n'est pas là où on croit.
Environ 0,40 euro par invocation, pour à peu près 60 invocations par mois. Vingt-quatre euros : négligeable. Le vrai coût est le temps de relecture des propositions. Un patch plausible mais faux prend plus de temps à évaluer qu'une absence de patch, parce qu'il faut vérifier un raisonnement au lieu d'en construire un.
Les garde-fous, dans l'ordre où ils sont apparus
Aucun n'était prévu au départ. Tous sont nés d'un incident.
Aucune permission d'écriture sur AWS. L'agent a un rôle en lecture seule, point. Il génère du texte, jamais un apply. C'est la règle qui rend toutes les autres moins critiques : le pire qu'il puisse produire est une mauvaise suggestion.
Aucun accès aux secrets. Les logs sont filtrés avant de lui être transmis. Un ARN de rôle ou un identifiant de compte dans un prompt part chez un tiers, et cela mérite une décision consciente plutôt qu'un effet de bord.
Périmètre restreint aux fichiers modifiés par la MR. Sans cette limite, l'agent partait « améliorer » des modules qui n'avaient rien demandé.
Refus systématique sur les ressources à état. Toute proposition touchant une base de données, un bucket avec des données, ou une ressource marquée prevent_destroy est rejetée automatiquement, quelle que soit sa qualité apparente. La règle est bête et elle est absolue , c’est précisément ce qui la rend fiable.
Ce que je ferais différemment
Commencer par le rôle IAM. J'ai construit le montage puis restreint les permissions après l'incident Aurora. L'ordre inverse aurait été plus sage, et m'aurait coûté une nuit blanche de moins.
Mesurer dès le premier jour. Je n'ai aucune donnée fiable sur les six premières semaines. Combien de patches acceptés, combien rejetés, combien de temps réellement gagné ? Je ne peux répondre que par impression, ce qui est une façon élégante de dire que je ne peux pas répondre.
Résister à l'extension du périmètre. À chaque succès, la tentation est de confier un peu plus. C'est ainsi qu'on se retrouve avec un agent qui a des droits d'écriture « juste pour ce cas-là ».
Ce que ça m'a appris sur les agents en production
Le discours ambiant oppose deux facons de pensé : l'agent autonome qui remplace l'ingénieur, et le gadget qui ne sert à rien. Mon expérience ne valide ni l'une ni l'autre.
Ce qui fonctionne, c'est un agent avec un périmètre étroit, sans droits d'écriture, sur des tâches à contexte local, avec une validation humaine systématique. Ça ressemble beaucoup moins à de la magie qu'aux démos qu'on voit passer. C'est aussi la seule configuration dans laquelle je le laisserais tourner sur une infrastructure qui compte.
Le gain réel n'est pas la vitesse. C'est de ne plus lire trois cents lignes de log un vendredi soir.
Top comments (1)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
The Aurora incident captures the real engineering boundary for LLM agents in infrastructure: capability is not authorization. I would formalize your approach as a policy enforcement layer between the agent and CI, rather than relying primarily on prompt constraints.
Generate the Terraform plan as a machine readable artifact, parse resource actions, and classify every proposed change against an explicit policy engine. Any create, update, or destroy affecting stateful resources should require a deterministic approval gate. Add blast radius analysis using dependency graphs, drift detection, and invariant checks before allowing a patch to proceed.
For non deterministic output, treat the agent as a probabilistic patch generator while keeping validation deterministic. Run fmt, validate, plan, policy checks, security scanning, and regression tests on every generated patch. Store prompts, patches, plans, decisions, and outcomes as immutable audit events.
The strongest architecture is therefore agent proposes, policy evaluates, CI verifies, human authorizes. That preserves the productivity gain without allowing probabilistic reasoning to become infrastructure authority. I would enjoy exchanging ideas on agentic DevOps safety patterns.