Pourquoi nous avons jeté 70% de la base documentaire d'entreprise sans écrire une seule ligne de code : anatomie technique d'un RAG d'entreprise

• Part des problèmes liés aux données : 70 à 80% de tous les échecs de RAG en entreprise (30% versions obsolètes, 20% doublons, 15% OCR défectueux)
• Cas réel de nettoyage de base : la réduction de 12 000 à 3 800 documents a multiplié la précision de la recherche
• Gain apporté par le Tool-based RAG : jusqu'à +70% de qualité de réponse en passant d'un pre-query aveugle au function calling
• Paramètres de chunking des réglementations : Parent-Child (child de recherche 200–300 tokens, parent contextuel 1500–2000)

En développant des assistants IA et des bases de connaissances projet chez AlpinaGPT (la plateforme compte aujourd'hui plus de 8 000 utilisateurs actifs et plus de 40 clients entreprises), j'ai étudié des dizaines d'implémentations RAG tierces. Le même scénario se répète presque partout : les ingénieurs assemblent en une semaine un prototype séduisant, défendent le budget, puis un mois après la mise en production, le système se met à citer avec assurance des arrêtés abrogés datant de trois ans et à inventer des clauses contractuelles inexistantes.

Les clients tentent de soigner cela en changeant de LLM ou en adoptant la recherche par graphe, à la mode. Mais mon expérience montre une proportion têtue : 80% des cas d'usage en entreprise se résolvent très bien avec un RAG classique avancé doté de métadonnées, sans recourir à un GraphRAG surdimensionné, et 70 à 80% de tous les échecs trouvent leur origine dans l'ingénierie des données, pas dans les poids du réseau de neurones.

Pourquoi le RAG d'entreprise produit-il des hallucinations et

retrouve-t-il des réglementations obsolètes ?

Entre le dossier de documents d'entreprise et la bonne réponse du modèle se nichent quatre goulots d'étranglement systémiques :

1. Un corpus d'entrée pollué (Data Engineering) : lorsqu'un client nous transmet 10 000 fichiers d'entreprise, 30% d'entre eux s'avèrent être des versions obsolètes sans date, 20% des quasi-doublons, et 15% des scans PDF mal formés truffés de résidus d'OCR et d'en-têtes/pieds de page parasites. Sur un déploiement, sur 12 000 documents transmis avec la mention « à jour », il n'en restait exactement que 3 800 après audit.

Nous avons simplement supprimé les trois quarts de ce cimetière de fichiers (présentations de 2020 et brouillons), et la qualité des résultats a été multipliée sans un seul commit de code. La règle de vérification essentielle de la première semaine : mesurer la part des fichiers dont la date de modification dépasse un an. 2.

Les échecs de la recherche vectorielle en russe : le modèle standard `text-embedding-3-large` d'OpenAI dérive souvent sur la terminologie sectorielle russe. Selon nos mesures, `multilingual-e5-large` et `jina-embeddings-v3` s'avèrent nettement plus précis sur les réglementations en cyrillique. De plus, la recherche vectorielle pure se perd sur des requêtes du type « clause 4.

2.1 de l'arrêté n°47 » — un circuit hybride `vecteur + recherche lexicale BM25` suivi d'un reranking est ici indispensable. 3.

Une dégradation silencieuse sans monitoring : la base se met à jour, et deux mois plus tard, la précision chute. Au-delà du trio de base des métriques RAGAS (`Faithfulness`, `Answer Relevancy`, `Context Recall`), la version v0.2 a introduit une métrique cruciale pour les entreprises, `Noise Sensitivity` — la résistance de la réponse à un contexte pollué.

Et l'indicateur précoce le moins coûteux pour repérer une panne de RAG en production reste le graphique hebdomadaire de la longueur moyenne des réponses en tokens : dès que le modèle ne retrouve plus le fait précis, il commence à « noyer le poisson » et à gonfler ses paragraphes, deux à trois semaines avant les premières plaintes des utilisateurs. 4. Une limite structurelle : le RAG travaille sur des instantanés statiques et ne remplace pas une base transactionnelle (CRUD) pour les stocks en entrepôt ou les prix en temps réel.

Comment découper correctement les chunks pour les réglementations, le

code et les FAQ ?

Fourrer un PDF de 80 pages dans un seul vecteur, ou découper les documents sans conserver les métadonnées (source, date, section, auteur), est le moyen le plus sûr de tuer la recherche. Il n'existe pas de taille de chunk universelle : nous adaptons la stratégie à la physique propre de chaque document.

• Contrats juridiques et réglementations internes : stratégie `Parent-Child`. La recherche porte sur un fragment enfant étroit de 200 à 300 tokens (pour une précision maximale du ciblage), tandis qu'un bloc parent large de 1500 à 2000 tokens est injecté dans le prompt du modèle pour ne pas perdre les conditions et clauses associées.
• Documentation technique et descriptions d'API : fenêtre fixe `Fixed-size` de 500 tokens avec un chevauchement (`overlap`) de 100 tokens, pour ne pas couper une idée en deux.
• Code source des dépôts : découpage strictement sémantique, le long des frontières de fonctions et de classes.
• Référentiels courts et bases de FAQ : méthode `Sentence window` — la recherche porte sur une phrase unique, et le modèle reçoit une fenêtre de `±N` phrases voisines.

Que faire concrètement : pourquoi le

Tool-based RAG surpasse-t-il la recherche native de 70% ?

Dans les implémentations primitives, la recherche est figée en dur avant chaque appel au modèle (Native RAG) : l'utilisateur écrit dans le chat « Bonjour, comment ça va ? », et le système va docilement chercher dans la base vectorielle cinq extraits aléatoires des statuts de l'entreprise, consommant des tokens pour rien et désorientant le modèle.

Nous avons fait évoluer l'architecture vers le Tool-based RAG : le moteur de recherche est connecté au modèle comme un outil externe via le `function calling`. L'agent décide lui-même s'il a besoin de consulter la base de connaissances, reformule lui-même la question de l'utilisateur en requête de recherche précise et, si nécessaire, effectue 2 à 3 appels ciblés vers différentes collections. Dans nos projets, cette seule transition apporte jusqu'à 70% de gain de qualité de réponse, et les deux jours investis dans l'écriture d'un parseur DOCX/PDF propre vers du Markdown structuré font gagner des mois de lutte contre les hallucinations.

Nous détaillons toute la cuisine de conception du RAG sur pgvector et des outils agentiques lors de nos sessions techniques à la [Hamidun Academy](https://academy.hamidun.com) et dans les décryptages d'architecture du [Vibe Club](https://hamidun.

com/club).