--- title: "Automatiser un processus sensible sans perdre la traçabilité" description: "Automatiser un processus qui touche à la santé, à la paie ou à la facturation n’est pas une question de vitesse. C’est une question de mémoire : savoir, après coup, qui a décidé quoi, avec quelles règles et sur quelles données." url: "https://mc-stud.io/articles/automatiser-un-processus-sensible-sans-perdre-la-tracabilite" author: "Matisse Chenavas" date: "2026-10-08" lang: "fr" ai: "true" --- # Automatiser un processus sensible sans perdre la traçabilité > Automatiser un processus qui touche à la santé, à la paie ou à la facturation n’est pas une question de vitesse. C’est une question de mémoire : savoir, après coup, qui a décidé quoi, avec quelles règles et sur quelles données. 6 min de lecture ## L’essentiel - Sur un processus sensible, la bonne mesure n’est pas le temps gagné, mais la capacité à expliquer chaque décision six mois plus tard. - Résoudre la règle au moment de l’exécution, puis la figer avec elle : on corrige demain sans réécrire hier. - Un glossaire partagé coûte quelques heures et en économise beaucoup à chaque incident. - Le système prépare, une personne valide : la validation humaine est une étape vérifiée sur des données précises. - Chaque étape doit pouvoir être rejouée seule, sans doublon. Quand on automatise un processus, on pense d'abord au temps gagné. C'est légitime : personne ne regrette les heures passées à recopier des fiches ou à reformater des tableaux. Mais sur un processus sensible, celui qui touche à des données de santé, à la paie ou à la facturation, le temps gagné n'est pas la bonne mesure du succès. La bonne mesure, c'est la capacité à répondre, six mois plus tard, à une question simple : **pourquoi le système a-t-il fait cela ?** Un processus manuel a un avantage que l'on sous-estime : il laisse des traces humaines. Un email, une initiale sur un document, le souvenir d'un collègue. Ces traces sont imparfaites, mais elles existent. Une automatisation mal conçue les efface, et les remplace par une boîte noire qui agit vite, sans mémoire. C'est là que naissent la méfiance des équipes et les incidents impossibles à expliquer. Voici ce que j'ai appris en concevant des systèmes qui automatisent ce type de processus, notamment le remplissage de formulaires de service après-vente à partir de fichiers reçus, et la lecture de cartes de complémentaire santé. ## Séparer la règle de son exécution La première erreur consiste à confondre la règle et son application. Dans un système de routage, par exemple, une fiche reçue doit être dirigée vers un ou plusieurs formulaires selon son contenu. La tentation est de calculer la destination une fois, à la réception, et de ne plus y revenir. Le problème apparaît au premier changement de règle. Si la destination est calculée à la réception, toutes les fiches en attente gardent l'ancienne logique. Si elle est recalculée en permanence, on ne sait plus quelle règle a réellement produit un formulaire déjà rempli. La solution retenue sur le projet de routage SAV mené pour Santécie tient en deux principes. D'abord, **la destination se résout au moment de l'exécution**, avec les règles en vigueur à cet instant. Ensuite, **cette résolution est figée avec l'exécution** : chaque formulaire rempli garde la trace de la règle, et de la version de la règle, qui l'a produit. On peut corriger une règle demain sans réécrire l'histoire d'hier. Ce découplage a un coût : il faut versionner les règles, et accepter qu'une prévision affichée à l'écran ne fasse pas foi. J'ai d'ailleurs distingué explicitement la « projection » de routage, une prévision utile pour la consultation, de « l'affectation » réelle, calculée juste avant le remplissage. Cette distinction de vocabulaire a évité bien des malentendus avec les utilisateurs. ## Nommer les choses avant de les automatiser La traçabilité commence par le vocabulaire. Si l'équipe métier et l'équipe technique n'emploient pas les mêmes mots pour les mêmes choses, aucun historique ne sera lisible. Sur ce projet, j'ai tenu avec l'équipe un glossaire partagé, avec pour chaque terme une définition courte et les mots à éviter. Une « requête » n'est pas un « lot », une « exécution » n'est pas un « fichier », un « rejeu » n'est pas une « complétion ». Ces nuances paraissent pointilleuses. Elles deviennent essentielles le jour où un utilisateur demande pourquoi un formulaire a été rempli deux fois : la réponse dépend précisément de la différence entre rejouer une requête entière et compléter seulement ce qui avait échoué. Je recommande ce glossaire à toute organisation qui automatise un processus sensible. Il coûte quelques heures au départ et en économise beaucoup à chaque incident. ## Garder l'humain là où il apporte du jugement Automatiser ne veut pas dire tout automatiser. Sur un processus sensible, certaines décisions doivent rester humaines, parce qu'elles engagent l'organisation ou parce que la machine se trompe d'une façon qu'elle ne sait pas détecter. Le démonstrateur de lecture de cartes de complémentaire santé que j'ai conçu pour Santécie en est un bon exemple. Le système extrait le texte d'une carte et propose des champs métier. Mais chaque champ reste facultatif et modifiable, et **une personne vérifie avant toute confirmation**. Le système ne vérifie pas les droits et ne prend aucune décision automatisée. Il prépare ; l'humain valide. Ce principe vaut aussi pour mes propres opérations. Lorsque des agents préparent ma facturation mensuelle, ils rédigent les brouillons de facture et d'email, mais rien n'est envoyé sans mon accord explicite. La validation humaine n'est pas une formalité ajoutée à la fin : c'est une étape du processus, vérifiée sur des données précises, par exemple le montant, le destinataire ou la période, et non sur une impression générale. La question à se poser n'est donc pas « que peut-on automatiser ? », mais « où le jugement humain apporte-t-il quelque chose que la règle ne capture pas ? ». C'est là qu'il faut placer les points de validation. ## Garder les données là où elles doivent rester La traçabilité concerne aussi le chemin des données. Sur un processus qui manipule des données de santé, savoir où elles transitent est aussi important que savoir ce que le système en fait. Sur le projet de lecture de cartes, le traitement est conçu pour rester sur le poste de l'utilisateur. Le recours à un service externe n'est envisagé que pour le banc d'essai, et seulement avec une garantie de rétention nulle des données. Les échantillons réels ne sortent pas du cadre du client. Cette discipline a un prix : certains services, plus simples à brancher, sont écartés d'emblée. Mais elle permet de répondre clairement à la question qu'un responsable de la conformité posera tôt ou tard. ## Rendre chaque étape rejouable Un processus automatisé finira par échouer. Un fichier mal formé, un service indisponible, une règle incomplète. La question n'est pas d'éviter toute panne, mais de pouvoir reprendre proprement. Pour cela, chaque étape doit être identifiable et rejouable indépendamment. Si une fiche est routée vers trois formulaires et qu'un seul échoue, on doit pouvoir relancer ce seul formulaire, sans refaire les deux autres et sans créer de doublons. Sur le benchmark OCR, chaque version de pipeline produit des artefacts immuables : on peut comparer deux exécutions sans se demander si quelque chose a changé entre-temps. Ce n'est pas un raffinement technique. C'est ce qui permet à une équipe de corriger un incident en quelques gestes, au lieu de tout reprendre à la main et de perdre au passage la confiance dans l'outil. ## Écrire les décisions, pas seulement le code Dernier point, souvent négligé : les décisions d'architecture doivent être écrites. Pas dans un document de cinquante pages que personne ne lira, mais dans des notes courtes, une par décision, qui disent ce qui a été choisi, pourquoi, et quelles options ont été écartées. Sur le projet de lecture de cartes, onze décisions de ce type ont été consignées : la séparation entre pilotage et exécution, l'immutabilité des artefacts, les conditions d'usage d'une API externe, la cible de déploiement. Le jour où un auditeur, un nouveau développeur ou le client lui-même demande pourquoi le système fonctionne ainsi, la réponse existe déjà. ## Par où commencer Si vous envisagez d'automatiser un processus sensible, voici trois questions à poser avant d'écrire la moindre ligne de code : 1. **Que devra-t-on pouvoir expliquer dans six mois ?** Listez les questions qu'un auditeur, un client ou un collègue pourrait poser. Le système doit pouvoir y répondre. 2. **Où le jugement humain est-il irremplaçable ?** Placez là vos points de validation, et faites-en des étapes à part entière. 3. **Que se passe-t-il quand une étape échoue ?** Si la réponse est « on recommence tout », le système n'est pas prêt. L'automatisation utile ne retire pas l'humain du processus. Elle lui retire les gestes mécaniques, et lui laisse, avec une meilleure mémoire, ce qui demande du discernement. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/articles/automatiser-un-processus-sensible-sans-perdre-la-tracabilite