Traitement de documents par IA : le premier projet qui se rembourse
Factures fournisseurs, bons de commande, contrats, formulaires, courriers entrants : le traitement de documents par IA est presque toujours le premier projet que nous recommandons à une ETI. Il cumule les traits qui font un bon premier chantier : un volume élevé, une vérité terrain sans ambiguïté (le montant est juste ou il ne l’est pas), une erreur qui se compte, et une valeur visible dès le premier mois sur le temps des équipes comptables ou achats.
Il fait rarement l’objet d’une présentation en comité de direction, et c’est lui qui finance le suivant.
Pourquoi les documents passent avant tout le reste
Une facture fournisseur est ouverte, lue, rapprochée d’un bon de commande, saisie dans l’ERP, puis classée. Multipliez par plusieurs centaines ou milliers par mois, et vous obtenez un processus qui coche chaque case de la grille que nous utilisons pour choisir un premier processus, y compris une relecture humaine rapide sur les cas douteux.
La valeur est immédiate parce que le processus existe déjà, avec ses gens, son outil cible et son rythme. Le système reprend une tâche que tout le monde veut lâcher, dans un outil que tout le monde connaît. C’est aussi l’apprentissage le moins cher : votre organisation en sort en sachant ce que sont un jeu d’évaluation et une file de revue.
Comment se construit une chaîne de traitement de documents
La chaîne que nous mettons en place tient en cinq blocs.
L’extraction structurée d’abord. Le modèle lit le document, PDF natif, scan ou photo, et renvoie des champs nommés dans un schéma fixe (fournisseur, dates, lignes, montants, TVA), avec un niveau de confiance par champ.
Les règles de validation ensuite, et elles sont déterministes, sans IA. La somme des lignes doit retomber sur le total hors taxe, le TTC doit correspondre, la date d’échéance doit suivre la date d’émission, le fournisseur et le numéro de commande doivent exister dans les référentiels, les quantités doivent correspondre à la réception. Ces règles attrapent la majorité des erreurs d’extraction sans relecture humaine, et elles ne se trompent jamais de la même façon qu’un modèle.
La file de revue pour les exceptions. Tout document qui échoue à une règle ou dont un champ a une confiance faible part dans une interface où un opérateur voit le document et les champs côte à côte, corrige et valide. Les corrections sont conservées et deviennent des cas de test.
L’écriture dans l’ERP ou l’outil métier, en dernier, avec des opérations que l’on peut rejouer sans créer de doublon, et les précautions qui s’imposent dès qu’un système écrit dans vos données. Et sous l’ensemble, un journal complet : quel document, quels champs extraits, quelles règles passées, qui a corrigé quoi, ce qui a été écrit où.
Ce qui fait échouer un projet de traitement de documents
Le premier piège est le périmètre. Vouloir couvrir cent types de documents dès la première version revient à construire cent projets à la fois. Nous commençons par un type et un flux : les factures fournisseurs de telle entité, reçues sur telle boîte mail. Le deuxième type arrive quand le premier tourne en production.
Le deuxième piège est l’absence de base de référence. Sans mesure préalable du temps par document et du taux d’erreur de la saisie manuelle, le système sera jugé sur des impressions, et les impressions sont dures avec les machines : une erreur d’IA se remarque, dix erreurs humaines passent inaperçues. Mesurer le processus avant d’y toucher prend quelques jours et évite ce procès.
Le troisième piège est la revue humaine mal dimensionnée. Trop large, elle absorbe tout le temps gagné et le projet se résume à un changement d’écran. Trop étroite, elle laisse passer des erreurs dans l’ERP, et la confiance s’effondre à la première facture payée deux fois. Le bon réglage se cale sur les mesures : la file reçoit au départ une part importante des documents, puis se resserre, type par type, à mesure que les chiffres le justifient. C’est le point où la plupart des POC s’arrêtent, parce qu’ils ont montré l’extraction et jamais le workflow de revue.
Comment mesurer que ça marche
Trois indicateurs suffisent, et ils se lisent dans le journal.
Le taux de traitement sans retouche : la part des documents qui traversent l’extraction, les règles et l’écriture sans passer par un humain, et donc le temps rendu aux équipes.
Le temps par document, exceptions comprises, comparé à la baseline. Un système qui traiterait quatre documents sur cinq en silence mais dont le cinquième prendrait trois fois plus de temps qu’avant aurait un bilan moins flatteur qu’il n’y paraît.
Les erreurs détectées, dans les deux sens : celles que les règles ont attrapées en sortie de modèle, et celles trouvées dans l’ERP après écriture. La seconde doit tendre vers zéro, la première peut rester élevée puisqu’elle mesure le travail des règles. Nous publions ces trois chiffres chaque semaine, et c’est sur eux que se décide chaque élargissement de l’autonomie.
Le coût dépend du nombre de types de documents, de l’état des référentiels et de l’ERP, et les fourchettes que nous constatons restent dans le bas de l’échelle. Si vous avez un flux de documents en tête et un volume mensuel, c’est le point de départ de notre offre d’IA sur mesure, avec un prototype sur vos propres documents avant tout engagement plus large.