Comment fonctionne une synchronisation ERP ↔ e-commerce

« Il suffit de synchroniser les stocks entre l'ERP et le site. » C'est la phrase qui déclenche la plupart des projets d'intégration e-commerce, et c'est aussi le premier malentendu. Derrière cette apparente simplicité se cache une architecture à part entière, avec ses flux, ses compromis et ses modes de panne.

Une synchronisation ERP ↔ e-commerce, ce n'est pas un script qui recopie une colonne d'une base vers une autre. C'est un système distribué qui doit rester cohérent entre deux logiciels qui n'ont ni le même modèle de données, ni le même rythme, ni la même définition de la vérité. Le jour où le flux tombe, ce n'est pas un bug isolé : c'est le stock qui ment, la commande qui se perd, ou le client qui achète un produit épuisé.

Cet article explique, pour des décideurs et des CTO en phase de découverte, comment fonctionne réellement une telle synchronisation : ce qu'on échange, selon quels patterns, avec quels pièges, et comment cadrer le projet avant de se lancer.

Ce qu'on synchronise réellement

Réduire le sujet aux stocks masque l'essentiel. Un flux ERP ↔ e-commerce fait circuler plusieurs natures de données, dans les deux sens.

Dans le sens ERP → site (sortant), on retrouve le catalogue (fiches produit, caractéristiques, arborescence), les stocks, les prix et les promotions, ainsi que les statuts d'expédition (numéro de suivi, date d'envoi). Dans le sens site → ERP (entrant), ce sont surtout les commandes et les clients qui remontent pour être traités par la logistique et la comptabilité.

Chaque flux a sa propre criticité et sa propre contrainte de fraîcheur. Un stock qui traîne de dix minutes provoque des surventes ; une description produit peut se contenter d'une mise à jour nocturne. Traiter tous ces flux avec la même mécanique est la première erreur d'architecture.

Les trois patterns d'intégration

Il existe trois grandes façons de faire circuler ces données. Aucune n'est universellement meilleure : chacune répond à un compromis entre réactivité, complexité et couplage.

Pull périodique

Le site (ou un middleware) interroge l'ERP à intervalles réguliers : « donne-moi les stocks modifiés depuis la dernière fois ». C'est le plus simple à mettre en place et le plus tolérant aux pannes — si une exécution échoue, la suivante rattrape. En contrepartie, il introduit une latence (l'écart entre deux exécutions) et une charge inutile quand rien n'a changé. C'est souvent le bon choix pour un import de catalogue fournisseur vers Magento ou son équivalent côté PrestaShop, où la fraîcheur à la minute n'est pas exigée.

Push

À l'inverse, l'ERP émet la donnée dès qu'elle change et la pousse vers le site. La réactivité est excellente. Mais ce pattern suppose que l'ERP sache émettre : webhook natif, connecteur, ou capacité à déclencher un appel sortant. Beaucoup d'ERP de PME/ETI ne savent pas faire cela proprement, ou seulement pour une partie des événements. Le push reporte alors la complexité côté ERP, ce qui n'est pas toujours négociable.

Event-driven

Entre les deux, l'approche pilotée par les événements découple les systèmes via un bus de messages ou des webhooks : l'ERP (ou une couche d'intégration) publie un événement « stock modifié », et un ou plusieurs consommateurs le traitent à leur rythme. On gagne la réactivité du push et le découplage du pull : le producteur ne connaît pas les consommateurs. C'est l'architecture qui sous-tend une véritable synchronisation temps réel ERP ↔ e-commerce, au prix d'une infrastructure un peu plus riche (file de messages, workers, supervision).

Delta ou full : le compromis de la volumétrie

Deuxième arbitrage structurant : envoie-t-on tout à chaque cycle, ou seulement ce qui a changé ?

Le full (rejouer l'intégralité du catalogue ou des stocks) est simple et auto-correcteur : quelle que soit la dérive accumulée, un cycle complet remet tout d'aplomb. Mais il coûte cher — bande passante, temps de traitement, charge sur l'ERP — et devient ingérable au-delà de quelques dizaines de milliers de références si on veut de la fréquence.

Le delta (n'envoyer que les enregistrements modifiés) est rapide et léger, mais piégeux à fiabiliser : il faut un horodatage ou un marqueur de changement fiable côté source, et surtout gérer les deltas manqués. La parade récurrente consiste à combiner les deux : un delta fréquent pour la réactivité, doublé d'un full périodique (souvent nocturne) qui rattrape les écarts. Dans tous les cas, chaque opération doit être idempotente : rejouer deux fois la même mise à jour doit produire le même résultat, sans doublon ni double décrément.

Les pièges classiques

Les projets d'intégration échouent rarement sur l'algorithme. Ils échouent sur les cas limites que voici.

• Surventes en multi-canal. Dès qu'un même stock alimente le site, des marketplaces et un magasin, la moindre latence de synchronisation vend un produit déjà parti ailleurs.
• Doublons et matching SKU/EAN. L'ERP raisonne en références internes, le site en SKU, les fournisseurs en EAN. Un mapping approximatif crée des doublons ou associe la mauvaise fiche.
• Casse silencieuse au changement de format. Un fournisseur ajoute une colonne, change un séparateur, renomme un champ — et l'import continue de « fonctionner » en intégrant des données fausses.
• Images manquantes. Le texte se synchronise, les visuels non : lien mort, chemin FTP modifié, média jamais publié.
• Deltas ratés. Une modification passée pendant une fenêtre de panne n'est jamais rejouée, et l'écart persiste jusqu'au prochain full — s'il existe.
• Absence de reprise sur incident. Un flux qui plante au milieu d'un lot, sans point de reprise, laisse le système dans un état partiellement synchronisé.

Résilience et supervision

Un flux d'intégration n'est pas un traitement ponctuel : c'est un service qui doit encaisser les pannes réseau, les indisponibilités temporaires de l'ERP et les pics de charge. Concrètement, cela veut dire faire transiter les opérations par des files de messages — avec Symfony Messenger et un transport Redis, AMQP ou Doctrine selon le contexte — plutôt que de les exécuter en direct.

Ce découplage ouvre les mécanismes de robustesse indispensables : rejeu automatique d'un message en échec avec temporisation, et dead letter queue pour isoler les messages définitivement irrécupérables au lieu de bloquer toute la file. En PME/ETI, ces transports suffisent très largement ; un bus comme Kafka n'est que rarement nécessaire et alourdit inutilement l'exploitation.

Reste le point le plus souvent négligé : l'observabilité. Sans supervision dédiée — métriques par flux, alerte sur les échecs et sur les anomalies (un import qui passe subitement de mille à zéro ligne) — personne ne sait que le flux est cassé avant que le client ne s'en plaigne. Un flux non supervisé n'est pas fiable : il est simplement silencieux.

Faut-il un middleware iPaaS ou un développement sur mesure ?

La question revient systématiquement, et la réponse n'est pas idéologique. Un iPaaS (plateforme d'intégration avec connecteurs préconfigurés) fait très bien le travail quand il s'agit de câbler deux systèmes standards sur des flux simples et bien balisés : time-to-market rapide, maintenance déléguée.

Le sur-mesure s'impose dès qu'il y a de la logique métier riche — règles de prix conditionnelles, gestion fine des promotions, contraintes de conditionnement —, plusieurs sources à réconcilier, ou une véritable orchestration des commandes (OMS) entre entrepôts et canaux. C'est typiquement le terrain d'un connecteur Magento sur mesure ou d'un connecteur entre Magento et les marketplaces, là où les connecteurs génériques atteignent vite leurs limites. Les deux approches ne s'excluent d'ailleurs pas : on peut réserver le sur-mesure aux flux à forte valeur métier et laisser un iPaaS gérer le reste.

Comment cadrer et chiffrer un projet d'intégration

La meilleure garantie contre les mauvaises surprises n'est pas technique : c'est une phase de cadrage sérieuse en amont. Elle consiste à répondre méthodiquement à quelques questions pour chaque échange.

• Lister les flux un par un — catalogue, stocks, prix, promotions, commandes, statuts d'expédition, clients — plutôt que de parler d'« une » synchronisation globale.
• Qualifier la source et la cible : l'ERP expose-t-il une API, des exports, une base ? Sait-il émettre des événements ? Quelles sont ses vraies capacités, pas celles de la plaquette.
• Définir la contrainte de fraîcheur par flux : temps réel pour le stock, horaire pour les prix, nocturne pour les fiches.
• Estimer la volumétrie : nombre de références, de commandes par jour, pics saisonniers. C'est ce qui tranche entre full et delta.
• Prévoir la gestion des anomalies : que fait le système quand une donnée est invalide, qu'un service est indisponible, qu'un delta est manqué ?

Un connecteur standard peut suffire quand les systèmes sont courants et les flux simples — c'est l'objet de mes connecteurs ERP ↔ Magento. Mais c'est le cadrage, flux par flux, qui révèle s'il faut ce niveau d'intégration ou un développement plus poussé. Ce travail d'analyse préalable coûte quelques jours ; il évite des semaines de correctifs et des surventes en production.

En résumé

Synchroniser un ERP et un e-commerce, ce n'est pas recopier des stocks : c'est concevoir un système distribué cohérent, choisir un pattern (pull, push ou event-driven) adapté à chaque flux, arbitrer entre full et delta, garantir l'idempotence et, surtout, superviser l'ensemble pour détecter les pannes avant les clients. Les projets qui réussissent sont ceux qui ont pris le temps de cadrer chaque flux au lieu de traiter « la synchro » comme un détail technique.

C'est exactement l'approche que je privilégie : partir des flux réels et de leurs contraintes, puis choisir entre connecteur standard et développement sur mesure. Vous avez un projet de connexion entre votre ERP et votre boutique, ou un flux existant qui casse silencieusement ? Parlons-en.