Ingénierie des prompts, du contexte, des harnais et des boucles : les quatre couches d’un agent IA
L’ingénierie des prompts et l’ingénierie du contexte couvrent deux des quatre couches. L’ingénierie des harness et des loop, un exemple de triage sur GitHub, ainsi que l’ordre de compilation en font partie également.
Sources: Prompt, context, harness, loop: the four layers of engineering an AI agent
Au milieu de 2025, le PDG de Shopify, Tobi Lütke, a écrit que la véritable compétence dans le travail avec les LLM n’était pas du tout l’ingénierie des prompts, mais plutôt la fourniture de suffisamment de contexte pour que la tâche puisse être résolue de manière plausible. Andrej Karpathy était d’accord, qualifiant cela d’art qui consiste à placer précisément les informations appropriées dans la fenêtre de contexte en fonction de ce que le modèle fera ensuite. Peu de temps après, l’« ingénierie du contexte » a remplacé l’« ingénierie des prompts » dans la plupart des discussions sérieuses sur l’utilisation des LLM.
Un an plus tard, les équipes qui développent des agents de codage autonomes, des bots de tri des problèmes et des pipelines de déploiement auto-réparateurs continuent de se heurter au même obstacle. L’ingénierie du contexte s’est avérée n’être qu’une partie d’un problème en quatre couches. De la plus étroite à la plus large, ces couches sont le prompt, le contexte, l’outil d’exploitation et le cycle, et chacune englobe celle qui se trouve à l’intérieur. Les deux couches extérieures, l’ingénierie de l’outil d’exploitation et l’ingénierie du cycle, reçoivent le moins d’attention, ce qui est étrange, car c’est là que réside désormais la majeure partie des avantages.
Considérez cela comme quatre questions : comment la demande est-elle formulée ? C’est le prompt. Que sait déjà le modèle au démarrage ? C’est le contexte. Que peut-il vraiment faire une fois en fonctionnement ? C’est l’outil d’exploitation. Et quand, et avec quelle fréquence, quelqu’un l’appelle-t-il ? C’est le cycle. Aujourd’hui, la majeure partie des véritables avantages réside dans le cycle, une couche qui n’avait même pas de nom il y a un an.
Ce qui suit est un cadre fonctionnel permettant de distinguer les différentes couches, ainsi qu’une séquence d’assemblage. Il part du principe que vous avez déjà effectué des appels à des outils ou des fonctions via une API de LLM. Si ce n’est pas le cas, commencez par là.
Une logique se dégage dans la pratique qui explique l’utilité de ce cadre : lorsque la sortie d’un agent est décevante, la solution ne réside presque jamais dans le prompt ; elle se trouve presque toujours à un niveau supérieur.
Couche 1 : le prompt, ou ce que vous dites
L’ingénierie des prompts constitue la couche la plus restreinte et concerne une seule chose : la manière dont une instruction est formulée pour le modèle.
Exemples : la façon de formuler un prompt système, la présentation d’un échantillon de type few-shot, la demande de raisonnement étape par étape ou de réflexion approfondie, ainsi que la décision de savoir si la réponse doit être fournie sous forme de JSON ou de texte libre. Il s’agit de l’art d’écrire un message permettant au modèle d’effectuer ce que vous souhaitez lors de sa prochaine itération.
Le travail est réel. La précision pour une même tâche peut varier énormément entre une instruction vague et une instruction précise. Prenons un agent de tri pour un projet GitHub, qui servira d’exemple concret. Un prompt faible ressemble à ceci :
Look at this GitHub issue and label it.
Et une version précise :
You are a triage agent for project X. For each issue, output JSON with:
component (one of the values in the taxonomy provided in context)
severity (critical | high | medium | low)
team (the owning team from the on-call table provided in context)
Base severity only on user-facing impact stated in the issue, not on your
own guess about difficulty. If the component is ambiguous, set
"component": "unknown" rather than guessing.
Le modèle, les outils et tout le reste sont identiques, pourtant le deuxième prompt produit des résultats structurés et fiables. Cependant, il faut prendre en compte ce qui est donné pour acquis : il s’exécute en une seule étape au cours d’une seule requête. Il part du principe que la taxonomie ainsi que le tableau des agents sont déjà chargés, que les outils existent, et qu’un autre élément décide du moment où le modèle est invoqué.
La plupart des tutoriels s’arrêtent à ce stade. La plupart des systèmes d’agents en production ne font que commencer à travailler sur ce sujet.
Niveau 2 : le contexte, ou ce que le modèle sait
L’ingénierie du contexte englobe tout ce qui entre dans le champ de vision du modèle avant qu’il ne traite votre prompt. Elle précède le traitement du prompt. Même un prompt parfait produit des résultats erronés lorsque le contexte est incorrect.
Cela inclut quels documents, fichiers de code ou enregistrements de base de données sont récupérés et injectés, quels schémas d’outils sont chargés et lesquels sont conservés pour économiser des jetons, quelle partie de l’historique de conversation est conservée par rapport à ce qui est résumé ou supprimé, ainsi que ce que les instructions du système indiquent au sujet du rôle et des limites du modèle.
Drew Breunig a listé en 2025 les manières dont le contexte échoue. Le « context poisoning » se produit lorsque des hallucinations pénètrent dans le contexte et y sont constamment référencées. La « distraction contextuelle » survient lorsque la longueur excessive du contexte pousse le modèle à s’y appuyer au détriment de ce qu’il a appris pendant l’entraînement. La « confusion contextuelle » se produit lorsque du matériel irrélevant diminue la qualité des résultats. Le « conflit contextuel » apparaît lorsque de nouveaux outils ou faits ajoutés contredisent les instructions existantes.
Le contexte coûte également de l’argent, et son encodage influence le montant total. TOON, un encodage compact du modèle de données JSON, utiliserait, selon les données de son propre ensemble de tests de mi-2026, environ 42,6 % de tokens en moins que JSON, avec une précision de récupération similaire (72,2 % contre 71,4 %). Les économies dépendent de la structure des données : pour des données tabulaires simples, la réduction atteint près de 59 %, tandis que pour des données imbriquées, elle tombe autour de 33 % ; le format CSV pur peut même surpasser les deux autres lorsque les données sont entièrement tabulaires. Il s’agit des chiffres fournis par le projet lui-même, il convient donc de les vérifier sur vos propres données. En résumé, un même ensemble de données, présenté sous trois formats différents, présente des différences en termes de coût et de fiabilité de lecture. L’ingénierie du contexte signifie choisir non seulement ce qui doit être inclus, mais aussi comment le coder.
Une courte illustration montre comment cela peut mal se passer. Imaginez un agent de génération d’articles qui produit constamment des résultats génériques. Deux jours sont passés à réécrire le prompt, à ajouter des exemples et des contraintes, ainsi qu’à affiner la définition du rôle, sans aucun résultat. Le prompt n’a jamais été le problème. Trente schémas d’outils sont chargés au préalable dans le contexte, noyant ainsi les instructions pertinentes. Le passage à un chargement différé, où une définition n’apparaît que lorsque l’agent la demande, améliore la qualité sans modifier un seul mot du prompt. Deux jours ont été perdus sur le mauvais niveau.
Si l’ingénierie des prompts consiste à choisir ses mots, l’ingénierie du contexte consiste à déterminer ce que le modèle peut voir avant même que vous ne parliez.
Niveau 3 : l’environnement d’exécution, ou ce que le modèle peut faire
Cet environnement d’exécution est le cadre autour du modèle : tout ce à quoi il peut accéder et tout ce qui interagit avec lui.
Les directives bien connues d’Anthropic concernant la création d’agents efficaces ont introduit l’idée d’une interface agent-ordinateur, conçue délibérément de manière parallèle à l’interface homme-ordinateur. Selon elles, il convient d’investir autant d’efforts dans la conception de la manière dont un agent interagit avec des outils que l’industrie en investit pour la manière dont les humains utilisent des logiciels.
Voici une définition simplifiée d’outil issue de l’exemple de triage :
{
"name": "apply_label",
"description": "Apply a label to a GitHub issue. Only use after reading the issue body and checking the component taxonomy.",
"parameters": {
"type": "object",
"properties": {
"issue_number": { "type": "integer" },
"labels": { "type": "array", "items": { "type": "string" } }
},
"required": ["issue_number", "labels"]
}
}
Le champ description assure une fonction contextuelle. Il détermine quand le modèle doit utiliser l’outil, et non seulement quels arguments il doit transmettre. Mais le schéma ne représente que la moitié du système d’encadrement.
L’autre moitié réside dans l’orchestrateur, qui enveloppe l’outil dans des éléments que le modèle ne voit jamais. Une porte d’approbation décide si apply_label s’exécute automatiquement ou est mis en file d’attente pour être traité par une personne. Une limite de fréquence, par exemple 60 enregistrements de labels par heure, empêche un boucle infinie de spammer le répertoire. Une frontière de sandbox limite ce que l’outil peut modifier. De tels enveloppements modifient le comportement sans aucun changement dans l’instruction du système.
Un système d’encadrement comprend également :
- Système de fichiers. Les fichiers que le modèle peut ouvrir, modifier, créer ou supprimer.
- Mémoire. La manière dont les informations sont stockées et récupérées au fil des interactions, comme les journaux de correction, les décisions antérieures et les conventions du projet.
- Retour d’information. Le mécanisme par lequel les résultats, les messages d’erreur et l’état de l’environnement parviennent à l’étape suivante.
- Limites de sécurité. Permissions, isolation et contrôles d’approbation.
Donnez des outils solides à une instruction moyenne, et elle surpassera généralement une instruction brillante mais dépourvue d’outils. Un agent qui ne peut pas ouvrir le fichier dont il a besoin ne bénéficiera en rien d’une formulation améliorée. Utilisez d’abord les outils.
Niveau 4 : la boucle, ou ce qui fait d’un agent un agent
L’ingénierie des boucles est le mécanisme qui rend un agent autonome. Il agit, observe le résultat, décide de ce qu’il doit faire ensuite et continue jusqu’à ce qu’un objectif soit atteint ou qu’une condition d’arrêt soit déclenchée, sans aucune intervention humaine à chaque étape. Ce niveau transforme un chatbot utilisant des outils en un système capable de résoudre des problèmes seul.
Voici la même idée en pseudocode. Il s’agit d’une illustration et non d’un code exécutable : des fonctions d’aide comme model.decide et execute sont omises.
def agent_loop(goal, max_iterations=10):
context = gather_initial_context(goal)
consecutive_errors = 0
for i in range(max_iterations):
action = model.decide(context, goal)
if action.type == "done":
return action.result
result = execute(action)
if result.error:
consecutive_errors += 1
if consecutive_errors >= 3:
# stuck: same approach keeps failing, decompose differently
context.add("Previous approach failed 3 times. Try a different strategy.")
consecutive_errors = 0
else:
consecutive_errors = 0
context.add(result)
return escalate_to_human(context)
Quelques lignes contiennent les décisions importantes : quand s’arrêter, quand changer de stratégie, quand abandonner. OpenAI a intégré ce principe dans un produit en ajoutant une commande /goal à Codex CLI en avril 2026. Vous définissez un objectif, et le système itère jusqu’à ce qu’il juge l’objectif atteint ou qu’il épuise son budget de tokens.
Un boucle naïve réessaie indéfiniment jusqu’à ce que quelque chose fonctionne. Une boucle bien conçue se rend compte qu’elle est bloquée, décompose le problème différemment, sollicite une intervention humaine ou abandonne une approche inefficace. Le concepteur Matt Webb a déclaré en mars 2026 qu’un agent doté d’un problème et d’une boucle while finira par le résoudre. C’est le qualificatif « finira par » qui révèle l’importance de l’ingénierie : budgets de tentatives, retards après des échecs répétés, ainsi que des stratégies de décomposition en cas d’impasse lors d’une seule tentative.
C’est pourquoi cette couche représente le changement le plus majeur en termes de pouvoir. Avec l’ingénierie des prompts, c’est une personne qui écrit chaque instruction. Avec l’ingénierie du contexte, c’est une personne qui décide de ce que le modèle voit à chaque appel. Avec l’ingénierie des outils, c’est une personne qui crée les outils une seule fois et que le modèle réutilise indéfiniment. L’ingénierie des boucles diffère par nature : c’est une personne qui conçoit un système capable de solliciter le modèle, d’évaluer le résultat et de le solliciter à nouveau, sans qu’aucune personne ne soit présente. Le contrôle passe de celui qui donne les instructions à l’agent à celui qui a conçu le système chargé de ces instructions.
Jon Udell a proposé, à la mi-2026, une formulation intéressante à retenir : il n’aime pas l’expression « humain dans la boucle » car elle attribue l’autorité aux machines, alors que c’est en réalité toujours notre boucle, et nous recrutons désormais des agents pour rejoindre l’équipe.
Toutes les quatre couches sur un seul agent : le tri des problèmes GitHub
Imaginez un agent qui traite de nouvelles demandes sur GitHub pour un projet open source de taille moyenne : il attribue des étiquettes au composant, évalue son niveau de gravité et l’envoie à l’équipe appropriée.
- Instruction. L’instruction du système lui indique de trouver le composant concerné, d’évaluer son niveau de gravité de critique à faible, d’attribuer l’équipe correcte et de répondre sous forme de JSON structuré.
- Contexte. Pour chaque décision, le système fournit le titre et le corps du message, les cinq derniers commentaires, la taxonomie des composants (un fichier YAML mis à jour tous les trois mois), des problèmes similaires antérieurs avec leurs étiquettes (obtenus par recherche vectorielle à titre d’exemples), ainsi que l’agent de garde.
Tous les 100 cas, le système compare sa précision avec les corrections effectuées par des humains et ajuste ses seuils. Dans un système similaire, le seuil de confiance aurait dû commencer à 0,85 et non à 0,7 comme on l’imaginait, car les étiquettes incorrectes entraînaient plus de travail pour les humains que celles manquantes. Ce type de calibration fait partie de l’ingénierie des boucles : on ne peut la déterminer qu’en faisant fonctionner le système et en observant ses erreurs au fil du temps.
Si l’on enlève n’importe quel élément, le système échoue différemment. Sans indication, le format de sortie est aléatoire. Sans contexte, des noms de composants sont inventés. Sans outils adaptés, il peut déterminer quoi faire mais ne peut pas étiqueter ou rechercher. Sans boucle, on se retrouve avec un assistant qui neagit que lorsque quelqu’un tape « trier ce cas » dans une fenêtre de chat, un par un.
D’où vient le vocabulaire
Le terme « prompt engineering » date de 2022. Riley Goodside a proposé de le diviser en context engineering et prompt programming dès 2023, mais ce vocabulaire n’a vraiment pris racine qu’après que Lütke et Karpathy aient utilisé l’expression « context engineering » en juin 2025, et que Simon Willison ait expliqué pourquoi elle était plus appropriée.
Les termes « Harness » et « scaffolding » sont entrés dans l’usage courant grâce aux travaux d’Anthropic sur des agents efficaces, qui ont formalisé l’interface agent-ordinateur et considéré la conception d’outils comme une discipline d’ingénierie à part entière.
Le concept d’ingénierie de boucle est le plus récent des quatre, et personne ne l’a inventé. Il est né de la convergence de plusieurs initiatives : la boucle axée sur des objectifs développée par OpenAI dans Codex, la distinction faite par Anthropic entre flux de travail (chemins fixes) et agents (boucles guidées par le modèle), l’évolution de LangChain allant du routeur à la machine d’état en passant par l’agent autonome, ainsi que l’habitude croissante de faire en sorte que l’humain conçoive la boucle sans intervenir dans ses étapes individuelles.
Cette séparation en quatre couches est une synthèse de ces utilisations convergentes et non une norme du secteur. Néanmoins, donner un nom aux couches accélère le diagnostic. Se demander si le problème concerne le prompt, le contexte, le système de gestion ou la boucle permet de réduire immédiatement le champ de recherche.
Où investir en premier
Les couches ont été énumérées du plus restreint au plus large, mais on les construit en partant du plus large, ou plutôt en commençant par le système de gestion. Pour un premier agent de codage autonome, l’ordre est le suivant.
- Harnais. Il doit permettre la lecture et l’écriture de fichiers, l’accès au shell, ainsi que la possibilité d’exécuter des tests et des commandes Git. Un agent non codant reçoit à la place des appels API, des requêtes de base de données ou des messages ; l’idée reste identique.
- Boucle. Même une boucle rudimentaire est utile : exécuter, vérifier si les tests passent, retourner une erreur en cas d’échec, puis s’arrêter après trois tentatives ou en cas de succès. Cela seul apporte déjà la majeure partie des avantages de l’autonomie.
- Contexte. Après avoir observé l’agent fonctionner dans sa boucle, on peut déterminer ce qui lui manque, que ce soit du code, des erreurs antérieures ou des conventions de projet. Deviner à l’avance gaspille généralement du temps.
- Indications. Avec un harnais et une boucle fonctionnels, les indications nécessaires sont généralement brèves et simples. L’aspect technique complexe a déjà été traité ailleurs à ce stade.
Il y a une exception. Si l’agent doit produire un résultat précisément formaté, comme du JSON structuré pour une API ou des conventions Markdown spécifiques, l’élaboration des instructions est cruciale dès le début, car il est difficile de corriger le format en cours d’exécution. Il s’agit d’un cas particulier, et non de la norme.
Les novices inversent généralement cette séquence : des semaines sont consacrées à des instructions système complexes, alors que l’agent ne dispose pas encore d’outils, pas de boucle et que des fichiers inappropriés figurent dans son contexte.
Passer de l’élaboration des instructions à l’ingénierie du contexte revient à admettre que le matériel fourni au modèle compte plus que la formulation de la demande. Passer ensuite à l’ingénierie des boucles et des outils revient à reconnaître encore plus : celui qui construit le système entourant le modèle détient plus de pouvoir que celui qui interagit avec lui.
Lectures complémentaires
- L’ingénierie de contexte agent : un guide pas à pas pour les ingénieurs en apprentissage automatique : Comment concevoir ce que voit un agent LLM à chaque étape – récupération, contexte structuré, mémoire, compression et évaluation – à l’aide d’un exemple d’agent de débogage en apprentissage automatique.
- De zéro-shot à auto-consistance : une échelle pratique des techniques de prompting : Comment choisir entre les approches zéro-shot, few-shot, de décomposition, les boucles de critique et les prompts de raisonnement, à l’aide d’un exemple de bot de soutien, ainsi que les moments où il est préférable de recourir à du code pur.