Extraction documentaire : faut-il la développer en interne ?

Pourquoi la démonstration est trompeuse

Un prototype réussit parce qu'il est construit sur un cas favorable. Un seul type de document, un seul émetteur, un fichier propre, quelques champs simples. La conclusion qu'on en tire, « c'est résolu », est vraie pour ce document et fausse pour le flux réel.

L'écart ne vient pas de la qualité du modèle. Il vient de tout ce qui entoure l'extraction.

Les sept chantiers d'une mise en production

La variabilité des formats

Trois cents fournisseurs produisent trois cents mises en page. Une instruction ajustée pour l'un dégrade les résultats des autres, et la dégradation n'apparaît qu'après coup. Le coût de maintenance croît avec le nombre d'émetteurs.

Les lignes de tableau

C'est le premier point de rupture. Extraire un numéro de facture est trivial. Extraire quarante lignes avec leur référence, leur quantité et leur montant, sans en omettre ni en inventer, ne l'est pas.

La détection des valeurs fausses

Un modèle génératif ne renvoie pas d'erreur. Il renvoie une valeur cohérente avec le contexte. Sans score de confiance ni lien vers la source, une donnée fausse est indistinguable d'une donnée juste jusqu'à ce qu'un tiers la découvre.

Le harnais d'évaluation

Sans jeu de test constitué sur des documents réels, aucune modification n'est mesurable. Construire ce jeu, l'annoter et le maintenir constitue un projet distinct, et c'est celui qu'on repousse systématiquement.

Les contrôles et l'accès aux référentiels

Une donnée extraite n'a de valeur qu'une fois confrontée aux données internes. Il faut écrire les règles métier, brancher les référentiels, et garantir que les calculs ne sont pas confiés au modèle.

L'interface de revue

Il faut un endroit où un opérateur voit le document, la valeur extraite, sa position dans le document, et corrige. C'est une application, pas un script.

Les migrations de modèles

Les versions changent, se déprécient, se comportent différemment. Sans évaluation automatisée, une migration se fait sans visibilité sur ses effets.

Le coût que personne ne compte

Le développeur qui a construit le prototype en devient propriétaire. Le système tourne tant qu'il est présent et que rien ne change. Le jour où un fournisseur modifie son format, où une API évolue, ou où cette personne quitte l'entreprise, l'équipe métier revient à la saisie manuelle sans que la direction en soit informée.

Quand l'internalisation est le bon choix

Trois situations la justifient sans réserve.

Un type de document unique, un format stable, un volume faible et un enjeu non critique. Le paramétrage tient dans un script et la maintenance est marginale.

Une équipe technique déjà constituée sur les sujets d'apprentissage automatique, et un traitement documentaire qui constitue le produit lui-même plutôt qu'une fonction support.

Une contrainte réglementaire interdisant tout traitement externe. La question devient alors un déploiement sur infrastructure interne, pas un développement.

Cinq questions avant d'arbitrer

Combien de formats distincts traitez-vous aujourd'hui ?

Que se passe-t-il concrètement quand une valeur extraite est fausse ?

Comment mesurez-vous qu'une modification améliore le résultat ?

Qui corrige les valeurs incertaines, et dans quelle interface ?

Qui maintient le système dans dix-huit mois ?

Une réponse floue à trois de ces cinq questions indique que le projet sera plus long que prévu.