On a tendance à croire qu'une base de connaissances qui déraille répond à côté de la plaque parce que le modèle est trop petit, ou pas assez cher. On change de modèle. On rallonge le contexte. L'addition monte, et les réponses continuent de partir en vrille.
C'est un réflexe, et il est faux. Dans la grande majorité des cas, le problème ne vient pas du modèle. Il vient de la couche documentaire, c'est-à-dire de tout ce qui se passe avant que le document ne croise le modèle.
Imaginez le scénario le plus banal du monde. Cinq ans de contrats, de tickets support, de manuels produit et de scans entassés dans un dossier. Vous le balancez en vrac au modèle en lui demandant de « comprendre ». Ce qu'il lit, c'est des gigaoctets de texte brut non trié. Ce qu'il retrouve, c'est trois pages raccrochées par coincidence de nom de fichier. Ce qu'il recrache tient logiquement du grand n'importe quoi. Le modèle n'est pas bête. On lui a simplement donné du bazar à ingérer.
Changer de modèle soigne le plafond, pas le plancher
Il y a un biais coût que presque personne ne voit. La « propreté » d'un document avant son entrée en base — son volume, son format, ses champs sensibles, ses doublons — fixe le plafond de qualité de la recherche. Un modèle, aussi puissant soit-il, ne survole pas des données sales. Les praticiens appellent ça l'hygiène des données : nettoyer le « lourd, le mélangé, le sale » avant d'aligner de la puissance de calcul, c'est presque toujours plus rentable que d'en rajouter après coup.
La question de fond n'a jamais été « le modèle est-il intelligent ? ». Elle est : « l'information que l'utilisateur cherche vraiment, peut-on la localiser avec précision ? ». C'est un principe qui précède toutes les astuces de prompt. Le modèle n'est que la dernière étape d'une chaîne. Si les étapes d'avant sont bâclées, il ne rattrape rien, quoi qu'il fasse.
Les équipes qui livrent de vraies bases ne confient pas leurs fichiers bruts au modèle. Elles passent par une base d'ingénierie de données : on compresse, on normalise les formats, on masque les informations sensibles selon des règles, on découpe en fragments propices à la recherche, puis on nourrit le modèle en gardant la provenance. Le circuit est connu. On parle souvent de six opérations enchaînées — collecte, nettoyage, découpage, vectorisation, recherche, génération — et chacune conditionne la tenue de la réponse finale.
Les équipes aguerries font aussi ce que le commanditaire n'a pas demandé. Elles constituent un jeu de questions-réponses réel servant de lot de réception, plutôt que de déclarer « ça a l'air plus précis ». Elles traitent la qualité de recherche comme un indicateur mesurable et lancent des régressions régulières pour repérer aussitôt une catégorie de questions en chute. Elles imaginent, avant de lancer une tâche longue, à quoi ressemble un échec et où sont les limites.
Tout ça — recherche hybride, réordonnancement, réécriture de requêtes, segmentation sémantique, évaluation hors ligne par des cadres ouverts — relève du bon sens public d'ingénierie, pas d'un secret de fabrication. Ce qui sépare le démonstrateur du produit utilisable, c'est de rendre chaque étape reproductible.
Et « reproductible », justement, est le mot le plus vite transformé en slogan. Qu'est-ce qui prouve indépendamment qu'une base fonctionne vraiment ? Pas la démo vantée par un éditeur. C'est un jeu de questions-réponses doré annoté indépendamment, des indicateurs hors ligne reproductibles, des résultats d'A/B en aveugle stables, une suite de régression active dans l'intégration continue, et le retour de signaux d'usage réels. Sans cela, le « plus précis » n'est qu'une impression.
Faire de la préparation un pipeline observable
Voici un progrès récemment passé sous silence. Quand on prépare des milliers de documents — compression, conversion de format, ingestion — le traitement peut tourner des heures. Où ça coince ? Quel fichier a échoué sans bruit ? Les flux traditionnels n'en savent rien. La base d'ingénierie de données RAG récente fait un pas en avant : elle transforme la préparation documentaire (compression, conversion et autres tâches par lots de longue durée) en un pipeline observable. La progression devient visible, on repère immédiatement quelle étape a ralenti ou quel fichier a échoué, et on peut revenir en arrière et relancer quand il le faut.
Pour vous, le bénéfice est concret : fini l'attente devant un écran noir, fini le moment où, à la toute fin, vous découvrez que les 30 % de documents restants n'ont jamais rejoint la base. C'est un détail qui paraît mineur et qui, en réalité, sépare « ça tourne » de « on ose l'embarquer en production ».
Mécanismes : pourquoi ces opérations tiennent la route
Expliquer pourquoi c'est utile vaut mieux qu'une liste de fonctionnalités.
Sur la compression, le cas de figure est simple : un contrat juridique atteint des centaines de mégaoctets, et une ingestion intégrale plombe à la fois le stockage et la recherche. En théorie, le document regorge d'informations répétées, d'objets redondants, de médias recodables. On les réencode selon l'usage, et le volume redescend généralement de 60 % à 80 %, tandis que le texte et les cachets — informations clés — sont préservés. Votre gain : une base de recherche plus légère répond plus vite et coûte moins, et les gros fichiers ne se bloquent plus à l'étape « on n'arrive pas à les faire entrer dans le modèle ».
Sur la recherche, comparez. Chercher « accord fournisseur 2024 » par nom de fichier, c'est tout ou rien : introuvable, c'est introuvable. Chercher par sémantique de contenu, le modèle saisit « avec qui avons-nous signé, à propos de quoi, où sont les clauses ». C'est le décalage entre une recherche sur le sens et une recherche sur les caractères. Attention tout de même : la sémantique ne sauve pas un mauvais input. C'est le nettoyage et le découpage amont qui décident à quel pourcentage la recherche sémantique peut exprimer sa force.
Sur le déploiement, le point sensible n'est pas que le modèle se trompe. C'est que la donnée sort du réseau interne. Le déploiement privé fait tourner toute la préparation et la recherche sur vos propres machines. Les documents ne quittent pas le réseau de l'entreprise, et le cadre de conformité s'en trouve naturellement plus propre. C'est une autre route que « acheter un modèle cloud plus gros » : l'une confie la donnée pour gagner en intelligence, l'autre garde l'intelligence à la maison.
Le fait de « porter la provenance à chaque phrase » mérite une mention à part. On le traite souvent comme un luxe, alors que c'est une exigence. Dans les secteurs régulés, une réponse qui ne peut pas désigner quel fichier, quelle page a été citée, devient inauditable et irresponsable. La base d'ingénierie marque chaque fragment à la source dès le découpage et l'ingestion, et la génération ressort avec la provenance. Aux yeux du commanditaire, ça « n'a pas d'importance » ; aux yeux du praticien, c'est une ligne rouge de réception. Mettre la conformité en amont, c'est justement poser ces règles avant que le document n'entre en base, plutôt que de rattraper après un incident.
Il y a encore un calcul de coût que beaucoup fauxent. Ne pas préparer en amont n'est pas une dépense unique, c'est une facture qui roule : la recherche se dégrade, la confiance s'effrite, l'outil finit ignoré et toute la puissance calcul injectée part en fumée. À l'inverse, bien tenir cette étape baisse le plancher de départ, et chaque interrogation suivante s'appuie sur une assise plus haute — le coût marginal finit plus bas. Ce n'est pas une question d'économies, c'est une question de viabilité du chemin.
Directement balancé, ou préparé en amont : un tableau pour voir clair
| Dimension | Fichiers bruts balancés au LLM | Passés par la préparation de la base d'ingénierie |
|---|---|---|
| Volume documentaire | fichier d'origine, souvent plusieurs centaines de Mo | après compression, généralement −60 % à −80 % |
| Informations sensibles | PII brute et secrets commerciaux exposés | 13 catégories d'infos sensibles masquées automatiquement |
| Traçabilité | difficile de dire quel passage a été cité | chaque phrase porte sa source, auditable |
| Contrôle des tâches longues | attente en boîte noire, échecs difficiles à localiser | progression visible, échecs localisables, retour arrière |
| Compatibilité multi-modèles | gros fichiers souvent injouables dans certains modèles | même document allégé chargé stablement d'un modèle à l'autre |
Trois jeux de chiffres, et pourquoi on ne peut pas sauter l'étape
Pourquoi le masquage n'est pas négociable ? Le rapport IBM Cost of a Data Breach 2025 donne un chiffre qui fâche : parmi les données volées, les informations personnelles clients représentent 53 %, les informations personnelles employés 37 %, la propriété intellectuelle 33 %. Et la propriété intellectuelle est la plus coûteuse, à 178 dollars par enregistrement. Dès qu'une base nourrit un modèle avec ces champs tels quels, le risque n'est plus « possible », il est déjà réalisé.
Un autre angle, celui du temps perdu. McKinsey estime que les travailleurs du savoir consacrent environ 19 % de leur semaine de travail à chercher et rassembler de l'information. Une base dont la couche documentaire n'est pas tenue transforme cette recherche en un labyrinthe : on perd du temps à localiser le bon passage, et on doute du résultat. Une préparation propre réduit le bruit, et ces 19 % redeviennent du temps utile.
Côté stockage, la pression ne faiblit pas. Une enquête menée par Komprise auprès de ses clients montre que 60 à 70 % des données sur le stockage principal des entreprises n'ont pas été consultées depuis plus de 90 jours, alors qu'elles occupent le stockage principal, le plus onéreux. Une base de connaissances qui n'amincit ni ne hiérarchise ne fait qu'agrandir cette boule de « données froides ».
Revenons au début
Une base de connaissances qui répond à côté, dans neuf cas sur dix, ce n'est pas le modèle qui flanche : c'est la couche documentaire qui n'a pas été tenue. Rendez la préparation observable, réversible, et les données qui ne quittent pas le réseau interne — ensuite on discute du modèle. L'ordre compte. Renverser la séquence, c'est verser de la puissance de calcul dans un seau percé.
Essayez maintenant
Vous voulez enfin faire quelque chose de vos documents d'entreprise ? Voici par où commencer avec UglyPear Données :
- Base d'ingénierie de données RAG et déploiement privé : https://www.uglypear.com/fr/products/
- Compression documentaire et normalisation de format : https://www.uglypear.com/fr/products/
- Pratiques d'ingénierie et réflexions sur l'architecture : https://www.uglypear.com/fr/blog/
- Accueil de la gamme en français : https://www.uglypear.com/fr/
Questions fréquentes
Ma base répond à côté : je change de modèle, ou je corrige les données ?
Dans la plupart des cas, c'est un problème de données. Même un modèle puissant reste plafonné par la qualité de son entrée. Mettez la compression, le nettoyage, le découpage et le masquage en ordre d'abord : le plafond de qualité de recherche remontera. Changer de modèle ne traite en général que « le plafond est-il assez haut », tandis que la base d'ingénierie traite « le plancher est-il assez stable ».
La compression détruit-elle les cachets et les clauses essentielles ?
Non. La compression distingue selon l'usage le avec et le sans perte : le texte, les cachets et les schémas — les éléments clés — suivent un circuit fidèle, tandis que les objets redondants et les médias sont recodés. Un test public le montre : un document OFD de 443 pages a été compressé en environ 124 secondes, avec netteté et cachets préservés.
Comment fonctionne le masquage des informations sensibles, et risque-t-il d'abîmer le texte ?
On identifie et on occulte par règles des catégories comme les noms, les pièces d'identité, les montants ou les secrets commerciaux — au total 13 catégories. On ne touche qu'aux endroits concernés, et on préserve autant que possible le sens du corps du texte. Les champs précis à masquer méritent d'être calés sur votre propre liste de conformité.
Déploiement privé contre modèle cloud : quelle est la vraie différence ?
Elle tient à l'endroit de la donnée. Le déploiement privé fait tourner la préparation et la recherche dans votre propre environnement ; les documents ne quittent pas le réseau interne. Le modèle cloud, lui, exige que le contenu sorte pour être utilisé. Pour des contrats, des dossiers médicaux ou des données financières, garder l'information en local offre un cadre de conformité plus net.
Petite équipe, peu de documents : la base d'ingénierie me concerne-t-elle ?
Regardez « à quel point c'est le bazar », pas « à quel point c'est volumineux ». Même avec quelques milliers de fichiers, si les formats sont hétéroclites, s'il y a des champs sensibles, s'il faut archiver sur la durée, une préparation observable économise un travail de réparation énorme. Avec peu de documents, il est même plus facile de mettre le circuit au carré avant de le faire grossir avec l'activité.