Les mots magiques ont cessé de marcher
Il y a deux ans, les équipes s'échangeaient des prompts comme des codes de triche. « Agis comme un avocat senior. » « Respire un grand coup et procède étape par étape. » Une partie aidait vraiment. La plupart relevait de la superstition, corrélée par hasard à de meilleurs modèles. Aujourd'hui, ces incantations ne changent presque plus rien, parce que les modèles sont devenus assez bons pour que la formulation astucieuse compte bien moins que l'information qu'on leur met réellement sous les yeux.
La compétence n'a pas disparu. Elle s'est déplacée. Le métier n'est plus de bien tourner une requête — c'est de réunir le bon contexte pour que le modèle puisse répondre tout court. Ce travail a un nom désormais : le context engineering. Et c'est une discipline réellement différente, plus proche de l'ingénierie des données et de la conception de systèmes que de la rédaction.
Ce que veut vraiment dire le context engineering
Le context engineering, c'est le travail de décider ce qu'un modèle voit au moment où il répond. Le prompt n'en est qu'une petite partie. Le contexte complet, c'est tout ce qui est dans la fenêtre : la question de l'utilisateur, les documents pertinents que vous avez récupérés, l'historique de conversation que vous avez choisi de garder, les sorties d'outils, les exemples, les instructions système et la mise en forme qui relie le tout. Obtenir le bon mélange, c'est là que naît désormais la qualité.
Même les guides officiels reflètent ce virage. Le guide de prompt engineering(lien externe, nouvel onglet) d'OpenAI ressemble moins à une liste de phrases magiques qu'à des conseils sur la fourniture d'instructions claires, de textes de référence et de structure. Des frameworks comme LangChain(lien externe, nouvel onglet) n'existent quasiment que pour résoudre l'assemblage du contexte — récupération, mémoire, orchestration — parce que c'est cette tuyauterie, pas la formulation, qui rend une fonctionnalité IA fiable.
Pourquoi la fenêtre est la vraie contrainte
Un modèle ne peut raisonner que sur ce qui tient dans son contexte, et gérer cet espace est devenu un problème d'ingénierie à part entière. Les fenêtres ont explosé — des centaines de milliers de tokens — mais plus grand n'est pas gratuit. Entassez-y trop de choses et le modèle perd le fil, la latence grimpe, la facture gonfle, ce qui rejoint directement ce que je disais dans le coût de l'IA va au-delà des tokens : chaque token ajouté est un coût et un risque, pas seulement une capacité.
Le vrai savoir-faire, c'est donc la curation, pas l'accumulation. Quels trois documents répondent réellement à cette question, parmi les dix mille que vous pourriez récupérer ? Quelle part d'historique vaut-il mieux garder plutôt que résumer ? Quand le modèle doit-il appeler un outil pour récupérer des données fraîches au lieu de s'appuyer sur un contexte périmé ? Ce sont des décisions de récupération, de classement et de mémoire — les mêmes réflexes qu'un bon ingénieur back-end possède déjà, pointés vers une nouvelle cible.
La fracture de compétences que cela crée
Le context engineering récompense ceux qui comprennent les systèmes, et il expose discrètement ceux qui n'ont appris qu'à discuter avec un modèle. J'écrivais dans le pair programming avec l'IA est un test de compétences que l'assistant amplifie le jugement existant plutôt que de le remplacer. Le context engineering, c'est le même effet un cran au-dessus. Quelqu'un qui comprend les pipelines de données, la récupération et où vit réellement l'information dans une entreprise construit des fonctionnalités IA qui marchent. Quelqu'un qui sait seulement formuler une requête construit des démos qui s'effondrent sur des données réelles.
Pour les gens du produit, cela recadre où investir. Le fossé défensif, c'est rarement le modèle — tout le monde loue les mêmes. C'est le contexte : vos données propriétaires, proprement récupérables, correctement classées, livrées au modèle au bon moment. C'est la version pratique de l'argument que je faisais dans l'IA générative pour les product owners — l'avantage vient de ce que vous donnez au système, pas du système lui-même.
Comment y devenir bon
Devenir bon en context engineering commence par regarder ce que votre modèle a réellement reçu, pas ce que vous supposiez qu'il avait reçu. Quand une fonctionnalité IA donne une mauvaise réponse, le réflexe est de bricoler le prompt. Le bon geste est d'inspecter toute la fenêtre de contexte et de se demander ce qui manquait, était faux ou noyé. Neuf fois sur dix, le correctif est dans la récupération ou la qualité des données, pas dans la formulation.
Quelques habitudes paient vite :
- Journaliser tout le contexte envoyé à chaque requête, pour déboguer ce que le modèle a vu au lieu de le deviner.
- Traiter la qualité de récupération comme une métrique produit — si le bon document n'est pas dans la fenêtre, aucun prompt ne vous sauve.
- Résumer et élaguer l'historique délibérément au lieu de reverser toute la conversation à chaque tour.
Rien de tout cela n'est glamour. C'est du travail de données. C'est précisément pour ça que l'avantage durable est désormais là, loin des raccourcis au feeling que je pointais dans le vibe coding ne sauvera pas votre produit.
Le Takeaway
Arrêtez de collectionner les prompts astucieux et commencez à auditer ce que votre modèle voit vraiment. La prochaine fois qu'une fonctionnalité IA déçoit, affichez toute la fenêtre de contexte avant de toucher à la formulation — la réponse est presque toujours dans ce que vous avez fourni, pas dans la manière de le demander.
