Context Engineering : la compétence qui a dévoré le prompt engineering
À mesure que les modèles sont devenus meilleurs pour suivre les instructions, la partie difficile s'est déplacée de la formulation du prompt vers l'assemblage du bon contexte. Ce qu'est le context engineering, ses briques de base, et pourquoi le minimal l'emporte sur le maximal.
Guillaume Rufenacht
Product Manager IA · Lisbonne
Demandez à un agent de voyage IA de réserver un hôtel à Paris et il vous réservera peut-être joyeusement une chambre à Paris, dans le Kentucky. Ce n’est pas un problème de prompt, c’est un problème de contexte. À mesure que les modèles sont devenus meilleurs pour suivre les instructions, la partie difficile de la construction avec eux s’est déplacée de la formulation du prompt vers l’assemblage du bon contexte autour de lui. Cette discipline, c’est le context engineering, et c’est là que se joue désormais l’essentiel du travail IA en production.
Voici ce que c’est, ce qui le compose, et la règle contre-intuitive qui l’empêche de se retourner contre vous, tirée de la façon dont je construis les pipelines LLM derrière Geonimo.
Key takeaways
- Le prompt engineering, c'est formuler l'instruction. Le context engineering, c'est assembler tout ce que le modèle voit : prompt, documents récupérés, mémoire et outils.
- Les briques de base sont la mémoire, l'état, la récupération (RAG) et les interfaces d'outils, avec un prompt rempli dynamiquement à l'exécution.
- En production, le prompt final est souvent surtout du contexte dynamique et seulement un peu d'instruction statique.
- Plus de contexte n'est pas mieux. Assemblez le contexte minimal suffisant et laissez le modèle récupérer le reste.
Prompt engineering vs context engineering
Le prompt engineering est l’art de formuler l’instruction elle-même : attribution d’un rôle, quelques exemples, chaîne de raisonnement, contraintes explicites. Il vous donne de meilleures questions. Le context engineering est la discipline au niveau système qui consiste à assembler par programme tout ce que le modèle voit pendant l’inférence, pour qu’il puisse plausiblement accomplir la tâche. Il vous donne de meilleurs systèmes. L’exemple parisien est tout l’enjeu : un contexte plus intelligent, une consultation du calendrier, la politique de voyage de l’entreprise sous forme de fichier, aurait évité à la fois la mauvaise ville et la chambre à 900 $, sans aucune formulation plus astucieuse.
Les briques de base
Le context engineering orchestre tout l’environnement autour du modèle. Les composants essentiels :
- Mémoire. Court terme (résumer les longues conversations pour rester dans la fenêtre) et long terme (un magasin vectoriel de préférences, d’historique, de schémas appris).
- État. Où vous en êtes dans un processus à plusieurs étapes : la réservation du vol a-t-elle réussi, quelle est l’heure d’arrivée, pour que l’agent ne perde pas le fil en cours de tâche.
- Récupération (RAG). Ne tirer que les sections pertinentes d’une source de connaissances, pas le document entier, via une recherche hybride sémantique et par mots-clés.
- Outils. Les interfaces qui permettent au modèle de réellement faire des choses, avec des descriptions qui précisent ce que fait chacune, quand l’utiliser et ses contraintes.
Le prompt engineering fait lui-même partie du context engineering : vous écrivez une instruction de base, puis vous injectez du contexte en direct à l’exécution, de sorte que le prompt final peut être composé à 80 % de contenu dynamique et à 20 % d’instruction statique. L’art, c’est la formulation ; le système, c’est tout ce qui l’entoure.
La partie contre-intuitive
Pourquoi c’est désormais le vrai travail
À mesure que les modèles s’améliorent, le prompting brut compte moins et le système autour du modèle compte davantage. La plupart des bugs du type « le modèle a halluciné » sont en réalité des bugs du type « nous l’avons entouré du mauvais contexte » : les mauvais documents, une mémoire périmée, un outil manquant. Bien gérer la mémoire, l’état, la récupération et les outils, c’est ce qui sépare une démo d’un système fiable, et cela s’associe directement au prompting comme discipline d’ingénierie, que j’aborde dans le guide de prompting Claude Code et avec les principes de simplicité dans construire des agents efficaces.
À retenir
Concevoir le contexte des systèmes LLM en production est au cœur de ce que je fais chez Geonimo. Découvrez comment je construis ou prenez contact.
Questions fréquentes
Quelle est la différence entre le prompt engineering et le context engineering ?
Le prompt engineering, c'est formuler l'instruction. Le context engineering est la discipline au niveau système qui consiste à assembler tout ce que le modèle voit (prompt, documents récupérés, mémoire et outils) pour qu'il puisse plausiblement accomplir la tâche.
Qu'est-ce qui entre dans le context engineering ?
La mémoire (court et long terme), l'état à travers les tâches en plusieurs étapes, la récupération (RAG qui ne renvoie que les sections pertinentes) et les interfaces d'outils avec des descriptions claires, plus le prompt lui-même, rempli dynamiquement à l'exécution.
Faut-il donner plus de contexte au modèle, ou moins ?
Assez, et pas plus. Assemblez le contexte minimal suffisant et laissez le modèle récupérer le reste. Surcharger le contexte revient à microgérer le modèle et dilue son attention.
Travailler avec moi
Vous voulez un système comme celui-ci pour votre pipeline ?
J'aide les équipes à faire passer l'IA d'un prototype malin à une production fiable : moteurs d'outbound, intelligence des leads et les pipelines LLM en dessous. Voyez ce que j'ai livré ou écrivez-moi.