Le Problème de la Saisie des Bons de Commande
— et Ce Qui le Maintient

Le problème à 217 $ dont personne ne parle

Demandez à un responsable achats combien coûte le traitement d'un bon de commande et vous obtiendrez généralement un regard vide. Pas parce qu'ils ne se soucient pas des coûts — c'est le cas. Mais parce que le coût de la saisie manuelle des données des bons de commande est réparti si uniformément dans les opérations quotidiennes qu'il disparaît en arrière-plan. Ce n'est pas une ligne budgétaire. C'est juste « ce qu'on fait ».

Le Center for Advanced Procurement Strategy (CAPS Research) mesure les coûts de traitement des bons de commande depuis des années. Leurs données intersectorielles montrent un coût moyen par bon de commande allant d'environ 50 $ à plus de 1 000 $ selon le secteur, avec une moyenne autour de 217 $. Les estimations spécifiques à l'industrie manufacturière, provenant de multiples sources, convergent vers 95 à 145 $ par bon de commande. Ce chiffre inclut non seulement le travail visible de saisie des données, mais aussi les relances par e-mail, les vérifications de statut, les corrections d'erreurs, la résolution des commandes en double et le temps passé à réconcilier les incohérences entre ce que dit le bon de commande et ce que le fournisseur a réellement expédié.

Une entreprise traitant 200 bons de commande par mois à 120 $ chacun dépense 288 000 $ par an rien qu'en coûts administratifs pour transférer les données de commande d'un document à un autre. Et c'est le cas médian. Dans le haut de la fourchette — les bons de commande complexes de l'industrie manufacturière avec des tableaux de 50 lignes et des approbations à plusieurs niveaux — le coût peut dépasser 500 $ par bon de commande.

Le chiffre en lui-même n'est pas le problème. Le problème est que ces coûts sont mesurés, publiés et évalués par des organismes de recherche indépendants depuis plus d'une décennie. Chaque responsable achats a accès à ces données. Les outils d'automatisation qui pourraient réduire ces coûts existent. Et pourtant, l'écart entre « connaître le chiffre » et « changer le chiffre » persiste dans la majorité des entreprises de fabrication et de distribution de taille moyenne. La question qui mérite d'être posée n'est pas « combien ça coûte » — c'est pourquoi ça continue de coûter autant, année après année, alors que la solution n'est pas un mystère ?

Ce n'est pas un problème. C'est une pile de trois.

Demandez à un éditeur de logiciel ce qui cloche dans le traitement manuel des bons de commande, et il vous répondra en une phrase : la saisie de données est lente et source d'erreurs. Cette réponse est techniquement vraie. Mais elle est inutile comme diagnostic. Le vrai problème n'est pas que les équipes achats tapent au lieu de cliquer. Le vrai problème, c'est une structure à trois niveaux qui rend la saisie quasiment inévitable dans les conditions actuelles du secteur.

Niveau un : la fragmentation des formats. Chaque bon de commande client est présenté différemment. L'un met le numéro de BC en haut à droite. Un autre le place dans un bloc d'en-tête à gauche. Un troisième l'intègre dans un code-barres en page deux. Le tableau des lignes — qui peut comporter 5, 50 ou 300 lignes — peut avoir six colonnes, ou quatorze. Les codes articles peuvent être dans la colonne un ou la colonne quatre. Les dates de livraison peuvent apparaître par ligne ou comme un champ unique dans l'en-tête. Comme l'a dit un utilisateur de Reddit sur r/manufacturing : "Le plus gros problème pour nous, c'est que les bons de commande clients n'arrivent pas dans le même format. Tout le monde utilise un format de BC différent, même pour les noms de champs."

Ce n'est pas une observation nouvelle. Tout professionnel des achats le sait. Ce qui est moins compris, c'est que la fragmentation des formats n'est pas un bug — c'est l'état d'équilibre du système. Le format de BC de chaque entreprise est généré par son ERP, configuré pour correspondre à ses structures de données internes, qui ont évolué au fil d'années de décisions métier spécifiques. Demander à 80 clients de standardiser leurs formats de BC n'est pas une demande d'achat. C'est demander à 80 entreprises de reconfigurer leurs sorties ERP — une tâche sans retour sur investissement de leur point de vue.

Niveau deux : le désalignement des incitations du fournisseur. Si vous êtes un fabricant recevant des BC de clients, vous avez de fortes incitations à automatiser la saisie. Chaque minute gagnée à taper est une minute rendue à la planification de production, à la gestion des stocks ou à la négociation avec les fournisseurs. Mais si vous êtes le client qui envoie le BC, vous n'avez strictement aucune incitation à changer votre format pour faciliter la vie du fournisseur. Le BC part comme toujours — généré par votre ERP, joint en PDF à un email — et la charge de saisie du fournisseur vous est invisible. Cette asymétrie est fondamentale. La partie qui contrôle le format n'a aucune incitation à le standardiser, et la partie qui a besoin de standardisation n'a aucun levier pour l'exiger.

Niveau trois : l'inadéquation des outils. L'approche dominante de l'extraction de données documentaires depuis deux décennies est basée sur des modèles : vous dessinez des cadres autour des champs sur un document type, vous les étiquetez, et l'outil extrait les données de tout document ultérieur correspondant à la même mise en page. Cela fonctionne pour les factures d'un seul fournisseur. Cela s'effondre pour les BC de 40 clients différents. Chaque client nécessite un modèle distinct. Chaque modèle prend du temps à construire. Et quand un client met à jour son ERP ou modifie la mise en page de son BC — ce qui arrive lors de migrations système, d'acquisitions ou de changements de marque — le modèle se brise silencieusement, produisant des données erronées ou rien du tout. Le travail que vous cherchiez à éliminer (la saisie manuelle) a été remplacé par un autre type de travail manuel (la maintenance des modèles).

L'EDI a résolu ce problème pour les plus grandes entreprises du monde. Pour tous les autres, il a créé un plafond.

Si vous êtes dans les achats depuis plus de quelques années, vous avez entendu le discours sur l'EDI. L'EDI 850 — la norme ANSI X12 pour les bons de commande électroniques — définit un format structuré pour l'échange de bons de commande de machine à machine. Lorsque les deux parties utilisent l'EDI, les bons de commande passent directement de l'ERP de l'acheteur au système de gestion des commandes du fournisseur sans intervention humaine. Pas de PDF. Pas de saisie. Pas de variation de format, car les deux côtés se conforment au même ensemble de transactions.

Cela fonctionne à merveille — pour les relations où c'est mis en œuvre. Les grands constructeurs automobiles, les grands détaillants et les donneurs d'ordre aérospatiaux utilisent l'EDI avec leurs fournisseurs de premier rang depuis des décennies. La chaîne d'approvisionnement de Walmart s'effondrerait sans cela.

Le problème est que la courbe d'adoption de l'EDI a un plafond dur. La mise en œuvre de l'EDI nécessite une infrastructure technique des deux côtés — logiciel de traduction EDI, protocoles de communication (AS2, VAN), et logique de mappage pour traduire entre les segments EDI 850 (BEG, N1, PO1, PID, CTT) et les structures de données internes de chaque partie. Le coût de mise en place se chiffre en milliers de dollars par partenaire commercial. Pour les relations à fort volume — un fabricant passant des commandes hebdomadaires de plusieurs millions — le retour sur investissement est immédiat. Pour la longue traîne des clients qui commandent trimestriellement ou sporadiquement — ce qui décrit la plupart des relations B2B de milieu de marché — il ne se concrétise jamais.

Le résultat est une réalité d'approvisionnement à deux vitesses. Les 10 à 20 % des relations commerciales les plus importantes fonctionnent avec l'EDI. Les 80 % restants fonctionnent par e-mail et PDF. C'est dans ce deuxième groupe que vit la saisie manuelle des données — et où elle continuera de vivre tant que les options d'automatisation nécessiteront une normalisation des formats que ces relations ne peuvent pas supporter économiquement.

CAPS Research a constaté que 31 % des responsables de la chaîne d'approvisionnement disent qu'un logiciel d'approvisionnement obsolète bloque l'exécution, et 37 % citent les problèmes d'accès aux données comme un obstacle majeur. Ces chiffres ne décrivent pas des entreprises qui ignorent l'automatisation. Ils décrivent des entreprises qui l'ont évaluée et ont constaté que l'économie ne fonctionne pas pour la majorité de leur portefeuille de fournisseurs.

Le piège du modèle : une automatisation qui crée du travail manuel

En théorie, l'extraction basée sur des modèles est une approche raisonnable. Vous montrez à l'outil un document exemple, vous marquez l'emplacement de chaque champ, et l'outil reproduit ce schéma d'extraction sur les documents suivants. C'est ainsi que la plupart des outils d'automatisation documentaire — des plateformes IDP d'entreprise aux SaaS plus légers — fonctionnent depuis les débuts de l'OCR.

En pratique, l'extraction par modèle a une propriété fatale pour le passage à l'échelle : le nombre de modèles nécessaires augmente linéairement avec le nombre de formats de documents distincts que vous recevez. Si vous avez 40 clients et que chacun utilise une mise en page de bon de commande différente, il vous faut 40 modèles. Chaque nouveau client nécessite une session de configuration de modèle — généralement 10 à 15 minutes pour identifier les champs, délimiter les zones et vérifier la précision de l'extraction. Quand le client n°41 arrive, quelqu'un doit interrompre son travail pour créer le modèle n°41.

Cela crée une inversion de la promesse d'automatisation. L'outil était censé éliminer le travail manuel répétitif. Au lieu de cela, il a créé une nouvelle catégorie de travail manuel répétitif — la maintenance des modèles — moins visible mais tout aussi chronophage. Et contrairement à la saisie de données, les défaillances de modèles sont silencieuses. Lorsqu'un client modifie discrètement le format de son bon de commande (nouvel ERP, nouvelle charte graphique, fusion de formats suite à une acquisition), le modèle ne génère pas d'erreur. Il extrait des données incorrectes ou manquantes, que vous découvrez en aval — quand la commande est erronée, l'expédition mal acheminée ou la facture ne correspond pas.

La structure des coûts est insidieuse. Une erreur manuelle de saisie — une quantité mal tapée ou un numéro de pièce inversé — est généralement détectée dans le même flux de travail, par la même personne ou par une validation en aval. Une défaillance de modèle produit des erreurs systématiques : chaque bon de commande du client X manque désormais du champ date de livraison, et personne ne le sait jusqu'à ce que l'entrepôt appelle pour demander où livrer. Le coût par incident est plus élevé et le délai de détection plus long.

Pour un fabricant de taille moyenne traitant des bons de commande de 20 à 80 clients différents sur plusieurs écosystèmes ERP — SAP, NetSuite, Microsoft Dynamics, Epicor, Sage, Infor — l'approche par modèle ne réduit pas le travail. Elle le déplace du poste de saisie vers l'écran de configuration des modèles. Et pour les équipes achats qui n'ont pas d'ingénieurs d'automatisation dédiés, ce déplacement aggrave le problème, au lieu de l'améliorer.

Ce que font vraiment les équipes achats au quotidien

Derrière les benchmarks de coûts et l'analyse structurelle, il y a un vrai flux de travail qui se répète des milliers de fois par jour dans les services achats de l'industrie manufacturière. Il vaut la peine de le décrire simplement — non pas comme une scène fictive, mais comme un composite de ce que les professionnels des achats racontent sur Reddit et dans les forums spécialisés.

La boîte de réception contient de nouveaux messages de clients. Chacun est une pièce jointe de bon de commande, généralement un PDF. Certains arrivent via un portail client ; la plupart par email. Le coordinateur achats ouvre le premier. Il vient d'un client utilisant NetSuite — le numéro de BC est dans l'en-tête, le code fournisseur dans un champ de référence, les lignes dans un tableau à 9 colonnes. Il ouvre son tableur ou ERP et commence à saisir : numéro de BC, date, nom du client, adresse de livraison. Puis les lignes, une par une : code article, description, quantité, unité de mesure, prix unitaire, montant total. Si le BC a 15 lignes, ce sont 90 données individuelles à transférer manuellement, sans inverser un chiffre ni sauter une ligne.

Le deuxième BC vient d'un client utilisant SAP. La mise en page est totalement différente. Le numéro de BC est en haut à droite. Le nom du client est à un autre endroit. Le tableau des lignes a 12 colonnes au lieu de 9, avec des champs supplémentaires pour l'entrepôt et la date de livraison par ligne. Les noms de champs diffèrent — SAP appelle ça « Matière » là où NetSuite dit « Code article ».

Le troisième BC vient d'un client sans ERP du tout — c'est un document Word converti en PDF, avec les lignes formatées en liste à puces plutôt qu'en tableau. Un outil d'extraction basé sur des modèles échouerait immédiatement. Une personne peut le lire, mais la friction cognitive liée au basculement entre trois structures documentaires complètement différentes plusieurs fois par heure est le vrai frein à la productivité — pas la vitesse de frappe.

Comme l'a décrit un utilisateur Reddit sur r/procurement : « On prenait littéralement des PDF de fournisseurs, on copiait les valeurs dans des tableurs, on vérifiait chaque ligne par rapport au BC, on envoyait des emails aux fournisseurs pour les écarts, on collait tout dans l'ERP parce qu'aucun de ces systèmes ne communique entre eux. La moitié du boulot, c'est de l'administratif déguisé en gestion fournisseur. »

Ce qui frappe dans cette description, ce n'est pas l'inefficacité — c'est la précision. Les systèmes ne communiquent vraiment pas entre eux. Le PDF est un format sans issue : il préserve la mise en page visuelle mais détruit la structure des données. L'ERP destinataire attend des données structurées et mappées par champ. Entre ces deux formats, il y a un être humain qui reconstruit manuellement la structure de données perdue quand le BC a quitté le système du client. Cet être humain n'ajoute pas de valeur. Il effectue une traduction de format — une tâche que le logiciel devrait gérer, mais ne peut pas, parce que les formats changent constamment.

L'inertie organisationnelle qui normalise la saisie manuelle

Si le coût de la saisie manuelle des bons de commande est mesurable et que les outils pour le réduire existent, pourquoi le marché n'a-t-il pas résolu ce problème ? La réponse dépasse la technologie — elle est ancrée dans les comportements organisationnels et les incitations des fournisseurs.

Le coût est invisible pour les décideurs. La saisie manuelle des bons de commande n'apparaît pas comme une dépense distincte. Ce sont des heures d'acheteurs et de coordinateurs réparties sur la semaine de travail, classées sous « frais généraux opérationnels » plutôt que « main-d'œuvre de saisie de données ». Aucun directeur financier n'approuve une ligne intitulée « Traitement manuel des bons de commande — 288 000 $ ». Le coût est réel, mais il est absorbé dans des salaires qui existeraient de toute façon. Cette invisibilité comptable signifie qu'il n'y a pas de propriétaire budgétaire naturel pour la solution. L'informatique ne gère pas l'efficacité des achats. Les achats n'évaluent pas les logiciels. Les finances ne voient pas la ligne. Le problème tombe dans les failles entre les services.

Les échecs d'automatisation sont plus visibles que le travail manuel fastidieux. Lorsque la saisie manuelle produit une erreur, la solution est simple : trouver l'erreur, la corriger, envoyer une commande mise à jour. C'est agaçant mais routinier. Lorsqu'un outil d'automatisation produit une erreur, l'échec est plus important, plus visible et plus difficile à diagnostiquer. Un lot de 50 bons de commande traités automatiquement avec un mappage de champs défectueux peut créer 50 commandes incorrectes — une crise qui atterrit sur le bureau d'un manager. Le professionnel des achats qui a défendu l'automatisation en porte le blâme. La leçon que la plupart des organisations tirent d'une mauvaise expérience d'automatisation est « nos documents sont trop complexes pour les outils » plutôt que « nous avons utilisé le mauvais type d'outil pour notre diversité de formats ». Cette asymétrie de risque — les échecs automatisés ont un coût organisationnel plus élevé que les manuels — crée un fort biais en faveur du statu quo.

Les éditeurs d'ERP ont les mauvaises incitations. Les entreprises les mieux placées pour résoudre la saisie des bons de commande — SAP, Oracle, Microsoft, NetSuite, Epicor — sont celles qui ont le moins d'incitations à le faire. Leurs modules d'achats supposent une entrée structurée. Leur modèle de vente repose sur l'adoption de la suite complète, pas sur l'extraction d'une solution ponctuelle. Lorsqu'un client demande « comment intégrer les données des bons de commande de mes clients dans votre système », la réponse est généralement « faites utiliser notre portail à vos clients », ou « mettez en place un EDI », ou « saisissez-les manuellement ». Ces trois réponses acceptent le problème de format comme extérieur à la solution. Le modèle économique de l'éditeur d'ERP dépend de votre adoption de sa plateforme de bout en bout — pas de la résolution de l'étape d'extraction qui se situe à la frontière entre votre système et celui de vos clients.

Le problème a été normalisé à travers des générations de professionnels des achats. Les personnes qui travaillent dans les achats depuis 15 ans ne se souviennent pas d'une époque où la saisie des bons de commande n'était pas manuelle. Elles ont construit leur flux de travail autour de cela. Elles ont des raccourcis Excel, des macros et des modèles mentaux qui rendent la saisie manuelle tolérable. Suggérer une automatisation ne ressemble pas à une amélioration d'efficacité — cela ressemble à une menace pour un système qui, malgré ses défauts, a permis d'expédier les commandes de manière fiable pendant des années. Le coût opérationnel du changement — apprendre un nouvel outil, faire confiance à ses résultats, gérer les cas particuliers lorsqu'il échoue — semble plus élevé que le coût opérationnel du statu quo, même si les calculs disent le contraire.

Ce qui changerait vraiment la donne

Si le problème fondamental est la fragmentation des formats — des documents qui portent les mêmes informations logiques (numéro de BC, lignes d'articles, quantités, prix) mais dans des mises en page physiques illimitées — alors la solution ne peut pas être un outil qui vous oblige à gérer chaque mise en page individuellement. Il faut un outil qui ne se soucie pas de la mise en page.

C'est la différence entre l'extraction par modèle et l'extraction par sens. Un modèle demande : où se trouve le champ ? Colonne 3, ligne 7, à 150 pixels de la marge gauche. Une approche par sens demande : qu'est-ce que ce champ ? Elle cherche du texte correspondant au rôle sémantique de « Numéro de BC » — un identifiant unique près du haut du document, généralement alphanumérique, souvent étiqueté avec une variante de « BC n° » ou « Numéro de commande » ou « Bon de commande n° » — et extrait la valeur, peu importe où elle se trouve sur la page.

C'est ce que fait l'extraction par nom de colonne : vous définissez les colonnes souhaitées — « Numéro de BC », « Nom du fournisseur », « Code article », « Quantité », « Prix unitaire », « Total ligne » — et l'IA localise chaque valeur en comprenant ce qu'elle signifie, pas où elle se trouve. Les noms de colonnes que vous saisissez deviennent les en-têtes du tableau de sortie. Une seule définition de colonne fonctionne pour tous les formats de BC de vos clients, car la logique d'extraction est sémantique, pas positionnelle.

Les implications structurelles sont significatives :

• Fonctionnement sans modèle. Aucune configuration par client. Aucune bibliothèque de modèles à maintenir. Aucun échec silencieux lorsqu'un client modifie la mise en page de son BC. L'extraction s'adapte automatiquement à la structure de chaque document.
• Gestion des lignes d'articles. Le principal contenu d'un bon de commande est son tableau de lignes d'articles, qui peut s'étendre sur des dizaines de lignes avec des configurations de colonnes variables. L'extraction par nom de colonne lit chaque ligne comme un enregistrement complet, en faisant correspondre la bonne quantité, description et prix à chaque ligne — y compris les tableaux répartis sur plusieurs pages.
• Entrées multi-formats. La même définition de colonne fonctionne sur les PDF, les documents scannés et même les captures d'écran d'e-mails. La logique d'extraction ne fait pas de différence entre un BC généré par SAP et un autre tapé dans un document Word — elle lit le contenu, pas le format.

Pour une présentation détaillée de son fonctionnement pratique, y compris un guide champ par champ pour l'extraction de BC, consultez notre article sur l'extraction de champs spécifiques de bons de commande vers Excel sans modèles. Pour le traitement par lots — appliquer la même définition de colonne à des BC de dizaines de clients différents en une seule opération — consultez notre guide sur le traitement par lots de bons de commande de tous les formats fournisseurs dans un seul tableur. Et pour le workflow d'automatisation de bout en bout, y compris comment connecter la sortie d'extraction à votre système de gestion des commandes existant, consultez notre article sur l'automatisation de la saisie des données de bons de commande sans ERP.

Questions fréquentes

Pourquoi ne pas simplement imposer notre format de bon de commande à tous nos clients ?

Vous pouvez essayer — et les grandes entreprises ayant un fort pouvoir d'achat y parviennent parfois avec leurs plus gros fournisseurs. Mais pour la plupart des entreprises de taille moyenne, le rapport de force est inversé : vous avez plus besoin des commandes de vos clients qu'ils n'ont besoin de standardiser leurs bons de commande. Même si un client accepte, la mise en œuvre implique que son équipe IT reconfigure un ERP, le teste et le déploie — un projet avec un coût réel et aucun bénéfice direct pour eux. La plupart des équipes achats constatent que l'effort nécessaire pour imposer un format standard dépasse celui de gérer la diversité des formats.

Mon ERP ne gère-t-il pas déjà la saisie des bons de commande ?

La plupart des modules d'approvisionnement des ERP gèrent la création des BC — générer des commandes fournisseur — mais sont bien moins performants pour la réception des BC — importer les commandes de vos clients. Les ERP attendent des données structurées (EDI, import CSV ou saisie directe) et n'offrent aucun mécanisme intégré pour extraire des données structurées de PDF non structurés. Si vos clients vous envoient des BC en PDF, votre ERP peut les stocker comme pièces jointes, mais pas les lire sans outils d'extraction supplémentaires ou saisie manuelle.

Quelle est la précision de l'extraction par IA pour les bons de commande avec des tableaux de lignes complexes ?

Les données de tableaux imprimés peuvent être reconnues avec une précision allant jusqu'à 99 % grâce aux modèles d'IA visuelle. Les cas les plus difficiles ne sont pas les longs tableaux — l'IA gère bien les structures répétitives — mais les documents où les lignes sont formatées en texte narratif plutôt qu'en lignes (courant dans les BC de services), ou lorsque des annotations manuscrites sont ajoutées aux tableaux imprimés. Pour ces cas particuliers, l'extraction doit être considérée comme un premier passage qui réduit le travail manuel de 80 à 90 %, sans l'éliminer complètement. Les résultats doivent toujours être vérifiés avant d'être intégrés à un ERP ou un système de gestion des commandes.

Que faire si mes clients envoient des BC avec des modifications ou annotations manuscrites ?

L'extraction par nom de colonne peut gérer l'écriture manuscrite, y compris les annotations sur des documents imprimés. L'IA lit le texte manuscrit comme faisant partie du contenu du document et le mappe aux champs appropriés en fonction du sens. La précision pour l'écriture manuscrite est inférieure à celle du texte imprimé — en particulier pour l'écriture cursive ou les annotations au crayon léger — donc les BC manuscrits doivent être vérifiés plus attentivement que les BC imprimés propres.

S'agit-il simplement d'un abonnement logiciel supplémentaire en plus de l'ERP que nous payons déjà ?

Il comble une lacune spécifique que la plupart des ERP ne couvrent pas : l'étape d'extraction entre la réception d'un BC en PDF et l'obtention de données structurées exploitables. Si vous payez actuellement pour cette étape avec du temps d'acheteur et de coordinateur — et les benchmarks de coûts suggèrent que la plupart des fabricants de taille moyenne le font, à 95–145 $ par BC — la comparaison n'est pas "logiciel vs. pas de logiciel". C'est "logiciel vs. coût de main-d'œuvre". Pour un fabricant traitant 200 BC par mois, même une estimation prudente place le coût annuel de traitement manuel au-dessus de 200 000 $. La question pertinente est de savoir si un outil d'extraction réduit ce montant de plus que son coût — un calcul qui dépend de votre volume et de la complexité de vos BC, et non du fait que l'outil s'insère dans votre catégorie budgétaire ERP existante.

Là où se trouve vraiment le problème

La saisie manuelle des bons de commande résiste aux décennies d'automatisation pour une raison. Ce n'est pas que les équipes achats soient technophobes ou mal informées. C'est que la structure du problème — une variabilité infinie des formats, des incitations divergentes entre acheteurs et fournisseurs, un paysage d'outils dominé par des approches basées sur des modèles incapables de s'adapter à des formats divers — rend la solution évidente (acheter un logiciel d'automatisation) inefficace pour la majorité des relations achats.

L'EDI 850 a résolu le problème pour les partenariats à fort volume qui justifient le coût de mise en place. L'extraction par modèle l'a résolu pour les cas où la stabilité du format est garantie. Mais entre ces deux solutions se trouve un vide qui contient la majorité des achats réels : des dizaines de clients, chacun avec son propre format de bon de commande, dont aucun ne se standardisera jamais pour vous. C'est dans ce vide que vit la saisie manuelle, et elle y restera tant que les équipes achats n'adopteront pas des outils qui n'ont pas besoin de standardisation des formats pour fonctionner.

Le passage d'une extraction basée sur les modèles à une extraction basée sur le sens — passer de « où se trouve le champ » à « qu'est-ce que ce champ » — change l'économie du problème à sa racine structurelle. Lorsque la précision de l'extraction dépend de la compréhension sémantique plutôt que du positionnement, la diversité des formats cesse d'être un obstacle pour devenir sans importance. Le coût de l'automatisation passe de « un modèle par fournisseur » à « une définition de colonne pour tous les fournisseurs ». La barrière à l'adoption n'est pas technique — c'est de reconnaître que la génération précédente d'outils d'automatisation a été conçue pour un monde où les formats de documents étaient stables, alors que la réalité des achats est tout le contraire.