Beaucoup d’entreprises lancent un projet RAG avec la mauvaise question : “Quel modèle faut-il utiliser ?” ou “Dans quel outil faut-il le monter ?”. La vraie question est beaucoup moins glamour : quel savoir interne mérite d’être récupérable, et avec quel niveau de risque ?
Si la connaissance de l’entreprise n’est pas bien gouvernée, un RAG ne la corrige pas : il lui donne seulement une interface plus convaincante.
Un RAG utile ne transforme pas la documentation en intelligence magique. Il réduit le temps entre une question opérationnelle et une réponse exploitable en sécurité. Pour cela, il ne suffit pas d’indexer des documents. Il faut décider ce qui entre, ce qui sort et ce que l’on fait quand le système ne sait pas.
La situation réelle : réponses rapides, décisions lentes
Imaginons une entreprise de taille moyenne avec les ventes, les opérations et le support répartis entre ERP, SharePoint, emails et tickets. Chaque équipe stocke l’information dans son propre format. Quand quelqu’un demande “Comment traite-t-on un retour hors délai ?” ou “Que se passe-t-il si un client premium ouvre un ticket critique ?”, la réponse existe, mais elle est dispersée.
Le premier réflexe consiste souvent à tout ingérer et à lancer un chatbot. Le résultat habituel est décevant : le système répond avec une confiance trompeuse, mélange anciennes et nouvelles versions, et n’est utile que dans une partie des cas. Le problème n’est pas le modèle. Le problème, c’est que la connaissance n’a pas de hiérarchie.
Un RAG bien conçu doit aider dans des cas précis, par exemple :
- questions répétitives du support interne,
- règles opérationnelles qui changent souvent,
- accès rapide aux politiques et procédures à jour,
- recherche d’éléments de preuve dans les tickets et la documentation technique.
Si le cas d’usage n’a ni volume récurrent ni coût d’erreur clair, le projet devient souvent une démo coûteuse.
Quelles sources garder, et lesquelles éviter
Voici la première vraie décision : toutes les sources ne doivent pas entrer dans l’index. La plupart des échecs de RAG viennent d’une volonté d’ingérer tout.
Sources qui fonctionnent souvent bien :
- manuels internes versionnés,
- procédures approuvées,
- base de connaissances du support,
- documentation technique contrôlée,
- FAQ métiers validées.
Sources à traiter avec prudence :
- fils d’emails,
- discussions informelles,
- notes personnelles,
- documents sans propriétaire,
- fichiers obsolètes sans gestion de version.
Cela ne veut pas dire qu’elles sont inutiles. Cela veut dire que leur valeur est contextuelle, pas normative. Une erreur fréquente consiste à autoriser le système à citer un email comme s’il s’agissait d’une politique. Cela crée une illusion de précision qui se paie ensuite en exploitation.
Critère simple : si une source peut changer une décision client, un sujet de conformité ou un impact financier, elle doit avoir un propriétaire, une date d’effet et une révision explicite. Sinon, elle ne devrait pas répondre seule.
Mini-cas : quand l’assistant en savait trop
Une entreprise de services avec plusieurs entités voulait réduire le temps passé par l’équipe opérations à chercher des réponses dans la documentation interne. Des manuels, tickets historiques et notes de projet ont été chargés dans un RAG pilote.
Au début, le système semblait utile. Mais en analysant des cas réels, trois problèmes sont apparus :
- il renvoyait des procédures déjà retirées,
- il mélangeait des critères de deux équipes différentes,
- il continuait à répondre alors que la documentation était ambiguë.
La correction n’a pas consisté à “améliorer le prompt”. Il a fallu réorganiser le projet : limiter le corpus aux documents en vigueur, séparer les sources par domaine, ajouter des marqueurs de confiance et forcer le système à répondre “introuvable” si la preuve était insuffisante.
La vraie valeur est venue ensuite : moins de temps perdu à chercher, moins d’escalades inutiles et moins de réponses inventées. Pas parce que l’IA est devenue plus intelligente, mais parce qu’on lui a permis d’être moins téméraire.
L’erreur inconfortable : vouloir qu’il réponde à tout
Voici la partie que beaucoup d’équipes ne veulent pas entendre : un bon RAG doit souvent refuser de répondre.
C’est gênant parce que cela ressemble à une mauvaise expérience utilisateur. En réalité, c’est un bon signe de contrôle. Si le système répond à tout, il extrapole généralement. Et en exploitation, extrapoler, c’est une autre façon d’inventer.
La décision la plus utile consiste souvent à définir trois comportements :
- répondre avec citation et source quand la preuve est forte,
- demander une clarification quand le contexte manque,
- escalader à une personne quand le risque est élevé ou la réponse non équivoque.
Il faut aussi accepter qu’un problème ne nécessite pas toujours de génération. Parfois, une recherche mieux filtrée suffit. Le RAG ne doit pas devenir un substitut à la gouvernance documentaire.
Les signaux qui montrent que le projet est bien cadré
Avant de passer à l’échelle, certains signaux comptent plus que la démonstration :
- les réponses reposent sur des sources visibles et à jour,
- le système indique quand la preuve est insuffisante,
- les utilisateurs cessent de solliciter les humains pour les sujets répétitifs,
- les responsables de contenu relisent et corrigent le corpus,
- les mauvaises réponses peuvent être rattachées à une source précise.
Si vous ne pouvez pas auditer une réponse, vous n’avez pas un assistant de connaissance ; vous avez une boîte noire avec une interface agréable.
Conclusion
Un RAG de connaissance interne ne se gagne pas avec le modèle le plus récent, mais avec un périmètre bien défini, une qualité documentaire maîtrisée et un comportement clair en cas de doute. La différence entre un pilote intéressant et un outil opérationnel tient à la discipline de contenu, pas au vernis de l’IA. Chez Codefuente, nous commençons généralement par cette carte des décisions avant de construire quoi que ce soit, parce que dans la connaissance interne, l’ordre compte plus que l’ambition.