Retour au blog

Après le context engineering : ce qui arrive change tout

$date: |read: 8 min|cat: Apprentissage
agentsanalyse
Après le context engineering : ce qui arrive change tout

#Le prompt engineering est mort — mais pas comme tu le crois

Pendant deux ans, le prompt engineering a été la compétence IA. Trouver la bonne formulation, ajouter "pense étape par étape", structurer ses instructions en sections — c'était la clé pour obtenir de bons résultats d'un LLM.

Puis les modèles sont devenus meilleurs. Les techniques qui nécessitaient un savoir-faire minutieux sont aujourd'hui intégrées directement dans les modèles. Et surtout, les systèmes IA ne sont plus des machines question-réponse : ce sont des agents multi-étapes avec des outils, de la mémoire et des données externes.

Le chiffre qui a enterré le débat vient d'Andrew Ng : GPT-3.5, un modèle plus ancien, atteint 95.1% de précision sur un benchmark de code quand il est utilisé dans un workflow agentique multi-étapes. GPT-4 avec un prompt unique parfaitement optimisé ? 67%.

Le gain de performance entre GPT-3.5 et GPT-4 est éclipsé par le gain apporté par un workflow agentique. Le goulot d'étranglement n'est plus la qualité du prompt — c'est l'information que le modèle a à sa disposition.

#Le context engineering : la vraie compétence

Le terme a été formalisé par Andrej Karpathy (ex-OpenAI et Tesla AI) : le context engineering est "l'art et la science de remplir la fenêtre de contexte avec exactement la bonne information pour l'étape suivante".

Tobi Lütke, CEO de Shopify, l'a popularisé mi-2025 en expliquant que le terme décrit bien mieux la compétence réelle : "l'art de fournir tout le contexte nécessaire pour que la tâche soit plausiblement résolvable par le LLM".

La différence avec le prompt engineering est fondamentale. Le prompt, c'est l'instruction que tu écris. Le contexte, c'est tout ce que le modèle voit au moment de l'inférence :

  • Le system prompt et le persona
  • L'historique de conversation
  • Les documents récupérés dynamiquement (RAG)
  • Les définitions d'outils disponibles
  • La mémoire longue durée entre sessions
  • Les résultats d'APIs externes
  • Les traces d'erreurs des étapes précédentes

La plupart des échecs d'agents ne sont pas des échecs du modèle. Ce sont des échecs de contexte — le modèle avait la mauvaise information, trop d'information non pertinente, ou il lui manquait une donnée cruciale.

#Pourquoi le context engineering atteint ses limites

Si le context engineering résout le bon problème, trois forces le poussent déjà vers une évolution.

#Le passage à l'échelle

Assembler manuellement le contexte pour chaque tâche ne tient pas la route quand le système grandit. Chaque nouvelle source de données, chaque nouvelle intégration nécessite qu'un développeur mette à jour la curation du contexte. La charge de maintenance devient insoutenable.

#Le context rot

Les LLM ont un budget d'attention fini. Même avec des fenêtres de 200 000 tokens, la qualité des réponses se dégrade sur l'information enfouie au milieu du contexte — c'est le problème bien documenté du "lost in the middle". Plus de contexte ne veut pas dire meilleur contexte.

#Le contexte statique vs. dynamique

Les premiers systèmes de context engineering utilisaient des templates statiques. Mais les agents en production ont besoin de contextes qui s'adaptent dynamiquement — en assemblant la bonne information juste-à-temps pour chaque étape d'une tâche multi-étapes, pas en chargeant tout d'avance.

#Ce qui vient après : trois paradigmes émergents

La question n'est plus "comment mieux rédiger ses prompts" ni même "comment mieux structurer son contexte". C'est : comment automatiser la gestion du contexte elle-même ?

Trois approches se dessinent.

#L'architecture de workflows automatisée

Plutôt que de curer le contexte manuellement, le code génère et gère le contexte automatiquement en fonction de la structure et de l'état du système.

Le principe : décomposer chaque tâche en étapes atomiques avec des schémas d'entrée/sortie clairs. Le code introspecte les bases de données et la documentation pour auto-générer ces schémas. À chaque étape, seule l'information pertinente est injectée dans le contexte — pas tout le projet d'un coup.

Le développeur passe de "curateur de contexte" à architecte de workflows. Il conçoit les flux, pas les prompts.

C'est l'approche défendue par des praticiens comme Serge Liatko (communauté OpenAI) et Andrew Ng : l'ingénieur conçoit le système qui alimente le modèle, au lieu de nourrir le modèle à la main.

#Le context engineering agentique (ACE)

Un papier accepté à ICLR 2026 propose une idée plus radicale : laisser les agents améliorer leur propre contexte à travers leur exécution.

Le framework ACE utilise trois sous-agents spécialisés :

AgentRôle
GeneratorExécute la tâche avec le contexte actuel
ReflectorAnalyse ce qui a fonctionné et ce qui a échoué après chaque exécution
CuratorMet à jour le playbook de contexte en préservant les connaissances du domaine

Après chaque exécution, le Reflector évalue les résultats. Le Curator met à jour le "playbook" — le document de contexte — de manière incrémentale. Le playbook s'améliore à chaque utilisation, sans intervention humaine.

Les résultats sont significatifs : +10.6% de performance par rapport aux baselines, en utilisant un modèle open source plus petit qu'un système IBM de production.

C'est du contexte qui s'améliore tout seul par l'usage. Plus l'agent travaille, meilleur devient son contexte — sans que personne n'édite manuellement un fichier de configuration.

#La discipline complète : l'ingénierie agentique

La troisième vision est la plus englobante. Le context engineering ne disparaît pas — il devient un module parmi cinq dans une discipline d'ingénierie plus large :

CoucheCe qu'elle couvre
Context EngineeringLa bonne information au bon moment
Workflow EngineeringComportement multi-étapes fiable des agents
Model EngineeringSélection et calibration du bon modèle par tâche
AgenticOpsTests, monitoring et sécurité des agents en production
Agentic UXTransparence et contrôle des actions de l'IA pour l'utilisateur

Cette approche reconnaît que le contexte seul ne suffit pas. Un agent en production a besoin de workflows fiables, du bon modèle pour chaque sous-tâche, d'une infrastructure de monitoring, et d'une interface qui rend ses actions compréhensibles.

#L'idée la plus spéculative : la fin de la fenêtre de contexte

L'équipe de Manus AI (un agent de production chinois) pousse la réflexion encore plus loin. Leur hypothèse : les modèles basés sur les Transformers pourraient ne pas être l'architecture finale pour les agents.

Les State Space Models (SSM) gèrent les contextes séquentiels longs bien plus efficacement que les Transformers. Combinés avec le système de fichiers comme mémoire persistante illimitée — plutôt que de tout compresser dans la fenêtre de contexte — ils pourraient représenter le prochain changement architectural.

En attendant, Manus AI optimise déjà dans cette direction : leur métrique clé est le taux de hit du KV-cache. En maintenant des préfixes stables et des structures de contexte en append-only, ils réutilisent les calculs entre les appels et réduisent les coûts par un facteur 10.

#Ce que ça change concrètement pour toi

Si tu construis des systèmes avec des LLM aujourd'hui, voici les implications pratiques.

Arrête d'optimiser tes prompts mot par mot. Ce n'est plus là que se joue la performance. Concentre-toi sur ce que le modèle voit — les données qu'il reçoit, les outils qu'il a, la mémoire qu'il conserve entre les sessions.

Pense en workflows, pas en appels isolés. Un agent qui décompose une tâche en étapes, avec le bon contexte à chaque étape, battra toujours un seul appel avec un prompt parfait.

Conçois tes contextes pour qu'ils s'améliorent. Même sans implémenter un framework ACE complet, tu peux loguer les succès et les échecs de tes agents, puis utiliser ces traces pour enrichir leur contexte initial.

Commence petit. Tu n'as pas besoin d'une architecture en cinq couches pour bénéficier de ces idées. Un CLAUDE.md bien structuré, des règles modulaires chargées selon le contexte, et une boucle de feedback sur les résultats — c'est déjà du context engineering qui tend vers l'automatisation.

Le vrai virage, ce n'est pas un outil ou un framework spécifique. C'est un changement de mentalité : passer de "comment je formule ma question" à "comment je conçois le système qui fournit l'information au modèle".

#Pour aller plus loin