Context engineering : la prise de conscience croissante de l’importance du contexte dans l’IA

Pourquoi le contexte est soudainement au cœur des débats. Jusqu’à récemment, concevoir des applications basées sur l’IA revenait souvent à peaufiner la formulation des prompts ou à ajuster les modèles. Mais à mesure que les organisations déploient des agents IA de plus en plus complexes (gestion des demandes clients, automatisation de workflows, synthèse de bases de connaissances volumineuses) un nouveau goulot d’étranglement est apparu : le contexte.

Prenons un assistant virtuel chargé de réserver des voyages, de répondre à des questions RH et de résumer des politiques internes. Même avec un modèle de langage de pointe, il peut se retrouver en difficulté : il oublie des informations clés, invente des réponses ou ne saisit pas les subtilités des demandes. Le problème ? Ce n’est pas le modèle, mais l’information à laquelle il a accès : incomplète, non pertinente ou mal structurée.

C’est tout l’enjeu du context engineering : garantir que les systèmes IA disposent des bonnes informations, au bon format, au bon moment. À mesure que le secteur prend conscience de cet enjeu, le context engineering s’impose comme un pilier des architectures IA fiables et évolutives.

Ce basculement est d’ailleurs souligné par des figures de l’industrie. Tobi Lutke, CEO de Shopify, résume ainsi le changement dans un tweet récent (source):

J’aime beaucoup le terme ‘context engineering’ plutôt que prompt engineering. Il décrit mieux la compétence fondamentale : l’art de fournir tout le contexte nécessaire pour qu’une tâche puisse être vraisemblablement résolue par un LLM.

Andrej Karpathy, autre référence du domaine, renchérit (source):

+1 pour ‘context engineering’ plutôt que ‘prompt engineering’. […] le context engineering est l’art délicat qui consiste à remplir la fenêtre de contexte avec exactement les bonnes informations pour l’étape suivante…

De la logique du prompt à une vision globale du contexte

Au-delà du prompt engineering

Le prompt engineering (l’art de formuler des instructions efficaces pour les LLMs) a marqué la première vague d’optimisation par l’utilisateur. Mais avec la montée en complexité des tâches et l’autonomisation croissante des agents, il est devenu évident que le prompt ne suffisait plus.

Le context engineering élargit la perspective :

• Le prompt engineering s’intéresse à la façon de poser la question.
• Le context engineering détermine ce que le modèle sait au moment de répondre.

Ce changement traduit une prise de conscience : un LLM ne sera jamais meilleur que le contexte qu’on lui fournit. Comme le souligne Philipp Schmid, « La majorité des échecs d’agents aujourd’hui sont des échecs de contexte, pas du modèle. » (PhilSchmid)

Définition du contexte

Dans les architectures IA actuelles, le « contexte » englobe :

• Les entrées utilisateur (requête, historique de conversation)
• La connaissance externe (documents, bases de données, APIs)
• L’état du workflow (étapes précédentes, résultats intermédiaires)
• Les outils et fonctions (exécution de code, calculatrices, recherche)

Le context engineering orchestre ces éléments pour composer dynamiquement la « fenêtre de contexte » optimale à chaque appel du LLM.

Ce que montrent l’industrie et la recherche

Pourquoi le context engineering s’impose aujourd’hui

L’essor des architectures agentiques, où les LLMs agissent comme agents autonomes ou orchestrent des workflows complexes, rend le context engineering incontournable. Comme le rappelle l’équipe LangChain : « Le facteur limitant pour la fiabilité des agents n’est plus le modèle, mais la qualité et la pertinence du contexte fourni. »

Facteurs clés :

• Les modèles progressent plus vite que la gestion du contexte. À mesure que les LLMs gagnent en puissance, le risque du « garbage in, garbage out » s’accroît.
• La fenêtre de contexte reste limitée. Même les plus gros modèles ne peuvent traiter qu’un volume restreint d’informations par requête : la sélection et la compression deviennent donc cruciales.
• Pression sur les coûts et la latence. Surcharger le contexte augmente les coûts et ralentit les réponses ; fournir trop peu d’informations dégrade la performance.

Exemples concrets

• Assistants de recherche d’entreprise : ils s’appuient souvent sur le retrieval-augmented generation (RAG) pour extraire les documents pertinents. Une mauvaise sélection du contexte aboutit à des réponses hors sujet, même avec un modèle performant.
• Systèmes multi-agents (par exemple pour l’automatisation de workflows) : ils doivent gérer l’isolation du contexte, pour que chaque agent reçoive uniquement les informations nécessaires, ni plus, ni moins.
• Bots de support client avec mémoire à long terme (tickets précédents, préférences utilisateur) : ils nécessitent une orchestration fine du contexte pour éviter les oublis ou les confusions.

Approche académique

Si la majorité des ressources sont issues de la pratique, une récente synthèse sur arXiv formalise le sujet, identifiant le context engineering comme un « goulet d’étranglement central pour la fiabilité des systèmes basés sur LLM » et appelant à des démarches d’évaluation et de standardisation.

Ce que cette prise de conscience change dans nos workflows

Techniques et stratégies clés

1. Sélection du contexte

   • Objectif : Filtrer et hiérarchiser l’information la plus pertinente.
   • Comment : Recherche vectorielle, sélection mémoire, algorithmes de ranking.
   • Exemple : Un bot interne ne remonte que les 3 documents de politique RH les plus pertinents pour la question posée.

2. Compression du contexte

   • Objectif : Faire tenir plus d’informations dans la fenêtre du LLM.
   • Comment : Résumer, tronquer, découper ; utiliser des résumés extractifs ou abstraits.
   • Exemple : Résumer un rapport de 20 pages en 300 mots pour le modèle.

3. Isolation du contexte

   • Objectif : Éviter les fuites d’informations et gérer la complexité.
   • Comment : Répartir le contexte entre sous-agents, sandboxer, utiliser des objets d’état.
   • Exemple : Dans un workflow, l’« agent réservation » n’accède qu’aux données de voyage, pas aux informations RH.

4. Sorties structurées

   • Objectif : Garantir la cohérence et l’interopérabilité.
   • Comment : Préciser le format attendu (JSON, XML…) dans le contexte ou le prompt.
   • Exemple : Demander au LLM de retourner un itinéraire structuré, pas un texte libre.

5. Workflow engineering

   • Objectif : Orchestrer les étapes LLM et non-LLM pour optimiser le contexte à chaque phase.
   • Comment : Pipelines multi-étapes, gestion des états, déclenchement d’outils externes.
   • Exemple : Un bot de support qui classe d’abord un ticket, puis extrait les FAQ pertinentes, puis rédige une réponse.

Évaluation, risques et compétences : les nouveaux défis

Évaluation et observabilité

Un point de friction récurrent reste l’absence de pipelines d’évaluation robustes et standardisés pour le context engineering. Si tout le monde s’accorde sur la nécessité de tester systématiquement (pertinence des réponses, latence, coûts), les méthodologies détaillées restent rares.

Bonnes pratiques :

• Journaliser les fenêtres de contexte et les sorties LLM pour assurer la traçabilité
• Faire de l’A/B testing sur différentes stratégies de sélection/compression
• Boucles de feedback utilisateur pour affiner l’assemblage du contexte

Risques et limites

• Confidentialité et sécurité : la fenêtre de contexte peut exposer des données sensibles. L’isolation et l’anonymisation sont indispensables.
• Context poisoning : un contexte malveillant ou erroné peut induire le modèle en erreur, avec des conséquences sur la fiabilité ou la sécurité.
• Biais liés aux outils : certains frameworks poussent leur propre vision du context engineering, qui n’est pas toujours généralisable.
• Manque de compétences : à mesure que la discipline se structure, il devient nécessaire de former ou de recruter sur ces nouveaux enjeux.

Vers une nouvelle discipline

Le passage du prompt au context engineering n’est pas qu’un ajustement technique : c’est une évolution professionnelle. La maîtrise des systèmes et la collaboration transversale deviennent essentielles. Reste à savoir si des rôles spécialisés émergeront ou si le context engineering doit devenir une compétence clé pour tous les praticiens IA.

Quelles priorités pour les équipes et les organisations ?

À mesure que les systèmes IA gagnent en autonomie, le context engineering n’est plus un « nice-to-have » : c’est un principe de conception fondamental. Les équipes devraient :

• Auditer leurs flux de contexte actuels : où se produisent les échecs ? Les modèles reçoivent-ils la bonne information au bon moment ?
• Investir dans les outils et l’observabilité : adopter des frameworks qui rendent les flux de contexte transparents et testables.
• Prioriser la sécurité et la confidentialité : mettre en place des garde-fous contre les fuites ou la corruption du contexte.
• Développer les compétences en context engineering : former les équipes ou recruter sur ce nouveau champ.
• Collaborer et standardiser : partager les bonnes pratiques, contribuer à des benchmarks ouverts, pousser à la normalisation sectorielle.

La prise de conscience croissante de l’importance du contexte dans l’IA n’est pas une simple tendance : c’est un tournant. En adoptant une démarche de context engineering, on ouvre la voie à des systèmes IA plus fiables, efficaces et dignes de confiance.

Pour aller plus loin

• The New Skill in AI is Not Prompting, It’s Context Engineering – Philipp Schmid
• Context Engineering for Agents – LangChain Blog
• Context Engineering for Agents – LangChain Video
• A Survey of Context Engineering for Large Language Models – arXiv
• Context Engineering - What it is, and techniques to consider – LlamaIndex
• How Long Contexts Fail - Drew Breunig