Comment nous évaluons les modèles qui lisent vos documents

Un modèle de langage qui lit un avis d’imposition donne toujours l’impression d’avoir raison. Il répond dans un français net, il cite des montants plausibles, et il ne signale jamais qu’il a deviné. C’est exactement ce qui rend son évaluation contre-intuitive : les qualités qui rassurent un lecteur sont sans rapport avec celles qui font une extraction fiable.

Cet article décrit ce que nous mesurons, et pourquoi.

La première décision est de ne pas lui confier le calcul

Chez Finsio, un modèle lit. Il ne calcule pas.

L’extraction d’un fait — « revenu net imposable : 62 480 € », « case 6NS », « versement PER de 4 200 € le 12 décembre » — est une tâche de lecture, où un modèle est bon. Le calcul de l’impôt sur le revenu à partir de ces faits est une tâche arithmétique et réglementaire, où un modèle est approximatif par construction : il produit le montant le plus vraisemblable, ce qui n’est pas le montant exact.

Nos barèmes, notre quotient familial, nos plafonds PER et nos cases de déclaration sont donc des moteurs déterministes, testés sur des déclarations réelles. Deux exécutions sur les mêmes données donnent le même résultat, au centime. Cette séparation n’est pas un choix de prudence : c’est ce qui rend l’évaluation possible. On ne peut pas mesurer la qualité d’une lecture si l’erreur de lecture et l’erreur de calcul se mélangent dans le même chiffre final.

Ce que « juste » veut dire chez nous

La définition retenue est plus stricte que le taux d’exactitude qu’on lit habituellement. Une extraction n’est comptée juste que si trois conditions sont réunies :

1. Le montant est exact au centime. Pas « du bon ordre de grandeur », pas arrondi.
2. Il est rattaché au bon document et à la bonne page. Un montant juste dont on ne peut pas montrer la provenance est invérifiable par l’utilisateur, donc inutilisable.
3. Il porte la bonne étiquette. Un revenu foncier lu comme un revenu de capitaux mobiliers est une erreur, même si le nombre est correct.

La deuxième condition est celle qui écarte le plus de réponses, et c’est voulu. Toute la promesse du produit tient dans la possibilité de remonter d’un chiffre affiché à la ligne du PDF qui le justifie. Une extraction sans source ne serait pas une extraction partiellement bonne : ce serait une affirmation.

Omission et invention ne se valent pas

Nous suivons deux taux d’erreur séparément, parce qu’ils n’ont ni la même visibilité ni le même coût.

L’omission — un montant présent dans le document et non extrait — est bénigne. Elle se voit : il manque une ligne, l’utilisateur la saisit, et le patrimoine reste juste. Elle dégrade le confort, pas la véracité.

L’invention — un montant absent du document, ou lu sur la mauvaise ligne — est le mode de défaillance qui compte. Elle ne se voit pas : le chiffre est plausible, il est présenté avec la même assurance que les autres, et rien dans la réponse ne signale qu’il a été construit plutôt que lu. C’est le seul type d’erreur qui peut traverser une validation humaine sans être remarqué.

Un modèle qui omet deux lignes sur vingt nous convient mieux qu’un modèle qui les complète toutes en se trompant sur une. Les moyennes agrégées font l’inverse : elles récompensent le second.

Le jeu d’évaluation

Un protocole ne vaut que par les documents sur lesquels il tourne. Le nôtre est construit sur trois principes.

Il porte sur des documents réels annotés à la main — avis d’imposition, IFU, attestations de versement, actes, bulletins de paie — et non sur des documents synthétisés. Les cas qui font échouer une lecture sont précisément ceux qu’on ne pense pas à générer : un scan de travers, un tableau coupé entre deux pages, une mention manuscrite, une année de revenus qui ne correspond pas à l’année de l’avis.

Il est figé et versionné. Un jeu d’évaluation qu’on complète au fil des erreurs constatées finit par mesurer la capacité du modèle à traiter les cas qu’on lui a déjà appris, ce qui produit une courbe qui monte toujours et ne dit rien.

Il sépare les cas courants des cas difficiles, et les deux scores sont lus séparément. Une moyenne unique laisse un progrès sur les documents faciles compenser une régression sur les documents qui comptent.

La validation humaine n’est pas un filet

Chaque fait extrait vous est présenté avec le document et la page dont il provient, et rien n’entre dans votre patrimoine avant que vous ne l’ayez accepté. C’est la règle « LYA propose, vous validez », et elle est dans l’architecture : il n’existe pas de chemin de code par lequel une extraction deviendrait une donnée patrimoniale sans passer par une validation.

Ce point n’est pas seulement une position de prudence. Le cadre européen — l’article 22 du RGPD sur les décisions individuelles automatisées, complété par le règlement sur l’intelligence artificielle — structure la manière dont une décision produite par une machine peut engager quelqu’un. Concevoir le produit autour d’une validation explicite plutôt que d’un contrôle ajouté après coup est ce qui rend cette exigence tenable sans réécrire le produit.

Ce que nous ne publions pas encore

Le protocole ci-dessus est en place. Les scores, non.

Publier un taux d’exactitude suppose un jeu d’évaluation assez large et assez stable pour que le chiffre ait un sens hors de notre équipe, et une méthode assez figée pour que deux mesures espacées de six mois soient comparables. Nous n’y sommes pas. Annoncer aujourd’hui un pourcentage qui bougera de dix points au prochain jeu de tests serait le genre de chiffre que le reste de ce site s’interdit.

Ils seront publiés ici, avec le protocole exact et la date de mesure, quand ils tiendront.