Commandes reçues par mail : comment un agent IA les saisit dans l'ERP sans tout casser

Beaucoup de commandes B2B arrivent encore par mail : PDF de revendeur, tableur de distributeur, corps de message d'un concessionnaire, bon scanné pris sur un salon. Un agent IA peut les pré-saisir dans l'ERP, à condition d'être construit comme un processus contrôlé, pas comme un modèle à qui l'on fait confiance. Voici l'architecture que nous recommandons, étape par étape, avec les contrôles qui évitent qu'une erreur parte en production.

Le principe : l'IA lit, votre système décide

Un modèle de langage est très bon pour lire un document mal structuré et en extraire des informations. Il n'est pas fait pour décider seul qu'une ligne est juste. L'architecture sépare donc les rôles :

1. Extraction : le modèle transforme le mail et ses pièces jointes en données structurées.
2. Rapprochement : du code classique compare ces données à votre référentiel clients et articles.
3. Contrôles : des règles métier vérifient la cohérence (prix, quantités, conditionnements, délais).
4. Décision : un score de confiance oriente la commande vers la saisie directe ou vers une validation humaine.
5. Intégration : la commande est écrite dans l'ERP par un canal maîtrisé.
6. Suivi : chaque correction humaine est enregistrée et sert à améliorer le système.

Le modèle n'intervient qu'à l'étape 1, et éventuellement pour proposer des correspondances à l'étape 2. Tout le reste est déterministe, testable et auditable.

Étape 1 : extraire le contenu du mail et des pièces jointes

Les formats reçus sont variés : PDF généré par l'ERP du client, PDF scanné, Excel, Word, texte libre, parfois un EDI partiel complété par un mail. Il faut d'abord normaliser :

• PDF natif : extraction du texte et de la structure des tableaux.
• PDF scanné ou photo : OCR, ou modèle multimodal capable de lire l'image directement.
• Tableur : lecture directe des cellules, sans passer par le modèle quand les colonnes sont identifiables.
• Corps de mail : texte brut, en retirant signatures et historique de conversation.

Le modèle reçoit ensuite ce contenu avec une consigne précise et un schéma de sortie imposé. La plupart des API de modèles récents permettent de contraindre la réponse à un schéma JSON, ce qui évite de parser du texte libre.

{
  "type_document": "commande | modification_commande | demande_prix | autre",
  "client": { "raison_sociale": "string", "numero_client_indique": "string|null" },
  "reference_commande_client": "string|null",
  "date_livraison_souhaitee": "YYYY-MM-DD|null",
  "adresse_livraison": "string|null",
  "lignes": [
    {
      "ref_client": "string|null",
      "ref_fournisseur": "string|null",
      "designation": "string",
      "quantite": "number",
      "unite": "string|null",
      "prix_unitaire_indique": "number|null",
      "attributs": { "taille": "string|null", "coloris": "string|null", "personnalisation": "string|null" }
    }
  ],
  "langue": "fr | en | de | es | it | ...",
  "remarques": "string|null"
}

Trois points de conception comptent :

• Le champ type_document. Une demande de modification ou d'annulation n'est pas une nouvelle commande. Si l'agent ne les distingue pas, vous créerez des doublons.
• Les valeurs null autorisées. Il faut explicitement permettre au modèle de dire « je ne sais pas ». Sinon il complète, et c'est là que naissent les erreurs silencieuses.
• La langue. Les commandes de distributeurs étrangers sont traitées par le même flux ; seule la désignation varie. Le rapprochement se fait sur les références, pas sur le texte traduit.

Étape 2 : rapprocher avec le référentiel articles et clients

C'est l'étape qui décide de la fiabilité. Une commande est rarement écrite avec vos codes articles : le client utilise ses propres références, une ancienne désignation, un libellé approximatif. Pour les grands comptes, chaque catalogue client a souvent ses propres codes.

Nous procédons en cascade, du plus sûr au moins sûr :

1. Correspondance exacte sur votre référence fournisseur si elle est présente.
2. Table de correspondance client : référence du client vers votre référence. C'est l'actif le plus précieux du projet. Si elle n'existe pas, l'agent la construit progressivement : chaque validation humaine d'une correspondance l'enrichit.
3. EAN ou code interne s'ils figurent sur le document.
4. Recherche approchée sur la désignation (similarité textuelle et sémantique) parmi les articles actifs, filtrée par la gamme habituelle du client.
5. Proposition du modèle parmi une liste restreinte de candidats, jamais parmi tout le catalogue.

Chaque ligne reçoit un statut : exacte, table_client, approchee, non_trouvee. Seuls les deux premiers statuts peuvent être saisis sans relecture.

Même logique pour le client : on identifie le compte par l'adresse d'expédition du mail, puis le numéro client, puis la raison sociale. Un mail d'un nouvel expéditeur ou d'un compte bloqué part toujours en validation.

Cas particuliers fréquents à traiter explicitement :

• Variantes : taille, pointure, coloris, finition. Un « noir 42 » mal lu devient un « noir 43 ». Le couple article et variante doit exister dans l'ERP, sinon validation.
• Personnalisations : broderie, gravure, marquage. Elles relèvent souvent d'une ligne ou d'une option à part, avec des règles propres. Validation humaine systématique au début.
• Conditionnements : le client commande « 3 cartons », vous gérez à l'unité. La conversion doit venir de votre référentiel, pas du modèle.

Étape 3 : les contrôles métier

Une fois les lignes rapprochées, des règles simples attrapent la plupart des erreurs restantes. Elles sont écrites en code, versionnées, et chaque échec est expliqué à la personne qui valide.

controles:
  - id: quantite_multiple_conditionnement
    regle: "quantite % article.conditionnement == 0"
    si_echec: validation
  - id: quantite_hors_habitude
    regle: "quantite <= 3 * moyenne_12_mois(client, article)"
    si_echec: validation
  - id: ecart_prix
    regle: "prix_unitaire_indique is null or abs(prix_indique - prix_tarif_client) / prix_tarif_client < 0.02"
    si_echec: validation
  - id: article_actif
    regle: "article.statut == 'actif'"
    si_echec: validation
  - id: doublon
    regle: "not exists(commande where client == c and reference_commande_client == ref)"
    si_echec: blocage
  - id: delai_faisable
    regle: "date_livraison_souhaitee is null or date_livraison_souhaitee >= today + article.delai_standard"
    si_echec: alerte

Les seuils (3 fois la moyenne, 2 % d'écart de prix) sont des exemples à calibrer sur votre historique. Le contrôle de doublon est indispensable : un même bon de commande est souvent renvoyé par mail « pour confirmation ».

Étape 4 : seuils de confiance et validation humaine

La commande obtient un score global qui combine la confiance de l'extraction, le statut de rapprochement de chaque ligne et le résultat des contrôles. Plutôt qu'un score opaque, nous recommandons une règle lisible :

• Saisie directe (à terme) : client identifié, toutes les lignes en exacte ou table_client, aucun contrôle en échec.
• Validation rapide : une à deux lignes douteuses, signalées en couleur ; la personne ne vérifie que ces lignes.
• Traitement manuel : document non reconnu, client inconnu, personnalisation, ou plus de N lignes douteuses.

L'écran de validation fait la moitié du succès. Il doit montrer côte à côte le document d'origine et la commande proposée, surligner la zone du PDF d'où vient chaque valeur, afficher la raison de chaque alerte, et permettre de corriger une correspondance en un clic, correction qui alimente la table client.

Au démarrage, tout passe en validation, y compris ce qui serait éligible à la saisie directe. Pendant quelques semaines, vous mesurez le taux de correction par catégorie. Vous n'ouvrez la saisie directe que pour les catégories où ce taux est durablement nul, client par client si nécessaire.

Étape 5 : l'intégration dans l'ERP

Trois options, par ordre de préférence :

1. API de l'ERP : création de la commande par appel, avec retour immédiat des erreurs (article bloqué, encours dépassé). C'est l'option la plus robuste.
2. Import de fichier : dépôt d'un fichier au format d'import de l'ERP, traité par un job planifié. Fiable, mais le retour d'erreur est différé : il faut lire le compte rendu d'import.
3. Automatisation de l'interface (RPA) : à éviter sauf dernier recours, car fragile à chaque mise à jour de l'ERP.

Quelle que soit l'option, deux règles :

• Créer la commande dans un état « à valider » ou dans un journal d'attente, plutôt que directement en commande ferme, tant que la saisie directe n'est pas ouverte.
• Donner au connecteur un compte technique aux droits limités : création de commandes clients, rien d'autre. Toutes ses écritures sont tracées avec l'identifiant du mail source.

Étape 6 : les indicateurs de suivi

Sans mesure, impossible de savoir si l'agent fait gagner du temps ou en déplace. Suivez chaque semaine :

• Nombre de commandes traitées par l'agent, et part de chaque statut (directe, validation rapide, manuel).
• Taux de correction par ligne : lignes modifiées par l'humain divisées par lignes proposées.
• Erreurs découvertes après saisie (retours, avoirs liés à une erreur de saisie).
• Temps moyen de validation par commande.
• Taille de la table de correspondance client, qui doit croître puis se stabiliser.

Les pièges que nous voyons le plus souvent

• Laisser le modèle choisir l'article dans tout le catalogue. Il trouvera toujours quelque chose de plausible. Restreignez les candidats.
• Ignorer les mails qui ne sont pas des commandes. Relances, modifications, questions : il faut les classer, pas les saisir.
• Faire calculer les prix par le modèle. Les prix viennent de l'ERP ; le modèle ne fait que lire le prix indiqué pour le comparer.
• Oublier les pièces jointes multiples. Un mail peut contenir deux bons de commande, ou un bon et des conditions générales.
• Négliger la sécurité. Un mail est une entrée non fiable : le contenu d'une pièce jointe ne doit jamais pouvoir modifier les consignes de l'agent ni déclencher autre chose qu'une proposition de commande.

La même architecture pour d'autres documents

Ce schéma extraction, rapprochement, contrôles, seuil de confiance, validation humaine ne se limite pas aux commandes. Il s'applique à tout flux de documents entrants à ressaisir : bons de livraison, factures fournisseurs, demandes de pièces détachées, documents clients à intégrer, et jusqu'à la production comptable à grande échelle dans un cabinet. Dans tous ces cas, la fiabilité vient moins du modèle choisi que de l'architecture autour : référentiel de rapprochement, règles de contrôle et seuils qui décident de ce qu'un humain doit voir.

Par où commencer

1. Extrayez trois mois de commandes reçues par mail avec leur saisie finale dans l'ERP : c'est votre jeu de test, avec la bonne réponse connue.
2. Mesurez la qualité de votre référentiel : part des articles avec une référence client connue, doublons de libellés, articles inactifs encore commandés.
3. Vérifiez le canal d'écriture : l'ERP a-t-il une API ou un format d'import de commandes ? Qui peut créer le compte technique ?
4. Démarrez sur un périmètre restreint (quelques clients à fort volume et formats réguliers) en validation humaine systématique.
5. Ouvrez la saisie directe catégorie par catégorie, uniquement quand le taux de correction mesuré le justifie.

Nous concevons et mettons en production des agents IA métier pour les PME et ETI industrielles, de l'extraction jusqu'à l'intégration ERP. Si vous voulez en parler : [email protected]