Tout ce dont vous avez besoin pour vos agents : le Context Engineering

Oui, je sais, le titre est un peu cheesy. C’est un clin d'œil à l’article sur les Transformers qui a lancé toute cette ère agentique. Et non, le context engineering ne sauvera pas un produit mal défini. Mais après avoir développé une douzaine d’agents ces deux dernières années, j’ai appris que lorsqu’un agent ne fonctionne pas, ce n’est presque jamais à cause du modèle… mais à cause du contexte.

Je ne suis pas le seul à penser ça : on entend la même chose de la part des équipes de LangChain, Anthropic, Cognition, et à peu près tous ceux qui déploient des agents en production aujourd’hui.

L’écosystème des agents commence à mûrir. On est passé du simple chatbot sur un LLM à des systèmes bien plus complexes. En travaillant dans plusieurs domaines, j’ai vu les mêmes schémas revenir sans cesse : RAG, prompt engineering, appel d’outils, logique de contrôle.

À un moment, on réalise que derrière les termes à la mode, ce n’est pas juste comme du design système. C’EST du design système. C’est de l’ingénierie logicielle, mais avec les LLM comme nouveau type de composant d’exécution. Un agent, finalement, ce n’est qu’un système qui appelle des API de façon non déterministe. C’est ça, le cœur du sujet.

Alors, qu’est-ce qui fait qu’un agent réussit ou échoue ? Qu’est-ce qui détermine s’il accomplit sa tâche ou s’égare complètement ? C’est la qualité de son context engineering. Pas seulement des prompts intelligents, mais bien l’état informationnel complet qu’on construit pour que le modèle puisse raisonner efficacement.

C’est de ça dont il est question ici : pourquoi le context engineering est la base du design agentique — et comment le traiter comme une vraie discipline logicielle.

Qu'est-ce que le Context Engineering ?

On aime tous coller des étiquettes sur les choses. Une fois que c’est nommé, on peut commencer à y associer des idées. Sans nom, les concepts flottent sans ancrage. Et c’est un peu ce qui s’est passé avec cette pratique émergente.

Si vous avez déjà construit des agents, vous avez sûrement déjà été confronté à la nécessité de faire du context engineering. Prenez un simple chatbot de questions/réponses propulsé par un LLM. Que se passe-t-il lorsque la conversation dépasse la fenêtre de contexte ? Vous devez vous poser cette question : qu’est-ce qui est assez important pour être gardé dans le contexte pour que l’agent reste utile ?

Pendant longtemps, on n’avait même pas de nom clair pour cette pratique. Cela a changé quand Tobi Lütke, CEO de Shopify, a dit préférer le terme context engineering à prompt engineering. Selon lui, ça reflète mieux la réalité du métier : l’art de fournir au modèle tout ce dont il a besoin pour résoudre la tâche de manière crédible.

Ce commentaire a lancé une discussion plus large. Andrei Karpathy, figure de proue du monde agentique et créateur des termes comme LLM OS ou vibe coding, a proposé une définition particulièrement pertinente :

"Le context engineering, c’est l’art délicat et la science de remplir la fenêtre de contexte avec juste ce qu’il faut d’informations pour l’étape suivante."

En fin de compte, c’est bien cela qui détermine le succès d’un agent. Pas juste des prompts bien écrits — mais un environnement conçu pour permettre à l’intelligence d’émerger.

Quelle différence entre context engineering et prompt engineering ?

Même si les deux termes se ressemblent, le prompt engineering n’est en fait qu’un sous-ensemble du context engineering.

Le prompt engineering consiste à concevoir et structurer l’entrée fournie au modèle pour obtenir une réponse précise. Cela inclut :

• Le choix des mots et la clarté des instructions
• La structure des entrées/sorties
• L’usage d’exemples (comme le few-shot prompting)
• Les rôles système et utilisateur
• Le ton, le style, les contraintes

Le context engineering, lui, va beaucoup plus loin. Il englobe tout l’environnement informationnel autour de l’interaction avec le modèle, incluant notamment :

• Le RAG (Retrieval-Augmented Generation)
• La gestion de la mémoire à long terme
• La sélection et l’orchestration d’outils
• Et, bien sûr, le prompt engineering lui-même

En résumé, le prompt engineering est un outil dans la boîte à outils du context engineering.

‍

Un exemple concret : la compression

Parmi les exemples les plus intéressants de context engineering, il y en a qui ne reposent ni sur le RAG ni sur le prompting. Parlons plutôt d’un concept fondamental : la compression.

Imaginons un agent qui échange avec un humain sur plusieurs tours. À un moment, la fenêtre de contexte atteint sa limite. Que faire ?

• Option 1 : tronquer. On coupe les messages les plus anciens pour ne garder que les récents. Efficace, mais on perd du contexte potentiellement crucial.
• Option 2 : stocker l’historique dans une base d’embeddings, et récupérer ensuite les morceaux utiles. Pratique, mais on reste limité par la qualité de la recherche.
• Option 3 : résumer. On condense les échanges pour en garder une version allégée mais significative.

C’est ce que fait Claude, l’agent de code d’Anthropic. Il intègre un mécanisme de compression contextuelle appelé auto-compact. Lorsque la limite de contexte approche (95 %), un second LLM résume automatiquement l’historique. C’est une solution élégante, simple, et prête pour la production.

Les grands modèles du context engineering

En observant les pratiques actuelles, on peut identifier quatre grands modèles de context engineering, décrits notamment par l’équipe de LangChain :

Écriture (Write)

Stocker l’information hors du contexte immédiat — dans une mémoire longue, un scratchpad, etc. Tout ne doit pas rester dans le prompt, tant que c’est accessible à la demande.

Sélection (Select)

Choisir quoi inclure dans le contexte. C’est ici que le RAG intervient. Par exemple, si un agent a accès à une grande base d’outils, on peut filtrer ceux pertinents pour la tâche en cours, réduisant le bruit et gardant le modèle concentré.

Compression (Compress)

Réduire la taille du contexte sans perdre l’essentiel. Cela inclut le résumé, le découpage, l’abstraction… L’objectif : rester sous les limites tout en préservant la continuité.

Isolation (Isolate)

Isoler les responsabilités. Utile surtout dans les systèmes multi-agents, où chaque agent se concentre sur un domaine. On évite ainsi les pollutions croisées de contexte.

Une fois qu’on maîtrise ces schémas, on peut vraiment structurer son design agentique et appliquer ces techniques à des cas réels.

Personnellement, ce qui m’intéresse le plus, ce sont les agents capables de se remettre d’une erreur ou de gérer de l’information manquante sans polluer le contexte — comme dans le RAG correctif. Ce champ est encore plein d’opportunités créatives.

Quand investir dans le context engineering ?

Comme pour toute décision d’architecture : ça dépend. Pour un chatbot simple à tour unique, un prompt template suffit. Mais dès que vous avez besoin de :

• Plans multi-étapes (≥ 10 tours)
• Choix d’outils parmi de nombreuses APIs
• Mémoire personnalisée entre sessions
• Optimisation du coût ou de la latence à grande échelle

… le context engineering vaut vraiment l’investissement.

Le défi : la mesure. On peut suivre les tokens et la latence, mais évaluer le succès global d’une tâche reste flou. Souvent, c’est juste un vibe-check, comme dirait Karpathy.

Et attention, les problèmes de contexte ne sont pas toujours visibles. Parfois, ce n’est pas une question de taille, mais de cohérence. Des infos contradictoires peuvent déstabiliser le modèle, ou un petit hallucination bug peut s’infiltrer tôt dans la chaîne et tout fausser discrètement. Ces échecs ne se repèrent pas facilement — ils se sentent. C’est pourquoi le context engineering est si crucial.

Une petite checklist pratique

Quand on construit des agents susceptibles de nécessiter du context engineering, voici quelques rappels utiles :

• Définir le contrat — Que doit-on absolument inclure à chaque étape ?
• Automatiser la sélection — Via des embeddings ou des règles.
• Définir les seuils de compression — Résumer de manière proactive avant d’atteindre la limite.
• Tout journaliser — Historique brut, sélectionné, compressé… tout.
• Versionner les prompts et les mémoires — Comme du code. On révise et on peut revenir en arrière.

Conclusion

Certains en ont peut-être marre de tous ces nouveaux termes, mais moi j’adore. Nommer les choses permet de cristalliser les idées. Ça crée un langage commun et ça fait avancer l’écosystème. C’est comme ça que l’innovation s’accélère.

C’est un moment passionnant pour être développeur, et encore plus pour construire des agents.

Rien de tout cela n’est entièrement nouveau. Mais ce qui est excitant, c’est que nous avons désormais un cadre pour le formaliser. On ne fait plus du prompt hacking dans notre coin — on conçoit des systèmes intelligents.

Vous explorez les systèmes agentiques ou cherchez à repousser les limites des LLM ? Écrivez-nous. Chez Osedea, on aide les équipes à transformer leurs idées en solutions concrètes et prêtes pour la production.