Un agent a besoin de signaux

Sat, 22 Aug 2026 00:00:00 GMT

Tout développeur, ou presque, utilise un agent de code aujourd'hui. C'est devenu un outil de base, au même titre que l'IDE, qu'il a d'ailleurs souvent remplacé.

Avec le temps, on est passé d'une interruption constante, à un fonctionnement de plus en plus autonome. Ce qui nous a permis de le faire ? L'amélioration de la boucle de rétroaction.

L'efficacité de la boucle de rétroaction influe sur le résultat et le degré d'autonomie. C'est pourquoi nous l'optimisons, en permanence. Chaque faux pas de l'agent doit nous interpeller sur l'efficacité de cette boucle. Et nous devons en traiter les causes.

Les signaux vont alimenter le contexte et en faire partie intégrante. Nous avons tous rapidement appris que ce qui conditionne le résultat est avant tout une question de contexte. En gros, mauvais contexte = mauvais résultat (fallait-il vraiment attendre les LLM pour le constater ?). Il faut donc traiter ce contexte avec attention.

Dans une conversation, le retour que nous faisons, avec nos suggestions et recommandations, pour corriger ou améliorer une solution, est le premier signal. Et c'est là que les agents de code sont devenus très utiles, pour apporter le bon contexte, selon les éléments qu'ils ont à disposition, et plus particulièrement, en scrutant la base de code, de manière automatisée, pour en déduire nos conventions, habitudes et éléments clefs.

Les agents comme Claude Code, Codex, OpenCode se sont démarqués en étant capables de récupérer ce contexte depuis la base de code et de le manipuler pour le fournir correctement au modèle sous-jacent. L'agent dispose d'outils qui lui permettent de lire et écrire des fichiers, exécuter un certain nombre d'actions, utiles à l'exploration et à la validation. Il se corrige lui-même quand il se rend compte que ses suppositions sont erronées. Et il améliore son contexte. Cela fait partie de la boucle.

Notre travail est de définir ce qui constitue cette boucle, et en quoi elle satisfait notre niveau d'exigence. À chaque niveau, quelles sont les informations nécessaires, quelles sont les actions possibles, avec quelle garantie de sécurité.

C'est ce qui nous a amenés à définir des conventions sur la manière d'explorer le code et le manipuler, généralement dans un fichier de règles, AGENTS.md, ou équivalent, pour que l'agent évite des erreurs récurrentes en lisant les bonnes (et surtout les mauvaises) pratiques. Une façon d'améliorer le signal de retour fait à l'agent, pour qu'il soit plus autonome. On supprime ainsi un certain nombre d'allers-retours inutiles.

Avec cela, la documentation est devenue un élément central, servant non seulement à expliquer le code, mais aussi le métier, la raison d'être d'un projet, les objectifs. On prend donc davantage soin de notre documentation. Le but étant qu'elle soit lue par notre agent quand il en a besoin et produise une solution en adéquation avec les exigences du projet.

Les tests automatisés ont eu un regain d'intérêt. Certains se sont rendu compte que ce n'était pas juste un truc qui fait perdre du temps ou qu'il faut faire pour cocher la case du bon dev. Un test qui échoue est un signal de non-conformité ou de nécessité d'adaptation. Donc on prend soin de la suite de tests. Et en plus l'agent peut en écrire. Il exécute la suite de tests, peut se réajuster s'il dérive, et la compléter avec de nouveaux éléments. Qu'il s'agisse de tests unitaires, d'intégration, ou d'analyseurs statiques de code, tous ces outils sont devenus encore plus indispensables avec un agent de code. Ils témoignent de la conformité technique en termes d'exécution. Et c'est un signal fort.

Les signaux doivent intervenir le plus tôt possible, être suffisamment exhaustifs pour guider l'agent de manière cohérente. Une analyse de code statique prend quelques secondes, elle doit être exécutée d'abord. Les tests d'intégration peuvent prendre plusieurs minutes, ils viennent ensuite. À chaque étape, nous commençons par scruter les actions de l'agent et ses dérives, pour rectifier notre boucle et passer au niveau suivant de validation.

Les serveurs MCP, compétences (skills), et scripts utilitaires en tout genre, sont autant d'outils complémentaires qui peuvent permettre à l'agent d'obtenir ces signaux. Il nous appartient de les définir selon nos besoins, pour obtenir un niveau de confiance suffisamment haut dans l'autonomie de l'agent et définir le niveau suivant, pour qu'il réponde à nos exigences.

Penser en signaux, c'est faire en sorte que l'agent devienne progressivement autonome, fiable et pertinent. Ainsi, il nous décharge de ce qui est répétitif, et nous pouvons être disponibles pour ce qui est important : le jugement, l'alignement de la tech avec le besoin métier.

Sören Ohnmeiss - Articles

Un agent a besoin de signaux