Extraire les données des documents fournisseurs : le travail que personne ne veut faire

Dans presque toutes les entreprises que j’accompagne, il existe une tâche que personne ne revendique et que tout le monde connaît : quelqu’un reçoit un document d’un fournisseur — une grille tarifaire, un catalogue, un bon de livraison, une fiche technique — et le ressaisit à la main dans le système. Cela prend quelques heures par semaine, cela génère des erreurs qu’on découvre plus tard, et cela n’apparaît dans aucun tableau de bord parce que ce n’est le projet de personne. C’est aussi, de tous les cas d’usage d’IA que je vois passer, l’un des plus sûrs.

La raison n’est pas technique. C’est que ce cas satisfait, par construction, les quatre conditions qui font qu’un projet d’IA produit un résultat mesurable plutôt qu’une démonstration¹ : un propriétaire évident, une mesure préexistante, un coût d’erreur borné, et un recours naturel.

Pourquoi ce cas est structurellement sain

Condition	Extraction documentaire
Propriétaire du résultat	La personne qui ressaisit aujourd’hui — elle a un avis immédiat
Mesure préexistante	Heures hebdomadaires de saisie, taux d’erreur constaté
Coût d’une erreur	Borné : une valeur fausse se corrige, elle ne détruit rien
Recours utilisateur	Naturel — un humain valide déjà, on ne fait que réduire son volume

À cela s’ajoute une propriété rare : le résultat se constate en trois semaines. La personne qui passait six heures par semaine en passe deux, ou elle n’en passe pas moins et le projet a échoué. Il n’y a pas d’ambiguïté, pas de débat sur l’attribution, pas de courbe à interpréter.

Le seuil de confiance, plutôt que l’automatisation totale

L’erreur de conception la plus fréquente consiste à viser une extraction sans intervention humaine. C’est ce qui fait dériver le projet vers six mois de réglages pour gagner les derniers points de fiabilité.

La bonne conception repose sur un seuil de confiance appliqué champ par champ. Au-dessus du seuil, la valeur est acceptée et écrite. En dessous, elle est présentée à un humain, préremplie, avec le passage du document mis en évidence.

Ce réglage change la nature de la tâche : on ne saisit plus, on vérifie une minorité de champs. Le gain de temps est déjà considérable, et il est obtenu sans exiger une fiabilité que le format des documents ne permettrait de toute façon pas.

Le seuil se règle par champ, ce qui est le point de finesse qui rend le système utilisable. Un libellé produit tolère l’approximation. Un prix ne la tolère pas : mieux vaut le faire vérifier neuf fois sur dix que d’écrire une valeur fausse une fois sur cent.

Un système qui extrait 80 % des champs avec certitude et demande confirmation pour les 20 % restants vaut mieux qu’un système qui prétend en extraire 99 %. Le premier est utilisable demain ; le second se règle pendant six mois.

Le périmètre : commencer par les formats réguliers

La deuxième discipline consiste à trier les documents avant de traiter quoi que ce soit.

Les documents fournisseurs se répartissent grossièrement en trois familles. Les formats réguliers — tableaux propres, structure stable d’un envoi à l’autre — s’extraient de façon fiable et représentent souvent la majorité du volume. Les formats variables — même information, présentation qui change à chaque envoi — demandent un traitement plus tolérant et une validation plus fréquente. Les documents dégradés — photographiés de travers, cellules fusionnées, annotations manuscrites — ne s’extrairont jamais correctement.

Le périmètre de départ ne retient que la première famille. Elle produit un résultat mesurable en trois semaines et elle finance la suite. Vouloir couvrir les trois d’emblée produit un projet long, sans jalon intermédiaire, et dont l’échec ne se constate qu’à la fin.

Il faut le dire au client sans détour : les documents dégradés continueront d’être saisis à la main, et c’est le bon arbitrage. Un système qui essaie de les traiter introduira des erreurs silencieuses dans des données de prix.

Ce qu’il faut construire autour

L’extraction elle-même est la partie facile. Trois éléments périphériques déterminent si le système sera utilisé.

La traçabilité. Chaque valeur écrite doit pouvoir être rattachée à son document source et à sa position dans ce document. Sans cela, une valeur douteuse découverte trois mois plus tard est indéfendable, et la confiance dans l’ensemble s’effondre.

Le retour arrière par lot. Un document mal traité doit pouvoir être annulé dans son intégralité, sans corriger champ par champ. C’est ce qui permet d’accepter le risque d’un traitement automatique.

La boucle de correction. Quand un humain corrige une valeur, cette correction doit être conservée — elle indique où le système est faible, et elle constitue la matière du réglage suivant. Un système qui n’apprend pas de ses corrections répétera les mêmes erreurs indéfiniment.

Le coût, et pourquoi il reste bas

Ce cas d’usage a un profil de coût favorable qu’il vaut la peine d’expliciter, parce qu’il contraste avec celui d’un agent conversationnel.

Le traitement est ponctuel et borné : un document, un appel, une sortie structurée. Il n’y a pas d’enchaînement de tours, pas de contexte réinjecté qui grossit, pas de boucle possible. C’est exactement l’inverse du profil qui fait exploser la facture d’un agent².

Le volume est prévisible, les entrées sont de taille connue, et le coût par document se calcule à l’avance avec une précision rare. Sur des volumes mid-market, il reste dérisoire face aux heures qu’il libère — et cette comparaison-là, contrairement à la plupart des projets d’IA, se fait sur deux chiffres que l’entreprise connaît déjà.

---

Footnotes

1. Sur les quatre conditions — propriétaire, mesure, seuil d’erreur, recours — voir Un projet d’IA ne meurt pas d’un mauvais modèle, il meurt d’un mauvais périmètre. ↩

2. Sur la structure de coût d’un agent et sur ce qui la fait déraper, voir Combien coûte vraiment un agent IA en production. ↩