Bons de commande PDF reçus par email : arrêter la ressaisie dans l'ERP avec l'OCR et un LLM

Il est 8 h 30 au service administration des ventes (ADV). Quelqu'un ouvre la boîte commandes@, télécharge le premier PDF de la journée et recopie dans l'ERP le nom du client, son numéro de commande, une douzaine de références, autant de quantités et une date de livraison souhaitée. Puis il passe au suivant, qui ne ressemble en rien au précédent : autre client, autre mise en page, tableau à cheval sur deux pages, parfois un scan de travers.

Cette ressaisie coûte du temps et produit des erreurs prévisibles : une référence voisine sélectionnée par mégarde, une quantité saisie dans la mauvaise unité, un prix qui ne correspond pas au tarif négocié. Chaque erreur se paie plus tard en litige, en avoir ou en livraison refaite, et chaque heure de saisie retarde la confirmation envoyée au client.

La chaîne qui automatise cette saisie tient en quelques maillons : une réception centralisée, une lecture OCR (reconnaissance optique de caractères), une extraction des champs par un modèle de langage (LLM) dans un format imposé, un rapprochement avec les référentiels de l'ERP, une validation humaine pilotée par des seuils, puis la création de la commande par API. Ce guide s'adresse aux dirigeants, responsables ADV et DSI qui veulent décider en connaissance de cause, sans écrire de code. Le périmètre est volontairement serré : des commandes clients B2B reçues en PDF par email, à transformer en commandes de vente. Les factures fournisseurs relèvent d'un autre sujet.

Un parti pris traverse toutes les étapes : l'IA lit et structure les documents, mais le gain réel vient surtout de référentiels propres, de règles de contrôle explicites et d'une validation humaine qui diminue progressivement.

Ce qu'il faut réunir avant de commencer

Aucune de ces conditions n'est technique au sens strict, mais chacune conditionne la suite. Un projet qui démarre sans échantillon réel ni référentiels fiables finit souvent par mesurer la qualité de l'IA sur des cas qui ne sont pas les vôtres.

• Un échantillon de 50 à 100 vrais bons de commande récents, représentatif des principaux clients et des cas difficiles (scans, multi-pages, annexes), pseudonymisé si besoin.
• Quelques chiffres de départ : volume de commandes par jour, temps moyen de saisie, taux de correction ou de litige, part du volume portée par les 10 à 20 premiers clients.
• Un accès administrateur à la messagerie (Microsoft 365, Google Workspace ou serveur IMAP) pour créer une boîte dédiée.
• Un moyen d'écrire dans l'ERP : API documentée, connecteur ou import de fichiers, avec un compte technique dédié.
• Des référentiels propres : clients, articles, tarifs négociés, et si possible une table de correspondance entre références client et références internes.
• Un référent ADV disponible pour définir les règles de contrôle et valider les cas en attente.
• L'avis du DPO ou du responsable conformité sur l'hébergement et la durée de conservation des documents.

Étape 1 : chiffrer la douleur et choisir ce qu'on automatise

Le but de cette première étape est d'établir un point de départ mesuré, pour savoir si l'automatisation sera rentable et pour fixer des objectifs vérifiables. Sans ce relevé, impossible de dire six mois plus tard si le projet a tenu ses promesses.

Concrètement, relevez sur deux à quatre semaines le nombre de commandes reçues par jour, le temps moyen de saisie (par commande et, si possible, par ligne), le taux de commandes corrigées ou contestées et le nombre de mises en page distinctes. La multiplication du volume quotidien par le temps de saisie donne le temps ADV consommé chaque jour ; le taux de litige donne le coût caché, celui des avoirs et des livraisons refaites.

Classez ensuite vos clients par volume. Dans beaucoup d'entreprises B2B, une poignée de gros comptes concentre l'essentiel des commandes, tandis que la longue traîne pèse surtout par la diversité de ses formats. Vérifiez-le sur vos propres chiffres : c'est cette répartition qui décide de la stratégie de l'étape suivante. Ce travail ressemble à un petit cadrage, et il gagne à être mené comme tel, avec l'ADV autour de la table.

Résultat attendu : une page qui chiffre la situation actuelle et fixe deux ou trois objectifs mesurables, par exemple la part de commandes validées sans retouche et le délai entre réception et saisie.

Étape 2 : vérifier d'abord les alternatives au PDF

Avant d'automatiser la lecture d'un PDF, demandez-vous si ce PDF doit continuer d'exister. Pour les gros comptes, une commande électronique structurée supprime le problème à la source : la commande arrive déjà sous forme de données, sans PDF à lire ni à ressaisir.

Plusieurs voies existent. L'EDI (échange de données informatisé) reste courant entre grands donneurs d'ordre et fournisseurs. Le réseau européen d'échange de documents Peppol définit un profil dédié, le profil Peppol BIS Ordering, qui couvre l'envoi d'une commande et la réponse du fournisseur (acceptation, acceptation avec modifications ou refus). Un portail client ou un punchout, où l'acheteur commande depuis son propre système d'achat dans votre catalogue, produit lui aussi des commandes structurées.

Vérifiez aussi ce que votre ERP sait déjà faire nativement, sans présumer qu'un module de reconnaissance de documents couvre les commandes de vente. À titre d'exemple, l'API Extract de l'ERP open source Odoo traite les factures, les relevés bancaires, les notes de frais et les candidatures, pas les bons de commande clients.

Un mot sur la réglementation, pour lever une confusion fréquente : la réforme de la facturation électronique entre entreprises (calendrier officiel sur impots.gouv.fr) porte sur les factures et sur la transmission à l'administration des données de transaction et de paiement (e-reporting). Elle s'applique progressivement : depuis le 1er septembre 2026, toutes les entreprises doivent pouvoir recevoir des factures électroniques et les grandes entreprises et ETI doivent les émettre ; l'obligation d'émission s'étend aux PME et micro-entreprises le 1er septembre 2027. Elle ne vous dispense pas de traiter les bons de commande que vos clients continuent d'envoyer en PDF.

Résultat attendu : deux groupes de clients. D'un côté, les gros comptes à orienter vers un canal structuré ; de l'autre, la longue traîne qui continuera d'envoyer des PDF, et que vise la suite de ce guide.

Étape 3 : centraliser la réception dans une boîte dédiée

Tant que les commandes arrivent dans dix boîtes personnelles, aucune automatisation ne tient. Le but est de faire arriver toutes les commandes au même endroit, une adresse dédiée de type commandes@, puis de les capter automatiquement dès leur arrivée.

Le mécanisme dépend de votre messagerie. Sur Microsoft 365, le service Microsoft Graph propose des notifications de changement sur les messages d'une boîte, livrées par webhook, Azure Event Hubs ou Azure Event Grid. Ces abonnements ont une durée de vie limitée (moins de sept jours pour les messages Outlook, moins d'un jour si la notification transporte le contenu du message) et doivent être renouvelés avant expiration. Le schéma ci-dessous, issu de la documentation Microsoft Graph (Microsoft, licence CC BY 4.0), oppose ce modèle « push », où Graph envoie les changements à votre application, au suivi par requête delta, où l'application interroge Graph à intervalles réguliers.

Sur Google Workspace, l'API Gmail envoie des notifications push via Cloud Pub/Sub, après un appel à la méthode watch. Google précise qu'il faut rappeler watch au moins tous les 7 jours, et recommande de le faire une fois par jour. Google prévient aussi que, dans de rares cas, une notification peut arriver en retard ou se perdre, et conseille une vérification périodique en complément : prévoyez ce rattrapage quelle que soit la messagerie, pour qu'aucune commande ne reste sans traitement dans la boîte. Sur un serveur de messagerie classique, une relève IMAP périodique fait le même travail, avec un léger délai.

Trois règles valent quel que soit le mécanisme. Archivez l'email et le PDF d'origine tels quels, avec leur date de réception : ce sont vos preuves en cas de litige. Écartez les doublons, en comparant l'empreinte du fichier et le couple client / numéro de commande client, car un même bon revient souvent en relance. Filtrez enfin les pièces jointes qui ne sont pas des commandes : CGV, plans, logos de signature, relances.

Résultat attendu : chaque commande arrive une seule fois dans la chaîne, archivée, et chaque pièce jointe est soit identifiée comme bon de commande, soit écartée avec un motif.

Étape 4 : décider où les documents sont traités

Cette question se règle avant de choisir un outil, pas après. Un bon de commande contient des données personnelles (nom, email et téléphone de l'acheteur) et des données commerciales sensibles, à commencer par vos prix négociés. L'endroit où il est lu et analysé engage donc votre conformité au RGPD et la confidentialité de vos conditions commerciales.

Trois options se présentent. Une API cloud d'un grand fournisseur, à condition de choisir une région d'hébergement adaptée et un contrat qui encadre le traitement : certains services proposent une région européenne, comme une partie des processeurs de Google Document AI, à vérifier version par version : la documentation de Google signale que certaines versions récentes peuvent traiter les requêtes hors de la région choisie. Une solution européenne, si votre politique de données le demande. Un modèle auto-hébergé, sur vos serveurs ou chez un hébergeur de votre choix, qui garde les documents chez vous au prix d'une exploitation à assurer. Dans tous les cas, vérifiez la région et le DPA (accord de traitement des données) du fournisseur, plutôt que de vous fier à une promesse générale.

Fixez dans la foulée la durée de conservation des PDF et des données extraites, ainsi que la liste des personnes qui y ont accès.

Résultat attendu : une décision écrite de la direction, prise après avis du DPO ou du référent conformité, qui précise où les documents sont traités, combien de temps ils sont conservés et qui peut les consulter.

Étape 5 : lire le document, avec les tableaux et les scores de confiance

Tous les PDF ne se valent pas. Un PDF natif, généré par le logiciel du client, contient déjà le texte : il suffit de l'extraire. Un scan est une image, qu'il faut d'abord reconnaître caractère par caractère, avec des risques d'erreur dès que la qualité baisse. Dans les deux cas, la partie qui compte le plus est le tableau des lignes : une ligne décalée, et la quantité d'un article se retrouve sur la référence du suivant.

Plusieurs familles de briques savent faire cette lecture. Mistral OCR, proposé par l'éditeur français Mistral AI, est accessible via l'alias mistral-ocr-latest. D'après la documentation de l'OCR de Mistral, il restitue les tableaux en Markdown ou en HTML, peut extraire à part, sur option, les en-têtes et pieds de page, lit de nombreuses langues et fournit des scores de confiance par page, par bloc ou par mot. Ces scores serviront plus loin à décider ce qui part en validation humaine.

Les autres grands fournisseurs proposent des services équivalents, avec une limite commune à connaître : dans les documentations consultées, aucun ne propose de modèle prêt à l'emploi dédié aux bons de commande. Le service Azure Document Intelligence de Microsoft (API v4.0) liste des modèles préconstruits pour les factures, les reçus, les contrats ou les pièces d'identité, et renvoie pour le reste vers son modèle de mise en page (layout), des extracteurs personnalisés ou un classifieur. Google Document AI propose notamment un analyseur de factures, un analyseur de formulaires, un extracteur personnalisé et un OCR d'entreprise. Chez Amazon, la fonction AnalyzeExpense d'AWS Textract vise les factures et les reçus. Pour une commande, on passe donc par la lecture générique de la mise en page, un extracteur entraîné sur vos documents, ou un LLM.

La manipulation consiste à soumettre votre échantillon à deux ou trois de ces briques et à comparer les résultats sur ce qui compte : les tableaux de lignes, les documents multi-pages et les scans les plus dégradés. Aucun chiffre public ne remplace ce test, car la qualité dépend de vos documents.

Résultat attendu : pour chaque PDF, un texte lisible avec ses tableaux et ses scores de confiance, et une idée claire des documents qui posent problème.

Étape 6 : extraire les champs utiles dans un format imposé

Le texte lu n'est pas encore une commande. Il faut en tirer des champs précis, toujours les mêmes, quel que soit le client : c'est ce qui permet au reste de la chaîne de fonctionner sans cas particulier par mise en page.

Les modèles de langage savent aujourd'hui produire une réponse qui respecte un format décrit à l'avance. Chez OpenAI, les sorties structurées, en mode strict, garantissent une réponse conforme au JSON Schema fourni, sauf refus du modèle ou réponse interrompue, deux cas à envoyer eux aussi en validation. Chez Mistral, les annotations de documents (document_annotation) appliquent un format défini par un schéma JSON, Pydantic ou Zod au document entier, avec une consigne générale optionnelle. Voici un schéma minimal, à adapter à vos besoins :

{
  "type": "object",
  "properties": {
    "client": { "type": ["string", "null"] },
    "numero_commande_client": { "type": ["string", "null"] },
    "date_commande": { "type": ["string", "null"], "description": "Format AAAA-MM-JJ" },
    "adresse_livraison": { "type": ["string", "null"] },
    "date_livraison_souhaitee": { "type": ["string", "null"], "description": "Format AAAA-MM-JJ" },
    "lignes": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "reference": { "type": ["string", "null"] },
          "designation": { "type": ["string", "null"] },
          "quantite": { "type": ["number", "null"] },
          "unite": { "type": ["string", "null"] },
          "prix_unitaire": { "type": ["number", "null"] }
        },
        "required": ["reference", "designation", "quantite", "unite", "prix_unitaire"],
        "additionalProperties": false
      }
    }
  },
  "required": ["client", "numero_commande_client", "date_commande", "adresse_livraison", "date_livraison_souhaitee", "lignes"],
  "additionalProperties": false
}

Le détail qui compte : chaque champ accepte une valeur vide (null), et la liste des lignes peut rester vide ; une commande sans ligne lisible part directement en validation. On demande explicitement au modèle de laisser vide ce qu'il ne trouve pas, plutôt que d'inventer une référence ou une date plausible. Un champ vide se traite à l'étape de contrôle ; une valeur inventée passe inaperçue. Gardez aussi en tête qu'un format imposé garantit la forme de la réponse, pas son exactitude : c'est le rôle des deux étapes suivantes.

Résultat attendu : pour chaque bon de commande, un même objet JSON, lisible par l'ERP, avec des champs vides là où l'information manque.

Étape 7 : rapprocher avec les référentiels de l'ERP

C'est ici que se joue la qualité : aucun modèle, si performant soit-il, ne connaît vos références internes ni vos tarifs négociés. Un bon de commande parle la langue du client ; votre ERP parle la vôtre. Le rapprochement traduit l'une dans l'autre : client, article et prix doivent dire la même chose des deux côtés.

Il faut d'abord identifier le client à partir de l'adresse de l'expéditeur, du SIRET ou du numéro de compte imprimé sur le document. Il faut ensuite traduire les références client en références internes, grâce à la table de correspondance citée dans les prérequis : c'est souvent le chantier le plus long, et le plus rentable. Viennent enfin les contrôles commerciaux : le prix unitaire comparé au tarif négocié, l'unité et le conditionnement (un carton de 12 commandé comme 12 unités, ou l'inverse).

Une règle ne souffre aucune exception : une référence inconnue ou un écart de prix n'est jamais corrigé en silence. La chaîne le signale, avec son motif, et un humain tranche.

Résultat attendu : chaque ligne est soit rapprochée d'un article et d'un prix connus, soit marquée avec la raison précise de l'écart.

Étape 8 : contrôler, puis faire valider par l'ADV ce qui doit l'être

Le but est de décider, commande par commande, si elle peut passer seule ou si elle doit être vue par quelqu'un. Deux familles de signaux s'additionnent. Les règles métier : totaux cohérents, quantités plausibles au regard de l'historique du client, prix hors tolérance, client bloqué ou en dépassement d'encours. Les scores de confiance issus de la lecture, qui aident à repérer un champ probablement mal reconnu, même quand il semble valide.

Chaque commande part alors dans l'une de deux voies : la validation automatique ou la file de validation. Dans cette file, l'écran affiche le PDF d'origine à côté des champs extraits, avec les écarts mis en évidence, pour que l'ADV corrige les seuls champs en cause au lieu de tout ressaisir.

Commencez à 100 % de validation humaine. Les premières semaines servent à mesurer, pas à gagner du temps. Ouvrez ensuite la validation automatique client par client, quand les chiffres le justifient : par exemple après un nombre de commandes consécutives sans retouche que vous fixez avec l'ADV.

Résultat attendu : une file de validation où chaque commande arrive avec son PDF, ses champs et le motif de son passage, et une liste de clients autorisés en validation automatique qui s'allonge à mesure que la confiance s'établit.

Étape 9 : créer la commande dans l'ERP et confirmer au client

Une fois validée, la commande doit entrer dans l'ERP sans ressaisie, ce qui suppose de se connecter à l'API de l'ERP. Au départ, créez-la de préférence en brouillon ou en devis : l'ADV garde la main sur la confirmation pendant la phase de rodage.

Prenons l'exemple d'Odoo 19. Son API externe JSON-2 s'appelle par une requête HTTP POST sur une adresse de la forme /json/2/<model>/<method>, authentifiée par une clé d'API. Cette clé se crée depuis les préférences de l'utilisateur, rubrique sécurité du compte, avec une description et une durée de validité obligatoires. Cette durée ne peut pas dépasser trois mois : la clé d'une automatisation permanente doit donc être renouvelée au moins une fois par trimestre et conservée de façon sécurisée, avec un rappel avant expiration pour que la chaîne ne s'arrête pas sans prévenir. Utilisez un compte technique dédié, limité aux droits nécessaires.

Deux points de vigilance figurent dans la même documentation. Les anciennes API XML-RPC et JSON-RPC (adresses /xmlrpc, /xmlrpc/2 et /jsonrpc) sont dépréciées et leur suppression est prévue avec Odoo 22, annoncé pour l'automne 2028 : un nouveau projet doit partir sur JSON-2. Surtout, l'accès à l'API externe est réservé aux formules Odoo Custom et n'est pas disponible sur les formules One App Free ou Standard. Vérifiez votre abonnement avant de concevoir l'intégration. Dans Odoo, la commande de vente correspond au modèle sale.order, qui reste à l'état de devis tant qu'elle n'est pas confirmée. Pour un autre ERP, la logique est la même : API documentée, connecteur ou import de fichiers.

Une garantie est indispensable : une même commande ne doit jamais être créée deux fois. Avant chaque création, la chaîne vérifie qu'aucune commande n'existe déjà pour le couple client et numéro de commande client, celui qu'on retrouve en général dans le champ référence client de la commande. Cette vérification et la création doivent former une seule opération, ou être réservées à un seul traitement à la fois : sinon, deux traitements lancés en même temps sur le même email peuvent conclure chacun que la commande n'existe pas encore. Rattachez ensuite le PDF d'origine à la commande créée, puis déclenchez l'accusé de réception au client.

Résultat attendu : une commande présente une seule fois dans l'ERP, avec son PDF attaché, et un client qui reçoit sa confirmation sans attendre la saisie du lendemain.

Étape 10 : mesurer, corriger, élargir

Une chaîne d'automatisation des processus métier ne se règle pas une fois pour toutes. Le but de cette dernière étape est d'en faire un outil qui s'améliore avec l'usage. Quelques indicateurs suffisent, à comparer au point de départ de l'étape 1 :

• la part des commandes validées sans retouche, au global et par client ;
• les champs les plus souvent corrigés, qui désignent la prochaine règle à écrire ;
• le délai entre la réception de l'email et la création de la commande ;
• le nombre de litiges liés à une erreur de saisie.

Chaque correction de l'ADV est une information : une référence client inconnue rejoint la table de correspondance, un écart de prix récurrent révèle un tarif à mettre à jour, une erreur de lecture répétée sur un client justifie un réglage dédié.

Une part du travail restera manuelle, et c'est normal : les commandes manuscrites, les modifications de commande envoyées par email libre (« finalement, doublez la quantité de la ligne 3 »), les conditions particulières négociées au téléphone. L'objectif n'est pas zéro intervention, mais une ADV qui consacre son temps aux cas qui demandent vraiment son jugement.

Vérifier que la chaîne tient

Avant d'ouvrir la validation automatique au moindre client, rejouez l'échantillon de départ dans la chaîne complète et contrôlez quelques comportements simples. Chaque PDF de commande doit donner exactement une commande en devis ou un élément dans la file de validation, jamais les deux, jamais aucun. Renvoyer le même email ne doit créer aucun doublon. Une référence inconnue, un prix hors tolérance ou un champ vide doivent toujours aboutir dans la file, avec leur motif. Enfin, l'ADV doit pouvoir retrouver en un clic le PDF d'origine depuis n'importe quelle commande créée.

Si ces quatre comportements tiennent sur votre échantillon, les indicateurs de l'étape 10 prennent le relais en production.