
L’entreprise conçoit et maintient des machines de lavage de haute précision pour l’aéronautique, le ferroviaire et l’automobile. Chaque machine est unique, livrée à façon, avec son propre dossier technique : notice d’utilisation, schémas électriques, nomenclatures de pièces, historique de maintenance. Au fil des décennies, ce patrimoine a gonflé jusqu’à atteindre 50 000 fichiers stockés sur un serveur interne.
Le problème était simple à formuler, beaucoup moins à résoudre. Les quatre techniciens itinérants du SAV (et la vingtaine de collaborateurs susceptibles de partir en intervention) passaient un temps déraisonnable à fouiller des arborescences de dossiers pour retrouver la bonne information. Un schéma électrique de 50 pages en PDF, une nomenclature Excel enfouie trois niveaux plus bas, une notice de 20 Mo dont personne ne se rappelait le nom exact. La friction ralentissait les diagnostics, allongeait les dépannages téléphoniques et pesait sur chaque intervention sur site.
La base documentaire n’était pas un simple répertoire de PDF. On y trouvait des notices natives, des scans de documents anciens, des plans mécaniques issus du logiciel de CAO, des nomenclatures exportées vers Excel pour alimenter l’ERP. Certains fichiers dataient d’avant la mise en place du progiciel de gestion, trois ans plus tôt seulement. La correspondance entre un numéro de machine et son client existait dans l’ERP, mais pas dans les dossiers du serveur.
Côté SAV, la pression venait aussi des clients. Quand un donneur d’ordres de l’aéronautique appelle pour une panne, la réponse doit être rapide. Si le technicien peut résoudre le problème par téléphone, l’intervention n’est pas facturée. Dès qu’il faut connecter un automaticien à distance, le compteur tourne. Chaque minute de recherche documentaire pesait directement sur la marge et sur la satisfaction client.
JUWA a conçu un assistant conversationnel adossé à un moteur RAG (Retrieval-Augmented Generation) entièrement hébergé sur infrastructure souveraine européenne. Le choix d’un modèle IA français pour l’OCR et le traitement du langage répondait à une exigence non négociable du client : aucune donnée ne devait servir à entraîner un modèle tiers, et l’hébergement devait rester en France.
Le traitement documentaire a commencé par un audit des 2 000 fichiers du périmètre pilote. Chaque document a été OCRisé, découpé en fragments contextualisés et enrichi de métadonnées (version du document, numéro de machine, type de contenu). Ce travail de préparation, souvent sous-estimé dans les projets RAG, a conditionné toute la qualité des réponses en production. L’interface, développée en React et optimisée pour iPad, a été pensée pour le terrain : un technicien en intervention devait pouvoir poser sa question et obtenir une réponse sourcée en quelques secondes, avec le nom du fichier et le numéro de page.
Réduire de 40 à 60 % le temps de recherche d’information pour les techniciens SAV et les équipes itinérantes, sur l’ensemble du parc documentaire technique
Indexer un échantillon de 2 000 documents critiques (notices, schémas électriques, nomenclatures) avec traçabilité complète des sources dans chaque réponse
Garantir zéro hallucination en production : chaque réponse doit citer le fichier et la page d’origine, ou déclarer explicitement l’absence d’information
Héberger l’intégralité de la solution sur infrastructure cloud souveraine européenne, sans exposition au Cloud Act, avec authentification SSO Microsoft 365
JUWA a mobilisé une task force de quatre profils complémentaires sur dix semaines : un Product Owner IA en charge du cadrage fonctionnel et de la coordination, un ingénieur IA & Data Engineer pour le traitement documentaire et le moteur RAG, un développeur front-end React spécialisé dans les interfaces mobiles, et un développeur back-end Node.js pour l’infrastructure et la sécurité.
L’accompagnement s’est structuré autour de deux rituels. Un comité de suivi hebdomadaire d’une heure permettait de valider l’avancement, réaliser des démonstrations intermédiaires et arbitrer les choix techniques avec le chef de projet interne et la direction. En parallèle, un rapport quotidien partagé synthétisait les actions réalisées, les tâches planifiées et les éventuels points de blocage.
La phase de recette a impliqué cinq techniciens SAV en conditions réelles pendant trois semaines. Leurs retours ont alimenté des cycles d’ajustement rapides (modification du découpage documentaire, affinement des prompts, correction des cas limites sur les schémas techniques). Le directeur des opérations et le chef de projet interne ont validé la conformité des réponses avec l’expertise métier accumulée sur plusieurs décennies.
10 semaines, de l’audit documentaire initial à la livraison du POC validé en recette métier. Le projet s’est découpé en trois phases : cadrage et fondations infrastructure (2 semaines), développement du moteur RAG et de l’interface (4 semaines), recette terrain et ajustements (4 semaines).
Comité de suivi hebdomadaire d’une heure en visioconférence avec le chef de projet interne et les parties prenantes. Rapport EOD quotidien partagé avec les équipes du client. Démonstrations intermédiaires toutes les deux semaines pour valider les avancées fonctionnelles.

Nos techniciens itinérants passaient parfois vingt minutes à retrouver le bon schéma électrique dans l’arborescence du serveur. Maintenant ils posent la question sur leur iPad et la réponse arrive avec le numéro de page. On a gagné un temps considérable sur les dépannages téléphoniques, et ça se voit directement sur la satisfaction de nos clients.