Si tu traînes dans le monde des LLM (ChatGPT & compagnie), tu as forcément vu passer le nouveau mot à la mode : Context Engineering. Et si tu as déjà souffert sur des prompts, tu t’es peut-être dit : “OK… donc c’est Prompt Engineering mais avec un nom plus cher ?”
Pas totalement. Mais avouons-le : l’écosystème IA adore renommer des trucs pour avoir l’air de découvrir la gravité.
Dans cet article, on va poser les bases, façon billet d’humeur : Context Engineering vs Prompt Engineering, c’est quoi la différence, pourquoi ça compte, et surtout pourquoi en Data ça devient… un petit sujet de migraine.
Prompt Engineering : l’art d’écrire des consignes au millimètre (et d’espérer)
Le Prompt Engineering, c’est quand tu passes ton temps à rédiger des instructions pour un modèle de langage :
- “Tu es un expert en data”
- “Réponds en JSON”
- “Sois concis”
- “Ne fabrique rien”
- “Cite tes sources”
- “Ne dis pas ‘ça dépend’”
Puis le modèle te répond avec une prose de 900 lignes, un JSON cassé, et un KPI inventé avec l’assurance d’un consultant en fin de mission.
Le prompt engineering, c’est la rhétorique : tu ajustes le ton, la structure, les contraintes, les exemples. C’est utile, parfois même indispensable. Mais ça reste une vérité simple :
tu joues sur la façon de parler au modèle.
Context Engineering : l’art de nourrir le modèle (plutôt que de le supplier)
Le Context Engineering, c’est quand tu réalises que le problème n’est pas seulement “comment je lui demande”, mais surtout :
“Qu’est-ce que je lui donne à voir, exactement, au moment où il répond ?”
Le contexte, c’est tout ce qui remplit la fenêtre de contexte d’un LLM :
- l’historique de conversation,
- les documents récupérés (RAG),
- les résultats d’outils,
- la mémoire,
- le profil utilisateur,
- les règles de conformité,
- les contraintes de format,
- les morceaux de spec, de data dictionary, de glossaire…
Et là, tu comprends une deuxième vérité, encore plus gênante :
un bon prompt avec un mauvais contexte donnera une mauvaise réponse.
un prompt moyen avec un contexte nickel donne souvent une réponse très solide.
Petite analogie (très scientifique, je te jure)
- Prompt Engineering : tu écris le script.
- Context Engineering : tu choisis la scène, le décor, les acteurs, la lumière… et tu vires les figurants qui racontent n’importe quoi.
Pourquoi “Context Engineering” devient un sujet chaud avec les LLM ?
Parce qu’on n’est plus dans le mode : “une question → une réponse”.
On est passé au mode : “un agent IA → plusieurs étapes → recherche → outils → synthèse → vérification (ou pas) → décision”.
Et là, le contexte devient :
- un budget (tokens = coût),
- un risque (bruit, contradictions, données obsolètes),
- un levier de performance (pertinence, précision, conformité).
En pratique, le context engineering, c’est gérer des opérations très concrètes :
- sélectionner les bonnes sources (pas tout, pas n’importe quoi),
- compresser (résumer, structurer, extraire l’essentiel),
- isoler (séparer des sous-contextes, agents, étapes),
- maintenir (éviter l’historique kilométrique et les répétitions),
- prioriser (ce qui compte, ce qui est accessoire),
- tracer (d’où vient l’info, et pourquoi elle est là).
C’est moins glamour qu’un prompt en caps lock… mais c’est là que les applis IA cessent d’être des démos et commencent à être des produits.
Context Engineering vs Prompt Engineering : la différence qui pique
Soyons clairs :
Le Prompt Engineering répond à :
“Qu’est-ce que je demande au modèle ?”
Le Context Engineering répond à :
“Qu’est-ce que je mets dans sa tête juste avant qu’il réponde ?”
Et si tu bosses avec des LLM en entreprise, c’est souvent LE sujet : parce que l’entreprise, c’est un endroit merveilleux où :
- une définition existe en 3 versions,
- le glossaire a été “mis à jour” en 2019,
- le datamart “final” n’est pas celui en prod,
- et le fichier Excel “référence” s’appelle copie_de_copie_v8_definitif.xlsx.
Résultat : tu peux faire le prompt le plus élégant du monde… si tu donnes au modèle un contexte bancal, il fera ce qu’il peut avec ce qu’il a. Et parfois, ce qu’il a, c’est du folklore.
En Data, le contexte… c’est la sémantique (et ça ne se bricole pas)
En Data, le “contexte” n’est pas juste un paquet de documents. Le contexte, c’est :
- une définition métier,
- une règle de calcul,
- une granularité,
- une dimension,
- une hiérarchie,
- un lineage,
- un niveau de qualité,
- un périmètre de vérité.
Donc quand un LLM répond à une question du type :
“C’est quoi un client actif ?”
La vraie question, c’est :
- Sur quel référentiel ?
- Pour quel périmètre ?
- À quelle date ?
- Selon quelle règle métier ?
- Avec quelle granularité ?
- Et où est la source de vérité ?
Sans ça, ce n’est pas “de l’IA qui hallucine”. C’est juste un système à qui on a donné un contexte flou et qui fait de son mieux pour remplir les trous.
Et là, le context engineering devient un truc beaucoup plus sérieux qu’une recette de prompt : c’est de l’ingénierie de la connaissance.
Conclusion : le prompt c’est le volant, le contexte c’est la route
On peut continuer à fétichiser le prompt. Mais dans la vraie vie, surtout en entreprise, la performance vient souvent de la qualité du contexte. Chez Follow-Us, on commence à voir un virage : le futur n’est pas « qui a le meilleur prompt », mais qui sait construire un contexte fiable, traçable et utile à partir de la réalité Data de l’entreprise.
Et c’est là qu’une question nous obsède de plus en plus : si le contexte est ce qui fait la différence… est-ce qu’on ne devrait pas arrêter de l’assembler comme un patchwork de documents, et commencer à le construire à partir d’un besoin réel, exprimé et construit ? Cette question fondamentale – « contexte structuré versus approche patchwork » – sera justement au cœur d’une série d’articles à venir, où nous explorerons les pistes concrètes pour construire des contextes structurés, pérennes et réellement adaptés aux défis de l’IA en entreprise.
Parce que si l’IA peut assister les data modelers à modéliser conceptuellement les entrepôts de données d’entreprise, alors… à quoi ressemblerait le « contexte » ?