Pourquoi un bon prompt ne suffit pas à obtenir une bonne réponse d'IA ?
J'ai longtemps cru que la qualité d'une réponse dépendait surtout de la qualité du prompt. C'est faux. Un prompt parfait placé dans un mauvais contexte donne une réponse médiocre. L'IA ne raisonne pas dans le vide : elle s'appuie sur tout ce qui se trouve dans sa fenêtre de contexte. Si cette fenêtre contient du bruit, des informations périmées ou des instructions contradictoires, elle produira quelque chose de décevant, même avec la meilleure formulation du monde.
Dans mon métier, je vois régulièrement des personnes passer des heures à peaufiner un prompt alors que le vrai problème est ailleurs. Le modèle n'a pas accès au bon fichier. Il a oublié les décisions prises la veille. Il ignore les conventions du projet. Ce sont des problèmes de contexte, pas de prompt.
Context engineering : définition simple et concrète
Le context engineering désigne l'ensemble des pratiques qui consistent à sélectionner, structurer et maintenir ce que l'IA reçoit avant et pendant son travail. Cela inclut plusieurs couches :
- Les fichiers : documents, code, données que vous fournissez explicitement à la session.
- La mémoire : ce que l'outil retient entre deux sessions, via des fichiers de projet ou des notes persistantes.
- Les exemples : échantillons de sorties attendues qui guident le style et le format.
- Les règles : contraintes durables, comme un ton à respecter ou des interdits.
- L'historique : les échanges précédents de la conversation, qui pèsent autant que votre dernier message.
Penser en termes de contexte change la posture. On arrête d'écrire des prompts toujours plus longs. On commence à orchestrer un environnement dans lequel l'IA travaille bien par défaut.
un prompt est un message, un contexte est un environnement
Quels sont les composants d'un bon contexte pour une IA ?
Comment choisir les bons fichiers à fournir ?
Trop de contexte tue le contexte. Fournir vingt documents quand trois suffisent dilue l'attention du modèle et augmente le risque d'erreur. Ma règle : chaque fichier présent dans le contexte doit pouvoir justifier sa présence. Avant une session, je me demande quelle information est indispensable pour répondre correctement. Je fournis uniquement cela.
Concrètement, pour rédiger un livrable, je donne : la consigne, un exemple de livrable antérieur validé, et les contraintes spécifiques. Rien de plus. La qualité monte, le coût et la latence baissent.
À quoi sert la mémoire de projet ?
Certains outils permettent de stocker des instructions permanentes liées à un projet. Claude Code utilise par exemple un fichier dédié aux conventions du dépôt. J'y consigne les décisions stables : ton éditorial, structure des livrables, interdits. Chaque nouvelle session démarre donc avec le capital accumulé, sans avoir à tout réexpliquer.
C'est le sujet d'un article complet que j'ai écrit sur la mémoire de projet avec Claude.md. Si vous travaillez sur un même projet sur plusieurs semaines, c'est le levier numéro un.
Pourquoi les exemples valent mieux que les descriptions ?
Décrire le résultat attendu prend dix lignes et reste ambigu. Montrer un exemple validé prend un fichier et laisse peu de place à l'interprétation. Je garde systématiquement un ou deux exemples de référence par type de tâche. Quand le style dérive, je remplace la description par l'exemple, jamais l'inverse.
Que se passe-t-il quand le contexte se dégrade au fil d'une session ?
Un phénomène méconnu mais central : le context rot. Plus une session s'allonge, plus le contexte s'encombre d'échanges anciens, de corrections, de fausses pistes. Les réponses perdent en précision. L'IA semble oublier vos premières instructions, alors qu'elles sont encore là, noyées sous le bruit.
J'y ai consacré un article détaillé sur le context rot et les sessions IA qui dérivent. En pratique, j'applique trois réflexes : sessions courtes et ciblées, redémarrage propre quand la qualité baisse, et report des décisions importantes dans la mémoire de projet plutôt que dans l'historique de conversation.
une session longue n'est pas un capital, c'est souvent une dette
Comment bien contextualiser une IA en pratique : ma méthode en cinq étapes
- Lister les informations indispensables à la tâche avant d'ouvrir l'outil. Trois à cinq éléments suffisent dans la plupart des cas.
- Préparer les fichiers : consigne claire, exemple de référence, données nécessaires. Nettoyés, nommés lisiblement.
- Configurer la mémoire de projet avec les règles durables, pour ne pas les répéter à chaque session.
- Démarrer une session courte, tester, et ajuster le contexte plutôt que le prompt quand le résultat déçoit.
- Capitaliser : chaque décision stable repart dans la mémoire, chaque exemple réussi devient référence.
Cette méthode m'a servi sur mes propres projets. Pour Scoutcite, un micro-SaaS monté seul en une journée, j'avais préparé à l'avance le cahier des charges, un exemple d'interface attendue et les contraintes techniques. Le contexte était prêt avant la première ligne de code. Même logique pour mon second cerveau IA : la valeur vient moins des requêtes que de la qualité des documents qui l'alimentent.
Context engineering vs prompt engineering : quelle différence ?
Le prompt engineering optimise un message. Le context engineering conçoit l'environnement complet dans lequel ce message est reçu. Les deux se complètent, mais ils n'ont pas le même rendement. Dans mon expérience, améliorer le contexte d'une tâche récurrente produit des gains plus durables que peaufiner indéfiniment le prompt. Le prompt se réécrit à chaque usage. Le contexte se construit une fois et sert partout.
C'est aussi ce qui distingue un usage ponctuel d'un usage professionnel de l'IA. Si vous voulez aller plus loin sur cette progression, j'ai décrit les niveaux d'usage de l'IA et le passage d'un usage artisanal à un usage structuré.
Par où commencer avec le context engineering ?
Commencez petit. Choisissez une tâche que vous répétez chaque semaine. Préparez son contexte idéal une fois : consigne type, exemple validé, règles. Stockez-le. Testez. Vous verrez rapidement si la qualité monte et si le temps passé baisse. Si c'est le cas, industrialisez : créez un gabarit de contexte par tâche récurrente.
Si vous préférez avancer accompagné, je propose des sessions de cadrage pour identifier les tâches de votre équipe qui gagneraient le plus d'un contexte bien construit. Vous pouvez aussi consulter mes réalisations pour voir des cas concrets.