Le prompt engineering est mort. Place au context engineering.

Il y a un an, les threads Twitter sur “les 10 prompts qui changent votre vie” faisaient des dizaines de milliers de likes. Aujourd’hui, ils sont devenus obsolètes — et pas parce que les prompts ne marchent plus, mais parce qu’ils ne suffisent plus à eux seuls.

La compétence qui compte vraiment en 2026, c’est le context engineering. Savoir quoi mettre dans le contexte d’un LLM, quand, dans quel ordre, et à quelle granularité. C’est ce qui fait la différence entre un agent qui sort 4 itérations pour résoudre un problème et un qui le résout du premier coup.

Ce qui a tué le prompt engineering

Trois évolutions ont rendu les vieux tricks obsolètes :

1. Les modèles sont devenus robustes au phrasing

Sonnet 4.5 (sorti fin 2025) a commencé à pouvoir gérer des instructions imparfaites sans se casser. Tu peux lui dire “fais ce truc” au lieu de “You are an expert X, your task is Y, follow these steps…” et il fait la même chose. Les grosses litanies de persona, de “let’s think step by step”, de “do not hallucinate” sont devenues du folklore. Les modèles actuels savent raisonner sans qu’on les supplie.

2. Les fenêtres de contexte ont explosé

1M tokens sur Opus, 200K standard sur Sonnet. Ce qui était une contrainte forte (comment tenir en 8K tokens ?) est devenu une abondance à gérer (comment ne pas noyer le modèle en 500K tokens ?). Le problème a changé de nature.

3. Les outils ont pris le relais

Claude Code, les MCP servers, les skills, les hooks. Tout ce qui était avant une bataille de prompt est maintenant une question d’architecture de tools. Le prompt est devenu un mince layer au-dessus d’un système de contexte riche.

Ce qu’est le context engineering

Le context engineering, c’est concevoir l’environnement informationnel d’un agent avant de lui poser la moindre question. Ça recouvre 4 dimensions :

Dimension 1 — La hiérarchie de contexte

Un agent moderne a plusieurs couches de contexte qui se combinent à chaque tour :

1. Instructions système (jamais changées)
2. Project memory : CLAUDE.md (stable sur le projet)
3. User memory : préférences globales (stable sur l'utilisateur)
4. Session memory : historique conversationnel (volatile)
5. Working set : fichiers/outils chargés pour la tâche (tactique)

Savoir quoi mettre où est une compétence. Si tu mets tes conventions de codage dans un prompt envoyé à chaque message, tu payes 5000 tokens à chaque tour. Si tu les mets dans CLAUDE.md, elles sont cachées, l’agent les voit à chaque fois, tu ne payes rien après le premier tour grâce au prompt caching.

Dimension 2 — La densité d’information

Le bon contexte n’est pas le plus grand. C’est le plus dense en information pertinente pour la tâche.

Exemple concret. Tu demandes à un agent de refactorer une fonction. Quel contexte lui donner ?

• Mauvais : la codebase entière “au cas où” (1M tokens, l’agent se perd).
• Mauvais aussi : juste la fonction (l’agent ne voit pas les callers, refacto casse tout).
• Bon : la fonction + les 3-5 fichiers qui l’appellent + le CLAUDE.md du projet + le test associé.

Cette sélection demande de comprendre ta codebase mieux que l’agent ne peut le faire de manière autonome. C’est ton boulot, pas le sien.

Dimension 3 — L’ordre

L’ordre dans lequel les informations apparaissent dans le contexte a un effet mesurable sur le comportement de l’agent. Rappel connu : les LLMs ont un biais de récence (ils pondèrent plus ce qui est récent) et un biais de primauté (ce qui est en début tient aussi bien).

Pratique : les instructions critiques doivent être soit tout début du system prompt, soit en fin de user message. Ce qui est au milieu est le plus oublié.

Dimension 4 — La gestion des transitions

Quand un agent tourne longtemps (10, 20, 50 tours), le contexte explose. Deux techniques en 2026 :

• Compaction : l’agent lui-même résume périodiquement les 20 derniers tours en un condensé de 500 tokens. Anthropic l’a automatisé dans Claude Code.
• Retrieval ciblé : au lieu de garder tout l’historique, on récupère seulement les morceaux pertinents via embeddings. Plus économique, mais au risque de perdre un détail.

Exemple concret : un agent de review de code

Avant (prompt engineering) :

You are an expert senior developer with 20 years of experience.
Your task is to review this pull request.
Follow these steps:
1. Read the diff carefully
2. Identify bugs
3. Suggest improvements
4. ...
[200 lignes d'instructions]

Maintenant (context engineering) :

system: Review ce PR.

[Claude Code charge automatiquement :]
- CLAUDE.md du projet → conventions, architecture, tech stack
- .cursorrules / conventions de code
- Les 5 derniers PRs mergés avec leurs reviews → exemples de style
- Le diff complet du PR
- Les fichiers touchés en entier (pas juste le diff)
- Les tests associés

+ un skill /review qui déclenche une séquence prévisible :
  1. Lire CONTRIBUTING.md
  2. Vérifier que les tests passent
  3. Lister les points douteux
  4. Proposer des changements concrets

Le prompt, lui, fait 4 lignes. Le reste, c’est du contexte bien architecturé. Et les résultats sont qualitativement meilleurs parce que l’agent a toutes les infos nécessaires au bon moment.

Ce qu’il faut apprendre si tu veux monter en compétence

Si tu veux progresser sur ces sujets en 2026, voilà ce qui compte :

1. Maîtriser CLAUDE.md et équivalents. Un bon CLAUDE.md de projet, c’est 60% du gain d’un agent bien configuré. Tu écris une fois, tu réutilises partout.

2. Comprendre le prompt caching. C’est la clé du contexte volumineux économique. Si tu ne l’utilises pas, tu vas faire exploser ta facture ou limiter tes contextes.

3. Apprendre à construire des skills / custom commands. Un skill bien fait, c’est une procédure figée qui encode ta connaissance métier. Tu la fais une fois, elle est utilisée 1000 fois ensuite.

4. Architecturer la mémoire de tes agents. Short-term, long-term, per-project, per-user. C’est le nouveau state management.

5. Pratiquer le debugging de contexte. Quand un agent se plante, 80% du temps c’est pas un problème de modèle, c’est un problème de contexte. Savoir inspecter ce qu’il a “vu” au moment de la décision est une skill critique.

Ce qui reste du prompt engineering

Le prompt engineering n’a pas totalement disparu. Il survit sur deux cas :

1. Quand tu attaques l’API directement avec un modèle moins capable (ou plus ancien), sans infrastructure autour. Là, la formulation exacte compte encore.

2. Pour des tâches créatives pointues (copywriting de haut niveau, exploration conceptuelle). Tu peux obtenir des sorties très différentes selon le cadrage du prompt, même sur les gros modèles.

Pour tout le reste — du dev, des agents, de l’automation —, c’est de l’archéologie.

À retenir

Arrêtez de collectionner des prompts comme des cartes Pokémon. Commencez à construire des environnements de contexte pour vos agents. Écrivez des CLAUDE.md. Faites des skills. Maîtrisez le caching. Architecturez la mémoire.

Le dev qui fera la différence dans les 2 prochaines années n’est pas celui qui connaît le “meilleur prompt”. C’est celui qui sait configurer un contexte dans lequel n’importe quelle question produit une réponse utile du premier coup.