Automatiser le traitement des commandes reçues par email : du message à l'ERP en moins de 2 minutes

La boite email de votre équipe ADV est probablement votre premier système de commandes. Pas SAP. Pas votre portail client. Votre boite Outlook.

C'est là qu'arrivent 60 à 70% des commandes B2B réelles dans une entreprise industrielle marocaine. Un acheteur qui envoie un Excel en pièce jointe. Un client qui écrit les détails dans le corps du message. Un grand compte qui joint son bon de commande PDF officiel. Un contact qui répond à un fil de discussion vieux de trois jours pour confirmer une quantité. Tous ces emails atterrissent dans la même boite. Tous attendent qu'un opérateur ADV les ouvre, les lise, les interprète, ouvre SAP, ressaisisse les données, et envoie une confirmation manuelle.

Ce flux n'est ni optimisé ni instrumenté. Il n'apparait dans aucun tableau de bord opérationnel. Il ne génère aucune alerte quand un email attend depuis 4 heures sans traitement. Et pourtant, il est le canal dominant des commandes dans la quasi-totalité des entreprises industrielles marocaines.

Cet article décrit exactement comment automatiser ce flux de bout en bout. Du message entrant à la commande créée dans SAP, en moins de 2 minutes, sans intervention humaine sur le flux standard.

Anatomie d'une commande par email : les cinq formats réels

Avant de concevoir une automatisation, il faut cartographier ce qui arrive réellement dans la boite email ADV. Il y a cinq formats distincts, et chacun pose un problème technique différent.

Le premier format est l'email avec bon de commande PDF en pièce jointe. C'est le cas le plus structuré. Le client a un ERP ou un logiciel de gestion qui génère un document PDF normalisé. La mise en page est fixe, les champs sont identifiables, la qualité du fichier est haute. C'est le cas le plus simple à traiter et le moins fréquent dans la réalité du terrain marocain.

Le deuxième format est l'email avec tableau Excel en pièce jointe. Le client gère ses commandes dans un fichier Excel personnel, souvent différent d'une commande à l'autre, avec des colonnes renommées, des lignes de totaux mélangées aux lignes produits, des onglets multiples dont le bon est à identifier. C'est un format que l'OCR ne traite pas du tout, et que l'IA documentaire standard traite mal.

Le troisième format est l'email en texte libre. Le corps du message contient toutes les informations nécessaires à la création de la commande : "Bonjour, besoin de 30 cartons ref 4402 et 15 palettes ref 7801 pour livraison jeudi à l'entrepot Ain Sebaa, merci de confirmer." Aucune pièce jointe. Aucune structure. Un texte conversationnel que seul un agent LLM peut interpréter correctement.

Le quatrième format est l'email avec image scannée. Le bon de commande existe sur papier, il a été signé et tamponné, puis photographié ou scanné et envoyé en pièce jointe JPEG ou PDF image. La qualité de numérisation est variable. Il peut y avoir des annotations manuscrites en marge. C'est le format le plus difficile à traiter et l'un des plus fréquents dans les secteurs de la construction et de la distribution régionale.

Le cinquième format est la confirmation dans une chaine d'emails. La commande réelle est dans une réponse à un fil de discussion existant, au milieu d'échanges relationnels. "Ok pour les quantités, tu peux lancer." Sans contexte du fil, cette phrase ne signifie rien. Avec le contexte, elle est une commande complète. Seul un agent qui lit la chaine entière peut la traiter correctement.

Un système qui ne couvre pas ces cinq formats ne couvre pas la réalité du terrain marocain. Il automatise une fraction du flux et laisse le reste en traitement manuel.

Le workflow automatisé complet : étape par étape

Pour automatiser les commandes reçues par email et les pousser dans un ERP, le flux standard comprend les étapes suivantes.

Etape 1 : Réception et classification. L'email arrive dans une boite dédiée aux commandes, ou dans la boite générale de l'ADV. L'agent lit l'email entrant et détermine sa nature : commande, demande de prix, réclamation, email relationnel. Cette classification est la première décision du système. Elle n'est pas basée sur des mots-clés prédéfinis mais sur la compréhension du contenu. Un email qui dit "tu peux m'envoyer un prix pour 50 unités ?" est une demande de prix. Un email qui dit "validé pour 50 unités, tu peux préparer" est une commande.

Etape 2 : Extraction des données. Une fois l'email identifié comme commande, l'agent extrait les champs nécessaires à la création de la commande SAP. Client, référence produit, quantité, unité, délai souhaité, adresse de livraison, conditions particulières mentionnées. L'extraction s'adapte au format : texte, PDF, Excel, image, chaine de messages. Le champ source est tracé pour chaque donnée extraite.

Etape 3 : Validation contre le référentiel SAP. Chaque champ extrait est validé contre les données de référence de l'entreprise. Le client existe dans SAP et est actif. La référence produit est présente dans le catalogue et disponible. Le prix implicite ou mentionné correspond à la grille tarifaire applicable à ce client. L'adresse de livraison est rattachée au bon compte client. Cette validation est automatique et prend moins de 3 secondes.

Etape 4 : Décision et action. Si tous les champs sont validés avec un niveau de confiance suffisant, la commande est créée directement dans SAP. Si un ou plusieurs champs sont ambigus ou invalides, l'agent isole ces champs spécifiques et génère une notification interne pour l'opérateur ADV. La notification contient uniquement les éléments en question, pas la commande entière à ressaisir.

Etape 5 : Confirmation client. Qu'il y ait eu intervention humaine ou non, une confirmation est envoyée automatiquement au client une fois la commande créée : numéro de commande, récapitulatif des lignes confirmées, date de livraison prévue. Le client reçoit une réponse dans les 2 minutes suivant son email, quelle que soit l'heure à laquelle il a envoyé sa commande.

Ce workflow traite une commande standard en 45 secondes à 2 minutes selon la complexité du document source. Il fonctionne 24 heures sur 24, 7 jours sur 7, sans pic de charge en fin de mois.

Les cas ambigus : comment le système décide

C'est le point où les systèmes simples s'arretent et où les agents font la différence. Les cas ambigus ne sont pas rares. Ils représentent 3 à 7% du flux réel selon le profil de clientèle. Voici trois cas concrets et le comportement attendu d'un système correctement conçu.

Premier cas : le client commande une référence obsolète. La référence "4402-B" a été remplacée dans le catalogue par la référence "4402-C" il y a deux mois. Le client n'a pas mis à jour ses bons de commande internes. L'agent identifie que "4402-B" n'existe plus dans le catalogue actif. Il identifie la référence de remplacement désignée dans le système. Il génère une exception avec les deux références, la raison de la substitution proposée, et soumet la décision à l'opérateur ADV. Il ne crée pas la commande sur une référence inexistante, et il ne rejette pas la commande sans proposition de solution.

Deuxième cas : la commande arrive d'un email non répertorié. Un nouveau contact chez un client existant envoie une commande depuis son adresse email personnelle, non encore enregistrée dans SAP. L'agent identifie le domaine email de l'expéditeur, fait le lien avec le compte client correspondant dans la base, crée la commande sous le bon compte client, notifie le commercial responsable du compte pour qu'il enregistre le nouveau contact, et confirme la réception au client. La commande n'est pas bloquée parce que l'expéditeur est nouveau.

Troisième cas : la quantité commandée dépasse le stock disponible. Le client commande 200 cartons d'une référence dont le stock disponible est de 140 cartons. L'agent ne rejette pas la commande et ne la crée pas pour 200 cartons avec un problème caché. Il crée une commande ferme pour 140 cartons sur le stock disponible, génère automatiquement un back-order pour les 60 cartons manquants avec la date de réapprovisionnement prévue, et envoie deux confirmations distinctes au client : livraison immédiate sur 140 cartons, livraison différée sur 60 cartons à la date de réapprovisionnement.

Ces trois comportements partagent une logique commune : l'agent ne bloque pas et ne laisse pas passer une erreur. Il propose une résolution ou isole le problème pour qu'un humain le traite en contexte complet.

Ce que gagne l'équipe ADV concrètement

Le changement n'est pas quantitatif. Il est qualitatif sur la nature du travail réalisé.

Avant automatisation, chaque email commande suit le même cycle. L'opérateur ouvre l'email, lit le contenu, identifie qu'il s'agit d'une commande, ouvre SAP, ressaisit les données champ par champ, vérifie la cohérence, sauvegarde, retourne sur l'email, envoie une confirmation manuelle. Sur une commande standard sans complication, cette séquence prend entre 8 et 12 minutes. Sur une commande avec une anomalie, une référence à vérifier ou un client avec des conditions particulières, elle en prend 20 à 30.

Après automatisation, 93 à 97% des commandes entrant par email passent dans SAP sans aucune intervention humaine. L'opérateur ADV traite les exceptions, en moyenne 30 secondes par exception, avec le contexte complet sous les yeux. Il ne ressaisit rien. Il décide sur les cas qui méritent une décision humaine.

Le résultat opérationnel direct est le suivant. Une équipe ADV de deux personnes gère le volume qui nécessitait quatre personnes sans automatisation. Non pas parce que les deux personnes restantes travaillent plus vite, mais parce que 95% du volume de travail mécanique a disparu. Les deux personnes restantes font un travail différent : elles gèrent les exceptions, les relations clients complexes, et les cas qui nécessitent un jugement humain réel.

Intégration technique : ce qu'il faut et ce qu'il ne faut pas

La question technique la plus fréquente dans les réunions de pré-déploiement est celle-ci : qu'est-ce qu'il faut toucher dans notre infrastructure ?

La réponse est simple. Il n'est pas nécessaire de modifier SAP. Il n'est pas nécessaire de déployer une nouvelle infrastructure serveur. Il n'est pas nécessaire d'ouvrir des accès ERP complexes ou de lancer un projet d'intégration de 6 mois.

L'intégration avec SAP se fait via l'API standard existante ou via un connecteur certifié. L'agent dispose d'un accès en lecture sur les référentiels nécessaires, catalogue produits, base clients, grilles tarifaires, et d'un accès en écriture sur le module de création de commandes. C'est un périmètre d'accès étroit, auditable, et révocable à tout moment.

Le déploiement sur un flux email commande homogène, c'est-à-dire un ensemble de clients avec des formats documentaires relativement stables, prend entre 3 et 4 semaines. La première semaine est consacrée à la cartographie des formats entrants et à la configuration des règles de validation. Les deux semaines suivantes au déploiement en mode observation, où l'agent traite les commandes en parallèle de l'équipe ADV et les résultats sont comparés. La quatrième semaine est le basculement en production avec supervision.

Les données restent dans l'environnement de l'entreprise. Le déploiement est possible en cloud privé ou on-premise selon les exigences de sécurité de l'organisation.

Conclusion

La boite email de votre ADV n'est pas un canal de communication. C'est un système de commandes non structuré qui traite 60 à 70% de votre flux entrant sans aucune instrumentation, sans aucune traçabilité automatique, et avec un cout en temps et en erreurs que personne dans l'organisation n'a jamais consolidé parce qu'il est invisible dans les reportings standard.

Automatiser ce flux est la décision avec le meilleur rapport impact sur délai de déploiement disponible aujourd'hui pour une entreprise industrielle marocaine. Le volume traité est immédiatement visible. Le gain de temps est mesurable dès la première semaine. Les erreurs disparaissent structurellement, pas progressivement.

Le seul prérequis est de décider que la boite email ADV mérite la même attention opérationnelle que l'ERP qui se trouve en aval.

Prochaine étape

Voir une démonstration sur vos propres emails de commandes.