EDI, portail B2B ou API : quel canal pour quelles commandes?

Choisir le canal selon le client

Le bon canal dépend du profil du client, de son volume et de ses moyens techniques. Le tableau suivant aide à structurer la discussion.

Le canal découle souvent d'une exigence du client plutôt que d'un choix du fournisseur. Une chaîne peut faire de l'EDI une condition pour référencer vos produits. Demandez ses guides d'implantation avant de vous engager sur un délai.

Ce qu'un projet EDI demande réellement

Chaque partenaire publie ses propres exigences : version de la norme, segments obligatoires, codes utilisés. GS1 Canada indique que des lignes directrices sectorielles canadiennes fondées sur X12 existent notamment pour l'épicerie, les services alimentaires, la pharmacie de détail et la santé.

Les correspondances représentent souvent l'essentiel du travail : codes produits du partenaire, vos références internes, unités de commande et adresses de livraison codifiées. Une erreur de correspondance produit une commande mal préparée, même si le document EDI est techniquement valide.

Prévoyez des tests avec chaque partenaire et lisez ses conditions : certaines prévoient des frais lorsqu'un document est manquant, tardif ou non conforme. Les échanges peuvent aussi passer par un prestataire qui traduit et achemine les documents; son rôle et son coût doivent être définis.

Quand le portail suffit et comment l'élargir

Pour la majorité des clients sans moyens d'intégration, le portail reste le canal le plus simple. Il gagne en efficacité avec la commande rapide par référence, la recommande et l'affichage des prix et de la disponibilité propres au compte.

L'import de fichier sert de passerelle pour les clients qui préparent leurs commandes dans un tableur. Fournissez un modèle, validez chaque ligne et affichez des messages d'erreur compréhensibles : référence inconnue, quantité non multiple, produit non autorisé.

Ouvrir une API aux clients équipés

Une API intéresse les clients dotés d'un outil d'approvisionnement, les places de marché et les intégrateurs. Définissez le périmètre ouvert : consultation du catalogue et des prix, création de commandes, statuts, expéditions et factures.

La sécurité doit être pensée par client : authentification propre à chacun, accès limité à ses prix et à ses commandes, limites d'appels, environnement de test et politique de versions documentée.

Précisez enfin les responsabilités. Qui répond au développeur du client? Qui surveille les erreurs? Comment le client est-il prévenu d'une évolution de l'API?

Faire coexister les canaux sans dupliquer les règles

Le principe à retenir : un seul moteur applique les prix, la disponibilité, le crédit et les approbations; les canaux ne sont que des points d'entrée. Chaque canal qui maintient ses propres règles devient une source d'écarts.

• La même liste de prix, quel que soit le canal.
• Les mêmes contrôles de crédit et de limites de commande.
• Un référentiel de produits unique et des correspondances centralisées.
• Une numérotation et un historique de commandes communs.
• Les mêmes statuts renvoyés au client, par message EDI, par API ou dans le portail.

Décidez aussi comment les approbations s'appliquent. Une commande EDI d'une chaîne est déjà approuvée par son système; vos propres contrôles internes, comme le crédit, continuent pourtant de s'appliquer.

Surveiller les erreurs et les accusés de réception

Chaque canal produit ses erreurs : référence inconnue, prix différent du contrat, adresse invalide. Désignez la personne qui les traite et la réponse attendue : accusé de réception EDI, message d'erreur de l'API ou notification dans le portail.

Rapprochez régulièrement les commandes reçues et acceptées, canal par canal. Ce contrôle permet de repérer une commande bloquée même lorsqu'une alerte a été manquée.

Votre grille de décision

Le choix d'un canal se fait client par client, mais les règles qui s'appliquent derrière doivent rester les mêmes pour tous.

Votre liste de décisions

• Classer vos clients selon leur profil, leur volume et leur capacité technique.
• Recenser les clients qui exigent l'EDI et obtenir leurs guides d'implantation.
• Définir le modèle d'import de fichier et ses validations.
• Fixer le périmètre, la sécurité et le soutien de l'API.
• Centraliser prix, crédit, références et statuts dans un même moteur.
• Attribuer le traitement des erreurs et le rapprochement par canal.

Où se situe Shopflow

La page Moteur B2B de Shopflow mentionne parmi les canaux B2B la commande par représentant et l'import EDI/CSV, reliés à un moteur commun : prix par client, catalogues privés, approbations et gestion du crédit. Les pages Commerce headless et Documentation API décrivent l'accès par API. Le site ne détaille pas la prise en charge des ensembles de transactions EDI propres à vos partenaires ni de service de réseau EDI : faites préciser les formats acceptés, la traduction des documents et le recours éventuel à un prestataire EDI.