Quand une boutique en ligne commence à vendre sérieusement, les bricolages deviennent visibles. Les stocks ne tombent pas juste, les commandes se dupliquent, la facturation part avec retard, et l'équipe passe ses journées à corriger des écarts entre plusieurs outils. À ce stade, connecter ERP et site e commerce n'est plus un sujet de confort. C'est un sujet d'exploitation.
Le vrai problème n'est pas l'existence de deux systèmes. Le problème, c'est l'absence de règle claire sur qui porte la vérité métier. Si le site dit une chose, l'ERP une autre, et qu'un fichier Excel vient arbitrer entre les deux, vous avez déjà une dette opérationnelle. Elle coûte en temps, en erreurs, en support client, et parfois en marge.
Pour une TPE ou une PME, le sujet est rarement de "faire une intégration" au sens abstrait. Il s'agit plutôt de remettre de l'ordre dans un flux commercial déjà vivant, sans casser la production, sans bloquer les équipes, et sans découvrir trop tard que le connecteur acheté sur étagère ne couvre que 60 % du besoin réel.
Connecter ERP et site e-commerce: ce qu'il faut décider avant de coder
Le premier travail n'est pas technique. Il consiste à poser les responsabilités de chaque système. Dans une architecture saine, on sait où naît chaque donnée, qui a le droit de la modifier, et dans quel sens elle circule.
En pratique, l'ERP est souvent le maître pour les prix B2B, les comptes clients, les conditions de paiement, les références produits, les stocks disponibles, la facturation et parfois la logistique. Le site e-commerce, lui, gère l'expérience de vente, le panier, le tunnel de commande, les promotions marketing, certains contenus produits et les interactions client. Mais ce partage varie selon votre activité.
Si vous vendez un catalogue simple en D2C, la logique peut être assez directe. Si vous gérez plusieurs dépôts, des tarifs contractuels, des commandes mixtes, des reliquats, ou un cycle de préparation complexe, l'intégration change de nature. On ne relie plus juste deux API. On modélise des règles métier.
C'est là que beaucoup de projets dérapent. L'équipe parle de synchroniser les commandes, mais personne n'a tranché des questions basiques. Que faire d'une commande payée alors que le stock ERP a changé ? Quel système crée le client ? Peut-on modifier une commande après validation ? Quid des avoirs, annulations, retours, commandes partielles ?
Sans ces réponses, le code produit seulement une illusion de connexion.
Les flux qui comptent vraiment
Sur le terrain, quatre flux concentrent l'essentiel du risque.
Le premier, c'est le catalogue. Il faut décider si les fiches produit viennent de l'ERP, du site, ou d'une couche intermédiaire. Si votre ERP contient des références techniquement exactes mais pauvres commercialement, le site devra souvent enrichir titres, médias, descriptions et SEO. Il faut alors éviter qu'une mise à jour ERP écrase ce travail.
Le second flux, c'est le stock. C'est aussi le plus sensible. Un stock mal piloté ne produit pas juste des erreurs internes. Il crée des ventes impossibles, du service client tendu et une perte de confiance. La fréquence de synchronisation, la gestion du stock réservé, les variations par entrepôt et les seuils de sécurité doivent être définis noir sur blanc.
Le troisième, ce sont les commandes. Là encore, le détail compte. Une commande n'est pas qu'un en-tête et des lignes. Il y a les modes de paiement, les taxes, les remises, les frais de port, les cadeaux, les statuts, les commentaires, les transporteurs, les pièces jointes parfois. Si vous simplifiez trop, la comptabilité ou la logistique récupérera le problème plus tard.
Le quatrième, c'est la donnée client. B2C et B2B ne se traitent pas pareil. En B2B, on gère souvent plusieurs contacts, des adresses multiples, des conditions commerciales, des numéros de TVA, des plafonds de crédit, voire des validations de commande. Le site peut être beau, mais si le modèle client n'est pas aligné avec l'ERP, l'expérience réelle restera bancale.
Connecter ERP et site e commerce: le piège du faux temps réel
Beaucoup de décideurs demandent du temps réel parce que cela semble plus propre. En réalité, ce n'est pas toujours le bon choix.
Le temps réel a un coût. Il augmente la dépendance entre systèmes, durcit les contraintes de disponibilité, et transforme chaque lenteur API en incident visible. Si l'ERP répond mal ou tombe, votre front e-commerce peut se retrouver bloqué sur des opérations critiques.
Pour certains flux, le quasi temps réel suffit largement. Un stock mis à jour toutes les 2 à 5 minutes peut être acceptable. Un catalogue poussé toutes les heures aussi. En revanche, la création de commande ou la remontée d'un paiement peuvent nécessiter une propagation immédiate ou quasi immédiate.
Le bon niveau de synchronisation dépend du volume, du risque métier et de la tolérance à l'écart. Une PME n'a pas besoin d'une architecture brillante sur le papier. Elle a besoin d'une architecture qui tient la charge, explique ses erreurs et se rattrape proprement.
API, middleware, connecteur natif ou développement sur mesure
Il n'existe pas de réponse universelle. Il existe des compromis.
Le connecteur natif est attirant parce qu'il promet une mise en route rapide. C'est parfois une bonne option pour un périmètre simple. Mais il faut lire au-delà de la plaquette. Quels champs sont réellement couverts ? Que se passe-t-il en cas d'erreur ? Peut-on rejouer un flux ? Les transformations métier sont-elles possibles ? Le support comprend-il vos particularités ou seulement le cas standard ?
Le middleware peut être pertinent quand plusieurs systèmes doivent cohabiter, ou quand on veut centraliser les mappings et la supervision. C'est utile, mais cela ajoute une couche de plus à opérer. Si personne ne sait la maintenir, vous déplacez le problème au lieu de le résoudre.
Le sur mesure est souvent le bon choix quand l'existant est déjà spécifique, quand l'ERP est ancien, ou quand le modèle commercial sort des chemins standards. Le sur mesure n'est pas automatiquement plus risqué. Il l'est surtout quand on code sans audit, sans journalisation sérieuse et sans stratégie de reprise. Je lis votre code avant d'en écrire. Sur ce type de sujet, c'est une règle de survie, pas une posture.
Ce qui casse en production
Les incidents les plus coûteux sont rarement spectaculaires au départ. Ils s'installent dans les détails.
On voit des doublons de commandes créés lors d'un timeout, parce qu'aucune clé d'idempotence n'a été prévue. On voit des statuts incohérents entre paiement, préparation et expédition. On voit des mappings de TVA incomplets qui faussent la comptabilité. On voit des produits désactivés côté site mais toujours vendables via un flux de stock resté actif.
Il y a aussi les problèmes de gouvernance technique. Personne ne sait où consulter les logs. Les erreurs partent par email dans une boîte jamais lue. Les traitements tournent par cron sans supervision. Et quand une panne survient, l'équipe n'a ni tableau de bord, ni procédure de reprise, ni estimation de l'impact.
Une intégration sérieuse ne consiste pas seulement à faire passer des données. Elle doit rendre les écarts visibles, tracer les transformations, isoler les erreurs et permettre une reprise sans improvisation.
La bonne méthode pour une PME déjà en activité
La bonne approche est progressive. On commence par auditer l'existant, pas par lancer un chantier d'intégration de six mois. Il faut comprendre les systèmes en place, les vraies irritations métier, les contraintes du code existant et le niveau de fiabilité des données.
Ensuite, on choisit un périmètre initial serré. Par exemple: catalogue, stock et commandes, sans traiter tout de suite les retours complexes, les avoirs ou la logique omnicanale. Cela permet de mettre en place les fondations: mapping, journalisation, supervision, files de reprise, tests de non-régression, et règles de vérité métier.
Puis on passe en production avec des garde-fous. Double lecture sur certains flux, mode dégradé documenté, tableaux de contrôle, et procédure claire en cas d'écart. Pragmatique et ennuyeux - comme ça doit l'être.
Enfin, on élargit. Une fois les flux vitaux stabilisés, on ajoute les cas périphériques, les raffinements métier, les automatisations annexes, ou une couche analytique si elle a un vrai usage.
Comment savoir si votre projet est prêt
Si vous ne pouvez pas répondre simplement à qui est maître du stock, de la commande, du client et du prix, le projet n'est pas prêt. Si vos équipes corrigent régulièrement des écarts à la main, il faut d'abord observer ces corrections. Elles révèlent la vérité du métier.
Si l'ERP est ancien, mal documenté ou déjà contourné par des exports manuels, il faut intégrer cette réalité dès le départ. Le bon projet n'est pas celui qui nie les contraintes. C'est celui qui les encadre.
Pour un dirigeant, le bon indicateur n'est pas la promesse d'une connexion rapide. C'est la capacité du prestataire à poser les mauvaises questions tôt, à réduire le périmètre intelligemment, et à assumer l'exploitation après mise en service. Chez Rocket Services, ce type de travail commence par du diagnostic concret, pas par un discours sur la transformation.
Connecter un ERP à un site e-commerce est un sujet d'architecture, mais surtout un sujet de discipline. Si vous traitez l'intégration comme un simple projet technique, elle vous reviendra en incident métier. Si vous la traitez comme un chantier de fiabilité, elle peut enfin retirer du travail manuel au lieu d'en créer.
Questions fréquentes
- Quel système doit être maître du stock, du prix et de la commande ?
- L'ERP est généralement maître du stock disponible, des prix B2B, des références produits et de la facturation. Le site e-commerce gère l'expérience de vente et les promotions marketing. Mais ce partage dépend de votre activité : si vous avez plusieurs dépôts, des tarifs contractuels ou des commandes complexes, les règles changent.
- Faut-il vraiment une synchronisation en temps réel entre ERP et site ?
- Pas systématiquement. Un stock mis à jour toutes les 2 à 5 minutes peut suffire, tout comme un catalogue poussé toutes les heures. Le temps réel augmente la dépendance entre systèmes et les risques d'incident. Le bon niveau dépend du volume, du risque métier et de votre tolérance à l'écart.
- Connecteur natif, middleware ou développement sur mesure : quel choix pour une PME ?
- Il n'existe pas de réponse universelle. Un connecteur natif convient pour un périmètre simple, mais vérifiez quels champs il couvre réellement et comment il gère les erreurs. Le sur mesure est souvent pertinent quand l'ERP est ancien, spécifique ou quand le modèle commercial sort des standards. L'important est de lire le code existant avant de coder.
- Par où commencer si on a déjà une boutique en activité ?
- Commencez par auditer l'existant pour comprendre les vrais problèmes métier, pas par lancer un chantier d'intégration complet. Choisissez ensuite un périmètre initial serré (catalogue, stock, commandes) pour mettre en place les fondations : journalisation, supervision, tests. Puis élargissez progressivement une fois les flux vitaux stabilisés.
- Quels sont les incidents les plus courants en production ?
- Les doublons de commandes lors de timeouts (sans clé d'idempotence), les statuts incohérents entre paiement et préparation, les mappings de TVA incomplets qui faussent la comptabilité, et l'absence de supervision des traitements automatisés. Ces problèmes viennent rarement d'une architecture mal pensée, mais de détails mal encadrés et d'une mauvaise gouvernance technique.