L'ingénierie de contexte : la compétence qui multiplie tout le reste

La distinction qui change tout

« Le prompt engineering concerne ce que vous dites. L’ingénierie de contexte concerne ce que le modèle voit. »

Ce cadrage, articulé par Martin Fowler et repris par Anthropic, capture le changement le plus important dans la manière dont les développeurs qualifiés travaillent avec l’IA. La plupart des développeurs se focalisent sur leurs prompts : la formulation exacte, les phrases magiques, les préfixes « agis comme ». Mais le prompt n’est qu’une fraction de ce que le modèle traite. Le reste est du contexte : les fichiers chargés dans la session, les fichiers mémoire que le modèle lit au démarrage, l’historique de conversation, les outils disponibles.

La gestion du contexte est plus importante que le prompt engineering. Un prompt médiocre avec un excellent contexte surpassera un prompt parfait avec un mauvais contexte à chaque fois. Et pourtant, presque personne n’enseigne l’ingénierie de contexte de manière systématique.

La hiérarchie du contexte

Tout le contexte n’est pas égal. Il fonctionne par niveaux, et comprendre ces niveaux est le fondement de la compétence.

Niveau 1 : Mémoire active (toujours chargée). C’est votre fichier CLAUDE.md : les instructions que le modèle lit au début de chaque session. C’est l’élément de contexte à plus fort levier que vous contrôlez. Chaque ligne de ce fichier influence chaque réponse que vous recevez. Traitez-le comme du code de production : s’il est trop long, l’IA en ignore la moitié. Pour chaque ligne, demandez-vous : « Supprimer ceci causerait-il des erreurs de l’IA ? » Si la réponse est non, supprimez-la. Utilisez IMPORTANT et YOU MUST pour les règles critiques qui ne peuvent être violées.

CLAUDE.md supporte sa propre hiérarchie. Les règles globales vivent dans ~/.claude/CLAUDE.md. Les règles à l’échelle du projet vont dans ./CLAUDE.md et sont partagées via git. Les règles spécifiques à un répertoire vont dans ./src/CLAUDE.md. Les préférences personnelles qui ne doivent pas être partagées vont dans CLAUDE.local.md, qui est dans le gitignore.

Niveau 2 : Contexte tiède (à la demande). Ce sont les compétences, commandes et workflows qui se chargent quand ils sont invoqués. Ils ne sont pas présents à chaque session, seulement quand nécessaire. Cela garde le contexte de base léger tout en rendant les capacités spécialisées disponibles.

Niveau 3 : Contexte froid (référence). Documents de passation, spécifications, records de décisions architecturales. Ils ne sont pas chargés par défaut. Ils existent comme des fichiers que le modèle peut lire sur demande. Le pattern interview-puis-spec vit ici : l’IA vous interviewe sur les exigences, produit un SPEC.md, et une session fraîche implémente à partir de cette spec. La spec transporte le contexte sans polluer la session.

La recherche

Trois résultats de recherches récentes plaident quantitativement pour l’ingénierie de contexte.

Résultat 1 : L’optimisation de CLAUDE.md seule améliore les performances de manière mesurable. Arize a découvert que l’optimisation des fichiers CLAUDE.md, sans aucun changement d’infrastructure, d’outils ou de workflow, produit une amélioration de 5,19% sur les tâches générales et de 10,87% sur les tâches spécialisées pour un seul repository. C’est un gain significatif obtenu en éditant un seul fichier texte. C’est l’intervention à plus fort levier disponible aujourd’hui pour tout développeur utilisant des outils IA.

Résultat 2 : Plus d’outils rendent l’IA moins performante, pas plus. Des chercheurs de Berkeley ont découvert que l’IA performe moins bien quand on lui donne plus d’outils. Des modèles qui réussissaient avec 19 outils disponibles échouaient avec 46. Chaque outil supplémentaire est du contexte supplémentaire que le modèle doit traiter, des options supplémentaires qu’il doit évaluer, une surface supplémentaire de confusion. L’ingénierie de contexte signifie donner au modèle exactement ce dont il a besoin, pas tout ce que vous avez.

Résultat 3 : Distiller l’information au compte-gouttes détruit les performances. Des chercheurs de Microsoft et Salesforce ont démontré que distribuer l’information séquentiellement au fil des tours de conversation, au lieu de la fournir d’entrée, cause une baisse de performance de 39%. Le modèle n’accumule pas la compréhension au fil des tours comme un humain le ferait. Il traite chaque tour avec la fenêtre de contexte complète, et l’information enfouie dix tours en arrière entre en compétition avec tout ce qui a suivi. Chargez votre contexte en amont. Ne forcez pas le modèle à le chercher.

Six stratégies qui fonctionnent

Ce ne sont pas des stratégies théoriques. Ce sont les pratiques qui produisent des résultats constants.

1. Gardez CLAUDE.md chirurgical. Chaque ligne mérite sa place. Si l’IA ne fait pas d’erreurs qu’une règle empêcherait, cette règle n’a pas sa place. L’optimisation produit des gains mesurables. Le surplus produit des pertes mesurables.

2. Effacez le contexte entre les tâches sans rapport. Utilisez /clear quand vous changez de tâche. Ne mélangez jamais des travaux sans rapport dans une même session. La pollution de contexte d’une tâche précédente dégradera les performances sur la tâche en cours. C’est gratuit et prend deux secondes.

3. Chargez l’information en amont. Donnez au modèle tout ce dont il a besoin au début de la conversation, pas réparti sur plusieurs tours. La baisse de performance de 39% liée à la livraison séquentielle d’information est trop importante pour être ignorée.

4. Utilisez le pattern interview-puis-spec. Pour les fonctionnalités complexes, faites une session qui vous interviewe sur les exigences et produit un SPEC.md. Puis démarrez une session fraîche pour implémenter à partir de la spec. Cela donne à la session d’implémentation un contexte propre et complet sans le bruit de la conversation exploratoire.

5. Appliquez la règle des deux corrections. Si vous avez corrigé l’IA deux fois sur le même problème et qu’elle se trompe toujours, arrêtez. Le contexte est empoisonné. Démarrez une session fraîche avec un meilleur prompt et un meilleur contexte initial. Les spirales de correction gaspillent du temps et dégradent la qualité.

6. Isolez le travail des sous-agents. Utilisez des sous-agents pour les tâches d’exploration : investiguer du code inconnu, rechercher des approches, cartographier des dépendances. Ne les utilisez pas pour de simples lectures ou recherches. Le surcharge ne vaut pas le coût pour des opérations simples, mais l’isolation est précieuse pour les tâches qui pourraient polluer le contexte de votre session principale.

Anti-patterns à éviter

Ce sont les erreurs qui coûtent le plus de temps tout en donnant l’impression d’être productif.

Le CLAUDE.md fourre-tout. Entasser chaque préférence, chaque règle, chaque cas limite dans un seul fichier. L’IA commence à ignorer les instructions parce que le rapport signal/bruit est trop faible. Moins c’est plus. Soyez impitoyable.

Ne jamais effacer le contexte. Exécuter tout le travail d’une journée dans une seule session. En fin d’après-midi, la fenêtre de contexte est remplie d’historique de conversation hors sujet du matin, et les performances du modèle se sont dégradées sensiblement.

Les spirales de correction. Corriger la sortie de l’IA, puis corriger la correction, puis corriger la correction de la correction. Chaque correction ajoute du bruit au contexte. Après deux corrections, il vaut mieux repartir de zéro.

L’exploration infinie. Envoyer des sous-agents en missions de recherche ouvertes sans limites claires. Ils consomment du contexte, retournent des informations tangentiellement pertinentes, et laissent la session principale encombrée.

La continuité basée sur l’espoir. Supposer que le modèle « se souvient » des détails importants du début d’une longue conversation. Il traite la fenêtre de contexte complète, mais l’attention n’est pas uniforme. Les informations critiques des premiers tours sont diluées. Utilisez des documents de passation et des specs pour préserver le contexte important explicitement.

Distiller l’information au compte-gouttes. Donner au modèle les exigences une par une au fil de plusieurs tours au lieu de fournir l’image complète d’entrée. La pénalité de performance de 39% est réelle et évitable.

L’effet multiplicateur

L’ingénierie de contexte n’est pas une compétence isolée. C’est la compétence qui rend toutes les autres compétences plus efficaces. Un meilleur contexte signifie une meilleure génération de code, une meilleure vérification, un meilleur débogage, de meilleures décisions architecturales. C’est la différence entre combattre l’IA et la diriger.

Les développeurs qui maîtrisent l’ingénierie de contexte n’écrivent pas de meilleurs prompts. Ils créent des environnements où même des prompts simples produisent d’excellents résultats. C’est le multiplicateur. C’est la compétence qui mérite l’investissement.

Commencez par votre CLAUDE.md. Auditez chaque ligne. Puis explorez le reste de la méthodologie pour voir comment l’ingénierie de contexte s’intègre dans un workflow de vérification complet.

Sources : Martin Fowler / Anthropic on Context Engineering · Arize, “CLAUDE.md Optimization Study” · Berkeley, “Tool Overload in AI Agents” · Microsoft/Salesforce, “Sequential Information Degradation in LLMs”