Presque personne ne décide de faire de l'EDI. On reçoit un courrier d'un client — une enseigne, un grand industriel — qui annonce qu'à partir de telle date les commandes passeront par EDI et que les factures devront suivre. Il y a une date, et la date n'est pas négociable.
C'est pour cela que ce sujet arrive rarement comme un projet d'amélioration et presque toujours comme une contrainte. Autant savoir exactement ce qu'elle demande.
Ce qu'une intégration EDI est, et ce qu'elle n'est pas
L'EDI — l'échange de données informatisé — est l'envoi de documents commerciaux normalisés entre deux entreprises, par un réseau sécurisé, dans un format que les deux systèmes savent lire. L'intégration EDI est autre chose : c'est le raccordement entre ce réseau et vos propres processus.
La distinction n'est pas académique, et elle décide du périmètre de votre projet. Deux rôles existent :
L'opérateur EDI transporte. Il gère la connexion avec vos partenaires, les accusés techniques, les conversions de protocole, la conservation des échanges. C'est son métier et ce n'est pas le nôtre : nous travaillons avec un partenaire opérateur pour cette partie, décrite sur sa page, où l'on trouve aussi les étiquettes SSCC qui accompagnent les palettes.
Votre système produit et consomme. Il transforme une commande reçue en commande exécutable, déclenche la préparation, et génère l'accusé, l'avis d'expédition et la facture au moment où les faits se produisent. C'est l'objet du module décrit sur message edi.
Un éditeur qui brouille cette frontière vous vendra un périmètre qu'il ne tient pas. Posez la question : qui transporte, qui produit.
Faites défiler latéralement pour voir toute la figure.
le système produit les messages, l'opérateur les transporte
Les cinq messages d'un cycle de commande
1. La commande du client
En norme américaine, l'EDI 850. En EDIFACT, le message ORDERS. C'est le document qui remplace le bon de commande reçu par courriel ou par fax, et c'est le seul que la plupart des entreprises connaissent au départ. L'EDI commande est d'ailleurs la porte d'entrée habituelle : on commence par recevoir, on apprend à émettre ensuite.
Ce qu'il contient détermine la suite : les références du client, qui ne sont pas les vôtres, les unités dans lesquelles il commande, qui ne sont pas forcément les vôtres, et l'adresse de livraison, qui peut être un entrepôt ou un magasin.
2. L'accusé de réception
EDI 855, en EDIFACT ORDRSP. Il dit ce que vous acceptez : la commande entière, une partie, avec quelles dates. C'est le message le plus souvent négligé, et c'est celui qui évite la moitié des litiges, parce qu'il fixe par écrit ce qui a été promis.
3. L'ordre d'expédition adressé à l'entrepôt
EDI 940. Ce message sert quand l'exécution physique est ailleurs : chez un prestataire logistique, sur un autre site, dans une autre société du groupe. Il transporte la consigne, et la confirmation revient par le même chemin.
4. L'avis d'expédition
EDI 856, en EDIFACT DESADV. C'est le message qui annonce ce qui part, dans quels colis, sur quelles palettes, et avec quels numéros de suivi. Il porte la structure logistique de l'envoi : ce qu'il y a dans chaque palette, et l'identifiant de cette palette.
Ce message circule dans les deux sens, et c'est utile de le savoir avant de cadrer un projet : la plateforme reçoit les DESADV entrants de vos fournisseurs et émet les DESADV sortants vers vos clients, dans les deux cas par l'opérateur. Les messages de stock — les états de stock échangés avec un partenaire — passent par le même chemin.
C'est là que les étiquettes SSCC entrent en jeu. Une palette annoncée dans un DESADV doit porter un identifiant que le destinataire peut scanner à sa réception, et cet identifiant doit correspondre au contenu annoncé. Les étiquettes sont générées par le système, pour les palettes mono-référence comme pour les palettes mixtes.
5. La facture
EDI 810, en EDIFACT INVOIC. Les messages de facture supposent que la plateforme soit raccordée à votre ERP, puisque c'est l'ERP qui facture. Elle demande le paiement, et elle doit concorder avec le DESADV et avec l'ORDRSP. Les trois ensemble constituent le dossier ; un écart entre eux, c'est un litige.
En Europe, les quatre premiers voyagent habituellement en EDIFACT. La norme américaine en chiffres reste utile à connaître parce que les documentations des éditeurs la citent.
Pourquoi l'EDI tient toujours, malgré les API
Parce qu'il n'est pas un choix technique. Il est une condition commerciale.
Les enseignes de la grande distribution, l'automobile, la santé et une grande partie de l'industrie l'exigent de leurs fournisseurs. Un format exigé par un client ne se remplace pas par un format que vous trouvez plus moderne, et la discussion ne porte jamais sur la technologie : elle porte sur le fait de rester fournisseur.
À quoi s'ajoutent deux qualités réelles. Les formats sont stables et universellement reconnus, ce qui vaut mieux qu'élégant quand il s'agit de tenir dix ans. Et une fois en place, un flux EDI absorbe des volumes importants sans surveillance particulière.
En logistique retail, le véritable enjeu derrière l'EDI n'est d'ailleurs pas l'échange lui-même : ce sont les pénalités de service attachées au respect du créneau de livraison et à la conformité de l'avis d'expédition. C'est ce qui fait monter le sujet jusqu'à la direction.
Les trois difficultés réelles, et comment elles se traitent
Le mappage, partenaire par partenaire. C'est la charge principale et elle surprend toujours. Chaque client a ses segments obligatoires, ses codes, ses unités, ses règles d'arrondi. Le travail n'est pas difficile ; il est long et minutieux, et il se chiffre par partenaire. Demandez un chiffrage par partenaire, pas un forfait global.
La rigidité du format. Un message EDI ne se modifie pas à la volée. Un cas particulier qui se règle en deux minutes au téléphone demande, en EDI, un segment prévu à l'avance. Ce n'est pas un défaut : c'est le prix de la stabilité. Mais cela veut dire que les cas particuliers doivent être listés avant, pas découverts après.
Les systèmes anciens. Un flux EDI mis en place il y a quinze ans, maintenu par une personne qui est partie, est un risque plus grand que l'absence d'EDI. Le passage par un opérateur plutôt que par un intergiciel maison déplace cette charge chez quelqu'un dont c'est le métier.
Et une question à poser avant de signer, comme pour tout raccordement : que fait un message rejeté. Un rejet silencieux produit une commande que personne n'a vue, donc une rupture d'engagement sans explication. Exigez de savoir où il s'arrête, qui est averti, et comment il est rejoué. C'est la même exigence que sur un connecteur ERP.
Où l'EDI rejoint la décision commerciale
Un message reçu n'est pas une commande exécutable. Entre les deux, quelqu'un doit décider : accepte-t-on la totalité, sur quel stock, depuis quel site, et qui est servi quand il n'y en a pas assez.
Ces décisions ne sont pas du ressort de l'EDI. Elles relèvent de la couche commandes — c'est ce que fait un logiciel de gestion des commandes — et l'exécution physique qui suit relève du logiciel WMS. L'EDI est le canal ; il ne décide rien.
C'est aussi pourquoi un projet EDI mené sans la couche commandes produit souvent le même résultat qu'avant : des commandes qui entrent plus vite dans une file que personne n'arbitre.
Ce qu'il faut retenir
Cinq messages, quatre noms EDIFACT, et une frontière : le système produit et consomme, l'opérateur transporte. Le reste du projet est du mappage, et il se chiffre par partenaire.
Si une date vous a été donnée par un client, commencez par les deux messages qu'il exige réellement — souvent l'ORDERS et l'INVOIC — et ajoutez le DESADV ensuite. Un périmètre réduit tenu à la date vaut mieux qu'un périmètre complet en retard, parce que c'est la date qui est dans le courrier.
