Le RAG, ou génération augmentée par récupération, promet une chose simple et puissante : répondre à partir de vos documents, avec vos informations, plutôt que de laisser le modèle inventer. En démonstration, c’est convaincant. On pose une question, la réponse arrive, sourcée, dans votre langue, et l’enthousiasme monte.
En production, la réalité rattrape vite la démo. Les documents sont sales, les découpages inadaptés, les réponses parfois fausses et parfois hors sujet, et la facture grimpe. Les erreurs se paient en utilisateurs déçus, en argent perdu et en confiance entamée, trois monnaies qu’un projet IA n’a pas les moyens de gaspiller.
Ces erreurs ne sont pas des fatalités. Elles sont, presque toutes, des étapes qu’on a sauté ou mal faites, et qu’on peut corriger avant de déployer. En voici les quatre principales, et ce qu’il faut surveiller pour qu’un RAG tienne la production.
Des documents jamais nettoyés
La première erreur est la plus banale et la plus coûteuse : on branche le RAG sur des documents bruts, sans les nettoyer. Des PDF scannés, des tableaux mal extraits, des doublons, des versions obsolètes qui se contredisent. Et on s’étonne ensuite que l’agent réponde à côté.
La réalité est que la qualité de la récupération dépend entièrement de la qualité des sources. Un modèle de langage ne peut pas compenser un document illisible. Si le contenu est mal extrait, le meilleur embedding du monde retrouvera du bruit, et la réponse sera du bruit. Le nettoyage des sources n’est pas une tâche annexe, c’est la moitié du travail d’un RAG utile.
Concrètement, cela passe par une chaîne de préparation : extraction propre, déduplication, versionnage, suppression des documents obsolètes, correction des tableaux et des images quand ils portent l’information. C’est un travail ingrat, souvent sous-estimé, et c’est pourtant lui qui sépare un RAG qui répond juste d’un RAG qui répond plausible.
Un chunking inadapté
La deuxième erreur se joue au moment du découpage. Pour être retrouvée, l’information doit être découpée en morceaux, les chunks, et la façon de découper décide de ce que l’agent pourra récupérer. Découper au mauvais endroit, c’est couper la réponse en deux.
Le réflexe courant est de découper à longueur fixe, par exemple cinq cents caractères, sans regarder le contenu. C’est simple, et c’est faux dès que le document a une structure. Une question et sa réponse se retrouvent séparées, un tableau est éclaté, une définition est coupée en plein milieu. Le modèle ne récupère qu’un fragment, et il répond sur un fragment.
Le découpage doit suivre la structure du document : les titres, les sections, les paragraphes, les tableaux. C’est plus de travail en amont, mais c’est ce qui permet à l’information de rester entière et retrouvable. Un bon chunking, c’est la moitié d’une bonne récupération.
Des réponses sans source
La troisième erreur est la plus dangereuse en termes de confiance : l’agent répond sans citer ses sources. On obtient une réponse, plausible, sans savoir d’où elle vient, sans pouvoir la vérifier, sans pouvoir la corriger quand elle est fausse.
Un RAG qui ne cite pas ses sources est une boîte noire. En production, c’est intenable, parce que chaque erreur devient une crise de confiance. L’utilisateur ne peut pas distinguer une réponse sourcée d’une réponse inventée, et finit par douter de tout, y compris des réponses justes.
La règle est simple : chaque réponse doit être traçable, reliée au document et au passage dont elle est tirée. Cela permet de vérifier, de corriger, et surtout de dire honnêtement « je ne sais pas » quand la source manque, plutôt que d’inventer. La traçabilité n’est pas une fonctionnalité, c’est la condition de la confiance.
Des coûts non maîtrisés
La quatrième erreur se voit sur la facture. Des prompts trop longs, des re-fetchs inutiles, un modèle trop gros pour la tâche : les coûts dérivent vite, et souvent sans qu’on le voie venir, parce qu’on n’a pas mesuré le coût par requête dès le départ.
Le coût d’un RAG se joue à plusieurs endroits : la taille du contexte envoyé au modèle, le nombre d’appels successifs, le choix du modèle, le volume de documents indexés. Chacun de ces paramètres se budgète, et les mauvaises surprises viennent toujours de celui qu’on n’a pas regardé.
La bonne pratique est de mesurer le coût par requête dès le prototype, de le suivre en continu, et de traiter toute dérive comme un signal d’alerte. Un RAG dont le coût explose n’est pas rentable, même s’il répond bien. Le coût n’est pas un détail, c’est une contrainte de production.
Ce qu’on surveille avant de déployer
Quatre chiffres résument la santé d’un RAG : le taux de réponses sourcées, le taux d’hallucination par catégorie, la latence, et le coût par requête. Le premier dit si les réponses sont vérifiables, le deuxième si elles sont fiables là où ça compte, le troisième si l’expérience est acceptable, le quatrième si l’économie tient.
Ces quatre chiffres ne demandent pas un outillage lourd. Ils demandent une discipline : les mesurer dès le début, les suivre en continu, et refuser de déployer tant qu’ils ne sont pas au niveau attendu. Tout le reste est de l’impression, et l’impression ne survit pas à la production.
L’accompagnement Agenticiel pour un RAG qui tient la production
Construire un RAG qui répond juste, sourcé et au bon coût, c’est un savoir-faire qui s’acquiert en livrant, et c’est là qu’une équipe habituée à la production apporte le plus. Agenticiel construit des assistants RAG sur vos données internes, et la méthode commence par ce que tout le monde néglige : le nettoyage des sources et le découpage.
Ensuite, on mesure. Taux de réponses sourcées, hallucinations par catégorie, latence, coût par requête : ces quatre chiffres sont posés dès le prototype et suivis jusqu’en production. Le résultat n’est pas un assistant qui impressionne une fois, c’est un assistant dont on peut dire précisément ce qu’il sait, d’où il le tire, et ce qu’il coûte.
Ce travail est mené par des développeurs offshore francophones, à Madagascar. La sous-traitance de développement permet d’itérer sur un RAG dans votre langue et sur des fuseaux compatibles, à un coût maîtrisé, sans perdre le contrôle sur vos données ni sur la qualité.
Notre approche consiste à faire primer la qualité des sources sur la sophistication du modèle : on nettoie, on découpe bien, on mesure, et on ne déploie que ce qu’on peut piloter avec des chiffres.