Vous pouvez avoir raccordé vos plus gros clients en EDI et continuer à ressaisir des commandes tous les jours. Les bons de commande arrivent par mail, les PDF s'accumulent dans la boîte de l'ADV, les tableaux Excel doivent encore être repris dans l'ERP. Ce n'est pas un échec de l'EDI. C'est simplement le flux qu'il ne couvre pas.
EDI et IA ne traitent pas le même flux
L'EDI est fait pour un échange déjà organisé entre deux entreprises. Les deux systèmes doivent s'entendre sur le format de la commande, les références articles et les règles de circulation du flux. Quand ce travail est en place, il n'y a plus de document à interpréter ni de ligne à ressaisir. C'est précisément sa force.
La fausse question est donc : « IA ou EDI ? » La bonne est : que faire des commandes qui restent hors EDI ?
Mais une commande rédigée dans un mail, envoyée en PDF ou jointe dans un fichier Excel n'arrive pas dans ce cadre. Elle arrive telle que le client travaille. Le sujet n'est plus de faire circuler une donnée structurée. Il faut d'abord lire le document, retrouver les références, puis préparer la commande dans l'ERP.
C'est là qu'un agent de traitement des commandes intervient. Il ne remplace pas un flux EDI en production. Il traite les commandes qui n'y entrent pas.
La différence tient en une phrase : l'EDI structure le flux en amont ; l'agent travaille avec le flux tel qu'il existe déjà.
| EDI | Traitement des commandes reçues par mail | |
| Prérequis | Un accord et un raccordement avec le client | Un accès à la boîte mail concernée et au référentiel articles |
| Formats | Ceux définis entre les deux parties | Mail, PDF, Excel, photo ou message texte |
| Rôle | Faire circuler un flux déjà structuré | Lire, extraire et préparer ce qui ne l'est pas |
| Place dans le système | Les comptes déjà raccordés | Les commandes reçues autrement, dans le même ERP |
Pourquoi l'EDI ne couvre pas tout
Un raccordement EDI ne se décide pas seul. Il suppose un accord avec le client, un projet et des ressources des deux côtés. Cela le réserve naturellement aux comptes dont les volumes et la régularité justifient cet effort. Le reste du portefeuille ne cesse pas pour autant de commander.
Ces clients continuent d'écrire un mail, d'envoyer un bon de commande en PDF ou de reprendre une offre dans un tableau Excel. Ce n'est pas un manque de discipline. C'est leur manière de travailler.
La question n'est donc pas de savoir si l'EDI est bon. Elle est de savoir ce que vous faites de la part du flux qu'il ne prend pas en charge.
Que faire de ce qui reste hors EDI ?
Le pire réflexe serait de considérer ce flux comme un résidu inévitable. C'est souvent là que les équipes ADV passent leur temps : ouvrir les pièces jointes, relire les lignes, retrouver les codes articles et créer la commande dans l'ERP. Le traitement des commandes reçues par mail part de cette réalité.
L'agent lit le format envoyé par le client, extrait les lignes, les rapproche du référentiel articles et prépare la commande. Les cas douteux peuvent être validés par un humain avant la suite du traitement.
Le changement est très concret pour l'équipe. Elle ne passe plus son temps à retranscrire. Elle contrôle les exceptions, traite les litiges et revient vers les clients lorsque son intervention est réellement utile.
Ce n'est pas une promesse de remplacer l'ADV. C'est une manière de réserver son attention à ce que le flux automatisé ne sait pas trancher seul.
Peut-on faire fonctionner les deux ensemble ?
Oui. C'est même la bonne façon de poser le sujet. Les clients déjà raccordés continuent de commander en EDI. Les autres envoient leurs commandes par les canaux qu'ils utilisent déjà. Les deux flux alimentent le même ERP, sans demander à un client raccordé de changer de canal ni à un client non raccordé de lancer un projet EDI.
La frontière ne se décide pas sur une préférence technique. Elle suit l'histoire commerciale et opérationnelle de chaque compte : ceux avec lesquels un flux est déjà structuré, et ceux qui commandent encore par mail.
Cette approche évite le faux choix entre moderniser l'existant et traiter le reste. L'EDI conserve sa place. Le traitement des commandes par mail complète ce qu'il laisse hors de son périmètre.
Même avec un CRM ou un ERP en place, les commandes reçues par mail peuvent rester hors du circuit automatisé. Le sujet n'est pas de remplacer le système en place, mais de relier ce qui arrive encore dans la boîte mail au reste du traitement.
Par où commencer ?
Ne commencez pas par compter le nombre de clients que vous pourriez raccorder en EDI. Commencez par regarder le travail qui existe déjà hors EDI. Trois indicateurs suffisent pour poser le diagnostic :
- Le nombre de commandes reçues par mail sur un mois.
- Le nombre de clients qui les envoient, pour savoir si le flux est concentré ou diffus.
- Le temps qui s'écoule entre la réception d'une commande et sa création dans l'ERP.
Ils montrent où se trouve réellement la saisie. Ils permettent aussi de choisir un premier flux précis, plutôt que de lancer un projet trop large.
Il est généralement plus logique de commencer par la commande que par l'accusé de réception. Tant que la commande n'est pas correctement capturée, automatiser l'étape suivante ne fait que déplacer le problème. Une fois le flux entrant traité, l'accusé de réception peut s'appuyer sur une commande créée sans ressaisie.
L'EDI reste la réponse la plus robuste pour les échanges déjà structurés avec les grands comptes. Pour le reste du portefeuille, le sujet est différent : faire entrer dans l'ERP les commandes qui arrivent encore dans la boîte mail. C'est là que l'agent a sa place.
