Ingénierie du contexte : ce qui a remplacé l’ingénierie de prompts
Longtemps, « travailler avec l’IA » voulait dire une seule chose : bien formuler un prompt. En 2025-2026, cela ne suffit plus. Les modèles appellent des tools, tirent des documents via RAG, gardent une mémoire de session et tournent dans des chaînes d’agents. Ce qui décide de la qualité n’est pas l’élégance de la phrase, mais l’ingénierie du contexte - la discipline qui conçoit exactement ce que le modèle voit à chaque étape : instructions, faits, historique, droits et limites. Ci-dessous - comment elle a remplacé l’ingénierie classique de prompts et comment l’appliquer dans les produits et processus internes.
- Prompt - texte d’instruction ; contexte - toute l’entrée du modèle à une étape
- Basculement - de « trouve la phrase magique » à « assemble le bon paquet de données »
- Couches - system, retrieval, mémoire, tools, état de la tâche, politiques
- Objectif - stabilité, moins d’hallucinations, maîtrise du coût des tokens
- Pratique - un contexte étroit et pertinent bat « tout fourrer dans la fenêtre »
- Pour le business - processus et architecture battent un chat chanceux dans ChatGPT
Qu’est-ce que l’ingénierie de prompts - et où elle a buté
L’ingénierie de prompts (prompt engineering) est l’art de formuler des requêtes LLM pour obtenir le style, le format et le comportement voulus : rôles (« tu es analyste senior »), exemples few-shot, chain-of-thought, templates de réponse stricts.
Elle marche bien pour :
- des tâches ponctuelles dans le chat ;
- la génération de brouillons ;
- former l’équipe « comment demander au modèle » ;
- des prototypes sans accès aux données internes.
La limite apparaît vite :
| Situation | Pourquoi un prompt seul ne suffit pas |
|---|---|
| Il faut des prix et règles à jour | Le modèle ne connaît pas votre tarif sans retrieval |
| Dialogue long / agent avec tools | La fenêtre se remplit de bruit ; le focus se perd |
| Plusieurs rôles et systèmes | Un system prompt « universel » se dilue |
| Contrôle risque et conformité | Politiques et masquage PII ne sont pas « une belle phrase » |
| Coût API | Tokens en trop à chaque tour = perte directe |
Le prompt reste une partie du système. Il a cessé d’être le levier principal de qualité.
Qu’est-ce que l’ingénierie du contexte
L’ingénierie du contexte (context engineering) conçoit le paquet d’entrée complet pour le modèle à chaque appel : quoi mettre dans system, quoi tirer de la base, quoi prendre de la mémoire, quels résultats de tools montrer, quoi écarter et quoi interdire.
Si le prompt est « comment demander », le contexte est « dans quel environnement informationnel le modèle répond ».
Couches typiques de contexte :
- Instructions et rôle - system prompt, politique de réponse, format JSON/Markdown.
- Tâche utilisateur - requête actuelle et historique minimal utile.
- Connaissances récupérées - fragments de wiki, CRM, code, FAQ via recherche/RAG.
- État - étape du funnel, id affaire, version document, résultat de l’étape précédente.
- Observations tools - sorties API, SQL, navigateur, outils MCP.
- Contraintes - « ne promets pas de remise », « ne cite pas de PII », « escalade à un humain ».
L’ingénieur de contexte pense comme un concepteur de pipeline, pas comme un copywriter de formules chanceuses.
Comment le contexte a remplacé la « magie du prompt »
| Avant (focus prompt) | Maintenant (focus contexte) |
|---|---|
| Long system prompt « pour tout » | Prompt étroit + assemblage dynamique de l’entrée |
| Coller le PDF entier dans le chat | Retrieval : seulement les chunks pertinents |
| « Souviens-toi de tout le dialogue » | Compression, résumé, mémoire sélective |
| Un modèle - un chat | Agents, orchestrateur + sous-agents, fenêtres séparées |
| Qualité = art de formuler | Qualité = pertinence, fraîcheur, ordre des couches |
| Déboguer le texte du prompt | Déboguer la source : miss retrieval, échec tool, overflow |
Le changement de paradigme ne signifie pas que les prompts sont « morts ». Ils sont devenus une couche aux côtés du retrieval, de la mémoire, des tools et des politiques - comme une requête SQL à côté du schéma et des index.
Pourquoi le basculement s’est accéléré en 2025-2026
Plusieurs facteurs ont convergé :
- Agents et tools - le modèle agit, ne se contente pas de répondre ; le contexte doit inclure les résultats des outils.
- Fenêtres longues - on peut mettre plus, mais « plus » sans tri = bruit et coût plus élevé.
- Données entreprise - sans RAG et versioning des documents, les réponses sont inutiles au business.
- Multi-agents - chaque sous-agent a besoin de son brief étroit, pas du log complet.
- Coût et latence - l’ingénieur de contexte optimise le budget tokens comme le backend le payload.
La pratique a donc glissé : du « prompt engineer » vers platform/ML eng et product qui construisent des pipelines de contexte.
Pratique : assembler le contexte pour une étape
Checklist utile avant l’appel LLM :
- Objectif de l’étape - ce qui doit sortir (JSON, décision, brouillon).
- Instructions minimales - sans dupliquer ce que tools et données fournissent déjà.
- Retrieval - top-k fragments avec métadonnées (source, date, version).
- Historique - seulement les tours pertinents ou un court résumé, pas tout le fil.
- Sorties tools - brutes mais tronquées ; pas de secrets ni de champs inutiles.
- Budget tokens - limite dure ; en overflow : instruction → tâche → faits → historique.
- Politiques - ce que le modèle ne peut pas affirmer sans un humain.
Exemple support :
[system] rôle + interdits + format
[retrieved] 3 chunks de la base de connaissances (avec date)
[state] id ticket, offre client, langue
[user] question actuelle
Pas comme ceci :
[system] 4 pages de « sois utile... »
[history] 80 messages en entier
[files] tout l’espace Notion
[user] question
Contexte vs prompt : que corriger si la réponse est mauvaise
| Symptôme | Souvent corrigé par le prompt | Souvent corrigé par le contexte |
|---|---|---|
| Mauvais ton / format | Oui : resserrer l’instruction | Rarement |
| Faits inventés | « N’invente pas » aide peu | Retrieval + refuser sans source |
| Contenu obsolète | Ajouter une date au prompt | Versions documents + filtre de fraîcheur |
| Le modèle « a oublié » la tâche | La répéter à la fin | Garder goal/state dans un bloc séparé |
| Cher et lent | Couper la politesse | Couper l’historique et le bruit retrieval |
| Action dangereuse | « Sois prudent » | Retirer le tool / exiger human-in-the-loop |
Règle de debug : d’abord les données et la sélection, ensuite la rédaction.
Ce que cela signifie pour le business
Si vous mettez de l’IA dans le CRM, le support, la recherche interne ou des agents de code :
- Le budget quitte les « cours de prompts pour managers » pour la qualité du corpus, l’indexation, les logs et les politiques d’accès.
- KPI qualité : hit-rate retrieval, part de réponses « avec source », coût par scénario, escalades humaines.
- Les playbooks de prompts restent utiles pour les chats manuels - mais l’IA produit se construit comme un pipeline de contexte.
- Choisir longue fenêtre, RAG ou fine-tuning est une décision d’architecture à part ; voir le décryptage.
Test de maturité pour le dirigeant : pouvez-vous expliquer de quelles sources le modèle a construit la réponse du cas d’hier ? Sinon - vous avez encore de l’ingénierie de prompts dans le chat, pas d’ingénierie du contexte dans le système.
Erreurs fréquentes
- Nourrir le modèle avec « tout ce qu’il y a » parce que la fenêtre est longue.
- Garder un system prompt géant au lieu d’un assemblage dynamique.
- Ne pas versionner les documents RAG - réponses sûres d’elles-mêmes mais périmées.
- Donner au sous-agent le log complet de l’orchestrateur au lieu d’un brief court.
- Cacher secrets et PII dans le contexte « parce que c’est pratique pour le modèle ».
- Confondre une meilleure formulation avec le colmatage d’un trou de données.
Conclusion
L’ingénierie de prompts nous a appris à parler aux modèles. L’ingénierie du contexte apprend à construire des systèmes où le modèle reçoit exactement l’information, les tools et les limites dont l’étape a besoin - ni plus ni moins. En 2026, la qualité de l’IA d’entreprise n’est pas définie par une « phrase magique », mais par un pipeline : sélection des faits, mémoire, tools, politiques et budget tokens. Le prompt reste une partie de ce pipeline - mais ce n’est plus le personnage principal.
Questions fréquemment posées
En quoi l’ingénierie du contexte diffère-t-elle de celle des prompts ?
Celle des prompts se concentre sur le texte d’instruction. Celle du contexte couvre toute l’entrée du modèle : instructions + faits récupérés + historique + état + résultats tools + interdits. Le prompt est une couche ; le contexte est le système qui assemble cette couche et les autres.
Faut-il encore du prompt engineering en 2026 ?
Oui, comme compétence et comme couche. Instructions claires, formats et few-shot comptent encore. Mais pour les produits et agents, un « prompt parfait » ne stabilise pas la qualité sans sélection de données, mémoire et politiques.
Est-ce la même chose que le RAG ?
Non : c’est plus large. Le RAG est une façon de remplir le contexte avec les connaissances du corpus. Le contexte inclut aussi la mémoire de dialogue, l’état du workflow, les sorties tools, les rôles et les politiques de sécurité. Le RAG est un composant typique et important, pas toute la discipline.
Par où commencer en entreprise ?
Choisissez un scénario (support, recherche de règlements, assistant commercial). Fixez les sources de vérité, ajoutez un retrieval avec dates/versions, compressez l’historique en résumé et journalisez « ce qui est entré dans le contexte ». Affinez le prompt une fois que les données cessent de mentir.
Comment savoir que le problème est le contexte, pas le modèle ?
Si changer de modèle (GPT → Claude → Gemini) change à peine l’erreur, mais changer le document / le top-k / la coupe d’historique la change - le problème est l’assemblage de l’entrée. Changez de fournisseur seulement quand le pipeline de contexte est transparent et mesurable.