Cas 004 : un assistant RAG pour l'équipe support technique d'un distributeur B2B (mesuré sur 11 mois)

TL;DR

• Client : distributeur B2B de matériel technique (CVC, plomberie, équipement de réseau) de 46 salariés près de Nantes. Environ 9 000 références actives, 3 techniciens au support, et un expert produit sur le départ en retraite. Problème : des questions de compatibilité et de spécifications qui partaient en chasse au trésor dans 9 000 PDF fournisseurs, un temps de réponse qui s'allongeait, et un risque de perte de savoir au moment du départ de l'expert.
• Stack livrée : ingestion documentaire n8n + base vectorielle managée + Claude pour la génération, le tout en copilote interne (l'IA prépare et cite ses sources, le technicien valide avant l'envoi). Setup 10 400 EUR en 7 semaines, exploitation 180 EUR par mois.
• Résultats à 11 mois : temps moyen de réponse technique divisé par 2,3, onboarding d'un nouveau technicien passé de 8 à 3 semaines, retours produits pour mauvaise compatibilité ramenés de 11 à 6 par mois, et surtout le départ de l'expert absorbé sans rupture de service.
• Trois incidents documentés sans maquillage : une fiche fournisseur périmée recommandée à tort, un technicien junior qui a copié une réponse sans lire la source, et deux mois où la base s'est périmée faute de responsable nommé.
• Anonymisé à la demande du client, chiffres réels conservés.

Pourquoi on publie ce cas

Quand on a publié notre guide sur la base de connaissance pour agent IA, on y défendait une idée qui passe mal en réunion commerciale : dans un projet RAG, le modèle ne fait pas la différence, c'est le corpus qui fait tout. Plusieurs lecteurs nous ont écrit pour demander un exemple concret, chiffré, avec les ratés. En voici un.

Ce déploiement coche une case rare dans nos retours d'expérience : ce n'est ni de la qualification de leads comme dans le cas 001, ni du support client externe comme dans le cas 002. C'est un outil interne, invisible pour les clients du distributeur, qui aide trois personnes à répondre plus vite et plus juste. Le genre de projet qui ne fait pas une jolie démo mais qui change la vie d'une équipe. Et qui, comme tous les projets honnêtes, a connu des semaines où rien ne marchait.

Comme pour nos trois premières études de cas : identité du client retirée, secteur et chiffres réels conservés.

Le contexte de départ

Le client distribue du matériel technique pour les professionnels du bâtiment : chauffagistes, plombiers, électriciens, installateurs de réseaux. Environ 9 000 références actives, une centaine de fournisseurs, et une clientèle d'artisans et de petites entreprises du Grand Ouest qui passent commande au comptoir, par téléphone ou via le site.

Le nerf de la guerre dans ce métier, ce n'est pas le prix, c'est le conseil technique. Un installateur qui appelle pour savoir si telle vanne thermostatique est compatible avec une chaudière de telle génération, si telle pièce de rechange existe encore, si tel raccord supporte telle pression : il veut une réponse juste, tout de suite. Une réponse fausse, et c'est lui qui se déplace deux fois sur le chantier. Une réponse lente, et il commande ailleurs.

L'état des lieux début 2025, au moment du cadrage :

• 3 techniciens au support, qui traitaient ensemble environ 70 demandes techniques par jour, par téléphone et par email.
• Une documentation produit éclatée : à peu près 9 000 fiches techniques en PDF, fournies par une centaine de fournisseurs, avec des conventions de nommage incohérentes, des doublons, et des versions multiples de la même fiche au fil des révisions.
• Un ERP qui connaissait les références et les stocks, mais rien des spécifications fines.
• Un homme-orchestre : le responsable technique, 28 ans de maison, qui avait le catalogue dans la tête. Quand une question était vraiment pointue, tout le monde se tournait vers lui. Et il partait en retraite à l'automne.

Ce dernier point était le vrai déclencheur. La direction ne nous a pas appelés pour gagner du temps, elle nous a appelés parce qu'elle avait peur. Peur de ce qui allait se passer le jour où le savoir accumulé en 28 ans franchirait la porte pour ne plus revenir. Le gain de productivité, on l'a présenté comme un bonus. Le sujet réel, c'était la continuité.

Ce profil est plus répandu qu'on ne croit. Selon Bpifrance Le Lab, 55 pour cent des TPE et PME françaises déclaraient utiliser des outils d'IA générative fin 2025, contre 31 pour cent un an plus tôt. Mais derrière ce chiffre flatteur, l'usage réel reste souvent superficiel : un commercial qui rédige un email avec ChatGPT, ce n'est pas la même chose qu'un système branché sur la documentation maison. Le saut entre les deux, c'est précisément le travail de structuration documentaire que ce client a accepté de financer. C'est ce saut qui sépare le gadget de l'outil.

Phase 1 : cadrage et nettoyage (3 semaines, presque aucune IA)

On répète ce conseil dans presque toutes nos missions et il vaut un cas pour l'illustrer : avant d'allumer le moindre modèle, il faut savoir ce qu'on lui donne à manger.

Les trois premières semaines n'ont quasiment pas touché à l'IA. On a fait l'inventaire des 9 000 PDF, et le diagnostic a été brutal. Environ 18 pour cent étaient des doublons stricts. À peu près 12 pour cent concernaient des références déjà retirées du catalogue mais jamais archivées. Et le nommage relevait de l'archéologie : on a trouvé une même fiche produit sous quatre noms de fichier différents selon l'année où un commercial l'avait téléchargée.

Sur un projet client PME en 2025, on avait sous-estimé exactement ce poste et on en avait payé le prix : un assistant qui hésitait entre trois versions d'une même fiche et sortait des réponses contradictoires d'une fois sur l'autre. Cette fois, on a budgété le nettoyage dès le départ. Concrètement :

• Déduplication par empreinte de contenu, pas par nom de fichier.
• Datation de chaque fiche : date de la révision fournisseur quand elle existait, date d'ingestion sinon. Ce champ deviendra crucial, on verra pourquoi avec le premier incident.
• Mise à l'écart des références mortes dans un dépôt séparé, non indexé mais conservé pour l'historique (un installateur peut toujours demander une pièce d'un modèle de 2009).
• Une convention de nommage unique, appliquée par script, pour tout ce qui rentre désormais.

À l'issue de ces trois semaines, on est passé de 9 000 fichiers en vrac à environ 6 200 fiches actives, propres et datées. C'est ce corpus-là qu'on a indexé. Le reste du projet a été beaucoup plus rapide parce que cette fondation était saine. Une fondation pourrie aurait condamné la suite, quelle que soit la qualité du modèle.

Phase 2 : l'architecture livrée

Rien d'exotique. Un pipeline RAG classique, mais discipliné. Quatre briques.

Ingestion. Un workflow n8n qui surveille un dossier partagé et la boîte fournisseurs. Quand une nouvelle fiche arrive ou qu'une fiche est révisée, elle est nettoyée, datée, découpée en fragments cohérents (un fragment par caractéristique technique plutôt qu'un découpage aveugle tous les 500 mots), puis envoyée à la base vectorielle. L'ingestion est incrémentale : on ne réindexe pas tout chaque nuit, seulement ce qui change.

Base de connaissance. Une base vectorielle managée, hébergée en Europe pour la question de la résidence des données. Chaque fragment porte ses métadonnées : fournisseur, famille de produit, date, et un drapeau actif ou archivé. Ces métadonnées servent à filtrer avant même la recherche sémantique, ce qui réduit énormément le bruit.

Génération. Quand un technicien pose une question, le système récupère les fragments pertinents et demande à Claude de formuler une réponse en s'appuyant uniquement sur ces fragments, avec une consigne stricte : citer la fiche source pour chaque affirmation, et répondre "je ne trouve pas l'information dans la documentation" plutôt que d'inventer quand le contexte ne contient pas la réponse. Cette dernière consigne paraît anodine, elle est en réalité le garde-fou numéro un contre les réponses inventées.

Interface et validation humaine. Pas de nouvel outil à apprendre. L'assistant vit dans la messagerie interne que l'équipe utilisait déjà. Le technicien tape sa question, reçoit une réponse pré-rédigée avec les liens vers les fiches sources, vérifie, et envoie au client. Pour les questions à fort enjeu (compatibilité, dimensionnement, sécurité), la relecture de la source est obligatoire. Ce choix d'architecture rejoint directement ce qu'on défend dans notre article sur la sécurité des agents IA en production : la maîtrise ne se joue pas dans le prompt, elle se joue dans ce que l'humain garde sous contrôle au moment de l'effet de bord, ici l'envoi au client.

Pourquoi avoir refusé le chatbot en libre service côté client, que la direction avait vu chez un concurrent et trouvait séduisant ? Parce que l'asymétrie du risque est trop forte. Les benchmarks 2025 du support automatisé évoquent des taux de déviation de tickets de 40 à 60 pour cent pour les meilleurs déploiements, et c'est réel sur du support logiciel grand public. Mais sur du conseil technique B2B où une erreur de compatibilité coûte un retour produit et un chantier bloqué, la déviation aveugle n'est pas un gain, c'est un transfert de risque vers le client final. On a préféré viser un assistant qui rend l'équipe meilleure plutôt qu'un robot qui la remplace mal.

Phase 3 : la mise en service et les chiffres

Première version utilisable au bout de six semaines. Pas parfaite, mais déjà au-dessus de la recherche manuelle pour les questions courantes. On a démarré en double commande : les techniciens posaient leur question à l'assistant tout en cherchant comme avant, pour comparer. Au début, la moitié des réponses de l'assistant étaient jugées "à retravailler". Au bout de deux mois, après plusieurs passes de nettoyage du corpus et d'ajustement du découpage, on était à environ 80 pour cent de réponses utilisables telles quelles ou avec un ajustement mineur.

Voici les chiffres mesurés sur 11 mois de production, comparés à la situation de départ :

• Temps moyen de réponse à une demande technique : d'environ 9 minutes (recherche dans les PDF, vérification, rédaction) à environ 4 minutes. Soit une division par 2,3. Sur les questions vraiment répétitives, on descend à moins de 2 minutes.
• Onboarding d'un nouveau technicien : le SAV a recruté en juin. Le nouvel arrivant a été jugé autonome sur le téléphone en 3 semaines, contre 8 semaines pour le précédent recrutement deux ans plus tôt. L'assistant lui servait de filet : il pouvait répondre juste avant de tout savoir par cœur.
• Retours produits pour mauvaise compatibilité : de 11 par mois en moyenne avant projet à 6 par mois sur le dernier trimestre. C'est le poste qui a le plus surpris la direction, parce qu'il touche directement la marge.
• Départ de l'expert : absorbé sans rupture. Avant son départ, on a passé trois semaines à transformer ses réponses orales en fiches de synthèse internes, intégrées au corpus. Son savoir n'est pas parti avec lui, il est devenu une source que l'assistant cite.
• Volume traité : l'équipe absorbe désormais les pics saisonniers (la rentrée chauffage) sans recourir à l'intérim, ce qu'elle faisait auparavant.

Une nuance honnête sur le temps gagné : il ne s'est pas transformé en réduction d'effectifs et ce n'était pas le but. Il s'est transformé en disponibilité pour le conseil sur les gros dossiers, ceux qui font la différence commerciale. C'est plus difficile à chiffrer qu'une ligne de salaire en moins, mais le directeur commercial vous dira que c'est là que le projet a vraiment payé.

Les trois incidents, racontés sans filtre

Une étude de cas qui ne raconte que les succès est une publicité. Voici ce qui a cassé.

Incident 1 : la fiche fantôme. Au quatrième mois, un technicien recommande une référence de circulateur en s'appuyant sur une réponse de l'assistant. Problème : la fiche citée correspondait à une version du produit retirée du catalogue six mois plus tôt. Le modèle de remplacement avait des cotes de raccordement légèrement différentes. L'erreur a été rattrapée par le technicien lui-même au moment de vérifier le stock dans l'ERP, mais elle aurait pu passer. La cause : une fiche obsolète qui n'avait pas été basculée dans le dépôt archivé, et qui restait sémantiquement assez proche de la question pour être récupérée. C'est exactement le phénomène que les praticiens du RAG appellent l'hallucination par voyage dans le temps : un vieux document, toujours indexé, qui ressort comme s'il était d'actualité. Le correctif a été double : un audit complet pour purger les fiches mortes restantes, et surtout un filtre dur sur le drapeau actif au niveau de la récupération, pour qu'une fiche archivée ne puisse plus jamais remonter dans une réponse, même si elle colle parfaitement à la question.

Incident 2 : le copier-coller du junior. Le nouveau technicien, dans sa troisième semaine, a pris goût à l'assistant un peu trop vite. Sur une question de compatibilité de pression, il a copié la réponse pré-rédigée sans cliquer sur la source, et l'a envoyée. La réponse était bonne sur le principe mais omettait une réserve qui figurait dans la fiche : une limite de température au-delà de laquelle le raccord n'était plus garanti. Le client a installé, ça a tenu, mais on est passé près d'un litige. La leçon n'est pas technique, elle est humaine : un copilote trop fluide pousse à la confiance aveugle. Le correctif a été un rappel de procédure (la source se lit avant l'envoi sur les questions à enjeu) et un petit ajout d'interface : sur les réponses portant sur la sécurité ou le dimensionnement, l'envoi n'est possible qu'après avoir ouvert au moins une source. Une friction volontaire, assumée.

Incident 3 : la base qui se périme en silence. L'été, le projet tourne, tout le monde est content, et personne ne surveille plus l'ingestion. Pendant près de deux mois, trois nouveaux fournisseurs ont été référencés sans que leurs fiches entrent dans le corpus. Résultat : l'assistant répondait "je ne trouve pas l'information" sur des produits que l'entreprise vendait pourtant, et les techniciens ont commencé à le contourner pour ces marques, ce qui érode la confiance dans l'outil. Le problème n'était pas technique, le pipeline marchait. Le problème, c'est que personne n'était responsable de la fraîcheur. On a corrigé en nommant explicitement une personne au SAV propriétaire du corpus, avec une règle simple : tout nouveau fournisseur référencé déclenche une tâche d'ingestion de ses fiches sous cinq jours ouvrés. Depuis, plus de trou.

Ces trois incidents ont un point commun qu'on retrouve dans presque tous nos déploiements : aucun n'est une défaillance du modèle d'IA. Le premier est un problème de données, le deuxième un problème de procédure humaine, le troisième un problème de gouvernance. C'est rassurant et déprimant à la fois : rassurant parce que tout cela se corrige, déprimant parce que ça veut dire que la techno est la partie facile.

Ce que ça a coûté, et le ROI mesuré

Soyons précis, parce que c'est là que beaucoup de prestataires entretiennent le flou.

Le coût de mise en place a été de 10 400 EUR sur 7 semaines, dont une part importante (à peu près 40 pour cent) consacrée au nettoyage documentaire, pas à la technique. L'exploitation tourne à 180 EUR par mois : environ 70 EUR de coût d'API, le reste en hébergement de la base vectorielle et en supervision légère. Sur 11 mois, le coût total ressort à environ 12 380 EUR.

En face, il faut distinguer deux natures de gains, parce qu'elles ne pèsent pas pareil.

Les gains soft, réels mais difficiles à encaisser : les minutes récupérées par l'équipe sur chaque réponse. C'est tangible au quotidien, ça améliore la qualité de vie et la capacité à absorber les pics, mais ça ne se transforme pas mécaniquement en euros tant qu'on ne réduit pas l'effectif, ce qu'on n'a pas fait.

Les gains durs, eux, se comptent : la montée en compétence du nouveau technicien raccourcie d'environ cinq semaines de salaire chargé, soit près de 4 500 EUR économisés une fois. La rétention du savoir de l'expert, qu'il aurait fallu sinon documenter en catastrophe ou racheter en prestation. Et surtout la baisse des retours produits pour mauvaise compatibilité, de 11 à 6 par mois, à environ 350 EUR de reprise pièce en moyenne, soit près de 1 750 EUR économisés par mois sur la fin de période. Sur ce seul poste, le projet se rembourse en sept à huit mois.

Le directeur, lui, ne cite jamais ces chiffres en premier. Quand on lui demande ce que le projet a apporté, il répond : "Je dors mieux depuis que je sais que le savoir de la maison ne tient plus dans une seule tête." C'est probablement la métrique la plus honnête, même si elle ne rentre dans aucun tableur. Pour creuser la question des coûts d'un agent en production, on détaille les postes et les pièges dans notre article dédié au coût d'un agent IA.

Ce qu'on referait, ce qu'on changerait

Ce qu'on garderait sans hésiter : le copilote validé par l'humain plutôt que l'automatisation totale, le filtre dur sur les fiches actives, et le découpage par caractéristique technique plutôt qu'en tranches aveugles. Ces trois choix expliquent l'essentiel de la fiabilité atteinte.

Ce qu'on ferait différemment : nommer le responsable du corpus dès le premier jour, pas après l'incident de l'été. Et investir encore plus dans le nettoyage initial, parce que chaque heure passée à assainir la base au départ a évité plusieurs heures de réponses douteuses ensuite. Si on devait résumer ce projet en une phrase pour un dirigeant de PME qui hésite : un assistant RAG ne vaut que ce que vaut sa documentation, et la documentation ne reste bonne que si quelqu'un en est responsable. Le modèle, lui, vous le changerez trois fois en deux ans sans que ça change grand-chose.

Si ce cas résonne avec une situation chez vous (un savoir concentré sur une personne, une documentation qui part dans tous les sens, une équipe qui passe son temps à chercher au lieu de répondre), c'est exactement le type de mission qu'on cadre en commençant par un audit du corpus avant de parler technique. La conversation honnête commence toujours par là.