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é:
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.