La démonstration marchait. La production, non.
Un analyseur de documents qui passait tous mes tests, et qui s'est mis à classer de travers dès qu'il a vu de vrais dossiers. Voici ce qui avait cassé, et pourquoi ce n'était pas un problème de modèle.
Le jeu de test était une fiction
L'automatisation devait lire des documents entrants, les classer et en extraire les informations utiles. Sur mon jeu de test, elle avait un comportement irréprochable. En conditions réelles, elle s'est mise à se tromper de personne.
La raison n'avait rien de technique. Mon jeu de test était pauvre par rapport à ce qui arrive vraiment. J'avais des documents propres, avec un cas par document et une personne clairement identifiable. La réalité m'a envoyé autre chose.
- Des documents où deux personnes figurent au même niveau, sans que rien n'indique laquelle est concernée
- Des notaires et des responsables mentionnés dans le document, aussi visibles que la personne dont il est réellement question
Un humain qui lit ces documents tranche sans y penser : il sait qu'un notaire n'est pas le demandeur. Le modèle, lui, voit deux noms de même importance et en choisit un. Il ne se trompe pas par incompétence, il tranche une question à laquelle le document ne répond pas.
Un jeu de test propre ne teste rien. Il valide que le mécanisme fonctionne, pas qu'il survivra au désordre du réel. Et le désordre est la règle, pas l'exception.
La mauvaise réponse : mieux demander au modèle
Le réflexe, à ce stade, est de retoucher les instructions. Expliquer ce qu'est un notaire, détailler les cas, ajouter des exemples. Ça améliore les statistiques et ça ne règle rien, parce que le problème n'est pas la formulation de la question.
L'information n'était pas dans le document. Aucune reformulation ne fait apparaître une donnée absente. Demander à un modèle de deviner mieux, c'est lui demander d'inventer avec plus d'assurance.
Ce que j'ai fait : aller chercher la vérité ailleurs
Le client dispose d'un ERP qui sait, lui, de quel dossier il s'agit et qui en est le demandeur. Cette information existait, elle n'était simplement pas dans le document que je donnais à lire.
Le traitement interroge donc l'API de l'ERP et récupère le dossier sous forme d'objet JSON. À partir de là, le croisement fait ce que le document seul ne permettait pas :
- identifier le demandeur réel parmi les personnes citées
- rattacher le document au bon dossier client
- écarter les notaires et les intervenants qui ne sont pas parties au dossier
- lier les personnes entre elles quand elles doivent l'être, les conjoints notamment
Le tout tourne dans un workflow n8n, qui orchestre la lecture, l'appel à l'ERP et le classement.
Le principe est général : ne demandez jamais au modèle ce qu'il ne peut pas savoir. Quand une information manque, elle se récupère dans le système qui la détient. Un modèle n'est pas là pour combler les trous, il est là pour traiter ce qu'on lui donne.
Ce qui reste ambigu ne doit pas être tranché
Même avec le croisement, certains cas restent indécidables. Ils tombent dans une catégorie « unclassified », et quelqu'un est prévenu.
Ce n'est pas un aveu de faiblesse, c'est la fonctionnalité la plus importante du système. Une automatisation qui classe tout, tout le temps, ne vous dit jamais qu'elle a eu un doute : elle produit des erreurs silencieuses que vous découvrez des mois plus tard, quand un client vous appelle. Celle qui lève la main sur trois pour cent des cas vous coûte trois pour cent de travail manuel et vous épargne les quelques erreurs qui font mal.
Comment on sait qu'elle s'améliore
Chaque vérification laisse une trace, stockée en base : ce qui a été proposé, ce qui a été retenu. Ce qui permet de comparer les taux de réussite et d'échec dans le temps, et de voir si une modification a servi ou pas.
Sans ces journaux, l'amélioration est une impression. Avec eux, c'est une mesure. Un apprentissage automatique plus lourd est envisagé sur cette base, mais il n'aurait aucun sens avant d'avoir accumulé assez de décisions vérifiées.
Ce qu'il faut en retenir
Une démonstration réussie ne prouve qu'une chose : que le mécanisme fonctionne sur les cas que vous avez choisis. C'est utile et c'est très loin d'être suffisant.
- Testez sur vos vrais documents, y compris les moches, les ambigus et ceux dont personne ne veut s'occuper. Ce sont eux qui décident du résultat.
- Cherchez ce que le document ne dit pas. Si l'information manque, un autre de vos systèmes la détient probablement.
- Exigez une catégorie pour le doute. Une automatisation sans porte de sortie produit des erreurs invisibles.
- Demandez comment on saura que ça s'améliore. Sans journal des décisions, personne ne pourra vous le dire.
Questions fréquentes
Pourquoi une automatisation qui passe les tests échoue-t-elle en production ?
Le plus souvent parce que le jeu de test est trop propre. Il contient des cas clairs, un sujet par document, des informations complètes. Les documents réels arrivent mal cadrés, incomplets, avec plusieurs personnes citées au même niveau et des intervenants qui n'ont rien à voir avec le dossier. Le mécanisme fonctionne, c'est la matière qui n'est pas celle qu'on avait prévue.
Que faire quand l'information n'est pas dans le document ?
Aller la chercher là où elle existe. Dans le cas décrit ici, l'ERP du client savait de quel dossier il s'agissait et qui en était le demandeur : le traitement interroge son API et croise le document avec le dossier récupéré. Reformuler les instructions du modèle n'aurait rien donné, puisqu'aucune formulation ne fait apparaître une donnée absente.
Faut-il que l'automatisation traite absolument tous les cas ?
Non, et c'est même à éviter. Un système qui tranche systématiquement produit des erreurs silencieuses qu'on découvre des mois plus tard. Mieux vaut une catégorie pour les cas non identifiés, avec une notification à un humain. Le peu de travail manuel que ça laisse coûte bien moins cher que les erreurs qu'on ne voit pas passer.
Comment mesurer qu'une automatisation s'améliore ?
En journalisant chaque décision et sa vérification dans une base : ce qui a été proposé, ce qui a été retenu. On compare alors les taux de réussite et d'échec dans le temps, et on sait si une modification a servi. Sans ces journaux, l'amélioration reste une impression, et personne ne peut dire si le système va mieux ou moins bien.
Une automatisation qui marchait, et qui ne marche plus
Décrivez-moi ce qu'elle rate et sur quels cas. En trente minutes je vous dis si c'est le jeu de test, une information manquante, ou autre chose.