EDI : pourquoi un « simple connecteur » peut devenir un vrai projet

Lors d'un projet pour une entreprise qui fournit une grande enseigne, la demande de départ semblait claire : relier Dolibarr aux échanges EDI du client pour réduire les manipulations. Aujourd'hui, des commandes arrivent, puis il faut préparer les expéditions, renseigner les documents et reprendre des informations dans un portail WebEDI. Quand une campagne concerne de nombreux magasins, ces opérations se répètent autant de fois.

Le besoin est réel. Mais avant de choisir un connecteur, j'ai dû revenir sur une question plus large : quelles informations doivent circuler, à quel moment, et avec quelles preuves de traitement ? C'est cette étude que je partage ici. Elle ne signifie pas que toute la chaîne est déjà déployée.

Partir des opérations, pas du logiciel

Dans ce dossier, Dolibarr est l'ERP : il rassemble les clients, les produits, les commandes, les expéditions et les factures. L'enseigne attend des messages structurés qui décrivent certaines de ces opérations. Il faut donc établir une correspondance entre les données disponibles dans l'ERP et celles exigées par le destinataire.

Un exemple suffit à montrer la difficulté : une commande peut être adressée à une société, mais livrée dans plusieurs dépôts. L'identité du client et celle du lieu de livraison ne sont pas interchangeables. Les codes GLN identifient les organisations ou les lieux ; les codes EAN identifient les produits. Si ces références sont absentes ou associées au mauvais objet, une transmission techniquement réussie peut rester inexploitable.

Les conditionnements doivent aussi être clarifiés. Une quantité de dix désigne-t-elle dix unités ou dix cartons ? Le connecteur ne peut pas décider à la place de l'entreprise. Cette règle doit être établie avant de convertir les données.

Trois messages, trois moments différents

Les spécifications étudiées reposent sur EDIFACT D96A, avec un sous-ensemble EANCOM. Derrière ces noms, on trouve une façon précise d'organiser les données, avec des champs attendus et des règles propres au partenaire.

ORDERS porte la commande envoyée par l'acheteur. DESADV annonce l'expédition : il décrit ce qui part effectivement et doit rester cohérent avec la commande d'origine. INVOIC porte la facture, avec ses montants, ses références et les informations nécessaires à son rapprochement.

Ces messages ne sont donc pas trois copies d'un même document. Une livraison partielle oblige, par exemple, à distinguer la quantité commandée de la quantité expédiée. La facture doit ensuite suivre le scénario convenu avec l'enseigne. Les règles de regroupement, les références de commande et les numéros de livraison font partie du fonctionnement à étudier.

Le format ne règle pas le transport

Produire un message EDIFACT ne suffit pas à le transmettre. Dans ce projet, les options de transport proposées sont AS2 ou X.400. Ce sont des moyens d'acheminer les échanges ; ils ne remplacent pas les règles de contenu.

AS2 permet d'échanger des messages sur HTTP avec des mécanismes de signature et de chiffrement. Il faut convenir des paramètres avec le partenaire, échanger les certificats nécessaires et anticiper leur renouvellement. Une passerelle ou un opérateur peut prendre en charge cette partie, mais il reste à définir qui surveille son fonctionnement.

L'accusé technique AS2, appelé MDN, est une autre brique. Il donne une information sur la réception et le traitement technique du message. Il ne constitue pas, à lui seul, une validation commerciale de la facture ou une preuve de paiement. Les retours métier éventuels doivent être identifiés séparément.

Tester la chaîne et prévoir les exceptions

L'environnement de test sert à vérifier les messages avec le partenaire avant la production. Je recommande d'y couvrir plusieurs situations : commande complète, expédition partielle, référence inconnue, message rejeté et nouvelle tentative après une erreur.

La nouvelle tentative mérite une attention particulière. Si une commande a déjà été importée, relancer le traitement ne doit pas créer une deuxième commande. Il faut conserver les identifiants des échanges, tracer les opérations et définir les conditions de reprise.

La supervision prolonge ce travail : qui reçoit une alerte, qui corrige les données et comment sait-on qu'un document attend encore un retour ? Sans réponse, l'automatisation déplace simplement les vérifications dans un endroit moins visible.

Ce que je retiens de cette étude

Un connecteur existant peut éviter une partie du développement. Il faut cependant vérifier son périmètre : messages couverts, règles de l'enseigne, transport, tests, retours et maintenance. Le prix d'installation ne dit pas tout de la charge future.

Avant de chiffrer, je préfère décrire le trajet d'une commande jusqu'à sa facture et les cas qui interrompent ce trajet. C'est ce qui permet de choisir une solution adaptée et de savoir ce qui restera manuel. Le connecteur devient alors une réponse à un processus défini, plutôt qu'une promesse dont chacun comprend quelque chose de différent.