Relier son site e-commerce à son ERP sans ressaisie : stocks, prix et commandes synchronisés

Une commande saisie deux fois est déjà une erreur qui attend son heure.

Un stock affiché à tort peut provoquer une survente. Un tarif B2B mal transmis peut accorder une remise que personne n'a validée. Une commande oubliée dans une boîte mail peut bloquer la préparation, et le client n'a jamais de nouvelles de son colis.

Relier un site e-commerce à un ERP ne consiste donc pas à brancher deux logiciels. Le vrai sujet : faire circuler les bonnes données, dans le bon sens, au bon rythme, avec une règle claire quand elles divergent. Ce guide, sans une ligne de code, vous aide à cadrer cette intégration e-commerce ERP avant de choisir un connecteur, un middleware ou une API.

En bref : le bon branchement commence par la bonne question

Une synchronisation fiable commence par six flux : produits, stocks, prix et tarifs clients B2B, commandes, statuts d'expédition et clients. Pour chacun, vous devez désigner une source de vérité, c'est-à-dire le système qui fait foi, puis préciser le sens de circulation et la fréquence.

Le temps réel n'est pas une promesse universelle. Un événement peut déclencher un échange rapidement, mais il faut encore recevoir la notification, traiter la donnée, gérer l'erreur et prouver le rapprochement. Les flux urgents peuvent être événementiels. D'autres peuvent fonctionner en quasi temps réel ou par lots planifiés.

Avant de commencer : avez-vous réuni les informations qui évitent les mauvaises surprises ?

La fiche de cadrage à préparer

Commencez par l'existant. Notez la plateforme e-commerce, sa version et ses extensions. Ajoutez l'ERP, la gestion des entrepôts, la facturation, les transporteurs et les éventuels outils de relation client. Shopify, PrestaShop, WooCommerce, Odoo et Sage sont des exemples à examiner, pas une liste de compatibilités garanties.

Réunissez ensuite les identifiants métier : référence produit, SKU, client, commande, entrepôt, tarif et statut. Un identifiant stable évite de créer deux fiches pour le même client ou de rattacher une commande au mauvais article.

Enfin, écrivez les règles qui existent déjà. Cela inclut les boutiques multiples, les entrepôts multiples, les taxes, les promotions, les tarifs B2B, les annulations, les retours et les commandes fractionnées. Une intégration ne corrige pas une règle floue. Elle peut au contraire la reproduire plus vite.

Le tableau des responsabilités

Pour chaque donnée, inscrivez quatre éléments : la source de vérité, le sens du flux, la fréquence (ou le déclencheur) et la règle en cas d'écart. Ajoutez en marge le nom de la personne qui contrôle le résultat.

Donnée	Source de vérité	Sens	Fréquence	Règle d'écart
Produit	ERP ou e-commerce, à décider	Vers l'autre système	Lot ou événement	Refuser l'écrasement sans validation
Stock vendable	ERP ou gestion d'entrepôt	Vers le site	Selon le risque de survente	Alerter et rapprocher
Prix B2B	ERP ou outil tarifaire	Vers le site	À chaque changement ou par lot	Priorité au tarif client négocié, écart tracé
Commande	Site e-commerce	Vers l'ERP	Événement ou quasi temps réel	Mettre en reprise si échec
Expédition	ERP ou transporteur	Vers le site	Événement ou lot court	Conserver l'historique
Client	Système désigné	Dans le sens défini	Événement ou lot	Détecter les doublons

Ce tableau est votre périmètre de départ. Il permet aussi de réaliser un audit et cadrage utile, centré sur les règles métier plutôt que sur une promesse d'outil.

Étape 1 : quels flux faut-il vraiment synchroniser, et lesquels peuvent attendre ?

But : transformer une liste de données en périmètre priorisé.

Vous n'avez pas besoin de tout connecter le premier jour. Commencez par les flux qui peuvent interrompre une vente, fausser une promesse client ou mobiliser l'ADV, c'est-à-dire l'administration des ventes.

Les produits regroupent les références, libellés, variantes et attributs. Les stocks ne se limitent pas à une quantité globale : il faut examiner les réservations, les entrepôts et la quantité réellement vendable. Les prix incluent les prix publics, les promotions et les tarifs clients B2B. Une mise à jour générique ne doit pas écraser une règle tarifaire particulière.

Les commandes partent généralement du site vers l'ERP. Le flux doit couvrir la validation, le paiement, l'annulation et le retour. Les statuts d'expédition reviennent ensuite vers le site : préparation, expédition, livraison, incident et retour. Les clients demandent une attention particulière aux adresses, aux comptes professionnels, aux consentements et aux doublons.

Le guide de Shopify sur l'intégration ERP raisonne lui aussi flux par flux : commandes et expéditions en temps réel déclenché par événement, stocks en temps réel ou planifié, reporting par lots planifiés. Le message est clair : une même intégration combine plusieurs rythmes.

Résultat attendu : une matrice qui indique ce qui circule, dans quel sens, avec quelle priorité et ce qui reste hors périmètre initial.

Étape 2 : temps réel ou lot planifié, le choix qui évite de payer pour de l'urgence inutile

But : choisir une fréquence adaptée à chaque flux.

Un webhook est une notification envoyée lorsqu'un événement précis survient. Shopify documente ce mécanisme et la liste de ses sujets d'abonnement. Pour une commande, une baisse critique de stock ou un changement de statut, ce déclenchement peut réduire le délai de propagation.

Il ne garantit toutefois ni la bonne réception ni le bon traitement. Shopify l'écrit noir sur blanc dans ses bonnes pratiques : la livraison d'un webhook n'est pas toujours garantie, un même envoi peut arriver en double et l'ordre d'arrivée n'est pas assuré. L'éditeur recommande donc de ne pas s'appuyer uniquement sur les webhooks et de lancer des tâches de réconciliation périodiques. Il faut prévoir un accusé de réception, une journalisation, une alerte et une reprise. Le temps réel est un mode d'échange, pas une garantie de cohérence parfaite.

Le quasi temps réel convient aux données importantes mais qui supportent un léger décalage. Une vérification régulière peut suffire pour certains stocks ou statuts, à condition que le délai acceptable soit écrit et contrôlé.

Les lots planifiés restent pertinents pour un catalogue volumineux, un recalcul de prix ou un rapprochement périodique. Ils réduisent parfois la complexité opérationnelle lorsque quelques minutes ou quelques heures de décalage ne changent pas la décision métier.

Résultat attendu : un rythme par flux, avec délai acceptable, fenêtre de traitement, contrôle de bonne réception et règle de reprise.

Étape 3 : connecteur, middleware ou API sur mesure, où se cache le vrai coût ?

But : comparer les voies de raccordement selon leur couverture et leur maintenance, pas selon le seul prix d'entrée.

Un connecteur natif est pertinent lorsque les flux et les règles dont vous avez besoin sont déjà couverts. Shopify le classe comme la voie la moins chère et la plus simple à maintenir, mais limitée par la feuille de route de l'éditeur. Vérifiez les limites fonctionnelles, la version prise en charge, les exceptions, le support et la manière de rejouer un échange en erreur.

Un middleware, ou iPaaS, est une plateforme qui orchestre plusieurs outils. Elle peut centraliser les transformations, les journaux et les reprises. En contrepartie, vous devez examiner le coût récurrent, la dépendance à la plateforme et les compétences nécessaires pour la superviser.

Une API est une interface documentée qui permet à un système d'échanger des données avec un autre. WooCommerce documente une API REST avec des clés d'accès et des ressources pour les produits, les commandes et les clients. PrestaShop documente un Webservice qui expose notamment les produits, les prix spécifiques, les stocks, les commandes et les clients. Côté ERP, Odoo documente une API externe pour lire et écrire ses données depuis un autre système.

Deux pièges à connaître chez Odoo : depuis Odoo 19, une nouvelle API (JSON-2) remplace les anciens points d'accès XML-RPC et JSON-RPC, dont la suppression est programmée dès l'hiver 2027 sur Odoo Online et à l'automne 2028 avec Odoo 22. Second piège : l'accès à cette API externe est réservé aux formules « Custom », pas aux offres « One App Free » ni « Standard ». Dans chaque cas, les objets réellement nécessaires, la version et l'offre utilisées doivent être vérifiés.

L'API sur mesure devient pertinente lorsque vos règles métier sont spécifiques ou que les solutions standard ne couvrent pas le besoin. Elle doit alors inclure dès le départ la sécurité des accès, les tests, les logs, la supervision, les évolutions et la maintenance.

Critère	Intégration sur mesure	Native (éditeur)	iPaaS
Coût	Élevé : fort investissement de développement au départ, puis ingénierie continue	Faible : souvent inclus dans les licences du logiciel	Moyen : abonnement, facturé selon l'usage ou le nombre de flux
Délai de mise en place	Long : projets de plusieurs mois (développement et recette)	Rapide : connecteurs prêts à l'emploi, configuration guidée	Court : connecteurs prêts à l'emploi pour les flux standard, mais mappings et configuration restent à faire
Montée en charge	Variable : fragile si l'on multiplie les liens point à point	Bonne : excellente pour des paires précises, limitée par la feuille de route de l'éditeur	Élevée : cloud natif, mise à l'échelle automatique pour des parcs multi-applications
Expertise technique	Élevée : développeurs seniors et architectes nécessaires	Faible à moyenne : compétences d'administration, support guidé	Moyenne : les outils low-code limitent le besoin de code poussé
Maintenance	Élevée : chaque changement d'API demande une reprise manuelle du code	Faible : l'éditeur gère les mises à jour principales	Faible à moyenne : le fournisseur gère sécurité et mises à jour
Cas d'usage probable	Systèmes anciens de niche sans connecteur	Paires standard (comme Shopify et NetSuite)	Synchronisation temps réel complexe entre plusieurs systèmes (ERP, WMS, CRM)

Tableau adapté et traduit de Shopify, « ERP Integration: Methods, Benefits, and Examples ». Le tableau d'origine compare aussi les ESB et les ETL, non repris ici.

Résultat attendu : une décision motivée flux par flux. Le choix peut être hybride : un connecteur pour un échange standard, un middleware pour orchestrer, et une API sur mesure pour une règle spécifique.

Étape 4 : quand les données se contredisent, qui tranche et qui reçoit l'alerte ?

But : prévoir le fonctionnement dégradé avant la première anomalie.

Une survente peut venir d'un stock indisponible, d'une réservation non remontée ou d'un échange arrivé dans le mauvais ordre. La règle doit préciser s'il faut bloquer la vente, alerter l'équipe et rapprocher les quantités.

Un prix divergent exige une décision explicite. Le tarif de l'ERP peut être prioritaire pour certains clients, tandis qu'une promotion peut être pilotée par le site. Dans tous les cas, évitez l'écrasement aveugle et conservez la trace de la décision.

Une commande en échec doit être détectée, placée dans une file de reprise et rendue visible à l'ADV. Le rapprochement avec le paiement évite de préparer deux fois la même commande ou de laisser une vente payée sans traitement.

Quand un événement est rejoué, l'idempotence évite de créer deux fois la même opération. Concrètement, l'échange doit reconnaître un identifiant déjà traité et ne pas dupliquer la commande. Shopify, par exemple, joint à chaque webhook un identifiant unique (X-Shopify-Webhook-Id) pour écarter les envois en double. L'historique doit conserver l'identifiant de corrélation, le statut, l'erreur et la personne qui a repris le dossier.

Résultat attendu : une procédure de reprise avec alerte, responsable, délai de traitement et preuve de rapprochement.

Ce qui fait varier le coût et le délai, ce n'est pas seulement le nombre d'outils

Le périmètre dépend du nombre de flux et de canaux, mais aussi de la qualité des données existantes. Les tarifs B2B, les entrepôts multiples, les retours et les commandes fractionnées pèsent souvent davantage que le nom des logiciels.

Les interfaces disponibles, les transformations nécessaires, la sécurité des accès, la supervision et la reprise influencent aussi le projet. Un connecteur rapide à installer peut couvrir moins de cas : chaque exception qu'il ignore se traite alors à la main ou par un développement à côté. Une architecture plus spécifique peut mieux respecter votre métier, mais demande plus de cadrage.

La gouvernance compte enfin autant que la technique. Il faut un interlocuteur métier, une validation des règles, une recette, une procédure de mise en production et une responsabilité de maintenance. Aucun choix ne garantit un temps réel parfait.

Vérification finale : votre synchronisation est-elle pilotable le jour où elle déraille ?

Avant la mise en service, vérifiez les points suivants :

• Chaque donnée possède une source de vérité et un sens de circulation.
• Les produits, stocks, prix B2B, commandes, statuts et clients ont un rythme documenté.
• Les règles d'annulation, de retour, de doublon et de conflit sont testées.
• Les erreurs sont visibles, rejouables et attribuées à un responsable.
• Un rapprochement périodique vérifie que les systèmes racontent la même histoire.
• La recette couvre les cas normaux et les cas dégradés.

Si une réponse manque, l'intégration n'est pas encore pilotable.

FAQ : les questions qui bloquent encore le projet

Faut-il synchroniser tous les flux dès le départ ?

Non. Priorisez les flux qui présentent le plus de risque opérationnel ou la plus forte valeur métier. Élargissez ensuite le périmètre après une recette concluante.

Un connecteur suffit-il toujours ?

Non. Contrôlez les règles métier, les versions, les exceptions, les logs, la supervision et la reprise. Une couverture annoncée ne signifie pas que vos cas particuliers sont gérés.

Le temps réel est-il obligatoire pour les stocks ?

Cela dépend du délai acceptable, de la fréquence des ventes et du risque de survente. Un rythme quasi temps réel ou un lot fréquent peut suffire si le décalage est connu, surveillé et accepté.

Que faut-il demander à un intégrateur ?

Demandez la matrice des flux, les sources de vérité, les responsabilités, le plan de reprise, les tests, la supervision et les conditions de maintenance. Le choix technique doit découler de ces réponses. Ce sont aussi les points que Koul cadre avec vous en début de projet (voir ci-dessous).

La bonne intégration est celle que vos équipes peuvent expliquer

Le cadrage suit une séquence simple : flux, source de vérité, fréquence, voie de raccordement, puis reprise des écarts. Cette séquence donne à vos équipes un langage commun pour décider et contrôler.

La bonne intégration n'est pas celle qui promet de tout synchroniser tout le temps. C'est celle qui sait quoi faire quand la donnée manque.

Faire réaliser l'intégration par Koul

Koul est une agence de logiciels métier et d'IA : relier un site e-commerce à un ERP fait partie des prestations que nous pouvons prendre en charge, du cadrage à la mise en production.

• Cadrage : matrice des flux, sources de vérité, rythmes et règles d'écart, comme décrit dans ce guide.
• Choix du raccordement : connecteur, middleware ou API sur mesure, argumenté flux par flux, sans parti pris pour une solution.
• Réalisation : développement des échanges, avec sécurité des accès, journalisation, alertes et file de reprise dès le départ.
• Recette et exploitation : tests des cas normaux et dégradés, mise en production, supervision et maintenance.

Si vous voulez partir de votre situation réelle, prenez rendez-vous avec l'équipe Koul : 30 minutes pour clarifier vos flux et vos sources de vérité.