Garbage in, garbage out — même avec le meilleur LLM
Vous avez déployé un chatbot interne alimenté par RAG. Les utilisateurs posent des questions et obtiennent des réponses… souvent à côté de la plaque. Le problème n'est pas le modèle — c'est la qualité de votre base documentaire. Des PDF mal formatés, des doublons, des documents obsolètes et un découpage approximatif produisent un retrieval médiocre. Résultat : le LLM hallucine ou donne des réponses partielles. Une base documentaire « RAG-ready » — nettoyée, structurée et découpée intelligemment — améliore la pertinence des réponses de 40 à 60 %.
Le problème
Une PME de services de 150 salariés lance un assistant IA pour répondre aux questions des collaborateurs sur les procédures internes. La base documentaire comprend 1 200 documents : PDF de procédures, fichiers Word de notes de service, pages du wiki Confluence, et quelques fichiers Excel de tableaux de bord. Le chatbot est déployé en 2 semaines. Et les retours sont catastrophiques.
Les problèmes les plus fréquents :
- Documents obsolètes qui polluent les réponses — La procédure de remboursement de frais existe en 4 versions : 2019, 2021, 2023 et 2024. Le RAG retrouve parfois l'ancienne version et le LLM génère une réponse basée sur des règles périmées. Un collaborateur se fait rembourser un montant incorrect.
- PDF scannés illisibles — 30 % des documents sont des scans de qualité médiocre. L'OCR produit du texte avec 15 % d'erreurs. Le RAG retrouve ces documents mais le LLM ne peut pas en extraire de sens. Les réponses contiennent des incohérences visibles.
- Chunks qui coupent au mauvais endroit — Un paragraphe clé de 800 mots expliquant une procédure complexe est découpé en 3 chunks sans overlap. Le chunk central, sorti de son contexte, est incompréhensible. Le LLM produit une réponse partielle ou fausse.
- Doublons et versions multiples — Le même document existe dans 3 dossiers différents avec des noms variés. Le RAG retrouve les 3 versions et le LLM ne sait pas laquelle prioriser. L'utilisateur perd confiance dans l'outil.
La solution n'est pas de changer de LLM — c'est de préparer les documents en amont. Découvrez notre approche complète sur la page RAG entreprise.
La solution IA
Construire une base RAG-ready, c'est un processus en trois étapes : trier, nettoyer et découper. L'IA assiste chaque étape pour accélérer le traitement et garantir la qualité.
Audit et dédoublonnage assisté par IA
Un script d'analyse parcourt votre base documentaire, identifie les doublons par similarité sémantique (pas juste par nom de fichier), détecte les documents obsolètes par analyse de date et de contenu, et classe les documents par thème. Résultat : vous passez de 1 200 documents à 600 documents uniques et à jour en 3 jours au lieu de 3 semaines.
Conversion et nettoyage automatisé
Chaque document est converti en texte structuré : extraction de texte des PDF (avec OCR amélioré par IA pour les scans), conversion des tableaux Excel en descriptions textuelles, normalisation des formats (dates, montants, noms). Les métadonnées sont enrichies automatiquement : titre, auteur, date, catégorie, mots-clés.
Découpage intelligent (semantic chunking)
Au lieu de découper mécaniquement tous les 500 tokens, l'IA identifie les frontières sémantiques : fins de section, changements de sujet, conclusions. Chaque chunk est autonome et compréhensible seul. Un overlap de 15 % assure la continuité. Gain mesuré : +35 % de pertinence sur le retrieval par rapport au découpage naïf.
Mise en oeuvre
Le processus se déroule en trois phases sur 3 à 6 semaines selon le volume de documents.
Audit et tri (semaine 1)
Inventoriez tous les documents : emplacement, format, taille, date de dernière modification. Exécutez un script de dédoublonnage par hash et par similarité sémantique. Classez les documents en 3 catégories : à garder (à jour et pertinent), à archiver (obsolète mais à conserver), à supprimer (doublon ou hors périmètre). Validez le tri avec les métiers concernés.
Nettoyage et conversion (semaines 2-4)
Convertissez chaque document en Markdown ou texte structuré. Pour les PDF scannés, utilisez un OCR de qualité (Azure Document Intelligence, Google Document AI ou Tesseract 5 avec post-traitement IA). Normalisez les métadonnées dans un schéma commun. Vérifiez manuellement un échantillon de 10 % pour valider la qualité de l'extraction.
Chunking et indexation (semaines 4-6)
Découpez les documents en chunks sémantiques de 500 à 1 000 tokens avec 15 % d'overlap. Ajoutez les métadonnées à chaque chunk (titre du document source, section, date). Vectorisez avec un modèle d'embedding adapté au français (CamemBERT, multilingual-e5, ou OpenAI ada-002). Indexez dans une base vectorielle (Qdrant, Weaviate, Pinecone). Testez avec 50 questions réelles et mesurez le recall.
Résultats
Voici les résultats mesurés chez nos clients après mise en production d'une base RAG-ready.
Questions fréquentes
Qu'est-ce qu'une base documentaire RAG-ready ?
C'est un ensemble de documents structurés, nettoyés et découpés en segments (chunks) optimisés pour être retrouvés par un système RAG (Retrieval-Augmented Generation). Concrètement, vos PDF, Word, pages web et wikis internes sont convertis en texte propre, enrichis de métadonnées (date, auteur, catégorie) et indexés dans une base vectorielle. Quand un utilisateur pose une question, le système retrouve les segments les plus pertinents et les envoie au LLM pour générer une réponse contextualisée.
Quels formats de documents fonctionnent le mieux avec le RAG ?
Les formats textuels structurés donnent les meilleurs résultats : Markdown, HTML, texte brut avec titres. Les PDF textuels fonctionnent bien après extraction. Les PDF scannés (images) nécessitent un OCR préalable, avec une perte de qualité. Les fichiers Excel et les bases de données relationnelles nécessitent une conversion en texte descriptif. Évitez les présentations PowerPoint lourdes en images — le texte des slides est souvent trop fragmenté pour un RAG efficace.
Quelle taille de chunks choisir pour le RAG ?
La taille optimale dépend du type de contenu et du modèle utilisé. Règle générale : 500 à 1 000 tokens par chunk pour des documents techniques, 200 à 500 tokens pour des FAQ ou des fiches produit. Un overlap de 10 à 20 % entre les chunks améliore la continuité. Testez avec vos données réelles : si le LLM manque de contexte, augmentez la taille ; si les réponses sont trop vagues, réduisez-la.
Combien de temps faut-il pour préparer une base documentaire RAG-ready ?
Pour une base de 500 à 2 000 documents, comptez 3 à 6 semaines : 1 semaine d'audit et tri, 2 semaines de nettoyage et conversion, 1 à 2 semaines d'indexation et de tests. Le temps dépend surtout de la qualité initiale des documents. Des PDF propres en français avec une structure claire se traitent 5 fois plus vite que des scans de documents manuscrits.
Pour les profils tech
Pipeline de préparation documentaire
Azure Document Intelligence / Docling
Azure Document Intelligence (ex Form Recognizer) extrait le texte, les tableaux et la structure des PDF avec une précision de 95 %+. Docling (IBM, open source) offre une alternative gratuite avec extraction de layout. Pour les scans, Tesseract 5 + post-traitement GPT-4 corrige les erreurs OCR courantes.
LangChain / LlamaIndex
LangChain et LlamaIndex proposent des stratégies de chunking avancées : RecursiveCharacterTextSplitter (par taille), SemanticChunker (par similarité), MarkdownHeaderTextSplitter (par structure). Embedding français : CamemBERT-large, multilingual-e5-large ou OpenAI text-embedding-3-small.
Stack recommandée
Comparatif des stratégies de chunking
| Critère | Semantic chunking | Fixed-size chunking | Par section/titre |
|---|---|---|---|
| Pertinence retrieval | Excellente | Moyenne | Bonne |
| Complexité | Moyenne (LLM requis) | Simple | Moyenne |
| Coût | Modéré (appels LLM) | Quasi nul | Quasi nul |
| Adapté aux docs FR | Oui (modèle multilingue) | Risque de coupure | Oui (si titres présents) |