RAG en production : 7 pièges à éviter

Le RAG — Retrieval-Augmented Generation — s'est imposé comme la méthode de référence pour connecter un grand modèle de langage aux données d'une entreprise. Le principe paraît simple : retrouver les documents pertinents, puis demander au modèle de répondre en s'appuyant dessus, avec citations à l'appui. La démonstration se monte en une après-midi et impressionne. La version qui tient vraiment en production — fiable, sécurisée, économiquement viable — est une tout autre histoire.

Sur nos missions d'intelligence artificielle, nous voyons les mêmes écueils revenir d'un projet à l'autre. La bonne nouvelle, c'est qu'ils sont parfaitement évitables quand on aborde le RAG pour ce qu'il est : un système de recherche d'information augmenté, donc un projet d'ingénierie de la donnée avant d'être un projet de modèle.

Pourquoi un RAG de démonstration ne tient pas en production

Un prototype se construit sur quelques documents propres et une poignée de questions favorables. En production, le système affronte des milliers de documents hétérogènes, des questions ambiguës, des utilisateurs aux droits différents et des exigences de coût et de latence. L'écart entre les deux n'est presque jamais une question de modèle : c'est la qualité de la recherche, la rigueur de l'évaluation et l'intégration au métier qui font la différence.

« Un RAG médiocre, ce n'est presque jamais le modèle. C'est la recherche. »

Les sept pièges les plus fréquents — et comment les éviter

Voici, dans l'ordre où ils font dérailler un projet, les sept pièges que nous rencontrons le plus souvent, et la manière dont nous les traitons concrètement.

1. Négliger l'indexation au profit du modèle

L'erreur la plus commune est de se concentrer sur le choix du LLM alors que la qualité d'un RAG dépend d'abord de ce qu'on lui donne à lire. Un découpage des documents (chunking) mal pensé — trop fin, trop grossier, ignorant la structure — et le système remonte des passages hors contexte que même le meilleur modèle ne saura exploiter. Avant de parler de modèle, on travaille la segmentation, l'enrichissement par métadonnées et la stratégie d'indexation.

2. Tout miser sur la recherche vectorielle

La similarité sémantique est puissante, mais elle rate les correspondances exactes : références produit, codes réglementaires, noms propres, numéros de version. Un RAG robuste combine recherche vectorielle et recherche lexicale (BM25), puis réordonne les résultats avec un reranker. Cette approche hybride améliore nettement la pertinence, surtout sur des corpus techniques ou réglementés.

3. Traiter les droits d'accès après coup

Un assistant ne doit jamais exposer un document auquel l'utilisateur n'a pas droit. Le filtrage par permissions doit s'appliquer au moment de la recherche, et non en post-traitement — sous peine de fuite de données. C'est un sujet critique dès qu'on touche à des informations sensibles, en santé comme en finance & assurance, où la conformité n'est pas négociable.

4. Avancer sans jeu d'évaluation

Sans dispositif de mesure, chaque ajustement de prompt, de modèle ou d'indexation relève du pari. On construit dès le départ un jeu de questions/réponses de référence et des métriques (pertinence du contexte, fidélité de la réponse, taux de réponse) que l'on suit à chaque itération. L'évaluation n'est pas une étape finale : c'est l'instrument de pilotage du projet.

5. Sous-estimer les hallucinations

Même bien alimenté, un modèle peut inventer. On réduit le risque en citant systématiquement les sources, en contraignant le modèle à répondre « je ne sais pas » quand le contexte est insuffisant, et en traçant chaque réponse jusqu'aux documents utilisés. La confiance des utilisateurs se gagne par la vérifiabilité, pas par la fluidité du texte.

6. Ignorer les coûts et la latence

La facture d'inférence grimpe vite avec le volume de contexte injecté à chaque requête, et un temps de réponse trop long tue l'adoption. Observabilité des coûts, mise en cache, compression du contexte et choix d'un modèle adapté à chaque cas d'usage permettent de garder une économie et une expérience maîtrisées.

7. Oublier l'intégration au flux de travail

Un RAG performant mais isolé dans une interface à part reste inutilisé. La valeur naît de l'intégration dans les outils déjà utilisés au quotidien. C'est exactement la logique de notre méthode de delivery : livrer de la valeur en contexte, pas une fonctionnalité de plus à aller chercher.

Notre méthode chez Strategin

Nous industrialisons les assistants connectés comme des produits logiciels à part entière, de la preuve de valeur jusqu'au run :

• Cadrage du cas d'usage. Quel besoin, quelles sources, quels droits, quel indicateur de succès — avant toute brique technique.
• Socle de recherche. Ingestion, chunking, indexation hybride et reranking, pensés pour le corpus réel et non pour la démo.
• Évaluation continue. Jeu de référence, métriques de qualité et tests de non-régression à chaque évolution de modèle ou de prompt.
• Sécurité & observabilité. Filtrage par permissions, traçabilité des sources, suivi des coûts et de la latence.
• Intégration & run. Mise en place dans les outils métier — parfois en s'appuyant sur Logik pour assembler rapidement l'application autour de l'assistant.

Mesurer ce qui compte vraiment

La réussite d'un RAG ne se juge pas à la sophistication de son architecture, mais à un effet observable : une réponse trouvée en quelques secondes au lieu de plusieurs minutes, une information fiable parce que sourcée, une équipe qui adopte l'outil sans qu'on l'y force. Les sept pièges ci-dessus ont un point commun — ils se règlent par la rigueur d'ingénierie, pas par la magie du modèle. C'est précisément là que se joue le passage de la démonstration à la valeur.