31 Termes sur les Agents de Codage IA à Connaître, Classés en Cinq Piliers

Chaque semaine, un nouveau terme apparaît dans mon fil d’actualité. Context engineering. Harness engineering. RLM. Progressive disclosure. J’utilise des agents de codage IA tous les jours, et le vocabulaire s’étoffait plus vite que ma compréhension du sujet.

Alors je me suis arrêté pour trier les 31 termes que j’avais accumulés. Cinq piliers ont émergé, et une fois que je les ai vus, l’architecture entière d’outils comme Claude Code et Codex a pris un sens qu’elle n’avait pas eu jusque-là.

Ces cinq piliers suivent une séquence logique : on conçoit ce que l’agent perçoit, on divise le travail entre agents, on contrôle leur exécution, on les aide à se souvenir d’une session à l’autre, et on les connecte au monde extérieur.

Concevoir. Diviser. Contrôler. Mémoriser. Connecter.

Concevoir ce que l’agent perçoit

Un modèle d’IA traite exactement une chose : sa fenêtre de contexte. Chaque system prompt, instruction utilisateur, fichier joint, entrée de l’historique de conversation, bloc mémoire et skill chargé est concaténé en un seul flux de tokens. Ce flux est l’univers entier du modèle. Le fichier AGENTS.md, que beaucoup d’équipes utilisent pour configurer le comportement de l’agent, n’est qu’un élément parmi d’autres dans ce flux.

Le prompt est l’instruction directe que vous donnez au modèle. Le prompt engineering est la pratique de concevoir ces instructions, avec des exemples et des formats de sortie, pour obtenir des résultats fiables. Ces deux termes sont bien établis, mais ils ne couvrent qu’une fraction de ce qui entre réellement dans le modèle.

Le context (contexte) regroupe tout ce à quoi le modèle peut se référer : system prompts, historique de conversation, fichiers joints, mémoire, skills et résultats d’outils. Le context engineering est la discipline qui consiste à décider ce qui entre, ce qui reste dehors, et dans quel ordre. La différence est réelle. J’ai vu des prompts identiques produire des résultats radicalement différents selon qu’un fichier de 2 000 lignes était placé avant ou après l’instruction. L’ordre n’est pas cosmétique.

L’intent (intention) est l’objectif réel de l’utilisateur, qui peut différer de ce qu’il a littéralement tapé. Quand vous écrivez “corrige les tests”, l’intention peut être “fais passer la CI” ou “refactorise la suite de tests pour correspondre à la nouvelle API”. Le routage des agents commence ici, et se tromper sur l’intention a des répercussions sur tout ce qui suit.

Un skill est un bundle réutilisable d’instructions expertes qui se charge dans le contexte au moment de son invocation. Pensez-y comme une fonction pour les prompts. Au lieu de coller les mêmes 200 lignes d’instructions à chaque fois que vous voulez un comportement précis, vous appelez /refactor-clean et le contenu du skill entre dans la fenêtre de contexte à la demande.

La progressive disclosure est le pattern de conception qui consiste à ne pas charger tous les skills dans le contexte d’un coup. L’agent ne charge que le skill dont il a besoin au moment où il en a besoin. Anthropic a publié cette approche dans leur article de blog sur les skills. C’est important parce que l’espace dans la fenêtre de contexte est limité. Charger 40 skills dès le départ brûle des tokens avant même que le modèle commence à travailler. La progressive disclosure garde la fenêtre légère et le modèle concentré.

L’erreur que j’ai commise à répétition au début : surcharger le contexte et me demander pourquoi la qualité des sorties se dégradait. La fenêtre de 200K tokens est un maximum théorique. En pratique, une fois qu’on tient compte des system prompts, des définitions de serveurs MCP et de l’historique de conversation, l’espace utilisable peut tomber à 70K ou moins. Le context engineering consiste à respecter cette contrainte.

Diviser le travail entre agents

Un seul agent qui gère tout semble simple, jusqu’à ce que la fenêtre de contexte se remplisse et que la qualité baisse. C’est pourquoi les architectures multi-agents existent.

Un subagent est un processus enfant auquel un agent principal délègue du travail. L’agent principal garde son propre contexte propre en externalisant les tâches spécialisées. Dans Claude Code, quand vous lancez une tâche de recherche en arrière-plan, c’est un subagent qui opère dans sa propre fenêtre de contexte et ne renvoie que le résultat.

Un swarm est un pattern où plusieurs agents travaillent en parallèle sur différentes parties du même problème. Si vous devez analyser cinq fichiers simultanément, un swarm permet à cinq agents de chacun traiter un fichier plutôt qu’un seul agent les traite séquentiellement.

Le fleet est la vue opérationnelle de vos agents en cours d’exécution. C’est un terme de gestion, pas d’architecture. Quand vous avez trois subagents et deux background agents actifs, cette collection constitue votre fleet.

Le handoff est le transfert de travail d’un agent (ou d’une personne) à un autre. Dans les workflows séquentiels, l’Agent A termine sa phase et passe la main à l’Agent B. Le détail important est ce qui est transféré : seulement le résultat, ou le contexte complet ? La plupart des handoffs transfèrent un résumé, ce qui signifie qu’une perte d’information est possible et doit être anticipée.

Un background agent s’exécute de manière asynchrone sans interaction de l’utilisateur. GitHub Copilot Workspace et Claude Code d’Anthropic supportent tous deux ce pattern. Vous décrivez une tâche, fermez votre laptop, et l’agent travaille de manière autonome. Les résultats apparaissent à votre retour.

Le piège dans lequel je suis tombé : diviser le travail entre trop d’agents trop tôt. Un seul agent avec un contexte bien conçu gère 80% des tâches mieux qu’un setup multi-agents mal coordonné. Ne divisez que lorsque vous avez la preuve qu’un seul agent atteint les limites de contexte ou que la qualité se dégrade.

Contrôler l’exécution des agents

Un agent qui génère du code correct est inutile s’il appelle aussi silencieusement des outils dangereux ou modifie des fichiers qu’il ne devrait pas toucher. Le contrôle est le troisième pilier, et c’est celui dans lequel la plupart des équipes n’investissent pas assez.

Le harness est le cadre opérationnel qui enveloppe l’exécution, la vérification et le cycle de vie d’un agent. Il comprend tout, des vérifications de permissions à la validation des sorties en passant par la logique de retry. Le harness engineering consiste à concevoir les contraintes et les boucles de rétroaction dans ce cadre. OpenAI a popularisé ce terme quand ils ont publié comment Codex a généré plus d’un million de lignes de code avec des patterns de harness structurés.

La trace est le journal d’exécution de chaque étape et décision prise par un agent. J’ai commencé à prendre les traces au sérieux après avoir découvert qu’un agent appelait un outil de recherche web 14 fois par tâche alors qu’il n’avait besoin de l’information qu’une seule fois. Sans la trace, j’aurais supposé que l’agent fonctionnait efficacement. Les traces sont ce qui se rapproche le plus du débogage pour les agents IA.

Le diff est la comparaison du code avant et après les modifications d’un agent. Avec les traces, les diffs forment le socle de vérification. Vous ne pouvez pas réviser ce que vous ne pouvez pas voir, et les diffs rendent les changements d’agents révisables de la même façon que les pull requests rendent les changements humains révisables.

Les guardrails sont des règles et des vérifications de validation qui empêchent les sorties dangereuses. Ils peuvent être aussi simples que “ne jamais exécuter de commandes shell contenant rm -rf” ou aussi sophistiqués que des classificateurs de contenu qui empêchent les données sensibles d’apparaître dans les sorties.

Un sandbox est un environnement d’exécution isolé avec des permissions restreintes. Codex s’exécute dans un sandbox Docker où l’agent peut écrire du code et lancer des tests mais ne peut pas accéder au réseau ni modifier le système hôte. C’est la différence entre “l’agent a fait une erreur” et “l’agent a fait une erreur qui a affecté la production.”

La CLI (command-line interface) connaît un regain d’intérêt à l’ère des agents. Exécuter des outils via un terminal s’avère plus efficace en tokens que de passer par des couches de protocole. Quand chaque token coûte de l’argent et consomme de l’espace de contexte, la directness de la CLI compte.

Le REPL (read-eval-print loop) est un environnement interactif pour exécuter du code immédiatement. Les agents utilisent les REPLs pour tester des hypothèses, valider des résultats intermédiaires et itérer sur des solutions sans d’abord écrire des fichiers sur le disque.

Mémoriser entre les sessions

Les grands modèles de langage ont une limite ferme : la fenêtre de contexte. Quand elle se remplit, le contenu le plus ancien est évincé. Pour des tâches qui s’étendent sur des heures ou des jours, cela pose un vrai problème.

La memory (mémoire) est tout système qui stocke l’historique de conversation et l’état des tâches au-delà d’une seule fenêtre de contexte. La memory hierarchy organise ces stockages en couches, typiquement court terme (conversation en cours), moyen terme (sessions récentes) et long terme (connaissances persistantes). Cette conception est parallèle aux hiérarchies de cache CPU pour la même raison : différents patterns d’accès ont besoin de différentes stratégies de stockage.

Les embeddings convertissent du texte en vecteurs numériques qui capturent le sens sémantique. Ils sont le fondement du RAG (retrieval-augmented generation), où un agent interroge une base de données vectorielle pour extraire des informations pertinentes dans sa fenêtre de contexte. Quand votre agent “se souvient” de quelque chose d’une session précédente, il effectue généralement une recherche par similarité basée sur les embeddings.

Un long-running agent maintient son état sur plusieurs fenêtres de contexte, travaillant sur des tâches qui durent plus longtemps qu’une seule session. Cela nécessite une gestion d’état externe car le modèle lui-même n’a pas de mémoire persistante.

La Ralph Loop, créée par Geoffrey Huntley, est une boucle de codage autonome qui résout le problème de mémoire de manière pragmatique. Chaque itération démarre une nouvelle instance d’agent, mais la progression est persistée via des commits git et des fichiers de progression. La nouvelle instance lit l’historique git et les notes de progression pour comprendre ce qui a été fait, puis continue à partir de là. Elle maximise le test-time scaling en itérant de manière répétée, chaque boucle bénéficiant du contexte accumulé dans le dépôt lui-même.

Le RLM (Recursive Language Model) adopte une approche fondamentalement différente. Au lieu d’injecter une longue entrée directement dans le modèle (où elle dépasserait la fenêtre de contexte), RLM stocke les données d’origine dans des variables REPL et laisse le modèle écrire du code pour les explorer. Le modèle émet des requêtes ciblées contre les données stockées via des appels de fonctions récursifs. Comme les données d’origine n’entrent jamais dans la fenêtre de contexte, aucune information n’est perdue par troncature. Les auteurs affirment que cette approche gère des entrées équivalentes à 100x la fenêtre de contexte normale.

Ces deux approches reconnaissent la même contrainte mais la résolvent différemment. La Ralph Loop travaille avec les limitations de la fenêtre de contexte en utilisant la persistance externe. RLM contourne entièrement la fenêtre de contexte en gardant les données à l’extérieur. Aucune n’est universellement meilleure ; le bon choix dépend de si votre goulot d’étranglement est la continuité des tâches (Ralph Loop) ou la taille des entrées (RLM).

Connecter les agents au monde extérieur

Un agent qui ne peut pas accéder à des outils externes, des APIs ou des services est limité à la génération de texte. Les protocoles résolvent le problème d’intégration.

Le MCP (Model Context Protocol) standardise la façon dont les modèles se connectent aux outils externes. Sans MCP, intégrer N modèles avec M outils nécessite N x M implémentations personnalisées. Avec MCP, chaque modèle et chaque outil implémente le protocole une seule fois, réduisant le coût d’intégration à N + M. C’est le même principe qui a rendu USB efficace : s’accorder sur une interface unique, et tout se connecte.

L’ACP (Agent Communication Protocol) standardise la communication entre les éditeurs et les agents de codage. Zed et JetBrains mènent son développement. Le problème qu’il résout est similaire à MCP mais à une couche différente : au lieu de modèle-vers-outil, c’est éditeur-vers-agent.

Le LSP (Language Server Protocol) est le standard établi pour la communication entre un éditeur et un serveur d’analyse de code. C’est la preuve originale que la standardisation des protocoles fonctionne dans les outils de développement. Une recherche de références qui prenait 30 secondes avec grep se fait en 50ms via LSP. L’utilisation de tokens passe de 2 000+ à environ 500 parce que LSP renvoie des résultats structurés et précis plutôt que des contenus de fichiers bruts. LSP est aussi le modèle de référence pour la conception d’ACP, ce qui fait sens : les formes du problème sont quasi identiques.

Ces trois protocoles opèrent à des couches différentes mais partagent le même constat architectural. Les intégrations point à point personnalisées ne passent pas à l’échelle. Les interfaces standardisées, oui.

La carte, pas le territoire

La plupart de ces termes n’existaient pas il y a six mois. S’ils semblent peu familiers, c’est normal. Le vocabulaire s’enrichit parce que le domaine s’enrichit, et les nouveaux concepts ont besoin de noms.

La valeur de ces cinq piliers n’est pas dans la mémorisation des définitions. Elle est dans le fait d’avoir un cadre mental qui vous dit où un nouveau terme se place dès que vous le rencontrez. Quand quelqu’un mentionne “agent memory”, vous savez que ça appartient au quatrième pilier. Quand un nouveau protocole sort, vous savez qu’il est dans le cinquième. Le cadre absorbe le nouveau vocabulaire sans se briser.

Je consulte encore régulièrement des termes. La différence, c’est que maintenant je sais sur quelle étagère ils appartiennent.