Extraire les données d'un bon de commande avec l'IA

Un bon de commande se lit comme une facture à l'envers : au lieu de dire « voici ce que vous devez », il dit « voici ce que je veux, quand et où ». L'extraction vise donc l'identité des deux parties, la référence de la commande, l'adresse et la date de livraison, et surtout les lignes (référence article, désignation, quantité, unité, prix). Les modèles prédéfinis de factures savent lire les bons de commande ; pour les formats particuliers, un schéma JSON imposé à un grand modèle de langage convient. Page mise à jour le 15/11/2026.

Ce qui distingue un bon de commande d'une facture

• Les références article comptent plus que les désignations. La désignation varie (« vis 6x40 » ou « VIS INOX 6 x 40 mm ») ; la référence fournisseur ou client sert à rapprocher la ligne de votre catalogue.
• Les quantités sont lues avec leur unité : pièce, carton, mètre, kilo. Une quantité sans unité est une source d'erreurs d'approvisionnement.
• Les dates de livraison peuvent être par ligne, pas seulement pour la commande entière.
• Les prix peuvent être absents : beaucoup de bons de commande internes n'en portent pas. Le champ doit pouvoir valoir null.
• Deux numéros coexistent : celui du bon de commande de l'acheteur, et celui de l'accusé du fournisseur. Ne les mélangez pas dans un seul champ.

Ce que lisent les services

Azure Document Intelligence. Microsoft indique que son modèle facture analyse les factures, les factures de services, les commandes clients (sales orders) et les bons de commande (purchase orders), pour 27 langues, avec photos, scans et PDF numériques. Les champs d'en-tête et de lignes sont renvoyés en JSON. Limites de fichier : 2 000 pages par PDF, 500 Mo en offre payante.

Google Document AI. La liste officielle des processeurs ne contient pas de processeur dédié aux bons de commande. L'Invoice Parser est présenté comme le plus proche : il extrait les champs d'en-tête et de lignes, dont un champ de bon de commande, en 12 langues dont le français. Pour des modèles de documents propres à votre entreprise, le Custom Extractor existe, mais son mode génératif n'est officiellement pris en charge qu'en anglais.

Un grand modèle de langage avec schéma. Pour un format de client très spécifique (tableau sur plusieurs pages, mise en page d'un ERP maison), un schéma strict est souvent plus rapide à construire qu'un modèle personnalisé. Comparatif des approches : LLM ou modèle spécialisé.

Le schéma d'un bon de commande

Un exemple de structure, à adapter. Les montants sont des chaînes recopiées telles quelles, pour éviter toute approximation ; vous les convertissez ensuite :

{
  "numero_commande": "string",
  "date_commande": "date | null",
  "acheteur_nom": "string",
  "fournisseur_nom": "string",
  "adresse_livraison": "string | null",
  "date_livraison_souhaitee": "date | null",
  "devise": "string | null",
  "lignes": [
    {
      "reference": "string | null",
      "designation": "string",
      "quantite": "number",
      "unite": "string | null",
      "prix_unitaire": "string | null",
      "date_livraison_ligne": "date | null"
    }
  ],
  "total": "string | null"
}

Les principes (champs nullables, un champ par information, descriptions écrites comme des consignes) sont détaillés dans schéma JSON d'extraction. Avec les sorties structurées d'Anthropic, rappelons que bornes numériques et longueurs de chaîne ne sont pas prises en charge dans le schéma : le contrôle « quantité positive » se fait dans votre code.

Les contrôles avant l'envoi à l'ERP

1. Arithmétique : quantité × prix unitaire = montant de la ligne, somme des lignes = total, quand ces champs existent.
2. Référentiel : la référence existe-t-elle dans votre catalogue ? Le client est-il connu ?
3. Unités : l'unité de la ligne est-elle compatible avec celle de la fiche article ?
4. Doublons : le numéro de commande a-t-il déjà été enregistré ? Un même bon envoyé deux fois par courriel est fréquent.
5. Rapprochement : la commande se compare ensuite au bon de livraison et à la facture. C'est un rapprochement à trois, qui se code sur les références et les quantités.

Un bon de commande qui échoue à un contrôle part en relecture humaine : voir seuil de confiance et validation. Mesurez la lecture de chaque champ sur 50 à 100 de vos bons avant de brancher l'ERP : mesurer la précision.

Order-X : quand le bon de commande est déjà structuré

Comme la facture a Factur-X, la commande a un format hybride : Order-X, un PDF qui embarque un XML. La bibliothèque Python factur-x le gère : elle sait extraire le XML d'un PDF Order-X, le contrôler et en générer, pour certains types de messages (commande, modification de commande, réponse à commande, d'après son historique de versions). Si certains de vos clients envoient de l'Order-X, lisez le XML : aucune extraction n'est nécessaire. La démarche est la même que pour les factures : lire le XML d'une Factur-X.

Et pour des milliers de bons ?

Quand les commandes arrivent par centaines, le flux (réception par courriel, file d'attente, reprise sur erreur) compte autant que le modèle : voir extraction par lots. Pour la partie facture de la même chaîne, voir le comparatif des API d'extraction de factures.