Il était une fois un dossier partagé. Chez la plupart des équipes e-commerce, il ressemble aujourd'hui à un grenier que personne n'ose vider : catalogues produits, fiches techniques, contrats fournisseurs, scripts de support, politiques de retour, séquences pour les lives. Rien ne disparaît, tout s'empile, et au bout de quelques mois, personne ne sait plus très bien où se trouve la bonne version d'un même article. On ouvre trois onglets, on cherche dix minutes, on finit par demander dans le groupe « quelqu'un a le dernier PDF de la garantie ? ».
La pression est venue d'ailleurs que de l'organisation interne. Les régulateurs, en Europe comme sur d'autres marchés, posent désormais des questions précises sur l'endroit où vivent réellement les données client et les registres de transaction. Lorsqu'un auditeur demande « où sont passées les preuves originales, et sont-elles sorties de votre réseau », la réponse « on verra plus tard » ne tient plus. La souveraineté des données n'est plus un slogan de conférence : c'est une contrainte de tous les jours pour qui stocke des commandes, des factures et des contrats. Et le scénario qui fait vraiment trembler, ce n'est pas le stockage — c'est l'incapacité à produire la bonne pièce, à la bonne minute, sans l'avoir confiée à un tiers.
Chez « UglyPear Data », le motif revient sans surprise d'une mission à l'autre. Le goulot n'est jamais un outil manquant. C'est trop de fichiers, trop dispersés, et trop fragiles — on a peur de supprimer quoi que ce soit, peur de ne plus le retrouver, peur qu'un audit révèle un trou que personne n'avait repéré. Les équipes e-commerce ne manquent pas de solutions pour classer. Elles manquent d'un endroit où le classement tienne la distance, sans que chaque recherche devienne un petit voyage.
McKinsey a mis un chiffre sur le temps gaspillé : près de 19 % de la semaine de travail part en recherche et en collecte d'informations. Dans une équipe e-commerce, le chiffre ne fait qu'augmenter, parce que la pile ne cesse de grossir et que chaque nouveau canal en ajoute une couche. Komprise a passé au crible un pan de stockage d'entreprise et en a tiré quelque chose d'inconfortable : entre 60 % et 70 % des données n'avaient pas été ouvertes depuis plus de 90 jours, et pourtant elles occupaient encore le niveau de stockage le plus cher. Les fichiers dont on a réellement besoin se retrouvent enterrés sous ceux qu'on avait oubliés. Le pire n'est pas le volume. C'est que la donnée utile se noie dans la donnée dormante.
Le coût, personne ne le budgète vraiment. Le stockage principal se facture au niveau premium. Laisser six à sept dixièmes de ses données sur ce niveau, c'est payer un loyer pour des fichiers endormis. Quand une opération promotionnelle se termine, les pages d'accueil de la saison dernière, les extraits de live périmés et les conditions promo annulées restent là, bien au chaud sur le tier le plus onéreux. Personne ne les efface, parce que personne ne veut être celui qui a parié trop vite sur « on ne sera jamais amené à en avoir besoin ». On paye pour des archives que plus personne ne lit.
L'e-commerce a sa propre torsion : trop de canaux, trop de versions. Un même produit circule en quatre ou cinq descriptions quasi jumelles — page de détail, script d'animateur, clause SAV, annonce à l'international. Laquelle est à jour ? Souvent, incertain. À cet instant on comprend que le vrai coût n'est pas le stockage. C'est « trouver » et « reconnaître ». Et la charge cognitive ne nous aide pas du tout. Une étude menée avec Asana et des chercheurs sur la concentration montre qu'après une interruption, il faut en moyenne 23 minutes pour retrouver un véritable état de focus, et qu'un travailleur passe sa journée à basculer entre environ 35 applications différentes. Chaque saut vers un autre outil pour retrouver un fichier n'est pas qu'une perte de temps mesurable : c'est une fracture dans l'attention, qui coûte bien plus cher que les minutes perdues au compteur.
Conifer tout ça à un modèle en cloud public pour bâtir une base de connaissances, c'est tentant sur le papier. En pratique, trois ennuis reviennent, et ils ne sont pas des détails de configuration.
Le premier : les données doivent quitter votre réseau. Dès qu'il s'agit de commandes client ou de registres de transaction, c'est un mur de conformité avant même d'avoir écrit une requête. On confie à un tiers ce qu'un auditeur exige de garder sous clé. Le deuxième : les fichiers bruts entrent directement dans l'index, et un catalogue de quelques centaines de pages, photo à chaque page, va saturer votre quota de stockage et de recherche avant même que quelqu'un n'ait posé une question. Le troisième : la recherche est lente, et on ne sait jamais tout à fait si le modèle « se souvient » bien de ce qu'il avance, ni d'où il le tient.
Alors, comment monter une base de connaissances à la fois conforme et retrouvable ? En trois gestes simples à énoncer, plus délicats à exécuter : garder les données sur ses propres serveurs, déployer une base d'ingénierie des données RAG en privé, et placer une étape de compression en amont de l'ingestion. C'est l'approche local-first — les données ne bougent pas, c'est le traitement qui vient à elles.
Voici un cadre de choix sur les dimensions qui comptent vraiment quand on compare les deux routes.
| Dimension | Base de connaissances SaaS en cloud public | RAG privé + compression (en local) |
|---|---|---|
| Destination des données | Sort du domaine, part vers le cloud public | Reste dans votre réseau |
| Adaptabilité conformité | Difficile à caler sur les règles locales d'archivage et de confidentialité | Modelable sur vos exigences de conformité |
| Réponse à la recherche | Affectée par le réseau et les quotas | Recherche locale, réponse rapide |
| Volume des fichiers | Fichiers volumineux indexés tels quels, coûteux en espace | Compressés et allégés avant indexation |
| Formats de longue traîne | Couverture limitée | Couvre PDF, images, vidéos, plans techniques, et plus |
Le travail dur d'un RAG privé n'est pas de brancher un modèle. C'est de nettoyer le matériel et de le ranger proprement dans la bibliothèque, avec des métadonnées qui tiennent la route. L'approche de « UglyPear Data » repose sur une base d'ingénierie des données RAG : un pipeline structuré, déployé en privé pour que les données ne quittent jamais le réseau, avec une désensibilisation automatique sur 13 catégories d'informations sensibles. Pour l'e-commerce, cela signifie que contrats fournisseurs, commandes client et fiches produits peuvent tous être retrouvés et cités en local, sans déplacer ni exposer les données originales. On interroge la source, on obtient la citation, et la donnée n'a pas franchi le pare-feu.
Le RAG seul laisse encore une bibliothèque gonflée. SmartSlim prend en charge l'étape précédant l'ingestion : il compresse documents, images, vidéos et audio — une réduction de volume publiquement annoncée de 60 % à 80 %. Un point mérite qu'on s'y arrête, parce qu'il change le quotidien des équipes produit : un « document composite » comme un catalogue regorge d'images, et le moteur de compression convertit ces images intégrées vers des formats plus légers avant que le fichier n'entre dans la bibliothèque. Vous n'exportez pas les visuels à la main, et vous ne perdez pas en lisibilité — les tampons et les graphiques restent nets.
Un détail de mise en pratique, vu du lecteur plutôt que de l'ingénieur : ces documents composés, catalogues et fiches techniques, embarquent souvent des dizaines d'images. Avant même l'entrée en base, le moteur de compression transforme les visuels intégrés en formats plus légers, si bien que l'ouvrage entier maigrit avant de rejoindre la bibliothèque. Pas besoin de sortir les images une par une ni de rejouer une chaîne d'export. Les éléments visuels clés — un sceau, un tableau de chiffres, une notice — restent parfaitement lisibles une fois le document allégé. Les chiffres publics donnent le ton : un volume réductible de 60 % à 80 %, un document de 443 pages traité en 124 secondes en conditions réelles, et les tokens liés aux images peuvent baisser d'environ 85,9 %. Autant d'espace économisé avant même la première recherche.
En surface, ce n'est que de la place gagnée. En regardant de plus près, on retire la jambe la plus coûteuse de tout le système : plus petit avant la recherche, c'est une recherche plus rapide et plus juste, et la synchronisation entre appareils cesse de s'enrayer. On ne fait pas seulement « tenir » le stockage. On rend la base utilisable au quotidien, par les gens qui n'ont ni le temps ni l'envie de devenir architectes de données.
Compresser sans bâtir de base, et les fichiers sont plus légers mais personne ne les trouve — on a un grenier propre, toujours illisible. Bâtir une base sans compresser, et vous avez construit quelque chose de trop lourd pour rouler, qui finit par être contourné. Les deux ensemble font une base de connaissances légère, rapide et conforme, et c'est précisément ce relais qui manque à la plupart des projets.
Un scénario concret, celui que les équipes support connaissent par cœur. On vous demande la clause de garantie d'un produit ancien, celui qu'on ne vend plus mais dont trois clients réclament encore la couverture. Avant, il fallait fouiller les historiques de discussion, traquer un PDF égaré, puis solliciter l'équipe produit en espérant une réponse avant la fin de la journée. Aujourd'hui, on interroge la base locale et la réponse revient avec sa source — quel document, quelle section, quel libellé exact. Commandes et contrats restent sur le réseau interne ; vous n'expédiez pas de données client vers l'extérieur pour obtenir une seule phrase. Et si la question devient un litige, la trace est déjà là, intérieure, citée, vérifiable.
L'échange avec l'auditeur s'apaise aussi, et c'est loin d'être le moindre bénéfice. Les auditeurs ne veulent pas entendre « nous avons ajouté de l'IA ». Ils veulent sortir la preuve originale à la demande et confirmer qu'elle n'a jamais quitté le réseau. Le déploiement privé, doublé d'un archivage local, répond exactement à cette exigence — un angle de souveraineté des données et de conformité en environnement isolé (air-gapped) que les offres SaaS peinent à garantir, précisément parce qu'elles supposent, par conception, que vos données entrent chez elles.
On pourrait croire que tout cela ne concerne que les grands comptes, ceux qui ont une équipe dédiée à la gouvernance. La réalité est l'inverse : ce sont les structures de taille moyenne, sans spécialiste de la donnée à plein temps, qui perdent le plus de temps dans les recherches et qui prennent le plus de risques sans le savoir. Une base locale, discrète, qu'on interroge comme on interrogerait un collègue, change la donne bien plus pour elles que pour un département already outillé. Pour explorer d'autres cas d'usage dans le détail, notre blog technique décompose plusieurs secteurs, de la logistique au support client.
FAQ
Q : Une base de connaissances e-commerce doit-elle obligatoirement être privée ?
R : Pas nécessairement. Si le matériel est léger et non sensible, un SaaS en cloud public suffit largement. Mais tout ce qui touche aux registres de transaction, aux commandes client ou aux contrats fournisseurs est bien plus sûr en local, où les données restent dans votre réseau et où vous gardez la main sur leur parcours.
Q : Les catalogues et fiches techniques sont riches en images. La compression va-t-elle les flouter ?
R : Le moteur traite spécifiquement les documents composés, en convertissant les images intégrées vers des formats plus légers tout en préservant les informations visuelles clés. Des tests publics ont traité un document de 443 pages en 124 secondes, avec une clarté maintenue — les tampons et les tableaux restent lisibles.
Q : Combien de temps faut-il pour monter une base RAG ?
R : L'approche privilégie un test de bout en bout, avec une recherche et une réponse au niveau de la sous-seconde. Les délais réels dépendent du volume de données et de la méthode d'intégration ; la plupart des cas sont évalués en se connectant directement aux bases métier existantes, sans migration brutale ni déplacement des données.
Q : Pourquoi utiliser la compression et le RAG ensemble ?
R : On peut utiliser l'un ou l'autre séparément, mais ensemble ils s'emboîtent. La compression réduit les fichiers avant ingestion ; le RAG assure la recherche et la génération en local. Ce relais donne une base légère, rapide et conforme, plutôt qu'un système moitié vide ou moitié engorgé.
Q : Pour les documents riches en images, le coût en tokens peut-il baisser ?
R : Oui. Les tests publics montrent que les tokens liés aux images peuvent chuter d'environ 85,9 %, ce qui compte surtout pour les contenus destinés à alimenter la recherche et à être cités en réponse.
Try it now
Pour voir le résultat en pratique, découvrez SmartSlim en éditions bureau et serveur, ou parcourez la base d'ingénierie des données RAG pour l'option de déploiement privé. D'autres scénarios décomposés attendent sur notre blog technique, et la vue d'ensemble des produits rassemble tout en un seul endroit.