Coder avec un agent IA : le gain vient de la conception, pas de la vitesse de frappe

Ce que mesurent les statistiques de productivité de l'IA

« L'IA augmente de 17 % le nombre de commits » ne dit rien de la valeur livrée à votre client. Si l'application arrive à la même date, avec la même qualité, ce chiffre correspond à un gain nul. Pire, la vitesse de frappe masque souvent un allongement des délais réels : du code produit vite sur un périmètre mal compris revient sous forme de corrections, de fonctionnalités refusées et de recettes à refaire.

Trois indicateurs mesurent ce qui compte pour un projet piloté avec des agents : le temps entre l'idée et la mise en production d'une fonctionnalité, le taux de reprise (défauts, bugs, fonctionnalités refusées) et le temps perdu à attendre des tiers (validation d'un store d'applications, recette, support d'une API externe). Le nombre de lignes de code produites ne figure dans aucun des trois.

Premier temps : laisser l'agent explorer, puis lire ce qu'il a compris

Avant toute ligne de code, l'agent parcourt la base de code existante et restitue ce qu'il en a compris. La qualité de son travail dépend entièrement de ce contexte : trop peu d'éléments et il invente, trop de fichiers hors sujet (une zone de dette technique, un module sans rapport) et il se laisse polluer. Le rôle de la personne qui pilote consiste à lire cette restitution avec un œil critique, comme on relirait la note d'un développeur qui découvre le projet. Deux questions guident cette lecture : reste-t-il assez de place dans la fenêtre de contexte du modèle pour mener le travail jusqu'au bout, et manque-t-il dans l'analyse une information du projet dont dépendra la suite ?

Prenez une fonctionnalité d'export de données. Si l'analyse de l'agent ne mentionne jamais le stockage des fichiers (un bucket S3, par exemple), c'est le signe qu'il ne sait pas où l'export sera écrit. Un développeur junior serait resté bloqué au même endroit, faute de savoir quelle technologie le projet utilise. Repérer ce trou avant l'écriture du code coûte une phrase. Le repérer après coûte une reprise.

Deuxième temps : se laisser poser des questions avant de décider

L'agent interroge ensuite son interlocuteur sur les sujets qui produisent le plus de défauts : structure des données, sécurité, volumétrie. C'est l'étape où les erreurs d'architecture se rattrapent à moindre coût. Sur l'export de fichiers volumineux (images, vidéos envoyées par des utilisateurs), la bonne question est celle du transit : les faire passer en mémoire sur le serveur provoque des dépassements de mémoire et des délais d'attente dépassés, un défaut qui n'apparaît qu'après quelques semaines de données réelles. La réponse correcte consiste à copier d'un espace de stockage à l'autre en flux continu, sans jamais charger le fichier entier.

Ce temps d'échange se pilote. La personne qui conduit l'agent oriente ses questions vers les zones à risque connues du projet, plutôt que de le laisser dérouler une liste générique. Elle sait, par exemple, qu'une application qui manipule des données de santé appelle des questions de sécurité que l'agent ne posera pas spontanément.

Pourquoi ne pas se contenter du mode « plan » intégré à l'outil

Les outils comme Claude Code proposent un mode plan natif. Nous le déconseillons pour la plupart des tâches, parce qu'il ne permet pas de maîtriser chaque élément qui arrive dans la fenêtre de contexte du modèle. Une commande personnalisée, rédigée par l'équipe, produit un plan prévisible qui respecte les contraintes du projet, et son affinage progressif sert d'apprentissage à l'équipe.

Troisième temps : un plan écrit, court, relu ligne à ligne

La discussion se conclut par un document de stratégie technique en markdown, suffisamment précis pour qu'un modèle l'exécute sans ambiguïté. Trois contrôles à la relecture : chaque ligne est exacte et non ambiguë, le document reste sous 200 lignes environ (au-delà, on le découpe en tâches), et le modèle peut lire chaque section sans contexte supplémentaire. Une fonctionnalité trop grosse pour un seul plan se scinde en plusieurs fichiers, chacun décrivant une tâche testable séparément.

Le plan s'appuie sur des garde-fous écrits, qui conditionnent la qualité du code produit. Des standards de codage rédigés en phrases claires et formulés en positif (« les fichiers de test définissent une fonction de fabrication de données » plutôt que « ne recréez pas un objet de test dans chaque test »). Un typage strict et un linter dont chaque erreur est renvoyée à l'agent, qui la corrige. Des hooks qui lancent automatiquement le formatage après chaque écriture de fichier, ce qui économise de la place dans le contexte. Et le développement piloté par les tests : l'agent rédige d'abord les tests, on les relit, puis il implémente en les exécutant.

Le développement piloté par les tests change ce que vous pouvez contrôler. Quand l'agent rédige d'abord les tests et que l'équipe les relit, la relecture porte sur le comportement attendu (« une commande sans adresse de livraison est refusée ») et non sur du code que peu de dirigeants peuvent juger. Ensuite l'agent implémente en relançant la suite de tests jusqu'à ce qu'elle passe, ce qui garantit un code testable par construction et donne à l'architecte l'occasion de construire un environnement de test solide, par exemple une base de données jetable démarrée en conteneur pour chaque exécution.

Le gain de cette méthode se situe à la conception : une fonctionnalité pensée, interrogée puis planifiée avant le code sort juste du premier coup bien plus souvent qu'une fonctionnalité demandée directement à l'agent. Le temps gagné vient des reprises évitées, pas de la saisie accélérée. C'est aussi ce qui rend la méthode transférable : elle ne dépend ni d'un outil précis ni d'un modèle particulier, puisque les outils changent tous les mois alors que l'ordre exploration, questions, plan écrit reste valable. Une équipe qui l'a intégrée change d'agent sans perdre sa façon de travailler.

Quand l'agent échoue, corriger le cadre et non le résultat

Corriger à la main ce que l'agent n'a pas réussi à produire fait perdre l'occasion de comprendre pourquoi il a échoué. Nous appliquons ici le principe du système de production de Toyota (le jidoka) : lorsqu'un défaut apparaît, on arrête la ligne, on cherche la cause, on corrige avant de reprendre. Concrètement : on ajuste la commande, les standards, les règles du linter, puis on relance.

Un cas typique. Pour reproduire un écran à partir d'une maquette Figma connectée par un serveur MCP, l'agent livre souvent un écran fidèle visuellement, mais avec des styles écrits en dur, sans réutiliser les composants du système de design et avec des textes non traduisibles. Plutôt que de retoucher le code, on injecte directement les fichiers de thème dans la demande et on fournit une extraction compacte des clés de traduction (quelques centaines de lignes au lieu du fichier complet, ce qui évite de saturer le contexte). Le composant suivant sort conforme, sans retouche.

Pour une direction, la conséquence pratique est simple. Demandez à votre prestataire ou à votre équipe un registre des cas où l'agent n'a pas livré au premier passage, et ce qui a été modifié dans le cadre en réponse. Un processus sans aucune trace d'échec n'est pas un processus sans échec. Cette discipline rejoint celle d'une reprise de MVP généré par IA, où l'on repose d'abord les garde-fous avant d'accélérer, et elle répond au constat de l'illusion de vitesse que crée l'IA sur un projet.

Ce que vous pouvez exiger sans lire une ligne de code

Vous n'avez pas besoin de juger le code pour vérifier qu'un agent est piloté avec méthode. Trois demandes suffisent lors d'un point d'avancement. Montrez-moi le plan technique de la dernière fonctionnalité significative et la date à laquelle il a été relu. Montrez-moi ce qui fait échouer le build quand le code est mal typé ou mal formaté, c'est-à-dire le linter et la configuration stricte du typage. Montrez-moi les tests écrits avant l'implémentation. Une équipe qui répond à ces trois demandes en quelques minutes a transformé l'agent en outil de production. Une équipe qui hésite l'utilise comme un clavier plus rapide.

Cette lecture éclaire aussi la question du budget. La consommation de l'agent pèse peu face aux heures de développement en jeu. Le poste qui compte est ailleurs : le temps de conception et de relecture par un profil capable de repérer ce que l'agent n'a pas vu. Un devis qui promet une division par trois des délais sans mentionner ce temps de conception décrit probablement un projet où les défauts arriveront après la livraison. Pour juger un tel devis, comparez le nombre de jours alloués à la conception avec ceux alloués au développement : un rapport qui s'inverse par rapport à vos projets passés est un signal à interroger.

Au prochain point d'avancement avec votre équipe de développement, posez une seule question : pour la dernière fonctionnalité livrée avec un agent, où est le plan écrit qui a été relu avant le code ?