Imaginez qu'on verse dans un « système intelligent » tous les documents que votre entreprise possède — contrats, notes de recherche, transcriptions d'appels, scans de plusieurs centaines de pages. Que va-t-il s'en faire ? La réponse honnête, celle que donne qui a vécu le truc, tient en trois issues : soit le système refuse de les absorber, soit il les prend et répond à côté de la question, soit la facture grimpe sans bruit. Aucune de ces issues ne ressemble à la promesse du chariot magique.
Le constat chiffré ne arrange rien. Komprise observe régulièrement la même chose sur les baies de stockage d'entreprise : entre 60 et 70 % des données posées sur le stockage primaire ne sont pas touchées depuis plus de 90 jours, et elles croupissent pourtant sur du matériel coûteux. McKinsey met un visage humain sur la recherche : les professionnels du savoir consacrent près de 19 % de leur semaine de travail — environ une heure et demie par jour — à chercher et rassembler de l'information. Asana enfonce le clou de l'interruption : il faut à peu près 23 minutes pour retrouver son fil après une coupure, et l'on bascule entre une trentaine d'applications chaque jour. Un document mal géré ne se contente pas de prendre de la place sur un disque. Il aggrave, en boucle, le coût de chaque interruption.
Devant ce gâchis, le réflexe du débutant est presque toujours le même : trouver un outil pour réduire la taille des fichiers, ou installer au plus vite une base vectorielle pour rendre la pile recherche. Qui a construit de vrais systèmes en production ne démarre pas de là.
La question de départ n'est pas « quel outil », mais « pourquoi ces données doivent-elles changer ». Pour réduire le stockage ? Pour que les pièces jointes passent dans un mail ? Pour dépenser moins de tokens quand un modèle répond au-dessus ? Ou pour tenir un archive conforme qui doit survivre dix ans sans altération ? La même pile, selon l'objectif, réclame un traitement radicalement différent. L'opérateur aguerri cloue les contraintes au sol avant de toucher quoi que ce soit, au lieu de faire de la « compression » ou de « l'index vectoriel » un réflexe par défaut.
Une fois les contraintes posées, le mouvement suivant consiste à séparer la pile selon ce qu'elle est réellement. Un PDF de contrat signé avec un cachet rouge, un scan technique en très haute définition et un rapport réglementaire de deux cents pages sont trois bêtes distinctes. Le contrat exige que la structure et le sceau restent intacts à la virgule près. Le scan regorge de pixels redondants. Le rapport traîne des motifs de mise en page répétés. Balancer une « compression par défaut » sur les trois à la fois, et l'on obtient le pire des mondes : ce qui devait rester net s'effrite, ce qui aurait dû rétrécir ne bouge pas. C'est précisément là que l'amateur et le professionnel se séparent — l'amateur surveille « de combien ça a rétréci », le professionnel surveille « ce qui ne doit jamais bouger ».
Le professionnel revient alors à l'information elle-même. Pourquoi un fichier est-il lourd ? Un scan parce qu'il est un raster dense plein de redondance que l'œil ne distingue pas, mais que les octets traînent ; un document texte à cause de structures répétées et d'objets embarqués. Compresser ou non, et comment, ne doit donc pas suivre un préréglage usine, mais l'usage du fichier : une archive légale sur dix ans reste sans perte et réversible, un aperçu écran ou un mail accepte la perte pourvu que l'essentiel survive. Reprendre ce commutateur des mains du défaut, voilà la frontière entre un professionnel et l'usine.
Se tromper de typage, et tout l'aval casse : un contrat marqué « avec perte », le sceau bave, c'est un incident ; un scan forcé à rester intact, la taille ne bouge pas et la chaîne ralentit. L'opérateur aguerri préfère donc passer quelques minutes en amont à demander « dans quelle catégorie ça rentre, et qui s'en sert après ». Le typage n'est pas une case à cocher du processus. C'est le socle sur lequel tout le reste repose.
Un contrat scanné vit ou meurt par son cachet et sa date — les flouter, c'est juridiquementaltérer le document ; une image médicale, comprimer le mauvais bord, et l'on masque la zone qui compte. L'amateur voit « soixante pour cent de plus léger » et s'en réjouit. Le professionnel demande « y a-t-il, dans ces soixante pour cent, quelque chose qui ne doit pas bouger », car c'est la réponse à « qui pâtira si la chose change » qui décide si l'on compresse, et comment.
Il existe une couche que les débutants oublient : le même document vit souvent dans plusieurs systèmes, avec des versions incohérentes. L'opérateur aguerri réconcilie doublons et versions avant de parler compression ou recherche, car indexer des données sales garantit une recherche médiocre quoi qu'il vienne ensuite. Et le coût se compte en global : les embeddings calculés une fois, le reranking exécuté une fois, le modèle relisant le texte une fois — où chaque token compte davantage, tire-t-on des passages en surplus pour laisser le modèle choisir, ou pré-classe-t-on pour en tirer moins ? Tant que ce calcul n'est pas clair, « économiser » reste un slogan. Surtout en configuration à retrieval augmenté : chaque passage remonté est relu une fois de plus par un modèle, si bien que documents sales et découpage négligent font intérêt mensuel sur la facture de tokens. Compresser en amont, nettoyer en amont — souvent moins cher que d'acheter plus tard un modèle plus gros.
Qui a livré ça traite une base de connaissances comme un système qui tourne, pas comme un simple dépôt. Les documents changent, le métier change, ce qui répond juste aujourd'hui peut faiblir quand la version du mois prochain arrive. Dès le début, on laisse la place à un jeu d'évaluation et à une possibilité de retour arrière, et l'on traite « construire » et « entretenir » comme un travail indivisible. C'est cela qui explique pourquoi tant de démos éblouissent puis s'effondrent en production : une démo prouve que le système sait renvoyer quelque chose ; la production exige qu'il continue de répondre juste sur des documents réels, sales et mouvants. Celui qui prend « renvoyer quelque chose » pour une fin et celui qui le prend pour un début construisent des systèmes qui n'ont rien à voir.
Beaucoup séparent compression et retrieval comme deux métiers. Le professionnel, non. Il voit « ranger, réduire, découper, vectoriser, retrouver, répondre » comme une ligne, et il ne fait confiance qu'au résultat de la ligne entière, jamais à un chiffre joli pris isolément. Et avant la compression et le retrieval, il y a généralement une étape de rangement — le même matériau éparpillé dans une douzaine de dossiers au nom chaotique. Le professionnel décide avant tout où cela doit aller et selon quel axe classer, car même une recherche soignée ne sauve pas un document mal classé. Un document proprement compressé apporte moins de bruit au retrieval, dépense moins de tokens, rappelle plus sûrement — la compression n'est pas ici un bonus de stockage, c'est une étape préalable à la qualité du retrieval. Et quand le retrieval répond à côté, le professionnel ne tient pas d'emblée le modèle pour responsable : il remonte et se demande si un découpage a coupé une phrase en deux, si une question familière ne peut pas être captée par une recherche littérale, si le passage pertinent a été tronqué.
Sur le terrain du retrieval, l'outillage du professionnel ne ressemble pas à l'imaginaire de l'amateur. Il ne jette pas la question brute dans la machine : les vrais utilisateurs demandent en argot, en abréviations, en synonymes, souvent en empilant trois intentions dans une phrase — la belle « indiquez la politique de remboursement » des jeux d'éval n'existe quasiment jamais. Ils font donc du retrieval hybride : une voie par mots-clés pour l'exact, une voie sémantique pour le sens, le tout fusionné, et le taux de ratés baisse aussitôt ; après le tri initial, un reranker pousse le pertinent tout en haut. Pour les questions dures, ils réécrivent une phrase familière en plusieurs sous-requêtes façonnées pour la recherche, interrogent chacune, puis assemblent. Les droits et les sources sont filtrés en amont pour ne rien faire fuiter de confidentiel. Nos réflexions sur ces montages sont régulièrement décrites sur https://www.uglypear.com/fr/blog/.
Rien de tout cela n'est du tape-à-l'œil. Tout converge vers un point : faire de « répondre juste » un indicateur mesuré plutôt qu'une loterie — ce que personne ne demande et que le professionnel fait pourtant : préparer, avant toute ligne de code, un lot de paires question-réponse étiquetées avec leurs sources, car sans cela « juste » n'a pas de définition ; répartir les ratés par type de question pour voir d'un coup quelle catégorie déraille ; rejouer l'ancien jeu d'éval après chaque mise à jour pour attraper la dégradation où « juste aujourd'hui, faux le mois prochain ». L'approche qui soude compression, retrieval et déploiement privé en une ligne de production se trouve du côté de https://www.uglypear.com/fr/products/.
Pourquoi donc accorder foi à tout ça ? Pas parce qu'un fournisseur assure « nous sommes précis », pas parce qu'un acheteur espère « ça devrait suffire ». Ce qui tient debout, c'est ce qu'un tiers peut reproduire : un jeu d'or de questions étiquetées indépendamment, où n'importe qui relançant votre système voit recall@k et fidélité posés sur la table ; des tests à l'aveugle où nouvelles et anciennes chaînes répondent à de vraies questions, notées anonymement par des évaluateurs indépendants ; et une suite de régression où les cas connus pour être justes doivent le rester, l'état rouge-vert ouvert à l'inspection. La même exigence vaut pour la compression elle-même : le document compressé s'ouvre-t-il à l'identique, le sceau est-il présent, la mise en page a-t-elle glissé ? On rouvre et l'on compare. Après réduction, de combien les tokens ont fondu et le retrieval tient-il encore ? On exécute la tâche aval et l'on a la réponse. La justesse ne vient de la promesse de personne, mais d'actes que n'importe qui peut vérifier.
UglyPear Data a récemment avancé d'un petit pas sur la couture entre compression et retrieval : la compression préalable des documents, avant qu'ils n'entrent en recherche, a été adaptée pour fonctionner de façon stable sur plusieurs grands modèles de la place, si bien que le même document allégé reste lisible et utilisable par des modèles différents. C'est exactement le seuil évoqué plus haut — on le réduit, et il ne doit pas devenir illisible au modèle. Ce n'est qu'un point d'appui secondaire, loin de toute la profondeur de l'ingénierie, mais la direction est saine : souder « petit » et « lisible » en une chose, puis empiler par-dessus évaluation, reranking et observabilité. Les retours d'expérience sur ce type de chaîne souveraine sont également suivis sur https://www.uglypear.com/fr/blog/.
Le tableau ci-dessous oppose le réflexe d'outil par défaut à la conduite de quelqu'un qui a livré ce genre de système, sur quelques points décisifs et mesurables.
| Axe de décision | Réflexe par défaut | Réflexe de l'opérateur aguerri | Signal mesurable |
|---|---|---|---|
| Point de départ | Compresser directement / poser un index vectoriel directement | Cloue d'abord pourquoi les données doivent changer | Contraintes documentées avant toute action (aucune vs plusieurs) |
| Traitement des documents | Une compression par défaut pour tous | Classe par contrat / scan / rapport, puis choisit | Part de documents mal typés (élevée vs faible) |
| Avec ou sans perte | Suit le préréglage | Décide par usage : sans perte pour archive, avec perte pour aperçu | Part de contenus altérés (élevée vs faible) |
| Compression et retrieval | Tenus pour deux métiers | Une ligne, confiance au résultat global | Bruit en entrée de retrieval (élevé vs réduit) |
| Requête | Recherche de la phrase brute | Retrieval hybride + rerank + réécriture/décomposition | Taux de ratés sur questions réelles (élevé vs réduit) |
| Preuve de qualité | Affirmation du fournisseur | Jeu d'or étiqueté + A/B à l'aveugle + suite de régression | Part de bonnes réponses vérifiable par un tiers (faible vs ouverte) |
Essayez maintenant
Pour voir une approche qui soude « déploiement privé, données ne quittant pas le réseau interne, compression et retrieval sémantique » en une ligne de production :
FAQ
Une petite entreprise avec peu de documents : la compression par défaut suffit-elle ?
Tout dépend de l'usage que vous faites des documents. Passer un fichier en interne, la compression par défaut passe généralement. Mais dès que les documents entrent en recherche, nourrissent un modèle ou doivent servir de preuve, la différence qu'apportent typage et stratégie devient réelle.
Un document compressé peut-il encore servir de preuve en justice ?
Cela dépend de la méthode. L'archive sans perte reste réversible et intacte, sceaux et contenu à l'identique, donc recevable. L'aperçu avec perte ne vaut que pour une lecture rapide. La clé n'est pas « a-t-on compressé », mais « quel chemin ce type a-t-il pris ».
Le retrieval hybride paraît lourd. Une petite équipe peut-elle se le permettre ?
Dans le fond, c'est « mots-clés plus sémantique » fusionnés, puis un reranker — le tout dispose d'implémentations ouvertes. Le coût n'est pas financier, il est dans la volonté de traiter « répondre juste » comme un indicateur à mesurer en continu.
Comment savoir si une base de connaissances répond vraiment juste ?
Ne croyez pas la démo. Il faut un jeu de questions-réponses étalonné, une évaluation rejouable, plus des tests à l'aveugle et de la régression. Si un tiers peut relancer votre système sur le même étalon, la conclusion tient.
Faut-il faire compression et RAG ensemble ?
Pas forcément par le même acteur, mais il faut les voir comme une ligne. Un document proprement compressé qui entre en retrieval apporte moins de bruit, dépense moins de tokens et rappelle plus sûrement — couper les deux en deux coûte en général aux deux bouts.