Context Engineering : La Compétence qui a Remplacé le Prompt Engineering en 2026

Andrej Karpathy l'a dit clairement : «Prompt engineering» est un terme trompeur. Il implique que l'art de travailler avec des modèles de langage consiste à formuler soigneusement des instructions — à écrire la phrase magique qui débloque le bon résultat. Ce cadre a toujours sous-estimé le vrai travail, et en 2026 il ne décrit plus ce que les équipes IA sérieuses font réellement.

Ce qu'elles font est du context engineering : la pratique délibérée et systématique de construire la bonne information au bon moment dans le bon format pour occuper la fenêtre de contexte d'un LLM lors de l'inférence. C'est en partie de la récupération, en partie de la gestion de mémoire, en partie de la conception de systèmes et en partie de l'UX. Ce n'est pas un prompt. Et les équipes qui le traitent comme tel laissent la majeure partie de la capacité de leur modèle inutilisée.

Pourquoi «Prompt Engineering» a Toujours Été le Mauvais Cadre

La phrase «prompt engineering» vient des intuitions de l'ère GPT-3 : les modèles étaient opaques, la bonne formulation débloquait des capacités cachées, et la compétence était essentiellement incantatoire. La façon dont le modèle fonctionnait dépendait de la bonne incantation.

Ce modèle mental a éclaté pour trois raisons :

1. Les fenêtres de contexte se sont élargies. Quand les modèles avaient 4K tokens, les prompts étaient courts. À 128K, 200K et 1M+ tokens, ce qu'on met dans la fenêtre est un problème de conception de système, pas un problème de rédaction.
2. Les systèmes sont devenus dynamiques. Les applications IA modernes n'utilisent pas un prompt statique. Elles récupèrent des documents, appellent des outils, maintiennent une mémoire entre les sessions et traitent des résultats intermédiaires.
3. Le signal s'est déplacé. Empiriquement, les plus grands écarts de performance entre équipes viennent de la qualité du contexte, pas de la formulation du prompt.

Les Six Couches du Contexte

Le context engineering signifie réfléchir délibérément à six composantes distinctes qui peuvent occuper la fenêtre de contexte d'un modèle lors de l'inférence :

• Couche 1 — Prompt système et instructions. Définition du rôle, contraintes de tâche, spécification du format de sortie, schémas d'outils. Fixe et relativement petit — typiquement 5–10% du budget.
• Couche 2 — Exemples few-shot. Démonstrations entrée/sortie qui ancrent le format, le ton et la gestion des cas limites. Les bons few-shots font un travail plus fiable que des paragraphes d'instructions élaborés.
• Couche 3 — Mémoire de travail / État. Le brouillon de l'agent : raisonnement intermédiaire, progression de la tâche, schéma de sortie structurée. Cette couche croît pendant une tâche.
• Couche 4 — Documents récupérés (RAG). Connaissance externe obtenue lors de l'inférence : résultats de recherche vectorielle, requêtes de bases de données, extraits de code, données en temps réel.
• Couche 5 — Résultats d'outils et d'actions. La sortie d'appels API, d'exécution de code, de recherche et d'autres invocations d'outils. Souvent verbeux, nécessite une troncature ou un résumé.
• Couche 6 — Historique de conversation. Tours précédents, mémoire résumée et préférences utilisateur persistées. Les longues conversations nécessitent des stratégies de compression.

L'idée clé : un «prompt» est au mieux la couche 1. Le context engineering est la pratique de gérer les six couches simultanément dans un budget de tokens fini.

La Qualité du Contexte Bat la Taille du Modèle

La découverte la plus pratiquement importante dans la littérature du context engineering est aussi la plus contre-intuitive : un modèle plus petit avec un contexte bien conçu surpasse régulièrement un modèle plus grand avec un contexte médiocre.

Cela a été démontré sur plusieurs benchmarks. Dans les tâches de génération de code, GPT-4o avec des few-shots soigneusement sélectionnés et un contexte de base de code pertinent surpasse o3 avec un prompt système générique.

«Nous avons passé trois mois à essayer différents modèles. Un sprint sur la qualité du contexte nous a donné les mêmes gains que nous cherchions depuis un trimestre.» — Développeur sur Hacker News

Le Budget de Contexte : Traiter les Tokens comme une Ressource Finie

Le changement de modèle mental le plus utile dans le context engineering est de traiter les tokens comme un budget. La fenêtre de contexte est une ressource rare. Tout ce qui y entre déplace quelque chose d'autre.

Techniques de gestion du budget qui apparaissent répétitivement dans les systèmes de production :

Récupération par niveaux

Ne pas récupérer des documents entiers. Utiliser un pipeline en deux étapes : un modèle de récupération rapide et bon marché sélectionne les candidats ; un re-ranker à codage croisé sélectionne les passages de plus haute pertinence.

Résumé progressif

L'historique de conversation et l'état intermédiaire croissent sans limite si non gérés. Le modèle de production est de résumer après un seuil — typiquement après chaque N tours ou quand l'historique dépasse X tokens.

Few-shots dynamiques

Si vous avez une bibliothèque de 200 exemples, récupérez les 3–5 les plus sémantiquement similaires à l'input actuel. Cette technique est l'une des optimisations de contexte à plus fort ROI.

Le Problème de la Qualité du Retrieval

Erreurs aux limites des chunks

Le chunking à taille fixe divise souvent des passages sémantiquement cohérents entre chunks. Le chunking conscient du document surpasse consistamment le chunking à taille fixe.

Contexte manquant pour les chunks récupérés

La technique «Contextual Retrieval» d'Anthropic préfixe un résumé de contexte spécifique au chunk à chaque chunk lors de l'indexation. Dans leurs benchmarks, cela a réduit les échecs de retrieval de 49% en combinaison avec le re-ranking.

Désaccord requête-document

HyDE (Hypothetical Document Embeddings) résout cela en générant une réponse hypothétique à la requête et en embarquant celle-ci, plutôt que d'embarquer la requête brute.

Quoi Construire en Premier

1. Auditer la pipeline de retrieval. Passer des chunks à taille fixe aux chunks sémantiques ou conscients du document. Ajouter une étape de re-ranking.
2. Implémenter le résumé de conversation. Limiter l'historique de conversation à une limite de tokens et résumer quand elle est dépassée.
3. Ajouter la récupération dynamique de few-shots. Construire une petite bibliothèque d'exemples de haute qualité. Récupérer les top-3 les plus similaires à l'input actuel.
4. Externaliser l'état des agents. Pour les systèmes multi-agents, déplacer l'état intermédiaire vers des stores externes structurés dès le départ.
5. Instrumenter la qualité du contexte. Ajouter de la journalisation pour les fenêtres de contexte et les résultats.

Le Point Essentiel

Le context engineering n'est pas une technique. C'est un changement de perspective : de traiter les modèles de langage comme des générateurs de texte qui répondent aux instructions, à les traiter comme des moteurs d'inférence dont les performances sont limitées par la qualité de l'information fournie lors de l'exécution.

L'écart entre ce que les équipes accomplissent et ce qui est possible est presque toujours un écart de contexte. Cet écart est un problème d'ingénierie. Et comme tous les problèmes d'ingénierie, il répond à un investissement systématique.

Le sort n'a jamais été dans les mots. Il a toujours été dans l'information derrière eux.