Automatiser la saisie d'un document métier : ce que le cas OptiBot nous a appris

Sur OptiBot, j’ai passé les premières semaines à améliorer le taux de reconnaissance des documents. C’était la mauvaise priorité. Ce qui a réellement fait décoller l’usage, c’est un écran — celui où l’opérateur valide ce que la machine a lu.

Je raconte ici ce qu’on a compris en route, parce que c’est le genre d’erreur qu’on ne fait qu’une fois.

Le problème d’origine

Chez un opticien, chaque dossier de tiers payant se saisit à la main, document après document. Pris isolément, c’est quelques minutes. À l’échelle d’un magasin, c’est du temps pris sur le conseil client. À l’échelle d’un réseau de franchise, c’est un coût permanent que personne ne mesure, parce qu’il est réparti partout et nulle part.

C’est le profil type du problème qu’on croit résoudre avec « de l’IA » — et qu’on résout mal si l’on s’arrête à l’extraction.

L’erreur que nous avons faite

La tentation est de chercher le meilleur modèle d’extraction possible, puis d’automatiser entièrement dès que le taux paraît suffisant.

Cette approche échoue pour une raison simple : une erreur d’extraction non détectée coûte beaucoup plus cher que le temps qu’elle fait gagner. Sur un dossier de remboursement, une donnée fausse génère un rejet, un rappel, une reprise — soit largement plus que les minutes économisées. Et surtout, elle détruit la confiance : après deux rejets, l’opérateur revérifie tout, et le gain disparaît entièrement.

Le bon objectif n’est donc pas d’atteindre 100 % d’automatisation. C’est d’atteindre 100 % de détection des cas douteux.

Photo : Michal Kulesza — licence CC0.

Ce qui fait réellement la différence

L’écran de validation. C’est la pièce maîtresse, et c’est de l’ergonomie, pas de l’IA. Le document et les champs extraits doivent être côte à côte, chaque valeur renvoyant visuellement à l’endroit du document d’où elle vient. L’opérateur doit pouvoir confirmer un dossier correct en un geste, et corriger un champ sans quitter le clavier.

Nous avons refait cet écran trois fois. La troisième version a plus fait pour l’adoption que tous les gains de précision cumulés.

Le traitement de l’échec. Un document illisible, une mutuelle inconnue, un format inattendu : ces cas existeront toujours. S’ils bloquent l’utilisateur, l’outil sera contourné — et un outil contourné une fois l’est définitivement. S’ils basculent proprement en saisie manuelle, l’outil reste utilisable même quand l’extraction se trompe.

Le signalement de l’incertitude. Un champ extrait avec un doute doit le montrer. Une interface qui affiche toutes les valeurs avec la même assurance apprend à l’utilisateur à tout revérifier, ce qui annule le gain. À l’inverse, un doute affiché honnêtement crée de la confiance sur tout le reste.

Le détail qui a tout changé

Le vrai déclic est venu d’une observation en magasin. Les opérateurs ne lisaient pas les champs un par un : ils balayaient l’écran, cherchaient ce qui clochait, et validaient. Ils travaillaient par exception.

Nous avons donc inversé la conception. Au lieu de présenter tous les champs comme également importants, l’écran met en avant ce qui mérite attention et laisse le reste en retrait. Le regard va directement au bon endroit.

C’est une décision d’interface, prise après avoir regardé des gens travailler. Aucune amélioration de modèle n’aurait produit le même effet.

Photo : Aidan Meyer — licence CC0.

Comment on sait que ça marche

Nous avons longtemps regardé le mauvais indicateur : le taux de champs correctement extraits. Il montait, tout le monde était content, et l’usage ne décollait pas.

L’indicateur qui compte, c’est le temps réel entre l’ouverture d’un dossier et sa validation, comparé à la saisie manuelle. Il intègre tout : la qualité de l’extraction, mais aussi le temps de relecture, les corrections, et les allers-retours quand quelque chose coince.

Deuxième indicateur, moins évident : la proportion de dossiers validés sans aucune correction. C’est lui qui mesure la confiance. Tant qu’il est bas, l’opérateur reste en posture de vérification, et le gain théorique ne se matérialise pas.

Et un troisième, franchement inconfortable à regarder : le taux d’erreurs passées en production. Une donnée fausse validée par inadvertance coûte plus que tout le reste. C’est la métrique qu’on n’a pas envie d’instrumenter, et c’est celle qui empêche de se raconter des histoires.

Le piège de la démonstration

Un mot sur les démonstrations, puisque c’est souvent là que se prend la décision d’achat.

Une démo d’extraction documentaire est facile à réussir : on choisit trois documents propres, bien cadrés, au format attendu. Le taux affiché est spectaculaire et ne prédit rien.

Si vous évaluez une solution, apportez vos documents — et les plus mauvais. Le fax reçu de travers, la photo prise au téléphone dans un magasin mal éclairé, le formulaire d’une mutuelle que personne n’a jamais vu. Ce que vous voulez observer n’est pas le taux de réussite, mais le comportement en cas d’échec.

C’est un test qui prend dix minutes et qui départage immédiatement.

Photo : Ch�u Th�ng Phan — licence CC0.

Les trois questions à poser

Si vous envisagez d’automatiser une saisie documentaire — factures, bons de commande, dossiers administratifs, contrats — jugez les propositions sur ces critères plutôt que sur un taux de reconnaissance annoncé :

1. Comment l’utilisateur valide-t-il, concrètement ? Demandez à voir l’écran, pas un schéma d’architecture.
2. Comment l’outil signale-t-il ce dont il n’est pas sûr ? S’il ne le signale pas, il vous fera revérifier chaque champ.
3. Que se passe-t-il quand ça échoue ? C’est la question la plus importante, et celle qu’on oublie le plus.

Un prestataire qui répond précisément à ces trois questions a déjà livré ce type de système. Un prestataire qui parle surtout du modèle utilisé ne l’a probablement pas encore fait.

Ce que coûte le démarrage

Une question qui vient toujours : combien de documents faut-il pour que ça fonctionne ?

Moins qu’on ne croit, à condition de bien les choisir. Ce qui compte n’est pas le volume mais la diversité : dix formats différents valent mieux que mille exemplaires du même. Le modèle doit voir la variabilité réelle, pas la répétition.

Le poste de coût sous-estimé n’est pas la collecte, c’est la constitution du jeu de référence : pour chaque document, saisir à la main ce que la machine devrait trouver. C’est fastidieux, cela demande quelqu’un qui connaît le métier, et c’est ce qui permet ensuite de mesurer objectivement toute amélioration.

Sans ce jeu de référence, on ne compare que des impressions — et chaque changement devient une question d’opinion.

L’effet sur les équipes, qu’on n’anticipe pas

Un point que nous avions sous-estimé : automatiser une tâche répétitive change le travail de ceux qui la faisaient, et pas seulement en volume.

Avant, l’opérateur enchaînait des dossiers simples et se concentrait par intermittence. Après, il ne traite plus que les cas que la machine n’a pas su faire — c’est-à-dire les plus difficiles, en continu. Le travail devient plus dense, et plus fatigant.

Nous l’avons découvert en observant, pas en le prévoyant. La conséquence pratique : il faut prévoir des respirations dans la file, et surtout ne pas calculer les objectifs en supposant que le rythme d’avant s’applique au travail d’après.

En résumé

L’automatisation documentaire n’est pas un problème de reconnaissance, c’est un problème de répartition du travail entre la machine et l’humain. La machine propose, l’humain dispose — et tout l’enjeu tient dans la qualité de ce dialogue.

C’est plutôt une bonne nouvelle : cela veut dire que le succès dépend d’un travail de conception, pas de l’accès à un modèle que vos concurrents n’auraient pas.