Table des matières
Tu décris ton projet, l'IA code... et ça part dans tous les sens.
Elle invente des fonctions qui n'existent pas. Elle utilise une version obsolète d'une lib. Elle oublie ton architecture et recrée des composants que t'as déjà.
Le problème ? Ce n'est pas l'IA. C'est ce que tu lui as donné.
L'IA code avec ce qu'elle sait. Et ce qu'elle sait dépend entièrement de toi.
C'est là qu'intervient le context engineering.
J'ai déjà partagé mon workflow concret pour structurer mes projets avec Claude Code. Là, on prend du recul. Pourquoi c'est important, ce qu'il y a derrière, et comment ça change ta façon de bosser avec l'IA.
Si tu veux juste implémenter, va lire l'autre article. Si tu veux comprendre pour créer ton propre système, reste ici.
Une précision aussi : ici on parle de projets de code. Si ce que tu cherches, c'est donner du contexte à l'IA pour ta vie et ton travail en général, j'ai écrit un article à part pour ça.
Le context engineering, c'est quoi ?
Prends deux développeurs de niveau égal. Le premier arrive sur ton projet, ouvre le dépôt, lit la doc, regarde comment les autres composants sont écrits. Le second reçoit une phrase par message et code aussitôt.
Le second va plus vite pendant vingt minutes. Après, il réécrit ce qui existe déjà, choisit une stack au hasard, et invente une architecture que tu n'aurais jamais validée.
Mais si tu lui donnes un onboarding complet : la doc du projet, les conventions de code, les erreurs à éviter, des exemples de ce qui a marché. Là, il devient productif immédiatement.
L'IA, c'est pareil.
Le context engineering, c'est construire cet onboarding. C'est donner à l'IA tout ce dont elle a besoin pour comprendre ton projet, tes contraintes, et ce que tu attends vraiment.
Ce n'est pas juste du prompt engineering
Le prompt engineering, c'est bien formuler ta demande. Trouver les bons mots pour obtenir une meilleure réponse.
Le context engineering va plus loin. C'est un écosystème complet :
- De la documentation
- Des exemples de code
- Des conventions à respecter
- Un historique de ce qui a été fait
- Des contraintes explicites
Le prompt engineering, c'est une partie du context engineering. Mais ce n'est qu'une partie.
Pourquoi c'est crucial
L'IA est puissante. Mais elle a trois problèmes fondamentaux.
1. Sa documentation est parfois obsolète
L'IA a été entraînée à une date précise. Tout ce qui s'est passé après, elle ne le connaît pas.
Les nouvelles versions de Next.js, les changements d'API de Supabase, les bonnes pratiques qui ont évolué... Si tu ne lui donnes pas la doc à jour, elle code avec ce qu'elle savait il y a 6 mois ou 2 ans.
Résultat : du code qui utilise des méthodes dépréciées, des patterns obsolètes, des approches qu'on ne recommande plus.
La solution : Tu lui donnes la documentation actuelle. Elle code avec les bonnes pratiques d'aujourd'hui.
2. Elle ne connaît pas ton projet
L'IA ne sait rien de ton architecture, de ta stack, de tes conventions. Pour elle, chaque conversation repart de zéro.
Si tu lui dis juste "ajoute une feature", elle va improviser. Elle va choisir une approche qui n'est peut-être pas cohérente avec ce que tu as déjà construit.
La solution : Tu lui donnes le contexte de ton projet : structure, conventions, exemples de code existant. Elle s'aligne sur ce qui existe.
3. Sans direction, elle part dans tous les sens
L'IA veut te faire plaisir. Si tu restes vague, elle remplit les blancs comme elle peut. Et souvent, pas comme tu l'aurais voulu.
"Fais-moi un formulaire" → Elle choisit une lib au hasard, un style qu'elle invente, une validation qu'elle imagine.
"Fais-moi un formulaire avec react-hook-form, validation Zod, style cohérent avec le reste de l'app, et gère les erreurs comme dans UserForm.tsx" → Elle fait exactement ce que tu veux.
La solution : Tu poses des contraintes claires. Elle prend les bonnes décisions.
Le vrai bénéfice
Quand tu donnes le bon contexte à l'IA, vous pouvez designer le projet ensemble.
Elle anticipe les problèmes parce qu'elle connaît les contraintes. Elle propose des solutions cohérentes parce qu'elle comprend l'architecture. Elle fait un bon plan dès le début parce qu'elle a toutes les infos.
C'est la différence entre un assistant qui exécute au hasard et un collaborateur qui comprend le projet.
Les composants du context engineering
Le context engineering, c'est un ensemble de briques. Chacune apporte un type de contexte différent à l'IA.
Le prompt engineering
C'est la brique la plus connue. Bien formuler ta demande pour obtenir une meilleure réponse.
Mais écrire un bon prompt à chaque fois, c'est fastidieux. D'où l'intérêt de les stocker et réutiliser. J'ai même construit un outil pour ça, une bibliothèque où je rangeais mes prompts qui marchaient.
Je ne m'en sers plus, et pas parce qu'il était raté. Parce que le problème a disparu. Ranger ses prompts, c'était une réponse au fait que l'IA ne se souvenait de rien d'une session à l'autre. Aujourd'hui, ce que je rangeais dans cette bibliothèque vit dans les fichiers du projet, et l'IA va les lire toute seule.
C'est exactement le déplacement dont parle cet article : on croit avoir un problème de prompt, on a un problème de contexte.
Et ce déplacement a continué. L'étape d'après, c'étaient les commands : des prompts préfaits qu'on déclenche avec un raccourci, une commande qui charge le contexte du projet, une autre qui commite proprement. J'en parlais dans MCP, agents, commandes.
Aujourd'hui, tout ça a été remplacé par les skills. Un skill, c'est un dossier de markdown qui décrit une façon de faire, et que l'IA va chercher elle-même quand le sujet s'y prête. Tu ne déclenches plus rien à la main.
Regarde le chemin parcouru : un prompt qu'on rangeait dans une bibliothèque, puis qu'on appelait par un raccourci, et maintenant un fichier que l'IA ouvre toute seule au bon moment. À chaque étape, le prompt s'éloigne de toi et se rapproche du contexte. C'est tout le sujet de cet article.
Le RAG (documentation externe)
L'IA ne sait que ce qu'on lui a appris. Mais tu peux lui donner accès à de la documentation externe, en temps réel.
C'est ce qu'on appelle le RAG (Retrieval-Augmented Generation). L'IA va chercher l'info dont elle a besoin dans une base de connaissances, puis l'utilise pour te répondre.
Ce que j'utilise :
- Context7 : un MCP qui donne accès à la doc de milliers de libs, toujours à jour
- qmd : un moteur de recherche qui tourne entièrement sur ma machine, sur mes fichiers markdown. Il cherche par mot exact et par sens. Je peux lui demander "la note où j'expliquais pourquoi je voulais arrêter ça" sans me souvenir d'un seul mot du texte, et il la sort. Rien ne part sur Internet, et il ne réindexe que ce qui a changé.
J'ai longtemps fait tourner mon propre service pour ça, avec une base vectorielle sur un serveur. Je l'ai abandonné pour une raison bête : il fallait revectoriser à chaque modification, donc l'index était toujours en retard sur mes notes. Un outil local qui ne réindexe que le delta règle le problème, sans serveur à maintenir.
Et pour du code, chercher par le sens ne suffit pas. Quand la vraie question est "qui appelle cette fonction, qu'est-ce que je casse si j'y touche", il te faut un graphe d'appels, pas un moteur de recherche. Je teste code-review-graph pour ça : il lit le dépôt, range les symboles et leurs relations dans une base locale, et répond à cette question précise. Je ne le laisse pas tourner en permanence, je le sors quand la question se pose.
Tu peux aussi simplement donner des liens vers d'autres projets et demander à l'IA d'aller les explorer pour s'en inspirer.
La mémoire (Memory Bank)
L'IA oublie tout entre les sessions. Chaque nouvelle conversation repart de zéro.
La solution : documenter ce que l'IA doit savoir dans des fichiers qu'elle lit au démarrage.
- CLAUDE.md : la carte du projet, les conventions, où trouver quoi
- Memory Bank : un dossier avec le contexte, l'architecture, les décisions prises
C'est le cœur de mon workflow.
L'état et l'historique
Si le mécanisme de saturation ne te parle pas, je l'ai expliqué en détail ici.
Ce que l'IA a fait dans la conversation en cours. Les fichiers qu'elle a lus, les décisions qu'elle a prises, les erreurs qu'elle a corrigées.
Plus la conversation avance, plus ce contexte se remplit. Et plus la fenêtre de contexte se sature. D'où l'importance de bien structurer ses sessions.
Les frameworks existants
Plusieurs personnes ont formalisé des approches complètes :
- PRP (Product Requirements Prompt) de Cole Medin et Raasmus
- BMAD (Breakthrough Method for Agile AI-Driven Development)
- GitHub SpecKit
Ce sont des variations du même principe : donner à l'IA un contexte structuré pour qu'elle produise du code de qualité.
Je me suis inspiré du PRP, mais j'ai trouvé que ça faisait trop de choses d'un coup. La fenêtre de contexte se remplit vite, et tu perds en maîtrise. J'ai préféré construire mon propre système, plus modulaire.
L'important, c'est de comprendre les principes. Ensuite, tu adaptes à ta façon de travailler.
Pour qui ? (Spoiler : surtout les débutants)
On pourrait croire que le context engineering, c'est un truc de dev senior. Que c'est pour ceux qui maîtrisent déjà.
C'est l'inverse.
Plus tu débutes, plus c'est utile
Quand tu connais bien une techno, tu peux corriger l'IA quand elle se trompe. Tu vois qu'elle utilise une mauvaise approche, tu la recadres.
Quand tu débutes, tu ne vois pas les erreurs. Tu fais confiance. Et l'IA t'emmène dans le mur sans que tu t'en rendes compte.
Le context engineering, c'est ta protection. Tu donnes à l'IA la bonne documentation, les bonnes contraintes, les bons exemples, et elle part dans la bonne direction dès le départ. Même si toi, tu ne saurais pas détecter une erreur.
Ça s'améliore avec la pratique
Plus tu connais les outils et les technos, mieux tu fais du context engineering.
Tu sais quelle doc donner. Tu sais quelles contraintes poser. Tu sais quels exemples sont pertinents.
Mais tu n'as pas besoin d'être expert pour commencer. Tu commences avec ce que tu as, et tu t'améliores au fil des projets.
Dans mon accompagnement
C'est exactement ce que je fais avec les gens que j'accompagne : je leur donne la documentation, je leur montre vers quoi s'orienter, je leur évite les pièges classiques.
Le context engineering, c'est transmettre le bon contexte. Que ce soit à une IA ou à un humain qui débute.
Le vibecoding inclut le context engineering
Le vibecoding "pur", décrire ce qu'on veut et laisser l'IA se débrouiller, ça ne tient pas sur les vrais projets.
Ça marche pour un petit script, un prototype rapide. Mais dès que le projet grossit, ça s'effondre.
Ce que j'appelle vibecoding, c'est un processus complet :
- Tester régulièrement au lieu d'attendre la fin
- Affiner en donnant des directives précises
- Aider l'IA avec de la documentation à jour
- Avoir un plan général et une vue d'ensemble
La "vibe", c'est pas le laisser-aller. C'est un processus bien huilé qui te permet de créer ce que tu veux, avec l'IA comme collaborateur, pas comme boîte noire.
Le context engineering, c'est ce qui rend ça possible.
Pour aller plus loin :
- Mon workflow concret pour structurer tes projets (réservé aux abonnés)
- Les tokens et le contexte pour comprendre pourquoi l'IA oublie
- MCP, agents, commandes pour les outils qui boostent ton IA
Commentaires