Modèles mentaux

”Focuser” l’agent

Pour qu’un agent soit réellement performant et prévisible, il ne faut pas le laisser dériver dans une liberté totale, mais au contraire bien le “focuser”. Ce terme de ‘focuser” décrit ce cadrage strict de l’agent : lui donner le bon contexte pour qu’il sache exactement « quoi faire ? », « comment le faire ? » et « comment vérifier que le résultat est correct ? ». Cela lui évite d’inventer des solutions hasardeuses, on évite ainsi le fameux « vibe coding » (coder à l’intuition sans garde-fou).

Pour réussir ce “Focus”, il faut articuler trois choses :

• Définir la tâche, “Quoi faire ?” : décrire clairement la tâche et l’attendu. La solution doit être décomposée en composants basés sur le modèle du domaine ou le style d’architecture du système. L’agent doit savoir exactement sur quel périmètre il intervient.
• Guider l’exécution, “Comment le faire ?” : C’est le Context Engineering. On fournit à l’agent les garde-fous nécessaires : patterns, bonnes pratiques, styles de développement (ex: Test-First) et exemples de référence. L’objectif est de guider sans saturer (attention à la fenêtre de contexte). On peut ici distinguer :
  • ce qui s’applique en permanence (le contexte globale du projet, c-à-d le CLAUDE.md ou AGENT.md.
  • ce qui s’applique en fonction de la tâche : pour les tâches spécifiques et répétitives, cette étape est idéalement encapsulée dans un “Skill”, une commande ou une rule réutilisable.
• Vérifier que le résultat est correct, “Quel retour peut obtenir l’agent sur son travail ?” : l’agent doit vérifier la qualité de ce qu’il a produit. Ici on va combiner des vérifications :
  • déterministes / computationnelles avec un retour “red/green”, idéalement avec des suites de tests pour vérifier le comportement attendu du système (sa correctness).
  • de jugement / inférentielles avec l’utilisation d’un agent qui fait une revue du travial effectué et propose des améliorations (en s’appuyant toujours sur le contexte).
  • hybrides / à la fois computationnelles et inférentielles, comme par exemple l’utilisation par l’agent d’un navigateur web qui combine les deux approches et les capacités multi-modales des LLMs (c-à-d le fait de pouvoir traiter du texte mais également des images, comme une copie d’écran d’une page web).

La bonne granularité des ces trois éléments est très importante. Il faut que la tâche ne soit ni trop large ni trop réduite, si trop large il faut donc préalablement décomposer la tâche (et utiliser les capacités de Plan de l’agent afin de faire cette décomposition, c.f. la section suivante sur les Workflows).

Inferential vs Computational

Toute tâche confiée à une machine relève dorénavant de l’un des deux régimes suivants :

• Le traitement inferential repose sur un LLM ou un agent qui interprète le contexte et produit un résultat. Il est lent, coûteux en tokens, et son résultat n’est que presque déterministe : la même entrée peut produire une sortie légèrement différente (c.f. cet article pour comprendre pourquoi un LLM n’est pas déterministe).
  On l’utilise de manière massive et surtout dans le cas où le jugement est nécessaire.
• Le traitement computational repose à l’inverse sur un programme déterministe “classique” (un script, un linter, une requête SQL, un test runner) qui produit une sortie, si possible structurée (dans tous les cas il faut dorénavant intégrer que cette sortie sera très probablement consommée par un LLM et donc qu’il interprète très bien le langage naturel). Il est rapide, léger, exécuté fréquemment (typiquement en CI), et son résultat est strictement reproductible, sauf en cas d’erreur (erreur elle-même attendue et lisible).

Le bon réflexe consiste à encadrer la part inferential par des étapes computational en amont et en aval : préparer le contexte, valider la sortie, transformer le résultat. Cette discipline réduit la consommation de tokens et stabilise les comportements, en particulier sur les chaînes exécutées fréquemment.

L’agent peut d’ailleurs servir à écrire lui-même la partie computational. Et lorsque le programme déterministe échoue, l’agent reprend la main pour l’analyser et le corriger : la boucle d’amélioration s’installe naturellement entre les deux régimes.

Workflows Humain et Workflows Agent

Il faut distinguer deux types de workflow :

• Les workflows d’agent IA (BMAD, Speckit, superpower, etc.), proposant chacun un ensemble de skills à utiliser dans une certaine séquence. Nous pensons que les workflows d’agent IA ne sont pas la chose la plus importante sur laquelle se concentrer mais qu’il vaut mieux plutôt se concentrer sur les artefacts qui vont être produits par chaque phase / skill et bien connaitre ce que chaque phase attend en entrée et produit en sortie.
• Les workflows humains : Les grandes phases d’utilisation d’un agent IA par un humain qui veut faire des tâches complexes doivent se rapprocher selon nous d’une boucle PDCA d’amélioration continue bien connu du lean (Plan/Do/Check/Act). Les grandes phases pour un humain qui est en interaction avec un Agent IA :
  • Design : définir notre intention, ce que l’on cherche à obtenir, quels besoins ? quelle solution et comment on décompose en terme d’architecture cette solution. L’humain décompose la solution en composant logiques, on demande à l’IA de valider et d’améliorer cette décomposition. On définit également ce qui est hors-périmètre afin d’éviter que l’agent ne parte dans une direction non souhaitée.
  • Plan : comment décomposer la solution en tâches qui seront exécutées par l’agent, donc avec la bonne granularité pour que l’agent soit efficace (des tâches ni trop grosses ni trop petites). On applique le principe de “focusing” de l’agent. L’agent peut ici produire son contexte “temporaire” afin qu’il séquence / parallèlise ses générations (le PLAN.md ou la liste des User story que l’agent exécutera).
  • Execute : l’humain déclenche l’exécution par l’agent, ici on cherche à ce que l’agent ait le maximum d’autonomie tout en gardant une traçabilité sur ce qu’il fait et des éventuelles décisions qu’il prend pendant cette exécution (un Traceability Log). Avant chaque exécution, l’humain peut passer rapidement la checklist suivante : TODO.
  • Check / Enhance : l’humain vérifie le résultat et adapte les trois piliers Arrange / Instruct / Assert que nous avons vu préalablement. C’est la phase la plus importante car l’humain ne doit pas se contenter de regarder et valider le résultat mais d’agir afin d’améliorer la prochaine itération de l’agent, souvent l’ajout d’exemples correct attendus fonctionne bien (Do’s et Don’t). Et bien sûr on peut demander à l’agent de s’améliorer lui-même ("Update your CLAUDE.md so you don't make that mistake again.").

Un LLM comme une fonction sans états

Considérer le LLM comme une fonction sans états. Considérez votre agent comme une fonction, malheureusement non pure car non déterministe : pour une entrée X (le contexte + l’instruction), il produit une sortie Y similaire mais non identique. Il n’y a pas de “mémoire interne” qui persiste entre deux appels. Les interactions avec un LLM se font par concaténation de texte car celui est complétement stateless, il ne se souvient pas des interactions précédentes (il y a bien un cache mais il est présent pour des raisons d’efficacité sur l’ensemble du texte déjà soumis au LLM). Tous les mécanismes de context engineering (permanent, à la demande, conversationnel, etc.) sont finalement un moyen de structurer cette conconténation de text soumis à l’agent. Pour ceux que cela intéresse le non-déterminisme des LLMs peut être corrigé.

Pourquoi ce modèle mental nous semble important :

• L’illusion de la conversation : Ce que nous percevons comme une “discussion” est en réalité une ré-exécution complète de la fonction. À chaque message, le système concatène l’historique total. Si l’historique devient trop lourd ou pollué (c-à-d qui envoie dans des espaces sémantiques très différents, ex : je parle de cuisine et d’ingénièrie logicielle 🤔), le résultat perdra de sa précision. Maîtriser le contexte, c’est maîtriser ce ratio signal/bruit (et donc penser à /clear ou /compact votre conversation pour optimiser ce ratio).
• Moins il y a d’informations parasites ou sur sujets différents dans cette concaténation de texte, plus le ratio signal/bruit pour l’agent est élevé. Si votre fonction reçoit 80% de contexte inutile pour 20% de besoin réel, la qualité de la réponse s’effondre. C’est un argument important qui justifie la granularité du contexte et des instructions.
• Pour développer cette idée, on peut considérer que le contexte permanent (system prompt + la hiérarchie de CLAUDE.md) et à la demande (skills, rules) sont la définition de la fonction (ses contraintes, son domaine, comment faire), tandis que l’instruction (le User Prompt) est l’appel de la fonction avec ses arguments. Ne pas mélanger le contexte (le comment, les contraintes, le cadre) avec la tâche (ce que l’agent fait). Cela aide l’agent à mieux isoler sa logique.