Tu as beau écrire le prompt parfait, le résultat est médiocre. Tu reformules, tu ajoutes des exemples, tu précises le format. Rien n'y fait.

Le problème n'est pas ton prompt. C'est ce que le modèle voit au moment où il répond.

Andrej Karpathy a nommé ça : le context engineering, "l'art et la science de remplir la fenêtre de contexte avec exactement la bonne information au bon moment."

La plupart des devs s'arrêtent au prompt engineering. Ils peaufinent le texte de la requête. Mais le prompt n'est qu'un composant. Ce qui détermine la qualité de la sortie, c'est l'ensemble des informations que le modèle reçoit : le prompt, bien sûr, mais aussi l'historique de conversation, les fichiers chargés, les outils disponibles, les exemples, les contraintes.

Le prompt engineering est un sous-ensemble du context engineering. Tu peux avoir un prompt parfait noyé dans 50 000 tokens de bruit. Le modèle le suit quand même mal.

Le context engineering adresse 4 problèmes concrets que tout lead dev a rencontrés :

Tu charges trop d'informations dans la fenêtre. Le modèle noie le signal dans le bruit. C'est ce qui arrive quand tu colles un fichier entier de 800 lignes pour demander "corrige ce bug à la ligne 42".

Le modèle oublie ce qui est au milieu de sa fenêtre de contexte. Les chercheurs ont mesuré : repositionner les contraintes critiques du milieu vers le début réduit les violations de conventions de 35-40%, sans changer un seul mot du prompt. Même contenu, même modèle, juste un réarrangement.

Après 20+ échanges, le contexte dérive. Le modèle perd le fil de l'objectif initial, répète des erreurs précédentes, ou commence à suivre ses propres suggestions au lieu de la consigne originale. C'est la "context rot".

Le modèle reçoit une information trop tôt (et elle sort de sa mémoire active) ou trop tard (et il a déjà décidé sans elle). Le context engineering, c'est aussi décider quand injecter l'information.

Sourcegraph et LangChain ont formalisé 4 techniques. Ce sont les leviers concrets sur lesquels tu peux agir :

Persiste l'état de l'agent à l'extérieur de la fenêtre de contexte. Un fichier todo.md que l'agent met à jour à chaque étape. Un fichier decisions.md qui trace les choix. La fenêtre est éphémère, le filesystem est permanent.

Concrètement : quand tu utilises Claude Code ou Cursor, le fichier AGENTS.md ou CLAUDE.md est du context engineering. Tu écris ce que le modèle doit savoir avant même de poser la question.

Ne charge que le nécessaire. Au lieu de coller tout un fichier, cible les lignes pertinentes. Au lieu de charger toute l'historique de conversation, garde les 5 derniers échanges significatifs.

C'est le principe du RAG : retrieval just-in-time. Le modèle n'a pas besoin de voir toute la codebase. Il a besoin de voir le bon fichier, au bon moment.

Résume ce qui est déjà en contexte avant d'ajouter du neuf. Si tu as 30 messages d'historique, compresse-les en un résumé de 10 lignes avant de charger le fichier suivant.

Anthropic recommande : "la plus petite quantité d'informations qui décrit complètement le comportement attendu." Minimal ne veut pas dire court. Ça veut dire dense.

Sépare les contextes par tâche. Un sous-agent pour la recherche, un autre pour l'écriture, un troisième pour la review. Chacun a sa propre fenêtre, propre et ciblée.

C'est l'architecture multi-agent : pas pour faire joli, mais pour que chaque agent travaille avec un contexte propre, sans pollution croisée.

La plupart des lead devs ont un fichier de contexte (AGENTS.md, CLAUDE.md, …). Mais il est souvent :

Check rapide :

Si tu as répondu non à une de ces questions, ton context engineering a de la marge.

Mem0. Couche de mémoire pour agents IA. Extrait, consolide et récupère cross-session les informations importantes. 26% de meilleure performance qu'OpenAI Memory sur les benchmarks multi-hop. Utile si tu construis des agents qui doivent retenir du contexte entre sessions.

Une ligne. Ça m'aide à calibrer les prochains numéros sur le niveau réel de votre pratique.