IA documentaire ou IA générative ? Choisissez l'architecture, pas le discours

« Nous allons mettre de l’IA sur nos documents » ressemble à une décision. C’est en réalité au moins cinq décisions distinctes, chacune avec un coût d’erreur différent. Les organisations qui les confondent s’en aperçoivent généralement le jour où il faut expliquer à un contrôleur d’où provient un chiffre.

Le choix ne se situe pas entre une approche « ancienne » et une approche « nouvelle ». Il se situe entre des architectures d’incertitude différente, appliquées à des étapes aux conséquences différentes. Un même processus documentaire a souvent besoin des deux.

Décomposer la tâche avant de choisir un modèle

1. Réception et maîtrise du fichier

D’où vient le document, comment son intégrité est vérifiée, qui y accède et où il est conservé. Cette étape est entièrement déterministe et n’exige aucun modèle. Elle détermine pourtant si vous pourrez démontrer plus tard que le document analysé est bien celui qui a été reçu.

2. OCR et lecture de la mise en page

Transformer une image en texte en conservant la position. La qualité est ici mesurable et les erreurs sont d’un type connu : colonnes fusionnées, tableaux décalés, résultats faibles sur l’écriture manuscrite ou les numérisations de faible résolution. Les documents français méritent une vérification propre — accents, cédilles et ligatures se comportent différemment d’un texte anglais.

3. Extraction par schéma

Extraire des champs déterminés : numéro de contrat, date, partie, montant, devise. Le schéma est la contrainte qui rend le résultat vérifiable. Si un champ doit être une date, il peut être validé comme une date. C’est l’étape que la plupart des organisations sous-estiment et qui apporte l’essentiel de la valeur pratique.

4. Interprétation

Comparer des clauses, résumer un contexte, classer une correspondance hétérogène, proposer une réponse. Le modèle génératif a ici sa place, car langue et mise en page varient. C’est aussi là que réside toute l’incertitude : le modèle peut omettre une réserve, relier des passages sans rapport ou formuler une affirmation que le document ne soutient pas.

5. Processus et action

Ce qui advient du résultat : validation, paiement, refus, escalade. Les conséquences d’une erreur naissent ici, pas dans le modèle. La même erreur d’extraction est négligeable si elle mène à une revue, et significative si elle mène à un paiement automatique.

Utiliser une voie hybride là où il y a des conséquences

La règle pratique est simple : là où le résultat a des conséquences juridiques ou financières, utilisez schéma et validation pour les valeurs, et un modèle génératif uniquement pour une interprétation qu’un humain relira. Ne laissez pas un modèle génératif produire des chiffres qui entrent directement dans un calcul sans avoir été vérifiés contre un champ extrait.

Cette approche hybride est généralement moins coûteuse. Traiter un document entier de manière générative coûte davantage qu’une extraction ciblée, et l’exactitude de l’extraction par schéma sur des champs structurés reste supérieure pour une dépense nettement moindre.

La langue française est une obligation, pas une préférence

Un point propre au marché français change la conception dès lors que le document sort de l’entreprise. En application de l’emploi de la langue française, le français est obligatoire dans la désignation, l’offre, la présentation, le mode d’emploi, la description de l’étendue et des conditions de garantie d’un bien, d’un produit ou d’un service, ainsi que dans les factures et quittances.

Les conséquences sont concrètes pour un système génératif. Un modèle entraîné majoritairement sur de l’anglais produit facilement des anglicismes, des tournures calquées ou des termes techniques non traduits dans un texte destiné au client. Si ce texte figure dans une offre, une notice ou une facture, ce n’est plus une question de style.

Trois mesures traitent le problème à la source. Fixez un lexique métier français imposé comme contrainte et non comme suggestion, avec les termes réglementés figés. Contrôlez la sortie sur la présence de termes non traduits avant qu’elle ne quitte le système. Et distinguez explicitement les documents internes des documents destinés au client : les premiers tolèrent un vocabulaire mixte, les seconds non.

Les documents sont des données assorties d’obligations

Si les documents contiennent des données personnelles — et contrats, correspondance et dossiers en contiennent presque toujours — le règlement général sur la protection des données s’applique intégralement : base légale, minimisation, durées de conservation, droits des personnes. Les fiches pratiques IA de la CNIL et les lignes directrices du Comité européen de la protection des données constituent le point de départ de l’analyse d’impact.

Le traitement hors de l’entreprise est une question distincte. Si un service externe est utilisé, le lieu de traitement, les sous-traitants ultérieurs et la question de savoir si vos contenus servent à entraîner des modèles se règlent contractuellement, avant le premier fichier transmis et non après.

Lorsqu’un document a une valeur probante, le règlement (UE) n° 910/2014 fixe le cadre de la signature électronique et des services de confiance. Un texte généré apposé sur un document signé n’hérite pas de sa force probante.

Construire le jeu d’évaluation avant l’interface

Le jeu d’évaluation est l’actif qui subsiste au changement de fournisseur. Il est composé de documents réels issus de votre flux, y compris les difficiles : mal numérisés, bilingues, à mise en page inhabituelle, avec ajouts manuscrits. À chacun correspond une réponse juste, établie par quelqu’un qui connaît le sujet.

Cent documents bien choisis renseignent davantage que dix mille documents ordinaires. L’objectif n’est pas de mesurer la performance moyenne, mais de trouver où le système échoue — et si la nature de l’échec est supportable par le processus.

Séparer source, déduction et décision

Tout résultat significatif doit pointer vers l’endroit du document source dont il provient : page, ligne, champ. Ce n’est pas un confort d’usage ; c’est la différence entre un système auditable et un système auquel on ne peut que se fier.

La législation sur l’IA introduit par ailleurs des obligations de transparence lors d’une interaction avec un système d’IA et pour les contenus générés. Si un texte généré quitte l’organisation, la question de savoir qui signale son origine et comment doit être tranchée avant la mise en service.

Concevoir la revue selon les conséquences

Tout relire n’est pas un contrôle : c’est une charge qui devient avec le temps une formalité. Le schéma utile est gradué : acceptation automatique en cas de confiance élevée et de faible conséquence, revue obligatoire en cas de conséquence élevée quelle que soit la confiance, et contrôle par échantillon sur les cas acceptés automatiquement, réalisé par une personne étrangère au traitement initial.

Les fonctions Measure et Manage du NIST AI Risk Management Framework offrent une structure utilisable pour définir ce qui est surveillé et comment il est réagi.

Prévoir le changement et la panne

Les modèles évoluent sans préavis, et le changement est rarement annoncé comme un changement de comportement. Le jeu d’évaluation doit donc être rejoué périodiquement, et pas seulement au déploiement. Fixez à l’avance quelle baisse déclenche le retour au traitement manuel et qui a autorité pour le décider.

Préparez aussi le chemin de repli. Si le système s’arrête, les documents continuent d’arriver. Une organisation sans solution manuelle opérante n’a pas automatisé un processus : elle a contracté une dépendance.

Le piège du taux d’exactitude moyen

Un chiffre unique d’exactitude — « le système atteint 98 % » — est la mesure la plus rassurante et la plus trompeuse d’un projet documentaire. Elle additionne des cas sans conséquence et des cas décisifs comme s’ils se valaient. Un système peut afficher une exactitude globale élevée et se tromper systématiquement sur une catégorie précise : les contrats bilingues, les avenants manuscrits, une clause de prix inhabituelle. Cette catégorie est souvent réduite en volume et lourde en conséquences.

La mesure utile n’est donc pas l’exactitude moyenne mais l’exactitude par catégorie de conséquence, rapportée à un jeu d’évaluation qui contient assez de cas difficiles pour rendre ces catégories visibles. La question à poser au fournisseur n’est pas « quelle est votre exactitude », mais « montrez-moi vos erreurs sur les documents que je vous ai fournis, et dites-moi lesquelles conduisent à un paiement ou à un refus ». Un fournisseur incapable de produire cette ventilation ne vous a pas encore montré ce que vous devez savoir.

Cette ventilation a aussi une valeur contractuelle : elle transforme une promesse commerciale en critère d’acceptation vérifiable, mesuré sur vos propres documents plutôt que sur un jeu de démonstration choisi par le vendeur.

Ce que cette approche ne peut pas faire

Aucune architecture ne rend un document plus exact qu’il n’est. Si le contrat est ambigu ou la numérisation illisible, le meilleur système produira une incertitude formulée avec assurance. L’approche hybride ne supprime pas non plus le besoin de personnes compétentes sur le fond — elle réduit leur volume de travail et augmente l’exigence sur leur jugement.

Si vous choisissez une architecture pour un processus documentaire à conséquences réelles, commencez par prouver l’approche sur vos documents.

Cet article est une adaptation de l’original anglais. En cas de divergence, la version anglaise fait foi.