Dans la plupart des organisations qui déploient de l'IA, le mot RAG est rapidement devenu synonyme de « contexte pour LLM ». Branchez vos documents sur un moteur de recherche vectoriel, injectez les résultats dans le prompt, et vous avez du RAG. C'est techniquement exact – mais ça ne résout pas la moitié des problèmes rencontrés en production.
Le context engineering est la discipline plus large qui adresse ces problèmes. Comprendre la différence est utile avant de concevoir ou d'évaluer un système IA d'entreprise.
Ce que le RAG fait précisément
RAG signifie Retrieval-Augmented Generation. Le mécanisme se déroule en trois étapes :
- Récupération : à partir de la question posée, un moteur de recherche retrouve les fragments de documents les plus pertinents dans une base indexée.
- Injection : ces fragments sont ajoutés au prompt envoyé au modèle, avec la question.
- Génération : le modèle répond en s'appuyant sur ce contexte injecté, plutôt que sur sa seule mémoire d'entraînement.
C'est efficace pour améliorer la précision sur un corpus défini. Mais ce mécanisme suppose que les étapes en amont (structuration, nettoyage, versionnement, hiérarchisation des sources) ont déjà été faites. Ce n'est presque jamais le cas au démarrage.
Les quatre lacunes du RAG seul
Les équipes qui se limitent à un RAG standard rencontrent généralement ces problèmes dans les 6 à 12 mois :
- Qualité des sources non contrôlée : le RAG est un moteur, pas un éditeur. Il récupère ce qui est dans la base – y compris les documents obsolètes, contradictoires ou mal rédigés. Sans gouvernance en amont, ces sources dégradent la qualité des réponses.
- Gestion des versions absente : si plusieurs versions d'un document coexistent sans qu'une règle de priorité soit définie, le moteur peut remonter n'importe laquelle. Le résultat est une réponse qui reflète le droit, la procédure ou la politique d'une date antérieure.
- Pas de hiérarchie d'autorité : le RAG ne sait pas que votre procédure interne fait autorité sur un article Wikipedia. Sans inscription explicite de cette hiérarchie dans les métadonnées et le scoring, tous les documents sont traités à égalité.
- Boucle de qualité inexistante : comment savoir que le système se dégrade ? Le RAG seul ne mesure pas sa propre pertinence dans le temps. Sans métriques (précision, rappel, taux de désaccord), les équipes ne détectent la dégradation qu'à travers les plaintes des utilisateurs.
Ce que le context engineering couvre en plus
Le context engineering est la discipline qui s'occupe de tout ce que le RAG suppose déjà résolu. Elle couvre :
- La structuration et le découpage des sources (chunking, métadonnées, hiérarchies).
- La gestion des versions et l'invalidation des documents obsolètes.
- La définition des sources d'autorité et leur poids dans le retrieval.
- La mesure de la qualité contexte-réponse (métriques RAGAS : faithfulness, recall, precision).
- La gouvernance des mises à jour : qui décide qu'un document entre dans la base ? Quand ? Selon quel processus ?
- L'optimisation du budget de tokens : quoi inclure dans le prompt quand les sources sont trop nombreuses ?
- La détection des dérives dans le temps et la remontée d'alertes.
- La gestion de la mémoire entre sessions pour les usages continus.
En résumé : le RAG est le moteur. Le context engineering est la discipline qui construit, entretient et améliore tout ce sur quoi ce moteur opère.
Un scénario de dégradation typique
Voici ce qui se passe concrètement dans un projet RAG sans context engineering :
Mois 1 : le système est déployé avec 200 documents soigneusement sélectionnés. Les réponses sont bonnes.
Mois 4 : les équipes ont ajouté 150 documents supplémentaires. Certaines procédures ont été mises à jour – les deux versions coexistent dans la base. La qualité des réponses commence à baisser sur les sujets les plus évolutifs.
Mois 8 : personne ne sait exactement ce qui est dans la base. Les utilisateurs signalent des incohérences. Un audit révèle que 30% des documents ont une version plus récente non indexée. L'équipe n'a pas les métriques pour avoir détecté la dégradation en temps réel.
Ce scénario est commun. Il ne vient pas d'un mauvais moteur RAG – il vient de l'absence de gouvernance du contexte.
Par où commencer
Si vous démarrez un projet aujourd'hui, deux bonnes pratiques à intégrer dès le premier sprint :
- Métadonnées temporelles obligatoires : date de création, date de modification, date de validité (si applicable). Elles permettent de filtrer les documents périmés avant même que le moteur de recherche intervienne.
- Mesure RAGAS dès le départ : mettre en place un jeu de questions de référence avec les réponses attendues, et mesurer la précision et la fidélité du système à intervalles réguliers. Sans baseline, impossible de savoir si le système s'améliore ou se dégrade.
Conclusion
Le RAG est une brique essentielle. Mais un système IA durable en entreprise nécessite la discipline complète du context engineering. La différence se mesure rarement au lancement – elle devient évidente à 6, 12 ou 18 mois d'exploitation.