Vous gérez une boutique WooCommerce et un ERP (Dolibarr, Sage, Ciel...). Vos clients commandent en ligne, mais les stocks ne se mettent à jour que manuellement. Les factures se doublent. Les informations clients s'éparpillent entre deux systèmes. Résultat : perte de temps, erreurs récurrentes, clients frustres.

Ce problème n'est pas rare en TPE/PME. La solution : une intégration automatisée entre WooCommerce et votre ERP. Pas de magic, juste de la technique bien pensée.

Le défi réel : pourquoi c'est plus complexe qu'il y paraît

Connecter deux plateformes, c'est séduisant sur le papier. En pratique, plusieurs obstacles surgissent :

  • La donnée n'est pas toujours au même format. WooCommerce gère les produits différemment qu'un ERP classique. Les variantes, les promotions, les métadonnées n'arrivent pas toutes.
  • Les flux doivent être bidirectionnels. Un produit WooCommerce doit mettre à jour le stock ERP, mais aussi l'inverse : si un client annule une commande en ERP, WooCommerce doit le savoir.
  • La timing est critique. Si une commande arrive à 14h30 sur WooCommerce mais que l'ERP traite les synchronisations toutes les heures, vous ratez 30 minutes d'intégrité.
  • Les erreurs réseau existent. Que se passe-t-il si la synchronisation échoue à mi-chemin ? La donnée est-elle perdue, dupliquée ?

Les trois approches : middleware, API directe ou plugin spécialisé

1. Plugin WooCommerce dédié (rapide, limité)

Des plugins comme WooCommerce Connector ou des extensions Dolibarr offrent une synchronisation pré-configurée. Avantage : mise en place rapide, pas de code à écrire. Inconvénient : rigidité. Vous ne pouvez pas personnaliser les règles (ex. : ne pas synchroniser les commandes en dessous de 50€, transformer les statuts spécifiques).

2. Middleware (flexible, maintenance)

Un service intermédiaire (Zapier, Make, ou un script maison) orchestre les échanges entre WooCommerce et l'ERP. Chaque événement WooCommerce (commande créée, produit modifié) déclenche une action ERP via API. Avantage : adapté à votre métier. Inconvénient : vous gérez l'infrastructure, les logs, les retry.

3. Intégration API directe sur mesure (optimal, investissement)

Votre équipe (ou un prestataire) développe un connecteur spécifique. L'application expose les événements WooCommerce (webhooks), écoute les changements ERP (polling ou webhooks), et maintient une couche de synchronisation robuste. C'est la solution pour les plugins WooCommerce exigeants ou évolutifs.

Les pièges à désamorcer avant de commencer

Perte de données en doublon. Si deux systèmes tentent de modifier la même commande simultanément, laquelle gagne ? Définissez une « source de vérité » unique (ex. : WooCommerce pour les commandes client, ERP pour les modifications de stock par votre équipe).

Sync infini. Produit modifié en ERP → WooCommerce → webhook → ERP de nouveau. Ajoutez un timestamp ou un hash pour détecter si une donnée a vraiment changé.

Performance dégradée. Une synchronisation mal écrite peut surcharger votre base de données. Utilisez des jobs asynchrones (cron, queue) au lieu de requêtes synchrones en temps réel.

Problèmes de sécurité. Les API ERP exposent des données sensibles (prix de revient, marges, infos client). Employez une authentification robuste (OAuth2, clés API avec scopes) et limitez l'accès à ce qui est nécessaire.

Une architecture qui marche : le flux recommandé

Voici ce qui fonctionne bien chez les PME que nous suivons :

  1. WooCommerce → ERP : Chaque nouvelle commande WooCommerce déclenche un webhook. Un worker asynchrone capture l'événement, formate la commande selon le schéma ERP, et l'insère via API. Statut : queued, puis confirmé ou erreur.
  2. ERP → WooCommerce : Chaque nuit (ou toutes les heures), un script interroge l'ERP pour les mises à jour de stock/produits depuis la dernière sync. Les changements sont appliqués à WooCommerce. Fallback : les clients voient un message « mise à jour stock » si c'est trop vieux.
  3. Suivi centralisé : Un dashboard simple affiche les syncs échouées. Alertes email si plus de N erreurs en 1h.

Cette approche découple les deux systèmes (pas de requêtes synchrones bloquantes) tout en restant fiable.

Pour une intégration sur mesure, cette logique peut être implémentée en quelques semaines et coûte moins cher qu'une année d'erreurs manuelles.

Quels outils/techs choisir ?

Si vous avez un développeur en interne :

  • Laravel / Symfony : connecteurs PHP robustes, packages Dolibarr déjà existants.
  • Node.js : performant pour orchestrer flux async, logs structurés faciles.
  • Python : scripts de sync simples, libraries Dolibarr éprouvées.

Sinon, envisagez un prestataire. Nos modules Dolibarr incluent souvent des connecteurs WooCommerce prêts à adapter.

Quand c'est prêt : monitoring et maintenance

L'intégration ne s'arrête pas au déploiement. Surveillez régulièrement :

  • Taux d'erreur de synchronisation (< 0.5% est bon).
  • Latence (combien de temps avant qu'un produit modifié en ERP apparaisse en boutique ?).
  • Écarts de stock (audit bimensuel : compte réel vs. données sync).

Préservez une procédure de « resync d'urgence » en cas de grosse panne.

Prochaines étapes

Évaluer l'approche qui vous convient commence par dresser l'inventaire de vos données critiques : quels champs, quel volume, quelle fréquence d'update. Si vous avez besoin d'aide pour cartographier cela et valider une architecture, contactez-nous. Nous avons guidé des dizaines de PME à travers ce processus.

Questions fréquentes

Ça dépend de votre besoin. Si vous vendez 20 commandes/jour, une synchro toutes les heures est fine. Si c'est 200/jour et que vous gérez peu de stock, le temps réel devient utile pour éviter les ruptures. Commencez par horaire (plus simple, moins coûteux), et upscalez si les problèmes surgissent.

Un plugin clé en main : 200–500€/an. Un middleware (Make, Zapier) : 50–200€/mois selon la complexité. Une intégration sur mesure : 5k–15k€ selon les règles métier. Comparez au coût des erreurs manuelles (1h/jour × votre taux horaire = vite justifié).

Non, si l'architecture est bien pensée. Les webhooks sont re-tentés, les jobs en queue persistent. C'est pourquoi un middleware ou un script maison avec retry logic est plus sûr qu'un plugin simple.