Connecter une boutique e-commerce à un logisticien consiste à organiser les échanges de commandes, de stocks, d’expéditions et de retours entre votre outil de vente et les systèmes du prestataire. Un connecteur annoncé compatible avec votre boutique ne suffit pas : il faut vérifier les flux couverts, les statuts, les délais de synchronisation, les exceptions et les responsabilités en cas d’échec.
Avant de déplacer le stock, faites tester un parcours complet : une commande reçue une seule fois, les bons articles préparés, un stock disponible cohérent et un suivi remonté au bon client. Le lancement doit être validé sur des preuves de fonctionnement, avec une procédure de reprise si un échange échoue.
Que faut-il connecter entre boutique et entrepôt ?
La boutique enregistre la vente. Le WMS pilote l’exécution dans l’entrepôt ; un OMS peut coordonner les commandes entre plusieurs canaux ou sites. Selon l’organisation, ces rôles sont répartis entre plusieurs outils. Le contrat et le dossier d’interface doivent préciser qui fait autorité pour chaque donnée.
| Flux | Informations nécessaires | Contrôle à prévoir |
|---|---|---|
| Catalogue | SKU, variantes, codes, unités, dimensions et conditionnements utiles | Une référence correspond à la bonne unité physique. |
| Commandes | Identifiant, lignes, quantités, adresse, service et consignes autorisées | La commande est acceptée, rejetée ou bloquée avec un motif visible. |
| Stock disponible | Quantités par site et statuts retenus pour la vente | Le stock réservé ou bloqué n’est pas vendu comme du stock libre. |
| Expédition | Colis, quantités expédiées, transporteur et suivi | Une préparation ne devient pas artificiellement une livraison effectuée. |
| Annulations | Demande, réponse et moment de traitement | Une commande déjà partie ne disparaît pas du système. |
| Retours | Commande d’origine, articles reçus, état et décision validée | Un retour physique ne déclenche pas automatiquement un remboursement. |
La documentation Shopify distingue le stock par emplacement et l’affectation des commandes selon les règles de routage. Ce point illustre un principe important : quand deux sites interviennent, leur stock et leurs responsabilités doivent être représentés explicitement. Le paramétrage précis dépend de votre plateforme et de sa configuration.
Connecteur natif, API, EDI ou fichier : que choisir ?
Un connecteur existant peut accélérer le projet si sa version et son périmètre correspondent au besoin. Une API donne accès à des échanges entre applications. L’EDI structure des messages selon un cadre convenu ; un fichier peut convenir à un flux limité si les contrôles et la fréquence restent compatibles avec la promesse commerciale.
La meilleure solution dépend des volumes, des canaux, des exceptions et du niveau de service. Évaluez surtout le résultat : quels événements passent, dans quel sens, avec quel délai et quelle preuve de traitement ? Un échange automatisé qui transmet une information erronée plus vite ne règle pas le problème.
- Nom et version de la boutique, modules et personnalisations concernés.
- Version du connecteur ou périmètre du développement à réaliser.
- Flux inclus et fonctions exclues, notamment retours et expéditions partielles.
- Responsable du paramétrage, des tests et de la maintenance.
- Abonnements, frais de démarrage, évolutions et conditions de sortie.
Ces éléments font partie du cahier des charges logistique. Ils doivent être connus avant de départager les opérateurs, pas découverts après le transfert des marchandises.
Qui décide du stock réellement vendable ?
Le stock physique, le stock informatique et le stock proposé à la vente ne sont pas nécessairement identiques. Une palette présente peut être en contrôle qualité. Des unités peuvent être réservées pour une autre commande. Un retour peut attendre une inspection.
Définissez une règle écrite : quelles quantités sont comptées, quelles réservations sont déduites, comment les statuts bloqués sont exclus et qui peut corriger une quantité. Évitez que deux outils modifient la même donnée selon des règles contradictoires.
Exemple entièrement hypothétique : le site possède 250 unités. Sur ce total, 30 sont réservées et 10 sont bloquées. Le disponible est donc de 210 unités si ces catégories sont distinctes et qu’aucune autre règle ne s’applique. Vérifiez que l’interface n’envoie pas déjà un stock net avant de déduire de nouveau les réservations.
Une synchronisation périodique crée aussi un délai entre deux mises à jour. Convenez de la fréquence cible, du traitement d’une rupture et des éventuelles protections commerciales. Aucun délai universel ne convient à tous les catalogues ou canaux.
Le fichier articles : la première cause à vérifier
Chaque variante doit être identifiable sans ambiguïté. Précisez l’unité de vente, l’unité stockée et les conversions : un carton de dix articles ne doit pas être traité comme une unité unique vendue au détail, sauf règle expressément prévue.
Contrôlez aussi les références désactivées, les kits, les produits offerts, les précommandes et les marchandises à lots ou dates. Pour un kit assemblé à la commande, qui déduit les composants ? Pour un lot commercial déjà constitué, quelle référence est stockée ? Testez les deux cas plutôt que de supposer qu’un même connecteur les couvre.
Le guide pour choisir un logisticien e-commerce situe les systèmes parmi les critères de sélection. Le présent guide détaille la validation opérationnelle de la connexion.
Quels tests effectuer avant le démarrage ?
Préparez des scénarios avec des données fictives ou adaptées à un environnement isolé. Notez pour chacun le résultat attendu, la preuve obtenue et l’écart restant. Les critères ci-dessous sont une proposition de recette à adapter au projet.
| Scénario | Résultat à démontrer |
|---|---|
| Commande simple | Les références, quantités, adresse et service correspondent au besoin. |
| Commande multi-lignes | Aucune ligne n’est perdue, confondue avec une variante ou traitée deux fois. |
| Message reçu deux fois | Le système reconnaît le doublon et ne crée pas deux préparations. |
| Référence inconnue | La commande est mise en exception, avec une alerte exploitable. |
| Rupture partielle | La règle convenue est appliquée : attente, fractionnement ou autre arbitrage validé. |
| Annulation avant et après lancement | La demande reçoit une réponse fidèle à l’état réel de l’exécution. |
| Expédition en plusieurs colis | Les quantités et suivis sont rattachés à la bonne commande. |
| Retour reçu | L’état et la décision de remise en vente sont distingués du seul événement de réception. |
| Connexion interrompue | L’incident est visible et les échanges reprennent sans perte ni doublon. |
| Correction de stock | L’écart est justifié et sa répercussion sur la vente est comprise. |
La documentation technique Shopify prévoit explicitement la détection des événements livrés plusieurs fois. La gestion des doublons mérite donc un test concret, même lorsque le logiciel est présenté comme standard.
Cas pédagogique : la commande transmise deux fois
Une boutique transmet une commande. L’entrepôt l’enregistre, mais la réponse de confirmation ne parvient pas à l’émetteur. Un nouvel envoi intervient. Si le récepteur traite chaque arrivée comme une vente différente, deux préparations peuvent être lancées.
Dans ce scénario hypothétique, le comportement attendu est de reconnaître l’identifiant déjà reçu et de retrouver son traitement existant. En cas d’exception, le support doit pouvoir suivre la même commande entre boutique, connecteur et WMS. Les journaux utiles servent à reconstituer les événements, sans exposer inutilement les données des clients.
Qui intervient quand la connexion tombe ?
Écrivez un circuit d’incident qui couvre le marchand, l’opérateur, l’éditeur et l’intégrateur selon le montage. Un contact commercial unique ne remplace pas une responsabilité technique désignée.
- Qui reçoit l’alerte et pendant quelles plages de service ?
- Qui peut suspendre les envois ou bloquer une vague de préparation ?
- Qui vérifie les commandes en attente avant de relancer ?
- Quels rapprochements prouvent que le flux est revenu à la normale ?
- Qui informe le service client et ajuste la promesse affichée ?
Reliez ces règles aux engagements de service logistiques : définition des statuts, mesure du délai, exclusions et escalade. Ne confondez pas le délai d’une interface avec le temps de préparation ou le délai du transporteur.
Quelles données transmettre et quels coûts prévoir ?
Transmettez les données nécessaires à l’exécution et organisez les accès par rôle. Si le prestataire traite les données personnelles pour votre compte, les obligations doivent être encadrées conformément au rôle de chaque partie. Prévoyez le traitement des incidents et le sort des informations à la fin du contrat, avec les fonctions compétentes.
Demandez un chiffrage séparant paramétrage initial, nettoyage du catalogue, développement éventuel, tests, abonnement, maintenance et évolutions. Comparez également les frais de reprise et d’export à la sortie. Le prix d’un prestataire logistique s’apprécie sur ce périmètre complet.
Une nouvelle marketplace, un changement de transporteur ou un kit promotionnel peuvent demander un nouveau paramétrage. Faites préciser le circuit de demande et de validation : ces évolutions doivent rester visibles au lieu de devenir des exceptions permanentes.
Quand donner le feu vert ?
Validez le lancement lorsque les scénarios critiques passent, que le stock de départ est rapproché et que les responsabilités sont acceptées. Un pilote sur un canal ou une famille de produits peut être pertinent si ce périmètre peut être isolé. Gardez un suivi renforcé des commandes manquantes, doublons, écarts de stock et statuts en retard.
Si le projet accompagne un changement de prestataire logistique, convenez de l’instant où chaque opérateur cesse ou commence à recevoir les commandes. Plusieurs sites peuvent fonctionner si les règles de stock et d’affectation sont maîtrisées ; la double exploitation exige une gouvernance claire.
Vous préparez une externalisation ou une connexion à un nouvel entrepôt ? Présentez votre boutique, vos canaux, vos volumes et vos contraintes sur la page recherche de prestataire logistique. Le cadrage permettra de consulter des opérateurs sur un périmètre comparable, puis de confirmer leurs capacités techniques.
Questions fréquentes
Un connecteur Shopify ou WooCommerce suffit-il ?
Il faut vérifier sa version, les flux couverts et les exceptions. Demandez une démonstration sur vos scénarios et des tests avant démarrage.
Le stock doit-il remonter en temps réel ?
Définissez une fréquence et un délai maximal adaptés au risque de survente et à vos canaux. Une promesse de temps réel doit être précisée et mesurée.
Peut-on commencer avec des fichiers ?
Oui si volumes, fréquence, contrôles et responsabilités le permettent. Le choix doit rester compatible avec la préparation et la promesse client.
Qui corrige les erreurs de référence ?
Un responsable du catalogue doit être nommé. Il coordonne la correction avec la boutique et l’entrepôt, puis fait contrôler les commandes concernées.
Un retour reçu remet-il automatiquement le produit en vente ?
La règle dépend du contrôle et de la décision prévus. La réception physique, l’inspection, la disponibilité et le remboursement sont des événements distincts.
Que prévoir à la sortie du contrat ?
Organisez les exports, les commandes ouvertes, la bascule des accès et le traitement des données. Vérifiez les droits, formats, délais et responsabilités avant la transition.
Sources et portée du guide
- Shopify — gestion des stocks entre emplacements et applications : principes d’affectation des stocks et commandes.
- Shopify Developers — vérification des événements reçus et détection des doublons.
- CNIL — article 28 du RGPD : encadrement de la sous-traitance des données.
Les scénarios et la grille de tests sont des propositions de méthode. Ils ne constituent pas l’annonce de fonctions disponibles chez un opérateur précis. Les compatibilités doivent être vérifiées pour les versions utilisées.