Une entreprise peut avoir des centaines, voire des milliers de documents internes, et continuer malgré tout à répondre à la même question par e-mail, chat ou réunion. La frustration habituelle n’est pas “nous manquons d’information”. C’est plutôt “nous en avons trop, et personne ne sait quelle version est valide”. C’est dans ce contexte que le RAG devient attractif : utiliser un modèle pour répondre à partir d’un contenu interne sans l’entraîner sur les données de l’entreprise.

Le problème n’est généralement pas l’intelligence du système. C’est la qualité, le périmètre et la gouvernance de ce que vous lui laissez lire.

Ma thèse est claire : un RAG n’a de sens que lorsque la douleur principale est l’accès contrôlé à la connaissance, pas l’absence de processus ou de discipline documentaire. Si l’entreprise attend de l’IA qu’elle “sache tout” sans avoir défini les sources, les responsables, les règles d’expiration et les critères d’exclusion, le résultat sera séduisant en apparence et fragile en exploitation.

Le scénario réel : des réponses répétées, des critères dispersés

Imaginez une PME industrielle ou de services B2B avec plusieurs équipes : opérations, commerce, support et administration. Chacune stocke ses documents dans des drives, dossiers, wikis ou systèmes différents. Les questions reviennent sans cesse :

• Quelle est la politique actuelle pour les remises exceptionnelles ?
• Quelle procédure appliquer lorsqu’une commande arrive incomplète ?
• Quelle est la bonne version du contrat-cadre ?
• Quel client bénéficie d’une exception approuvée, et jusqu’à quand ?

Le coût ne se limite pas au temps. Il y a aussi des décisions incohérentes, des réponses contradictoires et une dépendance à quelques personnes qui “savent où tout se trouve”.

Un RAG peut aider si le besoin est de répondre avec contexte et rapidité, mais il ne faut pas le confondre avec un système maître. Il ne remplace pas le contrôle documentaire, ne corrige pas une mauvaise taxonomie et ne règle pas des exceptions mal gérées.

Quand un RAG est adapté et ce qu’il doit prouver

Quelques signaux montrent un vrai bon cas d’usage :

1. Les questions sont répétitives et textuelles. Il s’agit de retrouver une politique, une procédure, un critère ou une preuve, pas de faire un calcul complexe.

2. La source de vérité existe, même si elle est dispersée. Cela peut être des manuels, SOP, contrats, FAQ internes, tickets résolus ou notes produit.

3. La citation de source compte. L’utilisateur ne veut pas une réponse “créative” ; il veut savoir d’où elle vient.

4. La connaissance évolue, mais pas toutes les heures. Si le contenu change trop vite, l’indexation et la validation deviennent une charge opérationnelle continue.

5. Il existe un responsable par domaine. Quelqu’un doit décider ce qui est indexé, archivé, exclu et retiré.

Dans une implémentation sérieuse, le RAG ne doit pas tout ingérer. Il doit ingérer des collections choisies : politiques en vigueur, procédures approuvées, documentation produit, contrats types, résolutions internes. Et dès le départ, il faut définir le type de réponse autorisé : résumé, citation, comparaison, navigation documentaire ou brouillon assisté.

L’erreur inconfortable : vouloir faire du RAG à la place du nettoyage documentaire

C’est le point que beaucoup d’organisations préfèrent éviter : si vos documents sont dupliqués, obsolètes ou sans responsables, le RAG ne doit pas être la première étape. Il est tentant parce qu’il semble plus rapide que de remettre de l’ordre dans la connaissance. Mais en pratique, c’est souvent l’inverse qui se produit : l’IA rend visible la dette documentaire.

Cas composite très courant : une entreprise de distribution voulait un assistant interne pour aider le service client à répondre sur les stocks, les retours et les conditions commerciales. Le pilote donnait des réponses correctes en apparence, mais trois problèmes sont apparus :

• des documents dupliqués avec des versions contradictoires ;
• d’anciennes politiques indexées avec les politiques actuelles ;
• des exceptions validées par e-mail que personne n’avait formalisées.

La solution n’a pas été “plus d’IA”. Elle a consisté à réduire le périmètre, définir un référentiel unique pour les politiques actives, ajouter des règles d’expiration et créer un processus pour transformer les exceptions en connaissance gouvernée. C’est seulement à ce moment-là que le RAG est devenu vraiment utile.

Comment le mettre en place sans créer une boîte noire

La décision technique importante ne concerne pas seulement le modèle. Elle concerne aussi la manière de concevoir un système auditable et maintenable.

1. Définir le périmètre de connaissance

Ne mélangez pas les contenus sans règles. Séparez les domaines : support, commerce, opérations, juridique, produit. Chaque domaine doit avoir son responsable et ses règles.

2. Prioriser la qualité sur le volume

Indexer 20 000 documents ne sert à rien si 8 000 sont obsolètes. Mieux vaut 800 bons documents que 8 000 documents ambigus.

3. Utiliser de vrais métadonnées

Date d’effet, responsable, type de document, statut, pays, entité. Sans cela, le système ne distingue pas une politique active d’une vieille note.

4. Forcer des réponses sourcées

L’interface doit montrer d’où vient chaque réponse. Si les citations ou la traçabilité sont insuffisantes, le système doit reconnaître l’incertitude ou répondre “non trouvé”.

5. Mesurer ce qui compte

Pas seulement la précision. Mesurez la baisse des questions répétées, le temps moyen pour trouver une réponse, la part de réponses sans source et le pourcentage de documents avec un responsable défini.

La décision qui mérite un vrai débat

La question inconfortable n’est pas de savoir si un RAG fonctionne techniquement. C’est de savoir si votre organisation peut le maintenir dans la durée. Si la discipline documentaire est faible, le projet dépendra d’un petit groupe qui connaît le système, relit les résultats et corrige manuellement les erreurs.

C’est pourquoi, dans certains cas, il est plus pertinent de commencer par nettoyer la documentation et mettre en place une gouvernance minimale avant d’exposer l’IA à toute la connaissance interne. Dans d’autres cas, un pilote très ciblé sur un domaine bien défini, avec peu de sources et une traçabilité stricte, est au contraire la bonne approche.

La différence entre un pilote utile et une démo élégante tient souvent à une seule question : qui répond quand l’IA se trompe ?

Si vous évaluez ce type d’assistant interne et que vous ne savez pas si votre vrai problème relève de la recherche, de la documentation ou de la gouvernance de la connaissance, Codefuente aide généralement à séparer ces trois couches avant de concevoir la solution.