Notre client est une PME industrielle française, filiale d’un groupe international, spécialisée dans la fabrication de composants techniques pour les secteurs aéronautique et ferroviaire. Avec plus de 3 000 clients actifs (des grands donneurs d’ordre de l’aéro aux opérateurs ferroviaires), l’entreprise traite un volume considérable de commandes chaque mois.
Le service Administration des Ventes, composé de sept personnes, réceptionne les bons de commande par email, les saisit manuellement dans l’ERP, puis génère un accusé de réception pour chaque commande. Jusque-là, rien d’anormal. Le problème, c’est l’étape d’après : chaque accusé doit être comparé au bon de commande d’origine pour vérifier que la saisie est correcte. Références produits, quantités, prix unitaires, unités de vente, délais de livraison, tout doit correspondre. Et quand on a 3 000 clients avec chacun ses propres codes articles, ses propres formats de commande et ses propres exigences, cette vérification devient un exercice de haute voltige.
Concrètement, l’équipe ADV consacrait en moyenne 15 minutes à chaque vérification. Multipliées par 1 900 commandes mensuelles, cela représentait 475 heures de travail par mois. Presque trois équivalents temps plein dédiés uniquement à de la double vérification documentaire.
Le taux d’erreur restait maîtrisé (une dizaine de non-conformités par mois) mais le coût d’une seule erreur pouvait être lourd. Une mauvaise référence, et c’est un lot entier expédié chez le mauvais client ou dans la mauvaise quantité. Dans l’aéronautique, ce genre de souci se règle rarement par un simple échange téléphonique.
L’ERP utilisé, un progiciel de gestion industriel sans API ouverte, compliquait encore la donne. Impossible de brancher un outil externe directement dessus. Les équipes IT du client avaient contourné la difficulté en créant une base de données miroir accessible en lecture, mais les données de référencement produit évoluaient plusieurs fois par jour, ce qui imposait des synchronisations fréquentes.
Plutôt que de proposer une solution clé en main du marché, les trois options évaluées en amont ne couvraient pas le besoin d’interface visuelle exprimé par le client, JUWA a conçu un outil sur mesure. Le principe est simple : l’opératrice glisse ses deux documents (bon de commande PDF et accusé de réception PDF), le moteur OCR couplé à un modèle IA souverain extrait les données de chaque document, puis un tableau de comparaison s’affiche au centre de l’écran avec les deux colonnes en regard. Les données concordantes apparaissent en vert, les écarts en rouge. Quand une référence client ne correspond pas à la référence interne, le système va chercher dans la base de données produits pour tenter un rapprochement automatique.
L’outil a été développé en React et Next.js côté interface, avec un back-end connecté à la base de données miroir du client. Le modèle d’extraction tourne sur Mistral, hébergé en cloud souverain européen. Un point non négociable pour une entreprise qui manipule les données commerciales de grands comptes aéronautiques au quotidien. Aucune donnée ne sort de l’infrastructure européenne.
Réduire le temps de vérification de chaque couple bon de commande / accusé de réception de 15 minutes à 5 minutes maximum, soit un gain net de 317 heures par mois pour l’équipe ADV.
Maintenir le niveau de fiabilité existant tout en accélérant le processus : le taux de détection des anomalies devait atteindre 95 %, sans dégrader le taux de non-conformité d’une dizaine par mois.
Construire une interface de comparaison visuelle qui affiche les deux documents côte à côte avec un tableau d’écarts central, permettant à l’opératrice de valider ou corriger en un clic. Sans remplacer le jugement humain.
Concevoir une architecture duplicable sur les autres entités du groupe industriel, qui partagent le même processus de vérification mais opèrent sur des ERP et des référentiels produits différents.
Sur ce projet, l’enjeu n’était pas seulement technique. Il était humain. Sept opératrices ADV, habituées depuis des années à leur checklist papier et à leurs fenêtres ERP multiples, devaient adopter un nouvel outil sans perdre en rigueur ni en confiance.
JUWA a commencé par une semaine de cadrage opérationnel : passation avec le cabinet d’accompagnement qui avait réalisé le diagnostic IA initial, entretiens avec les opératrices et le chef de projet IT, validation des règles métier critiques (gestion des blocages, correspondances entre références client et internes, cas des commandes multi-lignes). Cette immersion a permis de maquetter une première version de l’interface avant d’écrire la moindre ligne de code.
Le développement a ensuite duré douze semaines en sprint, avec un point hebdomadaire réunissant le chef de projet client, le DSI groupe et l’équipe JUWA. Chaque livraison intermédiaire était testée sur des jeux de données réels (pas sur des cas de laboratoire). La recette finale a mobilisé deux opératrices en bêta-test pendant deux semaines, avec remontée directe des ajustements nécessaires.
15 semaines (1 semaine de cadrage, 12 semaines de développement, 2 semaines de recette et déploiement.)
Sprint avec points hebdomadaires (COPIL), bêta-test terrain avec les opératrices ADV, livraisons incrémentales.
« On voulait garder la main sur la vérification, pas la déléguer à une boîte noire. L’outil qu’on a aujourd’hui fait exactement ça : il nous montre les écarts, il nous aide à aller vite, mais c’est toujours nous qui validons. Et surtout, on a récupéré du temps pour des tâches qui comptent vraiment. »
