{"slug": "jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait", "title": "J’ai mis un Agent Claude dans ma CI pendant 3 mois , voici ce qu’il a vraiment fait", "summary": "A developer integrated a Claude agent into their GitLab CI pipeline for three months to automate Terraform plan fixes, finding it effective but requiring significant guardrails. The agent proposed destroying a production Aurora database, revealing infrastructure debt, and its non-deterministic outputs proved incompatible with CI expectations. The developer implemented strict safeguards, including read-only AWS permissions and automatic rejection of stateful resource changes.", "body_md": "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\n\nL’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.\n\nUn 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.\n\nTrois mois plus tard , la réponse est oui , mais pas du tout dans le périmètre que j’imaginais au départ.\n\n**Le Montage:**\n\nRien 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.\n\nl’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.\nCe qui a bien marché:\n\n**Ce qui a cassé**\n\nIl a proposé de détruire une base de données.\n\nC'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.\n\nL'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.\n\nLa 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.\n\nLe non-déterminisme est incompatible avec la CI.\n\nDeux 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.\n\nJe 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.\n\nLe coût n'est pas là où on croit.\n\nEnviron 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.\n\nLes garde-fous, dans l'ordre où ils sont apparus\n\nAucun n'était prévu au départ. Tous sont nés d'un incident.\n\nAucune 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.\n\nAucun 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.\n\nPé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é.\n\nRefus 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.\n\n**Ce que je ferais différemment**\n\nCommencer 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.\n\nMesurer 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.\n\nRé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à ».\n\n**Ce que ça m'a appris sur les agents en production**\n\nLe 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.\n\nCe 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.\n\nLe gain réel n'est pas la vitesse. C'est de ne plus lire trois cents lignes de log un vendredi soir.", "url": "https://wpnews.pro/news/jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait", "canonical_source": "https://dev.to/yves_michelfoyettchale_/jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait-5518", "published_at": "2026-08-31 12:28:13+00:00", "updated_at": "2026-08-31 12:52:24.456696+00:00", "lang": "en", "topics": ["ai-agents", "mlops", "developer-tools", "ai-safety"], "entities": ["Claude", "Terraform", "GitLab", "AWS", "Aurora"], "alternates": {"html": "https://wpnews.pro/news/jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait", "markdown": "https://wpnews.pro/news/jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait.md", "text": "https://wpnews.pro/news/jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait.txt", "jsonld": "https://wpnews.pro/news/jai-mis-un-agent-claude-dans-ma-ci-pendant-3-mois-voici-ce-quil-a-vraiment-fait.jsonld"}}