Agentic coding en prod : vrai levier ou chaos ?

Les agents de code occupent une place de plus en plus visible dans les équipes produit et développement. Après l’autocomplétion, puis les assistants conversationnels capables d’expliquer du code ou de générer une fonction, la promesse a changé d’échelle : il ne s’agit plus seulement d’aider un développeur à écrire plus vite, mais de déléguer des suites d’actions entières à un système capable de lire un dépôt, proposer des modifications, lancer des commandes, écrire des tests et parfois ouvrir une pull request.

Sur le papier, le gain paraît évident. Sur un vrai projet web, la question est moins simple. Entre la démo impressionnante et la production, il y a la qualité du code, la sécurité, la cohérence d’architecture, la revue, la traçabilité et, surtout, le coût caché des erreurs silencieuses. Comme souvent avec les outils IA, le sujet n’est pas de savoir si “ça marche”, mais dans quelles limites cela crée un vrai levier sans dégrader la base de code.

Pour une équipe qui construit un produit web, l’agentic coding n’est ni une révolution magique ni un gadget à balayer d’un revers de main. C’est un outil potentiellement utile, à condition de le cadrer avec le même sérieux qu’un nouveau framework, un nouveau pipeline CI ou une nouvelle couche d’abstraction.

Pourquoi les agents de code montent si vite

La montée des agents de code s’explique d’abord par une continuité technique. Des outils comme GitHub Copilot, ChatGPT, Claude ou encore des environnements comme Cursor ont habitué les équipes à interagir avec du code en langage naturel. L’étape suivante est logique : au lieu de demander “écris-moi cette fonction”, on demande “corrige ce bug”, “mets à jour cette route”, “ajoute les tests”, “prépare une migration” ou “analyse ce dépôt et propose un plan”.

Cette évolution est aussi portée par plusieurs facteurs très concrets :

• La pression sur la vélocité : les équipes doivent livrer plus vite sans forcément recruter davantage.
• La maturité des workflows outillés : Git, CI/CD, tests automatisés, linters et environnements reproductibles rendent certaines tâches plus “pilotables” par un agent.
• La fragmentation des projets modernes : front, back, infra légère, analytics, CMS, design system. Beaucoup de petites tâches répétitives apparaissent aux interfaces.
• Le marketing très agressif des éditeurs : la démonstration d’un agent capable de modifier dix fichiers en une minute impressionne plus qu’un bon outil de refactoring.

Il faut aussi reconnaître une vérité simple : sur certaines tâches, les gains sont réels. Un agent peut parcourir rapidement un dépôt, repérer des patterns, proposer des modifications cohérentes à petite échelle et accélérer des travaux qui relevaient jusque-là d’une exécution manuelle fastidieuse.

Mais cette montée rapide crée aussi une confusion fréquente : on mélange souvent capacité de génération et capacité de décision. Un agent peut enchaîner des actions. Cela ne veut pas dire qu’il comprend le contexte produit, les contraintes métier, les arbitrages d’architecture ou les compromis de performance qui ont façonné le projet.

Ce qu’on appelle vraiment “agentic coding”

Le terme est parfois utilisé à tort pour désigner n’importe quel assistant IA. Dans la pratique, on parle d’agentic coding lorsqu’un système ne se limite pas à répondre à un prompt, mais exécute une séquence orientée objectif. Cela peut inclure :

• l’exploration d’un dépôt ;
• la lecture de fichiers liés à une fonctionnalité ;
• la proposition d’un plan d’action ;
• la modification de plusieurs fichiers ;
• l’exécution de tests ou de commandes shell ;
• la correction d’erreurs détectées en cours de route ;
• la préparation d’un diff ou d’une pull request.

Autrement dit, on ne parle plus seulement d’un copilote qui suggère une ligne. On parle d’un système qui agit dans un périmètre donné. C’est précisément ce passage à l’action qui crée à la fois l’intérêt et le risque.

Sur un projet web, cette logique s’intègre assez naturellement à des outils déjà connus : dépôt Git, scripts npm ou pnpm, tests avec Vitest ou Jest, lint avec ESLint, tests end-to-end avec Playwright ou Cypress, CI sur GitHub Actions ou GitLab CI/CD.

Plus votre chaîne de qualité est explicite, plus un agent peut être utile. Plus votre projet repose sur des conventions implicites, des décisions historiques mal documentées et des zones grises, plus l’agent risque de produire un code “plausible” mais faux.

Ce qu’un agent peut vraiment automatiser sur un projet web

Le bon réflexe consiste à évaluer les tâches, pas la promesse globale. Un agent est souvent pertinent quand le travail est localisé, répétitif, vérifiable et réversible.

Les refactors mécaniques à faible ambiguïté

Exemples typiques :

• renommer une API interne ou un composant utilisé dans plusieurs fichiers ;
• uniformiser un pattern de gestion d’erreur ;
• migrer une partie du code vers une convention déjà définie ;
• ajouter un typage manquant dans une zone bien délimitée en TypeScript.

Sur ce terrain, un agent peut faire gagner du temps, surtout si le dépôt est propre et si les tests couvrent correctement la zone touchée. Le gain vient moins de “l’intelligence” que de la vitesse d’exécution sur une tâche structurée.

La génération de tests de premier niveau

Pour produire des tests unitaires simples, des cas de base ou des scénarios end-to-end à partir d’un comportement déjà documenté, l’agent peut être utile. Il peut aussi aider à identifier des trous de couverture. En revanche, il ne faut pas confondre présence de tests et qualité des tests. Des tests générés peuvent valider l’implémentation actuelle sans vraiment protéger le comportement métier attendu.

Un cas utile, par exemple, consiste à demander la génération de tests autour d’un bug déjà reproduit. Si l’équipe fournit le contexte, le résultat attendu et les fichiers concernés, l’agent peut accélérer la création d’un garde-fou avant correction.

La maintenance de faible niveau

Certaines tâches de maintenance se prêtent bien à l’automatisation assistée :

• mise à jour ciblée de dépendances avec vérification du changelog ;
• adaptation de snippets de configuration ;
• suppression de code mort identifié ;
• normalisation de commentaires ou de documentation technique interne.

Attention toutefois : la mise à jour de dépendances n’est jamais purement mécanique. Un agent peut préparer le terrain, mais la validation doit rester humaine, notamment pour les changements de comportement, les impacts de build et les implications de sécurité.

Le prototypage interne

Pour explorer une idée, monter rapidement une preuve de concept ou tester une intégration secondaire, l’agent peut être un très bon accélérateur. C’est souvent là que le ratio gain/risque est le meilleur. Le problème commence quand un prototype généré vite glisse en production sans remise à niveau.

Un agent est généralement plus fiable pour accélérer l’exécution d’un plan clair que pour définir lui-même le bon plan.

Là où les gains sont souvent surestimés

Le discours commercial laisse parfois penser qu’un agent pourrait prendre en charge une user story entière de manière robuste. Dans la réalité, plus une tâche implique des arbitrages, des dépendances implicites ou des conséquences transverses, plus le risque augmente.

La compréhension métier

Un agent peut lire des fichiers, des commentaires ou des tickets. Cela ne remplace pas la compréhension des exceptions métier, des compromis historiques ou des détails contractuels entre équipes. Dans un back-office e-commerce, par exemple, une règle de calcul de remise ou de TVA ne se déduit pas proprement du code seul si la logique a évolué par couches successives.

Les changements d’architecture

Refondre un flux d’authentification, revoir une stratégie de cache, restructurer un design system, découpler un monolithe applicatif ou repenser la gestion d’état d’un front ne sont pas des tâches à déléguer à un agent sans pilotage serré. L’outil peut aider à explorer, documenter ou exécuter des sous-parties, mais il ne doit pas devenir le décideur technique.

La résolution de bugs flous

“Corrige le bug” est une consigne séduisante, mais dangereuse. Quand un bug est intermittent, lié à la concurrence, au timing réseau, à une condition de production rare ou à un effet de bord entre services, un agent peut facilement “faire disparaître le symptôme” sans traiter la cause. Dans certains cas, il ajoute même une couche de complexité qui rend le problème plus difficile à diagnostiquer ensuite.

Les risques concrets en production

Le vrai sujet n’est pas seulement la qualité brute du code généré. C’est l’ensemble des risques introduits dans le cycle de delivery.

Qualité : du code plausible mais fragile

Le principal danger est le code qui semble correct à la lecture rapide, passe parfois les tests existants, mais introduit une dette subtile. Cela peut prendre plusieurs formes :

• duplication de logique au lieu de réutiliser l’abstraction existante ;
• contournement d’une convention du projet ;
• gestion incomplète des cas limites ;
• tests trop couplés à l’implémentation ;
• ajout de complexité pour résoudre un problème simple.

Sur une base de code mature, ce type de dérive coûte cher, car il dégrade la cohérence globale. Une équipe peut gagner une heure aujourd’hui et perdre plusieurs jours dans six mois en maintenance, revue ou débogage.

Sécurité : surface d’attaque élargie

Dès qu’un agent interagit avec du code de production, des secrets, des dépendances ou des commandes shell, la question sécurité devient centrale. Quelques points d’attention reviennent souvent :

• exposition de données sensibles dans les prompts, logs ou contextes envoyés à un service tiers ;
• suggestions de code vulnérable, par exemple sur la validation d’entrée, l’échappement, l’authentification ou la gestion des permissions ;
• usage non maîtrisé d’outils externes ou de dépendances non validées ;
• exécution de commandes avec un périmètre trop large.

Les recommandations de base restent valables : moindre privilège, séparation des environnements, secrets hors du contexte accessible, revue humaine obligatoire et scans de sécurité dans la CI. Des outils comme GitHub Code Scanning, Semgrep ou Snyk restent utiles, avec ou sans agent.

Revue : surcharge cognitive déplacée

Un argument fréquent en faveur des agents est qu’ils “font gagner du temps”. C’est vrai seulement si le temps économisé à l’écriture n’est pas reperdu en revue. Or une pull request volumineuse, générée vite, mais difficile à relire, peut devenir un piège. Le reviewer ne sait plus toujours si le changement reflète une intention claire ou une exploration opportuniste de l’outil.

Le risque est double :

• soit l’équipe relit superficiellement parce que “l’IA a déjà fait le gros du travail” ;
• soit la revue devient plus lente qu’avant, car il faut reconstituer la logique réelle du changement.

Dans les deux cas, la qualité de décision baisse.

Traçabilité : qui a décidé quoi ?

Sur un projet sérieux, il ne suffit pas de savoir qu’un diff a été mergé. Il faut comprendre pourquoi il a été fait, dans quel cadre, avec quelles hypothèses et quels contrôles. Si un agent modifie plusieurs couches à la fois sans documentation claire, la traçabilité se dégrade.

Ce point est particulièrement sensible pour les équipes qui travaillent dans des contextes réglementés, ou simplement pour celles qui doivent maintenir un produit sur plusieurs années. Une base de code n’est pas qu’un ensemble de fichiers : c’est aussi une mémoire de décisions.

Le vrai critère : est-ce que l’agent réduit le coût total ?

Pour juger un usage d’agentic coding, la bonne métrique n’est pas “est-ce qu’il a écrit du code vite ?”. La bonne question est plutôt : est-ce que le coût total de livraison et de maintenance diminue réellement ?

Ce coût total inclut :

• le temps de formulation de la demande ;
• le temps de génération et d’itération ;
• le temps de revue ;
• le temps de correction des erreurs introduites ;
• l’impact sur la maintenabilité ;
• le risque sécurité ou conformité ;
• la charge mentale imposée à l’équipe.

Si un agent permet de traiter rapidement une série de tâches répétitives avec des diffs petits, testables et faciles à relire, le bilan peut être excellent. Si, au contraire, il produit des modifications larges, peu explicables et coûteuses à valider, le gain affiché est souvent un mirage.

Autrement dit, la vitesse locale n’a de valeur que si elle n’augmente pas le désordre global.

Un cadre simple pour tester sans abîmer la base de code

Le meilleur moyen d’évaluer l’agentic coding n’est pas d’ouvrir les vannes partout. C’est de définir un cadre expérimental strict, avec des règles simples et mesurables.

1. Choisir un périmètre à faible risque

Commencez par des tâches non critiques : outillage interne, scripts, documentation technique, tests, refactors localisés, maintenance de composants périphériques. Évitez d’emblée l’authentification, le paiement, les permissions, les migrations de données sensibles ou les zones historiquement fragiles.

2. Imposer des tâches atomiques

Un agent doit travailler sur des objectifs étroits : un bug bien reproduit, une convention à appliquer, une suite de tests à compléter, une migration limitée. Les demandes vagues du type “améliore l’architecture” ou “optimise l’application” sont de très mauvais candidats.

3. Encadrer les droits d’action

Le principe du moindre privilège est essentiel. Selon l’outil utilisé, limitez ce qu’il peut lire, modifier ou exécuter. L’idéal est de commencer dans un environnement de développement isolé, sans accès aux secrets de production, avec une capacité d’écriture bornée au dépôt ou à une branche de travail dédiée.

4. Rendre la validation automatique incontournable

Un agent ne devrait jamais contourner la chaîne de qualité existante. Au minimum :

• lint obligatoire ;
• tests unitaires pertinents ;
• build reproductible ;
• si possible tests end-to-end sur les parcours touchés ;
• scans de sécurité si le projet en dispose.

Si votre projet n’a pas ces garde-fous, le problème n’est pas l’agent : c’est l’absence de socle qualité.

5. Forcer des diffs petits et lisibles

Une règle pratique fonctionne bien : refuser les modifications trop volumineuses ou trop transverses. Plus le diff est petit, plus la revue est sérieuse, plus l’apprentissage est rapide. L’équipe peut alors identifier les cas où l’agent aide vraiment, et ceux où il complique tout.

6. Mesurer avant de généraliser

Ne vous contentez pas d’un ressenti. Mesurez sur quelques semaines :

• temps moyen de réalisation d’une tâche comparable ;
• temps de revue ;
• taux de retours après revue ;
• bugs détectés après merge ;
• niveau de retouche humaine nécessaire.

Sans cette mesure, on surestime facilement l’effet “wow” des premières démos.

Une politique d’équipe plus utile qu’un enthousiasme individuel

L’un des risques sous-estimés est l’usage individuel non cadré. Un développeur très à l’aise avec un agent peut produire vite. Un autre peut introduire de la confusion sans s’en rendre compte. Sans règles communes, la base de code devient hétérogène non seulement techniquement, mais aussi dans sa manière d’être produite.

Une politique d’équipe simple peut suffire. Par exemple :

• définir les types de tâches autorisées ;
• interdire l’usage sur certaines zones sensibles ;
• exiger une mention claire quand un agent a été utilisé de manière substantielle ;
• documenter les prompts ou instructions importantes quand elles influencent fortement le résultat ;
• adapter la checklist de revue.

Le but n’est pas de bureaucratiser l’outil, mais d’éviter que chacun improvise sa propre gouvernance. Sur un produit qui dure, la discipline légère vaut mieux que l’euphorie dispersée.

Quand l’agent devient un vrai levier

Dans les meilleures configurations, l’agentic coding apporte un bénéfice net. On le voit surtout dans les équipes qui ont déjà une culture d’ingénierie solide : conventions claires, architecture lisible, pipeline fiable, tests présents, revue sérieuse, documentation minimale mais utile.

Dans ce contexte, l’agent devient un accélérateur d’exécution. Il aide à absorber la petite maintenance, à produire des premiers jets de tests, à préparer des refactors mécaniques, à explorer rapidement une piste ou à réduire le temps passé sur des tâches à faible valeur cognitive.

À l’inverse, dans une base de code déjà confuse, mal testée, peu documentée et sous tension permanente, l’agent risque surtout d’industrialiser le flou. Il ne corrige pas un déficit de rigueur : il peut l’amplifier.

Conclusion : utile, oui, mais seulement sous contrainte

L’agentic coding en production n’est ni un faux sujet ni une solution miracle. Oui, il peut devenir un vrai levier sur des projets web réels. Non, il ne remplace ni le jugement technique, ni la compréhension produit, ni les garde-fous d’une équipe mature.

Le bon cadrage est simple : confier à l’agent des tâches bornées, testables, relisibles et réversibles. Mesurer les gains réels. Refuser les zones critiques sans supervision forte. Et considérer la revue, la sécurité et la traçabilité comme des prérequis, pas comme des détails.

Si vous traitez l’agent comme un outil d’exécution sous contrôle, il peut vous faire gagner du temps. Si vous le laissez devenir une source de décisions implicites, il peut rapidement transformer votre vélocité apparente en dette bien réelle.

Sur Code Brut, le sujet mérite d’être observé sans fascination ni rejet réflexe. Testez petit, mesurez proprement, et gardez une question en tête : est-ce que votre codebase ressort plus saine après usage ? Si la réponse n’est pas clairement oui, le gain n’en est probablement pas un.