Agent de codage IA : pourquoi le chat ne suffit plus pour piloter les agents de développement

Un agent de codage IA peut analyser un dépôt, modifier plusieurs fichiers, lancer des tests, corriger une erreur puis poursuivre son travail. À mesure que ces agents gagnent en autonomie, une limite devient pourtant visible : le chat n’est pas un très bon cockpit.

Le problème n’est pas la conversation elle-même. Elle reste très efficace pour donner une intention, préciser une demande ou arbitrer un point.

Le problème commence quand le travail dure.

Après plusieurs dizaines d’actions, où se trouve la dernière décision validée ? Quel fichier a été modifié ? Quelle hypothèse a été abandonnée ? Quels tests sont passés ? Quel point attend encore une validation humaine ?

Le 17 août 2026, GitHub a précisément mis en avant cette question avec ses « canvases ». L’idée consiste à faire persister l’état d’un workflow agentique dans une interface structurée plutôt que de demander à l’humain de reconstruire cet état depuis un historique de conversation.

Pour une DSI, le changement est important. Piloter un agent IA de développement logiciel ne consiste plus seulement à écrire de meilleurs prompts. Il faut concevoir un système dans lequel son travail reste inspectable.

Le problème n’est plus seulement de faire coder l’IA

Les premiers assistants de code répondaient surtout à une question locale : « Peux-tu compléter cette fonction ? »

Un coding agent travaille autrement. Il peut recevoir un objectif plus large, explorer le projet, choisir une série d’actions et avancer pendant plusieurs étapes.

Google Cloud décrit d’ailleurs le codage agentique comme une approche dans laquelle des agents peuvent planifier, écrire, tester et modifier du code avec une intervention humaine réduite.

Cette autonomie change le problème de fond.

Quand l’IA suggère trois lignes de code, le développeur peut les relire immédiatement.

Quand un agent travaille sur une migration, une correction transverse ou une fonctionnalité pendant plusieurs étapes, il faut pouvoir comprendre où il en est et pourquoi il en est arrivé là.

La qualité du modèle reste importante. Mais elle ne suffit plus.

L’interface de pilotage devient une partie de l’architecture.

Un historique de chat n’est pas un état

Une conversation donne une impression de continuité. Pourtant, elle mélange plusieurs choses : instructions, réponses, logs, corrections, changements d’avis et résultats intermédiaires.

Au bout d’un moment, le lecteur doit interpréter l’historique pour reconstruire la situation actuelle.

GitHub résume bien le problème dans son retour d’expérience : quand le travail agentique s’allonge, il devient facile de perdre la trace de ce qui a été exécuté, modifié, validé ou de ce qui nécessite encore un jugement humain.

Pour une équipe technique, cette différence entre historique et état est essentielle.

Un historique dit :

« Voilà tout ce qui s’est passé. »

Un état inspectable dit :

« Voilà où nous en sommes maintenant. »

Ce deuxième format est beaucoup plus utile pour piloter un agent de codage IA.

On peut par exemple voir qu’une migration est en phase de validation, que deux tests bloquent encore, qu’une décision d’architecture a été approuvée et qu’une modification sensible attend la revue d’un développeur.

L’humain n’a plus besoin de relire vingt messages pour comprendre la situation.

Ce que signifie vraiment « rendre un agent inspectable »

Un état inspectable ne veut pas simplement dire « afficher davantage de logs ».

Accumuler encore plus de données peut même produire l’effet inverse.

L’objectif consiste à exposer les informations nécessaires à une décision humaine.

Pour un workflow agentique de développement logiciel, cela peut inclure :

• l’étape actuelle du workflow ;
• les tâches terminées, en cours ou bloquées ;
• les décisions importantes prises par l’agent ;
• les brouillons ou modifications actuellement retenus ;
• les résultats de tests et contrôles ;
• les éléments qui nécessitent une validation humaine.

GitHub illustre cette logique avec deux expériences différentes.

La première, Java Modernization Studio, structure un travail de modernisation autour de phases explicites telles que l’évaluation, la correction, la validation et la préparation à la livraison.

La seconde, Site Studio, conserve l’état de différentes sections d’un site, leurs brouillons et leur statut de validation. Malgré des cas d’usage très différents, GitHub retrouve le même schéma : définir les états, rendre visibles les décisions, faire persister le travail et maintenir des points d’approbation humaine.

C’est ce modèle qui intéresse une DSI.

Il transforme un agent qui « discute et agit » en un système dont l’avancement peut être supervisé.

L’état persistant réduit aussi un problème de contexte

Avec un chat classique, chaque nouvelle interaction dépend fortement de ce qui précède.

Plus le workflow dure, plus il devient coûteux de maintenir un contexte propre.

Un développeur peut rappeler une décision. L’agent peut relire des éléments. Un nouveau membre de l’équipe peut parcourir la conversation. Mais toutes ces opérations consomment du temps et parfois des tokens.

Une interface structurée permet de déplacer une partie de cette mémoire hors de la conversation.

Le statut d’une tâche n’a pas besoin d’être redéduit depuis dix messages. Il peut être enregistré directement comme « en revue ».

Une décision validée n’a pas besoin d’être reformulée à chaque étape. Elle peut devenir un élément persistant du workflow.

On passe ainsi d’une logique où la conversation contient le travail à une logique où la conversation pilote un état de travail partagé.

C’est une nuance importante pour l’orchestration des agents IA.

Pour les DSI, le vrai gain est la gouvernance

Un agent plus autonome n’est pas forcément un agent plus facile à exploiter.

C’est même souvent l’inverse.

Plus le système peut agir seul, plus l’entreprise a besoin de connaître son état et de contrôler ses points de décision.

Cette question rejoint un sujet plus large de gouvernance des agents IA. Un workflow agentique doit permettre de déterminer ce que l’agent peut décider seul, ce qui doit être enregistré et à quel moment un humain doit reprendre la main.

Chez Scroll, nous faisons déjà cette distinction lorsque nous comparons agent IA et automatisation. Un agent peut choisir son chemin selon le contexte. Cette liberté apporte de la puissance, mais aussi davantage de besoins en matière de cadrage, de tests et de supervision.

Pour une direction technique, trois niveaux deviennent alors complémentaires.

Le code permet de savoir ce qui a été produit.

Les logs permettent de savoir ce qui s’est exécuté.

L’état du workflow permet de savoir où en est le processus et ce qui doit se passer ensuite.

C’est ce troisième niveau qui manque souvent aux expériences centrées uniquement sur le chat.

Mais rendre l’agent inspectable a un coût

C’est probablement la partie la plus intéressante du retour publié par GitHub.

Construire cette couche de pilotage n’est pas gratuit.

GitHub indique qu’environ 2 000 crédits IA ont été consommés pour Site Studio et environ 3 000 crédits IA pour le canvas de modernisation Java.

Ces chiffres doivent être interprétés avec prudence.

Ils correspondent aux deux expériences décrites par l’auteur. L’article ne fournit pas de méthodologie permettant d’en faire un benchmark du coût d’un canvas ou d’un agent de codage IA en entreprise.

Autrement dit, la bonne question n’est pas :

« Un état inspectable coûte-t-il 2 000 ou 3 000 crédits ? »

La bonne question est :

« Le coût de cette couche de pilotage est-il compensé par la baisse des reprises, des prompts répétés, des erreurs de contexte et du temps de supervision ? »

Et cette réponse dépend du workflow.

Le coût par tâche n’est pas le bon indicateur

La tentation naturelle consiste à suivre uniquement le nombre de tokens ou de crédits consommés.

C’est insuffisant.

GitHub l’a également constaté dans ses travaux sur l’efficacité de ses workflows agentiques. Les équipes ont dû instrumenter l’usage des tokens, le nombre d’appels aux modèles et d’autres signaux, car deux exécutions d’un même workflow peuvent traiter des charges de travail très différentes. GitHub souligne aussi la difficulté à mesurer une efficacité réelle sans mesure fiable de la qualité du résultat.

Pour une DSI, le coût d’un agent IA doit donc être rapproché d’un résultat opérationnel.

Une analyse pertinente peut regarder le coût par ticket résolu, le temps de revue humaine, le taux de tâches reprises, les validations nécessaires ou encore le nombre d’exécutions qui nécessitent une intervention manuelle.

Un agent qui consomme moins mais oblige un senior à passer quarante minutes à comprendre ce qu’il a fait n’est pas forcément plus économique.

À l’inverse, une interface de pilotage plus coûteuse peut devenir rentable si le même workflow est exécuté des centaines de fois.

Les workflows répétés sont les meilleurs candidats

Tous les agents de développement n’ont donc pas besoin d’un canvas complexe.

Pour une tâche ponctuelle et courte, le chat reste souvent suffisant.

La logique devient plus intéressante dès qu’un processus est récurrent, comporte plusieurs étapes ou implique plusieurs personnes.

Une migration applicative en est un bon exemple. Il faut analyser l’existant, identifier les dépendances, modifier le système, vérifier les résultats puis obtenir plusieurs validations.

Même problème pour une génération de fonctionnalités avec revue humaine, une modernisation de code legacy ou une chaîne de correction de bugs.

Dans ces situations, le besoin se rapproche moins d’un chatbot que d’un outil métier piloté par des agents IA.

C’est aussi ce que l’on constate lors du passage d’un prototype IA à une application robuste. La génération initiale peut être rapide. La difficulté apparaît lorsque l’on doit gérer l’architecture, les données, les droits, les validations et les cas limites. Nous détaillons ce passage dans notre retour sur la transformation d’un prototype IA en application robuste.

Une nouvelle couche apparaît dans la stack de développement IA

Pendant longtemps, le débat sur le développement logiciel IA s’est concentré sur les modèles et les outils : GitHub Copilot, Claude Code, Codex, Cursor et les autres coding agents.

Pour les entreprises, le prochain sujet pourrait être moins visible mais plus structurant.

Il s’agit de la couche de pilotage située entre l’humain et les agents.

Elle doit conserver l’état, rendre les décisions lisibles, organiser les validations et fournir les données nécessaires pour mesurer le coût réel du workflow.

Le meilleur agent de codage IA ne sera donc pas forcément celui qui agit avec le moins d’interventions humaines.

Ce sera souvent celui dont l’autonomie reste compréhensible.

Ce que les directions techniques doivent retenir

Le chat reste une très bonne interface pour exprimer une intention.

Il devient beaucoup moins adapté lorsqu’il doit servir à la fois de commande, de mémoire, de journal d’exécution, de gestionnaire de tâches et de système de validation.

À mesure que les agents de développement prennent en charge des workflows plus longs, l’état inspectable devient une condition de pilotage.

Mais cette visibilité doit elle-même être mesurée. Ajouter une interface, de la persistance et des contrôles n’a de sens que si le gain dépasse leur coût.

Pour une DSI qui expérimente aujourd’hui les agents IA, le sujet n’est donc plus seulement de choisir un modèle ou un coding agent. Il faut aussi déterminer quels workflows méritent une couche de pilotage durable, quels états doivent être conservés et comment mesurer leur valeur.

C’est précisément sur ce type de cadrage que Scroll peut intervenir : architecture du workflow, choix entre automatisation et agent IA, conception des points de contrôle, intégration aux outils internes et passage d’un prototype agentique à un système exploitable en production.

L’enjeu n’est pas d’ajouter de l’IA partout. Il est de construire des agents que vos équipes peuvent réellement piloter.