OCR ou IA : quelle différence pour lire un bon de commande ?

Un lecteur de documents, ou OCR, reconnaît des caractères et les range selon un modèle : le numéro client ici, les quantités dans telle colonne. Un agent de traitement des commandes part du sens. Il lit le mail et ses pièces jointes, identifie ce qui est commandé, le rapproche de votre référentiel articles et prépare la commande dans l'ERP.

OCR signifie reconnaissance optique de caractères. La technique, ancienne et fiable, transforme une image ou un PDF numérisé en texte. Pour en tirer une commande, les logiciels de lecture automatique ajoutent un modèle par mise en page, construit le plus souvent client par client. Dans une entreprise de dispositifs médicaux rencontrée en mars 2026, l'ADV décrit ce travail : entourer un identifiant, le numéro de Siret par exemple, pour que le logiciel reconnaisse le client, puis lui indiquer où se trouvent les références, la désignation, le conditionnement et les prix, « en bas à gauche ».

Un agent de traitement des commandes ne dépend pas de cette carte des zones. Il lit la commande là où elle se trouve, en PDF, en fichier Excel ou rédigée dans le corps du mail, et cherche dans votre référentiel articles ce que le client a voulu dire.

La question n'a rien de théorique. Dans 4 % des entreprises que nous avons rencontrées entre septembre 2025 et août 2026, le prospect en parlait de lui-même : il avait un OCR en place, ou voulait savoir ce qui le distingue d'un agent. Beaucoup d'éditeurs mêlent aujourd'hui les deux techniques, et l'étiquette « IA » ne tranche rien. Ce qui tranche, c'est ce que le logiciel fait de la ligne une fois lue.

Autre différence, plus discrète : un lecteur attend qu'on lui remette le document, souvent sur une adresse réservée aux commandes que les clients doivent apprendre à utiliser. L'agent travaille dans la boîte où les commandes arrivent déjà. La labélisation de la boîte mail y repère le message qui contient une commande et le confie à l'agent qui doit le traiter.

Parce qu'il a appris des positions, pas un sens. Son modèle dit où se trouve chaque information sur un document donné. Quand le client change d'ERP, ajoute une colonne, envoie une photo au lieu d'un PDF ou écrit sa commande dans le mail, la zone attendue est vide ou fausse. Chaque nouvelle mise en page demande un nouveau modèle.

Le lecteur ne se trompe pas de lettre, il se trompe de case. Tant que le document ressemble à celui qui a servi à construire son modèle, tout va bien. Dès qu'il s'en écarte, le logiciel cherche l'information là où elle n'est plus.

Chez un fabricant de panneaux décoratifs, la personne qui pilote le projet d'automatisation a posé le calcul en octobre 2025 : 1 500 clients, donc 1 500 mises en page de bons de commande, et 20 jours de mise en route par client avec un lecteur classique. Le reproche ne portait pas sur la lecture : ces logiciels « sont même bons » en OCR. Mais « c'est assez lourd à mettre en œuvre et dès que ça bouge, ça pète ».

Même bien réglé, un lecteur reste sensible à des détails que personne ne remarque. Dans l'entreprise de dispositifs médicaux, des références connues n'étaient plus reconnues parce qu'un client les avait entourées à la main, ou qu'un point-virgule avait changé de place.

Le lecteur reste très solide sur un gros client qui envoie chaque jour le même document. C'est même le cas que le fabricant de panneaux réservait aux technologies lourdes : un client qui pèse 10 millions d'euros et commande tous les jours. Il l'est beaucoup moins sur un portefeuille où chacun commande à sa manière, et ce cas est fréquent : dans 47 % des entreprises que nous avons rencontrées, le prospect décrit des commandes reçues en PDF, en Excel, en photo ou en message texte.

En rapprochant la ligne du référentiel articles au lieu de la recopier. L'agent compare ce que le client a écrit, désignation, dimensions, couleur, avec vos articles. Quand une seule référence correspond, la ligne passe. Quand plusieurs restent possibles, elle s'arrête et attend l'équipe, dont la correction est retenue pour les commandes suivantes.

C'est le vrai sujet, et la plupart des comparaisons entre OCR et IA passent à côté. « Pour le même produit, ça peut avoir 5, 6, 7, 8, 9 noms différents », nous disait en octobre 2025 le dirigeant d'un distributeur de robinetterie. Ses équipes s'y retrouvent parce qu'elles connaissent leurs clients. Un lecteur, lui, recopie le nom choisi par le client. Reste à trouver l'article qui se cache derrière, et c'est l'ADV qui s'en charge, ligne par ligne.

Le cas se complique quand un article se définit par plusieurs caractéristiques. Chez le fabricant de panneaux décoratifs, « il faut 7 à 8 paramètres pour définir un article » : largeur, longueur, épaisseur, couleur, finition, chacun écrit à la façon du client, l'épaisseur en millimètres, avec un point ou une virgule. Tant qu'il en manque un, la ligne peut correspondre à 10, 15 ou 20 articles. D'où la conclusion tirée côté projet : tout le retour sur investissement dépend de la capacité à relier cette chaîne de caractères à la base articles.

Les mots changent aussi d'un client à l'autre. Chez un négociant en matériaux rencontré en mai 2026, le même article s'appelle parpaing, agglo creux ou bloc selon qui commande, et ces appellations ne figurent pas toutes dans la désignation du produit.

Un agent de traitement des commandes ne cherche pas un mot identique : il compare ce qui est écrit à votre référentiel. Quand la correspondance est sûre, la ligne passe sans que personne y touche. Sinon, elle s'arrête et attend l'équipe. Ce que l'équipe corrige, l'agent l'apprend et le réutilise sur les commandes suivantes de ce client.

Le contrôle reste humain là où il compte. « Il faut toujours qu'il y ait un contrôle humain », insistait le dirigeant du distributeur de robinetterie à propos de ses devis : dans son métier, quelques erreurs suffisent à perdre sa crédibilité. L'équipe ne passe plus ses journées à chercher des références. Elle tranche les cas que l'agent lui soumet.

Sur un document propre, lire les caractères n'est plus le problème : les deux y arrivent. Le taux qui compte est la part des lignes associées à la bonne référence de l'ERP sans intervention. Il dépend de vos clients, entre ceux qui recopient votre référence et ceux qui écrivent une désignation à eux. Il se mesure sur vos propres commandes.

Méfiez-vous du taux annoncé avant tout essai. En octobre 2025, un éditeur promettait au fabricant de panneaux décoratifs 90 % de lignes associées. Côté projet, on tablait plutôt sur 50 à 70 %, et on jugeait qu'à 60 %, ce serait déjà un bon résultat pour des articles à huit paramètres.

Le même fabricant proposait une façon simple de juger un essai, à reprendre telle quelle : sur 100 lignes en entrée, combien sont associées avec certitude, combien laissent un doute, combien restent inconnues. Ces trois tas disent ce que l'ADV aura encore à faire, bien mieux qu'un taux de lecture.

Une ligne qui porte votre référence s'associe sans grande difficulté, avec un lecteur comme avec un agent. Une ligne rédigée en désignations commerciales demande un vrai rapprochement : c'est là que l'écart se creuse.

Posez enfin une question qu'on oublie souvent : que devient une ligne en échec ? Dans le projet de ce fabricant, le logiciel envisagé n'apprenait pas des corrections : une ligne non associée devait repartir en saisie manuelle, et rien n'empêchait la même erreur de revenir à la commande suivante. C'est le point qui laissait le projet sceptique. Avec un agent de traitement des commandes, la ligne en doute attend l'équipe, et la correction sert aux commandes suivantes du même client. Le taux du premier mois compte moins que sa progression.

Pas sans l'avoir mesuré. Un lecteur bien réglé sur des documents stables rend un vrai service, et le travail fourni pour l'entraîner a de la valeur. Comptez les commandes qu'il fait entrer dans l'ERP sans retouche, ce qu'elles coûtent, et le temps passé sur les autres. C'est sur ces autres qu'un agent de traitement des commandes a sa place.

L'entreprise de dispositifs médicaux citée plus haut le montre bien. « Aujourd'hui, on est à 70 % des saisies, mais ça fait plus de deux ans qu'on y travaille. Ça ne se fait pas par magie », nous disait sa direction ADV en mars 2026. Les 30 % restants ressemblent à tout ce que décrit cet article : des fax de mauvaise qualité, des références écrites à la main, des clients d'un même groupement qui partagent un format, où modifier une règle pour l'un en dérègle un autre.

Pas question pour autant de tout recommencer : l'équipe y a consacré plus de deux ans, et la direction ADV craint de la perdre en lui faisant tout reprendre à zéro. L'argument est sérieux. Il plaide pour commencer par les commandes que le lecteur ne traite pas, plutôt que de tout basculer d'un coup.

Le coût, lui, se compare commande par commande. Chez un fabricant de portes de garage, un essai mené en 2019-2020 a été arrêté : le lecteur ne s'en sortait pas avec les articles configurés, et il revenait à environ 3 € par commande, pour des commandes autour de 50 €. Le calcul était vite fait : 80 % du gain attendu partait chez le fournisseur. En décembre 2025, la personne qui l'avait évalué reconnaissait que les prix ont sans doute baissé depuis.

La bonne unité n'est donc pas le prix de la page lue, mais le coût de la commande réellement entrée dans l'ERP sans ressaisie. Avant de trancher, sortez trois chiffres :

1. La part des commandes que le lecteur fait entrer dans l'ERP sans retouche.
2. Le temps que l'équipe passe sur toutes les autres.
3. Le coût de chaque commande réellement traitée.

Sur un bon de commande lisible, lire n'est plus le problème. Associer chaque ligne au bon article l'est encore, et c'est là que se perd le temps de l'ADV. Un agent de traitement des commandes lui rend ces heures, pour les clients, les litiges et les devis qui attendent une relance.