Relier une boutique en ligne et un ERP : stocks et commandes

Relier une boutique en ligne (Shopify, PrestaShop, WooCommerce) à un ERP ou un logiciel de gestion commerciale (Sage, EBP, Cegid, Odoo, Divalto) revient à faire circuler correctement quatre flux : le stock vers la boutique, les commandes vers l'ERP, les fiches produits selon le champ qui fait foi, et les expéditions ou retours en sens inverse. Les connecteurs natifs des principaux éditeurs couvrent déjà ces flux de base sans développement particulier dans la majorité des cas. Le sur mesure devient utile quand un second canal de vente s'ajoute, quand les déclinaisons de produits ne se structurent pas de la même façon des deux côtés, ou quand le stock doit être arbitré finement entre plusieurs entrepôts.

Ce n'est presque jamais un problème d'API : les plateformes e-commerce et les ERP du marché en exposent une. C'est un problème d'arbitrage métier, exactement comme pour n'importe quelle synchronisation entre deux logiciels : quel système publie quoi, dans quel sens, et avec quelle marge de sécurité.

Cet article détaille les quatre flux dans l'ordre où ils posent réellement problème en pratique, les difficultés qui cassent une intégration pourtant bien pensée (multicanal, surréservation, déclinaisons), et ce que l'IA apporte concrètement quand les catalogues ou les libellés ne se correspondent pas exactement d'un système à l'autre.

Le stock : quelle donnée publier, de l'ERP vers la boutique

C'est le premier flux qui fait mal quand il est mal conçu : afficher un produit en stock alors qu'il ne l'est plus, ou l'inverse, masquer une référence disponible parce que le chiffre remonté était faux. Le vrai sujet n'est pourtant pas technique. C'est de décider quel stock on publie.

Un ERP connaît en général plusieurs niveaux de stock pour une même référence :

• Le stock physique. Ce qui se trouve réellement dans l'entrepôt, indépendamment de toute commande en cours.
• Le stock réservé. Ce qui est déjà affecté à une commande non encore expédiée, qu'elle vienne de la boutique ou d'un autre canal (vente directe, revendeur, marketplace).
• Le stock disponible à la vente. Le stock physique moins le stock réservé, c'est-à-dire ce qui peut réellement encore être vendu.

Publier le stock physique brut sur la boutique est l'erreur la plus fréquente sur ce flux. Elle finit toujours par créer une survente : un client commande un article déjà réservé pour une autre commande, et il faut ensuite gérer un remboursement ou un délai imprévu, avec l'insatisfaction que cela génère.

Deux autres décisions doivent être prises avant tout développement, quel que soit le connecteur retenu :

• Faut-il une marge de sécurité ? Sur une référence à forte rotation vendue sur plusieurs canaux, publier un peu moins que le stock réellement disponible (une réserve non affichée) protège contre les écarts entre deux synchronisations. Sur une référence à faible rotation, cette marge n'a pas grand intérêt et réduit inutilement les ventes possibles.
• Que fait-on des ruptures et du réassort ? Une référence à zéro doit-elle disparaître du catalogue, rester visible en précommande, ou simplement afficher une indisponibilité temporaire ? La réponse dépend du délai de réassort connu côté ERP, une information que le connecteur peut aussi faire remonter vers la fiche produit plutôt que de se limiter à un stock binaire disponible ou non.

Les commandes : ce qui doit remonter de la boutique vers l'ERP

Une fois la commande passée sur la boutique, elle doit arriver dans l'ERP sous une forme exploitable pour la préparation, la facturation et la comptabilité. Ce flux est plus dense que le stock, car plusieurs éléments doivent se recouper correctement en même temps.

• La correspondance des références produits. La boutique et l'ERP doivent désigner le même article par le même identifiant, ou un mappage explicite doit exister entre le SKU de la boutique et la référence interne de l'ERP. Sans cette correspondance fiable, la commande arrive dans l'ERP avec une ligne de produit que personne ne reconnaît.
• Les clients existants et les nouveaux. Un client déjà présent dans l'ERP (souvent un client B2B ou récurrent) ne doit pas être recréé en doublon à chaque commande. Une clé de rapprochement fiable, en général l'email combiné au nom ou au SIRET, évite cette multiplication de fiches.
• Les modes de paiement. Carte bancaire, virement, paiement en plusieurs fois : l'ERP doit recevoir un statut de paiement cohérent avec ce qu'a réellement encaissé la boutique, pour que la comptabilité ne parte pas d'une hypothèse fausse.
• Les frais de port. Ils doivent apparaître comme une ligne identifiable dans l'ERP, pas noyés dans le montant total de la commande, faute de quoi le rapprochement comptable devient approximatif.
• La TVA et les remises. Le taux de TVA appliqué (parfois différent selon la nature du produit ou le pays de livraison) et les remises consenties doivent remonter avec la commande, pas être recalculés a posteriori dans l'ERP à partir d'un montant global.

Ce flux illustre bien pourquoi la conception d'une synchronisation ne se limite jamais à brancher deux API : chaque champ mal mappé dans les commandes se traduit directement par une erreur de facturation ou un désagrément client. Notre article sur la suppression de la double saisie entre deux logiciels métier détaille la méthode générale de conception de ce type de flux, qui s'applique ici comme pour n'importe quel couple de logiciels.

Fiches produits et catalogue : qui fait foi sur quel champ

Le catalogue circule le plus souvent dans le sens ERP vers boutique : c'est l'ERP qui connaît la référence, le prix d'achat, le poids, les dimensions ou le code EAN d'un produit. Mais l'enrichissement marketing du produit, lui, vit presque toujours dans la boutique : description commerciale, images retouchées, mots-clés SEO, avis clients, contenu de réassurance.

C'est la question qui doit être tranchée avant tout développement, exactement comme pour n'importe quelle synchronisation entre deux logiciels : quel système est propriétaire de quel champ.

L'erreur la plus fréquente sur ce flux consiste à synchroniser la fiche produit en bloc, dans un seul sens, sans distinguer les champs. Une mise à jour venue de l'ERP écrase alors une description ou des images pourtant travaillées côté boutique, ce qui décourage vite l'équipe marketing de maintenir ses fiches à jour.

Expéditions et retours : le sens inverse

Une fois la commande préparée et expédiée depuis l'ERP ou l'outil logistique, l'information doit redescendre vers la boutique pour informer le client : statut d'expédition, transporteur, numéro de suivi. C'est ce flux qui évite au service client de répondre à la main à chaque "où en est ma commande".

Le retour suit une logique proche mais dans un contexte plus sensible :

• Le retour annoncé par le client doit être visible côté ERP avant même que le colis n'arrive, pour anticiper le contrôle qualité et la remise en stock.
• La réception et le contrôle du retour se font côté entrepôt, dans l'ERP, et déterminent si l'article est remis en vente, mis de côté pour réparation, ou détruit.
• Le remboursement ou l'avoir est en général piloté par l'ERP ou la solution de paiement, puis son statut redescend vers la boutique pour que le client soit informé sans avoir à relancer le service client.

Le point d'attention principal sur ce flux est le mouvement de stock associé au retour. Un article rendu ne doit remonter en stock disponible qu'après contrôle qualité, jamais automatiquement dès la réception du colis, sous peine de revendre un produit endommagé.

Multicanal, surréservation, déclinaisons : les limites du connecteur natif

Le connecteur natif de l'éditeur (celui fourni directement par Shopify, PrestaShop, WooCommerce ou par le module e-commerce de l'ERP) couvre correctement les quatre flux précédents tant que la situation reste simple. Trois difficultés reviennent le plus souvent quand ce n'est plus le cas.

Le multicanal, quand une marketplace ou un point de vente physique s'ajoute

Dès qu'un second canal de vente entre en jeu, une marketplace comme Amazon ou Cdiscount, une boutique physique, un revendeur B2B, le stock doit être arbitré entre plusieurs sources de demande en même temps, pas seulement synchronisé entre deux systèmes. Le module marketplace fourni par certains éditeurs gère souvent bien un canal supplémentaire, mais plafonne vite dès qu'il faut répartir finement un même stock entre trois ou quatre canaux avec des règles de priorité différentes.

La surréservation, quand deux canaux vendent la dernière pièce

La surréservation apparaît quand deux canaux vendent la même unité de stock avant que la synchronisation n'ait eu le temps de mettre à jour l'un des deux. Plus l'écart entre la vente réelle et la mise à jour du stock est long, plus le risque augmente. Une synchronisation en temps réel ou quasi temps réel réduit fortement ce risque par rapport à une synchronisation en lots une ou deux fois par jour ; notre article sur le choix entre synchronisation temps réel et batch détaille les critères pour trancher entre les deux selon le volume de commandes et la criticité du stock concerné. C'est un cas particulier des conflits et erreurs de synchronisation entre logiciels traités plus largement dans notre article dédié.

Les déclinaisons de produits, qui n'existent pas de la même façon des deux côtés

Une taille, une couleur ou un conditionnement se structurent rarement de façon identique dans une boutique en ligne et dans un ERP. La boutique gère souvent la déclinaison comme une variante d'un produit parent, tandis que l'ERP la traite parfois comme une référence indépendante à part entière, avec son propre code article. Sans mappage explicite entre ces deux structures, la synchronisation crée des références orphelines ou des stocks qui ne se recoupent jamais correctement. Notre article sur la correspondance des champs entre deux logiciels détaille la méthode pour construire ce mappage proprement.

C'est à ce stade, quand plusieurs de ces difficultés se combinent (multicanal, déclinaisons complexes, règles de stock spécifiques par entrepôt), que le module standard de l'éditeur ne suffit plus et qu'un connecteur sur mesure entre logiciels devient la solution la plus fiable, en particulier si l'entreprise a déjà tenté de forcer un module générique à couvrir un cas qu'il ne gère pas correctement. Notre article sur le choix entre connecteur standard et développement sur mesure détaille les critères pour trancher entre les deux avant d'engager un développement.

Ce que l'IA apporte concrètement, sans surpromettre

Sur une intégration propre, avec des références identiques des deux côtés, un connecteur classique suffit largement. L'IA devient utile précisément là où les données ne se correspondent pas exactement, ce qui arrive souvent en pratique, surtout sur un catalogue ancien ou repris de plusieurs sources.

• Le rapprochement des références quand les libellés diffèrent. "T-shirt col rond bleu marine M" côté boutique et "TS-CR-BM-M" côté ERP désignent le même article. Un modèle de langage comprend cette équivalence à partir du contexte, là où une correspondance exacte échoue.
• La normalisation des catalogues fournisseurs entrants. Quand un nouveau fournisseur envoie son catalogue dans son propre format (unités, intitulés, structure de fichier), l'IA reformate ces données vers le format attendu par l'ERP avant intégration, plutôt que de laisser quelqu'un ressaisir le catalogue à la main. Notre article sur l'intégration des tarifs fournisseurs avec l'IA détaille cette mécanique côté achats, qui suit la même logique côté catalogue produit.
• Le contrôle de cohérence entre les deux systèmes. Une IA peut comparer périodiquement les catalogues et les stocks de la boutique et de l'ERP pour signaler les écarts (référence présente d'un seul côté, prix qui divergent, stock qui ne se recoupe pas) avant qu'un client ne tombe sur une fiche produit incohérente.

Dans les trois cas, la règle reste la même que pour toute automatisation de données : l'IA propose un rapprochement ou une correction avec un niveau de confiance, une personne valide les cas ambigus. Un système qui fusionne ou corrige des fiches produit sans validation humaine finit toujours par introduire une erreur qu'il aurait fallu repérer avant publication.

Au delà de la seule synchronisation avec l'ERP, notre page sur l'IA appliquée à l'e-commerce détaille d'autres cas d'usage utiles à une boutique en ligne, du chatbot au pricing dynamique en passant par la génération de fiches produits.

Questions fréquentes sur la connexion boutique en ligne et ERP

Pour aller plus loin

• Supprimer la double saisie entre deux logiciels métier : la méthode générale pour trancher la source de vérité et le schéma de synchronisation, applicable à n'importe quel couple de logiciels.
• Synchronisation en temps réel ou en batch : comment choisir entre les deux selon le volume et la criticité du flux, en particulier pour le stock.
• Connecteur standard ou développement sur mesure : les critères pour savoir quand le module natif de l'éditeur ne suffit plus.
• Prévision de stock IA en PME : anticiper le réassort plutôt que seulement réagir aux ruptures.
• Intégrer les tarifs fournisseurs avec l'IA : la même logique de normalisation appliquée aux catalogues d'achat.
• Automatiser son e-commerce avec l'IA : 12 tâches : un panorama plus large des automatisations possibles au delà de la seule synchronisation ERP.
• Outils IA pour l'e-commerce : comparatif 2026 : les outils du marché à connaître pour compléter une intégration ERP.