Context engineering : le guide complet (2026)

Le context engineering est la compétence IA décisive de 2026

Le context engineering est la discipline qui consiste à concevoir des systèmes dynamiques fournissant la bonne information, au bon format, au bon moment à un modèle de langage. Si vous avez déjà reformulé un prompt dix fois sans obtenir le résultat attendu, le problème ne venait probablement pas de votre formulation. Il venait du contexte.

Comme le résume Tobi Lutke, CEO de Shopify : le context engineering est « l’art de fournir tout le contexte pour qu’une tâche soit plausiblement résoluble par le LLM ». Andrej Karpathy complète cette vision en décrivant « l’art et la science de remplir la fenêtre de contexte avec exactement la bonne information pour l’étape suivante ». J’ai passé les six derniers mois à appliquer cette approche sur mes projets, et la différence avec le prompt engineering classique est nette.

En 2026, les modèles de langage raisonnent mieux que jamais. Leurs limites ne viennent plus de leur capacité de compréhension, mais de l’information que vous leur fournissez. Selon Gartner, le context engineering est en train de remplacer le prompt engineering comme discipline clé pour les entreprises. Le context engineering répond à ce constat : au lieu de perfectionner la question, vous structurez l’environnement informationnel complet dans lequel le modèle opère.

Prompt engineering vs context engineering : ce qui a changé

Le prompt engineering reste utile, mais il ne suffit plus. Voici ce qui distingue les deux approches.

Le prompt engineering : optimiser la question

Le prompt engineering se concentre sur la formulation : choix des mots, structure de l’instruction, ajout d’exemples (few-shot), chaîne de pensée (chain-of-thought). C’est une compétence de rédaction qui opère à l’intérieur de la fenêtre de contexte. Elle fonctionne bien pour des interactions ponctuelles.

Le context engineering : architecturer l’information

Le context engineering agit en amont. Il définit ce qui remplit la fenêtre de contexte avant même que l’utilisateur pose sa question. Instructions système, données récupérées dynamiquement, mémoire conversationnelle, outils disponibles, format de sortie attendu : tout cela fait partie du contexte.

Tableau comparatif

Critère	Prompt engineering	Context engineering
Périmètre	L’instruction envoyée au modèle	L’ensemble de l’environnement informationnel
Approche	Rédaction itérative	Architecture de systèmes
Type d’entrée	Texte statique, templates	Entrées dynamiques multi-sources
Cas d’usage	Requêtes ponctuelles	Agents, workflows, production
Analogie	Poser une bonne question à un expert	Construire la bibliothèque et les outils de l’expert

Mon constat après des mois de pratique : si vous reformulez un prompt à répétition sans amélioration, le modèle manque probablement d’information, pas d’instruction. Le context engineering corrige ce problème à la source.

Les 7 composants du contexte

Les 7 couches qui composent le contexte complet d’un modele de langage.

Chaque interaction avec un LLM repose sur un contexte composé de sept couches distinctes. Comprendre ces couches permet de structurer méthodiquement ce que le modèle reçoit.

1. Le system prompt (instructions système)

Le system prompt définit le comportement global du modèle : son rôle, son ton, ses contraintes et ses règles. Il persiste pendant toute la session. Dans les outils de développement comme Claude Code, le fichier CLAUDE.md joue exactement ce rôle : il charge des instructions permanentes à chaque session.

Un system prompt efficace ne se contente pas de dire « Tu es un assistant utile ». Il spécifie le domaine d’expertise, les formats de sortie attendus, les erreurs à éviter et les règles métier à respecter.

2. Le user prompt (instruction utilisateur)

C’est la requête immédiate de l’utilisateur. Le prompt engineering classique se concentre exclusivement sur cette couche. En context engineering, elle n’est qu’un des sept composants.

3. L’état et l’historique (mémoire court terme)

Le fil de conversation en cours est la mémoire de travail du modèle. Chaque échange précédent consomme des tokens et influence la réponse. Une gestion intelligente de cet historique (résumé des échanges anciens, suppression du bruit) améliore la cohérence sans gaspiller la fenêtre de contexte.

4. La mémoire long terme

Certains systèmes stockent des informations entre les sessions : préférences utilisateur, décisions passées, patterns récurrents. Cette mémoire persistante permet au modèle de s’adapter au fil du temps sans repartir de zéro à chaque conversation.

5. Les données récupérées (RAG)

Le RAG (Retrieval-Augmented Generation) injecte des documents externes pertinents dans le contexte au moment de la requête. C’est la technique qui permet de connecter un LLM à vos données privées : documents internes, base de connaissances, emails, wiki d’entreprise. Le RAG est une composante majeure du context engineering, mais il n’en est qu’une partie.

6. Les outils disponibles

Les définitions d’outils (tool definitions) indiquent au modèle quelles actions il peut effectuer : appels API, recherche web, exécution de code, lecture de fichiers. Le Model Context Protocol (MCP) standardise cette couche avec un protocole universel pour connecter les LLM à des outils externes.

7. Le format de sortie structuré

Les spécifications de format (schéma JSON, template Markdown, structure YAML) guident la forme de la réponse. Un modèle qui sait exactement quel format produire génère des résultats plus fiables et directement exploitables par un pipeline automatisé.

Les 5 stratégies du context engineering

5 strategies pour optimiser le contexte : de la selection des donnees (+90% perf. avec multi-agents) au formatage structure.

La recherche et les retours de terrain pointent vers cinq stratégies pour concevoir un contexte performant.

Sélection : récupérer uniquement ce qui compte

La sélection consiste à choisir, parmi toutes les données disponibles, uniquement celles qui sont pertinentes pour la tâche en cours. C’est le principe du RAG : au lieu de charger toute une base documentaire, un pipeline de recherche sémantique identifie les passages les plus pertinents et les injecte dans le contexte.

La sélection repose sur plusieurs techniques : la recherche vectorielle par embeddings, le filtrage par métadonnées, la pondération par récence et le reranking par un modèle secondaire. Selon les équipes d’Elastic, combiner recherche vectorielle et recherche par mots-clés (recherche hybride) produit les résultats les plus équilibrés.

Compression : économiser chaque token

Chaque token consommé a un coût financier et un impact sur la latence. La compression vise à conserver l’information critique en réduisant le volume. Cela passe par le résumé automatique des conversations longues, l’élagage des détails non pertinents et le chunking sémantique (découper les documents par concepts plutôt que par blocs arbitraires).

Selon une étude de Chroma Research sur le context rot, les performances des LLM se dégradent nettement au-delà d’environ 1 million de tokens, quelle que soit la taille théorique de la fenêtre de contexte. Les 18 modèles frontières testés montrent une dégradation mesurable à chaque incrément de longueur de contexte. La compression n’est pas optionnelle : c’est une nécessité architecturale.

Ordonnancement : placer l’information au bon endroit

Les LLM ne traitent pas toutes les positions du contexte avec la même attention. Le phénomène dit « lost-in-the-middle » montre que les modèles perdent en précision sur les informations situées au centre de longs contextes, avec une chute de précision de plus de 30 % dans certains cas. Les informations les plus critiques doivent être positionnées au début ou à la fin du contexte.

En pratique : placez les règles et contraintes systèmes au début, les données de travail en cours à la fin, et l’historique conversationnel au milieu.

Isolation : diviser pour mieux raisonner

Plutôt que de charger un contexte massif dans un seul agent, l’isolation consiste à décomposer une tâche complexe en sous-tâches confiées à des agents spécialisés. Chaque agent reçoit un contexte ciblé, limité à ce dont il a besoin. C’est le principe des architectures multi-agents.

Selon les recherches d’Anthropic sur leur système multi-agents, les systèmes multi-agents surpassent les agents uniques de 90,2 % en performance, mais consomment 15 fois plus de tokens. L’isolation est un arbitrage entre précision et coût.

Formatage : structurer pour la compréhension

Le format dans lequel l’information est présentée influence directement la qualité de la réponse. Les tests montrent que les formats structurés (YAML, XML, Markdown avec headers) surpassent le texte brut ou le JSON dense pour les instructions complexes.

Claude, par exemple, excelle avec les balises XML pour délimiter les sections du contexte. Un system prompt structuré avec des sections claires (<rules>, <context>, <examples>) produit des résultats plus fiables qu’un bloc de texte continu.

Context engineering en pratique : 3 cas d’usage

La théorie ne suffit pas. Voici trois cas concrets que j’ai mis en place ou observés, et qui illustrent la différence avec une approche purement basée sur le prompt.

Cas 1 : le fichier CLAUDE.md pour le développement

Sur ce blog, j’utilise un fichier CLAUDE.md pour structurer le contexte permanent de Claude Code. Il contient ma stack technique, mes conventions de code, les patterns architecturaux et les règles métier. Au lieu de répéter ces informations à chaque conversation, elles sont chargées automatiquement.

# Exemple simplifié de CLAUDE.md
## Stack
- Astro + Tailwind CSS
- TypeScript strict
- Tests avec Vitest

## Conventions
- Composants dans src/components/
- Nommage PascalCase pour les composants
- Pas de any en TypeScript

## Règles métier
- Toutes les dates en format ISO 8601
- Langue du contenu : français
- URLs en kebab-case

Ce fichier est du context engineering en action. Il remplace des dizaines de prompts répétitifs par une source de vérité centralisée.

Cas 2 : un agent de planification avec RAG et outils

Un agent chargé de répondre aux questions d’une équipe commerciale illustre le context engineering complet. Son contexte se compose de :

• System prompt : rôle (assistant commercial), ton (professionnel), contraintes (ne jamais inventer de prix)
• RAG : catalogue produits, grilles tarifaires, historique des propositions commerciales
• Outils : accès CRM via API, calculateur de devis, recherche dans la base de tickets support
• Mémoire : préférences du client, interactions passées résumées

Chaque composant est assemblé dynamiquement au moment de la requête. Sans context engineering, cet agent hallucinerait des prix ou ignorerait l’historique client.

Cas 3 : un pipeline éditorial automatisé

Un workflow de création de contenu peut orchestrer le contexte en plusieurs étapes :

1. Recherche : un agent collecte des sources, des données et des questions fréquentes via des outils de recherche web
2. Rédaction : un second agent reçoit un contexte structuré (brief, sources, consignes éditoriales, articles existants pour le maillage interne)
3. Relecture : un troisième agent vérifie le style, la grammaire et la conformité SEO avec un contexte contenant les règles éditoriales

Chaque agent opère dans un contexte isolé et optimisé. Le résultat est plus fiable qu’un prompt unique demandant de « rédiger un article SEO complet ».

Les erreurs courantes en context engineering

Structurer le contexte ne suffit pas. J’ai fait chacune de ces erreurs avant de les identifier. Elles reviennent systématiquement dans les projets de production.

Surcharger le contexte

Plus de contexte ne signifie pas de meilleures réponses. Un contexte surchargé dilue l’attention du modèle et augmente la latence et les coûts. Gartner recommande de traiter le contexte comme une infrastructure critique, au même titre que la cybersécurité : chaque élément injecté doit justifier sa présence.

Négliger l’ordonnancement

Injecter des données RAG au milieu d’un long contexte sans réfléchir à leur position est une erreur fréquente. Les informations critiques enterrées au centre du contexte seront partiellement ignorées par le modèle.

Confondre instructions et données

Mélanger les règles comportementales et les données factuelles dans un même bloc réduit l’efficacité des deux. Séparez les instructions stables (system prompt) des données variables (résultats RAG, historique). Cela permet de mettre à jour les données sans perturber les objectifs de l’agent.

Ignorer la boucle de feedback

Le context engineering n’est pas un exercice ponctuel. Les contextes doivent évoluer en fonction des résultats obtenus. Quand un agent échoue, la première question à poser est : « Quelle information manquait dans le contexte ? » plutôt que « Comment reformuler le prompt ? ».

Comment démarrer avec le context engineering

4 niveaux de maturite en context engineering : chaque niveau s’appuie sur le precedent.

Vous n’avez pas besoin d’une infrastructure complexe pour commencer. Voici la progression que je recommande.

Niveau 1 : structurer vos system prompts

Passez du prompt unique au system prompt structuré. Définissez le rôle, les contraintes, le format de sortie et les exemples dans des sections séparées. Utilisez des délimiteurs (XML, Markdown) pour clarifier la structure. Si vous utilisez Claude Code, le fichier CLAUDE.md est le point de départ idéal.

Niveau 2 : ajouter du contexte dynamique

Intégrez un pipeline RAG pour injecter des données pertinentes à chaque requête. Des outils comme n8n permettent de construire ces pipelines sans coder, avec des connecteurs vers vos bases de connaissances.

Niveau 3 : architecturer des agents spécialisés

Décomposez les tâches complexes en agents isolés avec des contextes ciblés. Chaque agent reçoit uniquement les instructions, outils et données dont il a besoin. C’est l’approche qui sous-tend les systèmes les plus fiables en production.

Niveau 4 : mesurer et itérer

Mettez en place des métriques pour évaluer la qualité du contexte : taux de réussite des tâches, coût en tokens, latence, taux d’hallucination. Ajustez le contexte en fonction des résultats, pas de l’intuition.

Ce que le context engineering change pour les professionnels

Le context engineering redéfinit les compétences recherchées en IA. Savoir formuler un bon prompt reste utile, mais c’est désormais une compétence de base. La vraie valeur est dans la capacité à architecturer des systèmes de contexte complets.

Pour les développeurs, cela veut dire maîtriser les pipelines RAG, les protocoles comme MCP, et les outils de mémoire persistante. Pour les professionnels non techniques, cela veut dire comprendre quelles informations structurer, dans quel format, et comment les maintenir à jour.

Selon Gartner, 40 % des applications d’entreprise intégreront des agents IA spécialisés d’ici fin 2026, contre moins de 5 % en 2025. Cette accélération rend le context engineering indispensable : chaque agent a besoin d’un contexte structuré pour fonctionner de manière fiable.

Les entreprises les plus avancées nomment déjà des responsables du context engineering, chargés de gouverner les données, les instructions et les outils qui alimentent leurs systèmes IA. Mon avis : le contexte est devenu une infrastructure critique, au même titre que les données ou le code.