Qu’est-ce que le context engineering et pourquoi est-ce important?
Lorsque vous envoyez un message à Claude, votre prompt ne représente qu’une infime partie de ce que le modèle reçoit réellement. La majeure partie du contexte est assemblée à partir de plusieurs sources: le system prompt, les fichiers CLAUDE.md, les Skills, la mémoire persistante, et d’autres éléments configurés en amont. L’ensemble de ce processus s’appelle le context engineering.
Contrairement à un prompt classique, qui est rédigé pour une requête précise, le contexte est utilisé de manière transversale sur de nombreuses requêtes différentes. Il doit donc être suffisamment général pour rester pertinent dans des situations variées, tout en guidant efficacement le modèle. C’est un exercice d’équilibre délicat, et cet équilibre a considérablement évolué avec l’arrivée des modèles Claude 5.
L’équipe derrière Claude Code a récemment fait une découverte surprenante: en travaillant avec des modèles comme Claude Opus 5 et Claude Fable 5, il a été possible de supprimer plus de 80 % du system prompt de Claude Code sans aucune perte mesurable sur les évaluations de code. Ce chiffre illustre à quel point les nouvelles pratiques de context engineering diffèrent de celles qui étaient en vigueur il y a encore quelques mois.
Libérer Claude de ses contraintes excessives
L’un des premiers enseignements tirés de cette évolution est que les anciens modèles étaient sur-contraints. Les system prompts accumulaient des règles parfois contradictoires, des exemples redondants, et des instructions très rigides conçues pour éviter les pires scénarios possibles.
Par exemple, une instruction comme ‘Ne jamais écrire de commentaires multi-lignes’ pouvait être totalement inadaptée pour certains projets complexes où la documentation détaillée est indispensable. Ces garde-fous étaient nécessaires pour les anciens modèles, mais ils deviennent contre-productifs avec les nouvelles générations, qui possèdent un meilleur jugement contextuel.
Le passage d’une logique de règles rigides à une logique de confiance dans le jugement du modèle est au coeur de cette évolution. Plutôt que de dire à Claude exactement quoi faire dans chaque situation, on lui donne désormais des principes généraux et on le laisse adapter son comportement au contexte réel.
Les anciennes pratiques devenues obsolètes
Voici un aperçu des mythes du context engineering qui ont été remis en question avec les modèles Claude 5.
Donner des règles strictes versus faire confiance au jugement
Avant, il fallait formuler des règles très précises pour éviter les comportements indésirables. Aujourd’hui, une instruction comme ‘Écris du code qui ressemble au code environnant: respecte sa densité de commentaires, ses conventions de nommage et ses idiomes’ suffit. Claude adapte son comportement selon le contexte, sans qu’on ait besoin de tout anticiper.
Donner des exemples versus concevoir des interfaces expressives
La règle numéro un pour l’utilisation des outils était de fournir des exemples concrets. Avec les nouveaux modèles, les exemples ont tendance à contraindre l’exploration du modèle à un espace trop restreint. Il vaut mieux concevoir des outils aux paramètres expressifs. Par exemple, un outil de gestion de tâches dont le statut est défini par une énumération claire (pending, in_progress, completed) guide naturellement Claude sur son utilisation, sans qu’on ait besoin d’exemples détaillés.
Tout mettre en amont versus la divulgation progressive
Les anciens system prompts incluaient toutes les informations potentiellement utiles dès le départ, même si elles n’étaient pas toujours nécessaires. La divulgation progressive (progressive disclosure) consiste à charger le bon contexte au bon moment. Des instructions spécifiques, comme celles liées à la vérification du code, peuvent être déplacées dans des Skills dédiés que Claude appelle uniquement lorsqu’il en a besoin.
Se répéter versus des descriptions d’outils concises
Les anciens modèles avaient parfois besoin d’instructions répétées à différents endroits du contexte pour s’en souvenir correctement. Avec Claude 5, il suffit de placer les instructions dans la description de l’outil concerné. Les répétitions dans le system prompt sont non seulement inutiles, elles peuvent même nuire à la clarté.
Mémoire manuelle versus mémoire automatique
Il était auparavant recommandé d’encourager les utilisateurs à sauvegarder manuellement des informations dans les fichiers CLAUDE.md. Désormais, Claude sauvegarde automatiquement les éléments pertinents pour le projet et pour l’utilisateur, réduisant la charge cognitive nécessaire à la gestion de la mémoire.
Spécifications simples versus références riches
Les fichiers markdown simples étaient la norme pour stocker des plans et des spécifications. Les nouveaux modèles peuvent exploiter des références bien plus riches: artefacts HTML, suites de tests détaillées, fonctions issues d’autres codebases, ou encore des rubriques d’évaluation (rubrics) permettant à Claude de comprendre vos préférences stylistiques ou architecturales dans un domaine donné.
Comment assembler votre contexte aujourd’hui
En appliquant ces nouveaux principes, voici comment structurer efficacement votre contexte pour Claude 5.
Le system prompt
Le system prompt est étroitement lié au contexte produit. Il indique à Claude dans quel environnement il opère et quel est son rôle général. Si vous utilisez Claude Code tel quel, vous n’aurez probablement jamais à le modifier. En revanche, si vous construisez votre propre agent, c’est ici que vous devez concentrer l’essentiel de votre effort de conception.
Le fichier CLAUDE.md
Gardez votre CLAUDE.md léger et concis. Décrivez brièvement l’objectif du dépôt, puis concentrez les informations sur les particularités et les pièges spécifiques à votre codebase. Évitez d’y répéter ce que Claude peut déduire directement en explorant votre arborescence de fichiers.
- Mentionnez les conventions non évidentes (par exemple, tous les types dans un seul fichier monolithique).
- Référencez des Skills pour les instructions détaillées plutôt que de tout intégrer directement.
- Utilisez la divulgation progressive: créez une arborescence de fichiers chargés au bon moment.
Les Skills
Les Skills sont des guides légers qui permettent à Claude de trouver les informations dont il a besoin au moment opportun. Évitez de les sur-contraindre, sauf dans des domaines critiques. Pour les Skills longues, divisez-les en plusieurs fichiers et appliquez la divulgation progressive. Les meilleures Skills encodent des opinions, des connaissances ou des pratiques spécifiques à votre équipe ou à votre produit.
Les références
Vous pouvez mentionner des fichiers directement dans vos échanges avec Claude pour les inclure comme références. Préférez les références sous forme de code plutôt que des descriptions textuelles ou des captures d’écran: un mockup HTML produira généralement de meilleurs résultats qu’une description écrite du même design, car Claude comprend le code avec une grande précision.
Simplifier: la démarche clé pour les nouveaux modèles
Si vous avez construit des system prompts, des Skills ou des fichiers CLAUDE.md complexes avec les anciens modèles, il est temps de les revoir. La simplification n’est pas une perte: c’est une opportunité de laisser les capacités natives des modèles Claude 5 s’exprimer pleinement.
L’outil claude doctor (accessible via la commande /doctor dans Claude Code) a été conçu pour vous aider à analyser et simplifier automatiquement vos fichiers de contexte. Il identifie les instructions redondantes, les contraintes inutiles et les sections qui peuvent être déplacées dans des Skills dédiés.
En résumé, le context engineering pour Claude 5 repose sur trois grands principes: faire confiance au jugement du modèle plutôt que de tout anticiper, charger le contexte de manière progressive plutôt que de tout mettre en amont, et concevoir des interfaces expressives plutôt que de multiplier les exemples. Ces principes peuvent sembler contre-intuitifs si vous avez l’habitude des anciens modèles, mais ils reflètent une évolution profonde des capacités des LLM de nouvelle génération.
Adopter ces nouvelles pratiques, c’est non seulement améliorer la qualité des résultats de vos agents, mais aussi réduire la complexité de leur maintenance sur le long terme. Moins de règles, moins de répétitions, et un modèle qui comprend réellement ce que vous voulez construire.
