« Nous avons une API » ne dit pas encore si une commande peut être acceptée, modifiée puis rapprochée d’une livraison. « Nous faisons de l’EDI » ne précise pas les messages ni les partenaires pris en charge. Pour comparer les deux, partez du parcours de la commande.
EDI et API ne décrivent pas la même chose
L’EDI organise l’échange de documents commerciaux structurés selon des règles partagées. Une API est une interface par laquelle deux systèmes échangent des données ou déclenchent des opérations. Un échange EDI peut utiliser une API comme moyen de transport ; les deux ne sont donc pas nécessairement concurrents.
GS1 France décrit notamment les messages ORDERS pour la commande, DESADV pour l’avis d’expédition et INVOIC pour la facture. Le standard et la version ne suffisent pas toujours : le guide d’implémentation du partenaire précise les champs, codes et règles réellement attendus.
| Question | Échange EDI | Échange par API |
|---|---|---|
| Que signifie le document ? | Message et guide partenaire | Schéma de données et contrat d’interface |
| Comment arrive-t-il ? | Canal convenu avec le partenaire | Appels, événements ou récupération périodique |
| Comment sait-on qu’il est accepté ? | Accusés techniques et réponses métier prévus | Réponse de l’interface et statut métier documentés |
| Comment gère-t-on une erreur ? | Rejet, correction et réémission convenus | Codes d’erreur, reprise et règles de répétition |
Dessiner le flux de bout en bout
Prenez une commande de vingt-quatre unités. Le système reçoit la demande, identifie l’acheteur et le lieu de livraison, retrouve le produit, applique les conditions, puis l’accepte ou la rejette. La préparation peut ensuite expédier dix-huit unités et placer six unités en reliquat, si cette possibilité est convenue.
L’avis d’expédition doit refléter ce qui part réellement. La facture et les éventuels avoirs doivent pouvoir être rapprochés des documents précédents, selon les règles du flux. Si l’interface sait seulement créer une commande, le travail de suivi peut rester entièrement manuel. Chiffrez ce reste à faire avant de comparer les coûts.
- Commande
Identifier les parties, les produits, les unités et les conditions.
- Acceptation
Confirmer le traitement ou renvoyer un rejet explicable.
- Expédition
Décrire les 18 unités réellement parties et le reliquat de 6.
- Rapprochement
Relier facture, livraison et éventuels avoirs selon le flux.
Un accusé de réception technique ne prouve pas l’acceptation commerciale.
Accorder les identifiants et les unités
- →Parties : client facturé, établissement livré et identifiants reconnus de chaque côté.
- →Produits : SKU interne, code partenaire ou GTIN, reliés à la bonne variante.
- →Quantités : unité, carton, multiple et conversion explicites.
- →Conditions : devise, prix net ou brut, réductions, taxes et dates pertinentes.
Les erreurs d’unité restent possibles dans un message parfaitement valide. Le socle de données du catalogue doit donc être vérifié avant les tests techniques. Un code produit inconnu doit produire un rejet compréhensible, pas une ligne libre qui échappe ensuite au rapprochement.
Prévoir la répétition d’un envoi
Supposons que le partenaire envoie une commande, que votre système l’enregistre, puis que la connexion se coupe avant le retour de l’accusé. Le partenaire peut renvoyer le même document. Si chaque réception crée une nouvelle commande, deux colis peuvent partir pour un seul achat.
Définissez la clé d’unicité avec le partenaire et le comportement attendu lorsqu’un même identifiant arrive avec un contenu différent. La reprise doit garder une trace de la première réception, des corrections et des statuts. Cette capacité est souvent appelée idempotence ; c’est le résultat opérationnel qui compte dans la recette.
Tester les exceptions avant la première vraie commande
| Cas | Résultat à vérifier |
|---|---|
| Commande valide | Une commande créée, montants et unités identiques au document source |
| Même document reçu deux fois | Pas de deuxième commande ni de deuxième expédition |
| Produit inconnu | Rejet explicite et correction possible |
| Livraison partielle | Quantités expédiées et reliquat identifiables |
| Modification après confirmation | Règle claire selon l’état de préparation |
| Panne puis reprise | Documents en attente retrouvés et rapprochés sans perte |
Conservez les données d’entrée, le résultat attendu et l’écart observé pour chaque test. Un écran vert prouve parfois seulement que le transport du fichier a réussi. Il faut également vérifier que la commande a été acceptée par le système de gestion et que le statut remonté correspond à cette acceptation.
Choisir selon les partenaires et le coût d’exploitation
Si un distributeur impose un message EDI précis, ce besoin est déterminant. Si un partenaire propose une API complète et documentée, évaluez sa couverture fonctionnelle, ses limites d’usage, la gestion des versions et la disponibilité des données. Demandez dans les deux cas qui traite les rejets et sous quel délai.
Un flux de facture ne suffit pas à conclure sur la conformité
Le choix technique d’un message INVOIC ou d’une API ne prouve pas, à lui seul, que toutes les obligations françaises de facturation électronique sont remplies. Le guide sur la facture électronique en distribution distingue le calendrier réglementaire, les acteurs et les données à préparer, avec les sources officielles.
Enfin, faites chiffrer installation, correspondances de données, tests, suivi des rejets et maintenance. Demandez une démonstration sur vos documents et votre partenaire exact. Le nom d’un connecteur dans une présentation ne garantit ni les messages couverts, ni le sens des échanges, ni le traitement des exceptions.
Par Anatole Briant
Par Pierre Lerebours
Par Anatole Briant
COO de Salesia
Pierre Lerebours est COO de Salesia. Il est votre interlocuteur pour le déploiement, la formation et le suivi.