Si vous suivez l'actualité de l'IA appliquée en entreprise, vous avez certainement entendu parler du RAG - Retrieval-Augmented Generation. C'est la technique qui consiste à enrichir le prompt d'un LLM avec des documents pertinents récupérés dynamiquement depuis une base de connaissances. C'est utile, souvent insuffisant.
Le Context Engineering est une discipline plus large qui englobe le RAG mais va bien au-delà. Comprendre la différence vous aidera à poser les bonnes questions quand vous évaluez des solutions IA.
Ce qu'est le RAG
Le RAG est une architecture technique. Voici comment ça fonctionne en pratique :
- L'utilisateur pose une question.
- Un moteur de recherche (vectoriel, BM25, ou hybride) récupère les documents les plus pertinents depuis votre base de connaissances.
- Ces documents sont ajoutés au prompt.
- Le LLM génère une réponse en s'appuyant sur ces documents.
C'est une avancée majeure par rapport aux LLMs sans contexte. Mais le RAG est un composant - pas une stratégie complète.
Les limites du RAG seul
Le RAG ne répond pas à plusieurs questions pourtant critiques :
- Quelle est la qualité du contexte récupéré ? Un bon moteur de recherche ne garantit pas des documents bien structurés, à jour ou non contradictoires.
- Comment mesure-t-on la qualité des réponses ? Le RAG est une mécanique de récupération. Il ne dit rien sur l'évaluation.
- Qui gouverne la base de connaissances ? Si personne ne maintient le corpus, le RAG récupérera des informations obsolètes avec la même efficacité que des informations fraîches.
- Comment gérer le budget de tokens ? Récupérer trop de contexte coûte cher et peut dégrader les réponses. Trop peu, et la réponse est incomplète.
Ce qu'est le Context Engineering
Le Context Engineering recouvre l'ensemble des décisions et pratiques qui déterminent ce que reçoit un LLM au moment d'une requête - pas seulement le mécanisme de récupération, mais aussi :
- La structuration et la gouvernance du corpus source (SSOT)
- Le choix du mode de recherche (sémantique, lexical, graphe de connaissances, hybride)
- La gestion du budget de tokens : équilibre entre quantité et pertinence du contexte
- L'évaluation continue de la qualité (RAGAS, tests de régression)
- La traçabilité : quelle source a produit quelle réponse
- La mise à jour et la synchronisation des sources
Le RAG est un sous-ensemble du Context Engineering. C'est le moteur de récupération. Le Context Engineering, c'est tout ce qui l'entoure.
Un exemple concret
Prenons une entreprise qui déploie un assistant IA pour son service client. Elle met en place du RAG sur sa base documentaire. Les premières semaines sont prometteuses. Trois mois plus tard, les réponses se dégradent : un produit a changé de nom, une procédure a été mise à jour, et deux documents contradictoires se retrouvent dans le corpus.
Le RAG fait son travail - il récupère les documents les plus similaires sémantiquement. Mais si personne n'a maintenu la base, si personne ne mesure la qualité des réponses, et si le budget de tokens n'est pas optimisé, le système se dégrade silencieusement.
Un approche de Context Engineering aurait anticipé ces problèmes : cycle de mise à jour documentaire, score RAGAS en continu, alertes en cas de dégradation.
Comment choisir ?
Si vous êtes en phase de prototypage et que vous voulez valider rapidement qu'un LLM peut utilement répondre à vos questions avec vos données, un RAG simple suffit. C'est le bon point de départ.
Si vous passez en production, si l'adoption interne est un enjeu, si la qualité des réponses touche à des décisions importantes ou à des données sensibles - vous avez besoin de Context Engineering, pas seulement de RAG.
Conclusion
Le RAG est ce qui fait que votre LLM peut lire vos documents. Le Context Engineering est ce qui fait que votre LLM peut faire confiance à vos documents - et que vous pouvez avoir confiance dans ses réponses. La nuance est petite, mais les conséquences opérationnelles sont considérables.