Série en 5 épisodes — Épisode 1/5

Il y a trois ans, savoir « parler » à un modèle était une compétence rare et un peu magique. On s’échangeait des captures d’écran de prompts qui marchaient, on se refilait des tournures comme des recettes de cuisine. Andrej Karpathy a résumé l’époque d’une formule devenue culte : le langage de programmation le plus en vogue, c’était l’anglais.

Aujourd’hui, plus personne de sérieux ne se présente comme prompt engineer. Le mot n’a pas disparu, mais il a rétréci. Il désigne désormais une petite partie d’un travail beaucoup plus large. Ce glissement de vocabulaire raconte une histoire précise sur la façon dont on construit des systèmes à base de LLM.

Cette histoire tient en trois mots : prompt, context, harness. Trois disciplines, trois questions, apparues dans cet ordre. La bonne nouvelle, c’est qu’aucune n’a tué la précédente. La mauvaise, c’est que beaucoup d’équipes croient faire du context engineering alors qu’elles bricolent encore des prompts, et parlent de harness sans en avoir jamais construit un.

Posons les définitions proprement. Elles structurent les quatre épisodes suivants.

Le prompt : comment je formule ma demande

Le prompt engineering, c’est l’art de rédiger l’instruction. Quelle tournure, quel exemple, quel format de sortie, quelle contrainte. On travaille à l’intérieur d’une seule requête et on l’optimise pour obtenir la meilleure réponse possible.

C’est né avec l’euphorie GPT-3, et ça reste utile. Un prompt mal rédigé donne un mauvais résultat, même avec le meilleur modèle du monde. Mais le prompt a une limite structurelle : il n’agit que sur ce que vous écrivez, pas sur ce que le modèle a réellement sous les yeux au moment de répondre. Vous pouvez ciseler l’instruction parfaite. Si elle est noyée sous 12 000 tokens d’historique inutile et trois documents mal formatés, elle ne pèsera rien.

Le prompt engineering optimise une interaction. Il ne dit rien du reste.

Le context : ce que le modèle doit voir

C’est précisément « le reste » que le context engineering prend en charge.

En juin 2025, Karpathy relance le débat : dans toute application LLM sérieuse, la vraie compétence n’est plus le prompt mais le context. Tobi Lütke, le patron de Shopify, embraye en le définissant comme l’art de fournir au modèle tout ce qu’il lui faut pour que la tâche devienne simplement résoluble. Simon Willison ajoute la dimension d’assemblage : réunir volontairement le system prompt, les documents récupérés, l’historique et les sorties d’outils en un ensemble cohérent. Anthropic en donne une formulation d’ingénieur : quelle configuration de tokens a le plus de chances de produire le comportement voulu.

Là où le prompt demande « comment je formule ? », le context demande « de quoi le modèle a-t-il besoin, maintenant, sous les yeux ? ». On passe de la rédaction à l’architecture de l’information. Le context window devient une ressource finie à gérer, avec ses trois façons d’échouer : trop peu d’information et le modèle hallucine, trop d’information et il se noie, une information contradictoire et il se perd.

Gartner a résumé le basculement sans nuance : le context est in, le prompt est out. C’est excessif, mais la direction est claire. Le prompt engineering était un artisanat. Le context engineering est de l’ingénierie système appliquée aux LLM.

Le harness : le système qui fait tourner la boucle

Puis 2026 est arrivé, avec un troisième mot.

En février, Mitchell Hashimoto met un nom sur une chose que les praticiens construisaient sans la nommer : l’agent harness. Le harness, c’est tout ce qui entoure le modèle sans être le modèle. L’exécution des outils, la mémoire, la gestion du context à chaque étape, la persistance de l’état entre les sessions, les règles de vérification, l’orchestration. Vivek Trivedy, chez LangChain, en donne la formule la plus tranchante : si vous n’êtes pas le modèle, vous êtes le harness.

L’idée devient concrète quelques semaines plus tard. Quand le code source de Claude Code fuite, fin mars, on découvre une base d’environ 512 000 lignes de TypeScript où l’interaction avec le modèle lui-même ne représente qu’une fraction minuscule. Tout le reste, c’est le harness. Le LLM est la plus petite pièce du système.

Le harness engineering repose sur un principe qui change la façon de travailler : chaque échec d’un agent n’est pas un prompt à réessayer, c’est un problème système à corriger une bonne fois. Vous ne relancez pas en priant. Vous réparez la mécanique. Et comme le harness est indépendant du modèle, vous branchez un modèle plus récent sans tout réécrire. Le modèle devient un composant interchangeable.

Pourquoi les trois comptent encore

On pourrait croire à un remplacement en cascade, chaque discipline enterrant la précédente. C’est faux, et c’est le point le plus important de cet épisode.

Regardez le schéma : le harness contient le context, qui contient le prompt, qui entoure le modèle. Un mauvais prompt sabote une bonne stratégie de context. Un context mal géré fait dérailler le meilleur harness. Les trois s’empilent, ils ne se remplacent pas.

Ce qui change, c’est l’endroit où se joue votre problème du moment.

• Vous générez un e-mail bien tourné en une seule fois ? Problème de prompt.
• Votre assistant répond à côté parce qu’il ne voit pas les bons documents ? Problème de context.
• Votre agent tourne sur vingt étapes, appelle des outils, perd le fil au bout de dix minutes ? Problème de harness.

Diagnostiquer correctement le niveau de la panne, c’est déjà la moitié du travail. C’est aussi une grille de maturité en creux : la plupart des équipes qui se disent avancées gèrent encore du context sur un seul agent en production. Ce n’est pas un reproche, juste un état des lieux honnête, et le point de départ de tout le reste.

La suite

Dans les quatre prochains épisodes, on descend dans chaque couche. L’épisode 2 revient sur le prompt engineering : ce qu’il était vraiment, les techniques qui tiennent encore la route en 2026, et le mur contre lequel il finit par buter. L’épisode 3 attaque le context engineering et sa gestion du context window comme ressource rare. L’épisode 4 démonte un harness pièce par pièce, avec Claude Code comme cas d’école. L’épisode 5 assemble tout ça en un modèle de maturité utilisable au bureau.

Une chose à retenir d’ici là. Quand quelque chose ne marche pas avec votre système LLM, ne demandez pas d’abord « quel meilleur prompt écrire ». Demandez « à quelle couche se situe le problème ». C’est déjà une autre façon de penser.

Ressources pratiques

• Anthropic, Effective context engineering for AI agents : la référence sur la gestion du context comme ressource finie. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Philipp Schmid, The New Skill in AI is Not Prompting, It’s Context Engineering : le billet qui a popularisé la distinction. https://www.philschmid.de/context-engineering
• Firecrawl, What is an agent harness : une bonne introduction au concept de harness et à son origine. https://www.firecrawl.dev/blog/what-is-an-agent-harness
• Schulhoff et al., The Prompt Report : le panorama académique le plus complet des techniques de prompting (58 techniques recensées). https://arxiv.org/abs/2406.06608