--- title: "Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande" description: "Pour Santécie, distributeur de dispositifs médicaux, une automatisation en production qui transforme les fiches de retour SAV en formulaires fabricants remplis, avec une trace d’audit pour chaque demande." url: "https://mc-stud.io/realisations/robotform-formulaires-sav" author: "Matisse Chenavas" date: "2026-09-18" lang: "fr" ai: "true" --- # Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande > Les fiches de retour SAV de Santécie sont routées vers les bons formulaires fabricants et remplies automatiquement, avec une trace d’audit pour chaque demande. - **Client**: Santécie - **Secteur**: Santé, distribution de dispositifs médicaux - **Période**: 2024-2026 - **Mon rôle**: Développeur principal, back-end et front-end - **Cadre**: Via un partenaire - **Équipe**: Intégré à une équipe existante · 2 personnes (Intégré à l’équipe projet, avec un second développeur sur 2024-2025.) - **Statut**: En production - **Technologies**: NestJS, Prisma, Vue.js, Pinia, TypeScript, BullMQ - **Temps de lecture** : 5 min ## L’essentiel - **Enjeu** : Chaque retour SAV doit partir vers le fabricant sur son propre formulaire ; la recopie manuelle prenait du temps et exposait à des erreurs coûteuses. - **Mécanisme** : Des règles de routage versionnées désignent les formulaires cibles, une automatisation déterministe les remplit, et l’IA ne voit que des échantillons synthétiques. - **Preuve** : Des dizaines de milliers de demandes traitées en production depuis septembre 2025, avec 100 % de complétion opérationnelle selon mon suivi d’exploitation. - **Impact** : La saisie devient de la configuration : au moins 500 heures évitées par tranche de 10 000 demandes, et un échec se rejoue isolément. - **Limites** : Les indicateurs viennent du suivi d’exploitation que je déclare ; ils n’ont pas été audités de façon indépendante. ## Indicateurs - des dizaines de milliers de demandes traitées en production depuis septembre 2025 - 100 % de complétion opérationnelle, au sens défini ci-dessus - 0 échec opérationnel, pannes externes suivies à part - ≥ 500 h de saisie évitées par tranche de 10 000 demandes (estimation) ## 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. 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. > [!IMPORTANT] La frontière de données > Les contenus de production ne passent jamais par un modèle de langage. L'IA accélère la préparation des correspondances ; elle ne voit pas les fiches réelles. ## Travailler dans l'équipe, pas à côté J'ai rejoint ce projet comme on rejoint une équipe : par son code, son vocabulaire et ses habitudes, et j'en suis devenu l'auteur principal[^git]. Le dépôt porte aujourd'hui ce qui permet à quelqu'un d'autre, humain ou agent, de le reprendre : un fichier de contexte à la racine, des décisions d'architecture consignées une par une, un audit des flux et un glossaire métier partagé avec les utilisateurs. 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 L'automatisation tourne en production depuis septembre 2025. Les chiffres ci-dessous viennent de mon suivi d'exploitation[^volume], et ils ne se lisent qu'avec leur définition. > [!NOTE] Définition de la complétion opérationnelle > L'automatisation remplit le formulaire de bout en bout, sans reprise manuelle, et produit une trace d'audit de l'exécution. Ce taux ne dit rien de la justesse sémantique d'une correspondance. Les pannes de dépendances externes sont suivies à part, comme incidents. 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. ## Ce que cela change La ressaisie se déplace vers la configuration : une règle se paramètre une fois et s'applique à chaque fiche reçue. À raison de 3 à 5 minutes de saisie manuelle par formulaire, chaque tranche de 10 000 demandes représente entre 500 et 830 heures de saisie évitées[^estimate]. 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. 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. [^git]: Historique Git du dépôt : 113 des 193 commits sont les miens, de juillet 2024 à septembre 2026. Un second développeur a contribué en 2024 et 2025. Un nombre de commits ne mesure ni l'effort ni la qualité. [^volume]: Comptages agrégés issus du suivi d'exploitation, que je déclare. Le volume exact et un export anonymisé des comptages se communiquent sur demande. [^estimate]: 10 000 demandes × 3 minutes = 500 heures ; × 5 minutes = environ 830 heures. La durée de 3 à 5 minutes est une estimation du remplissage manuel, pas une mesure. ## Liens - [Santécie](https://santecie.com/) --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/robotform-formulaires-sav