Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande

Le point de départ

Santécie distribue des dispositifs médicaux. Quand un appareil revient en SAV, le retour doit partir vers le fabricant avec le bon formulaire, rempli selon son modèle à lui : chaque fabricant a ses champs, ses versions et ses exigences. Les fiches de retour arrivent le plus souvent sous forme de fichiers Excel, et quelqu’un devait en reporter le contenu, formulaire après formulaire.

Ce travail n’exige aucun jugement, mais une attention constante, et une erreur de report coûte cher à corriger. La demande était donc double : supprimer la recopie, et savoir après coup ce qui a été envoyé, où et pourquoi.

Ce que j’ai construit

Le cœur du système n’est pas le remplissage, mais le routage. Une fiche peut concerner un formulaire, plusieurs, ou aucun selon son contenu. J’ai structuré le domaine autour de trois notions nettes : le groupe de formulaires, identifié par un code métier stable ; la configuration de routage, écrite comme une suite de conditions ; la cible de remplissage, qui associe un formulaire à une version précise.

Mock

Deux décisions ont pesé. Le routage se résout au moment de l’exécution, puis se fige avec elle : on corrige une règle sans réécrire l’histoire, et chaque formulaire rempli garde la règle qui l’a produit. J’ai aussi distingué, avec l’équipe, la complétion d’une demande, qui relance seulement ce qui a échoué, de son rejeu complet.

Une API NestJS avec Prisma porte le domaine, des files BullMQ absorbent les volumes, et une interface Vue 3 sert à gérer les formulaires, leurs versions et les règles. L’accès est réparti par rôle, opérateur ou administrateur, et les journaux comme les contenus traités ont une durée de conservation.

Où passe l’IA, et où elle ne passe pas

Sur des données de santé, la question n’est pas de savoir si l’IA peut aider, mais où elle a le droit d’intervenir. Les demandes de production passent par une automatisation déterministe, avec des règles et un schéma stricts. L’analyse assistée par IA sert uniquement, sur des échantillons synthétiques, à générer les modèles de correspondance entre les colonnes reçues et les champs d’un formulaire. La validation humaine porte en amont, sur la configuration, et non sur chaque demande.

Travailler dans l’équipe, pas à côté

Ce glossaire a compté plus qu’il n’y paraît. Une « demande » n’est pas un « lot », un « rejeu » n’est pas une « complétion ». Le jour où un utilisateur demande pourquoi un formulaire a été rempli deux fois, la réponse tient dans ces distinctions.

Ce que montrent les preuves

La trace, elle, se consulte à tout moment : pour une demande donnée, l’outil montre quelle règle s’est appliquée, quelle branche a été retenue et quelles conditions ont été évaluées.

Mock

de demandes traitées en production depuis septembre 2025

des dizaines de milliers

de complétion opérationnelle, au sens défini ci-dessus

100 %

échec opérationnel, pannes externes suivies à part

0

de saisie évitées par tranche de 10 000 demandes (estimation)

≥ 500 h

Ce que cela change

Quand une fiche échoue, on sait quelle règle l’a dirigée où, et on la complète ou on la rejoue sans reprendre le lot entier.

Mock

Le système continue d’évoluer, avec des travaux récents sur l’intégration au routage SAP et sur le déploiement. J’y travaille en indépendant, intégré à l’équipe projet : d’abord en micro-entreprise, puis via MC Studio depuis janvier 2026.

Limites

• Les comptages sont les miens : ils n’ont pas fait l’objet d’un audit indépendant, et le volume exact se communique sur demande.
• Le taux de complétion mesure l’exécution de bout en bout avec sa trace, pas la justesse de chaque correspondance.
• Le temps évité est une estimation fondée sur une durée de saisie manuelle, pas une mesure avant et après.
• Le projet est mené en équipe : les choix de produit ont été partagés, et je n’en revendique pas seul la direction.