Hier encore, les commandes web remontaient dans Sage, Odoo ou Cegid. Ce matin, silence : les ventes en ligne continuent, mais votre ERP ne communique plus avec votre boutique. Stocks figés, commandes à resaisir à la main, équipe logistique dans le flou. Ce n'est pas « un bug PrestaShop » — c'est la rupture d'un flux métier critique.
Chez Apresta, on intervient régulièrement sur ce type d'urgence chez des PME de Lille et des Hauts-de-France. Dans 80 % des cas, la cause est identifiable en moins de deux heures : token expiré, mise à jour silencieuse, quota API dépassé ou middleware arrêté. Voici comment diagnostiquer, corriger et éviter que ça se reproduise.
Symptômes : reconnaître une rupture de sync ERP–boutique
La coupure se manifeste d'abord par des signaux opérationnels que l'équipe finit par normaliser. Les commandes web n'apparaissent plus dans l'ERP depuis plusieurs heures ou plusieurs jours, alors que la boutique continue d'enregistrer des ventes. Les stocks affichés côté site reflètent une dernière synchronisation connue — souvent datée — et les alertes du connecteur ont cessé, parfois parce que personne ne les recevait déjà.
Avant la panne totale, des signaux plus discrets annoncent le problème : la sync ralentit progressivement (quinze minutes de décalage qui deviennent deux heures), des erreurs intermittentes « timeout » ou « 401 Unauthorized » apparaissent dans les logs, et des doublons de commandes surgissent après des tentatives de relance manuelle. Si l'équipe resaisit les commandes à la main, le double run masque l'ampleur réelle de la rupture. Plus la sync accumule de retard, plus le rattrapage devient risqué : conflits de stock, commandes dupliquées, litiges clients.
Causes les plus fréquentes de coupure
La coupure est rarement « l'ERP est en panne ». C'est presque toujours le pont entre les deux systèmes qui lâche.
Expiration ou révocation des tokens API
Les connecteurs OAuth ou clés API expirent selon des cycles fixes (30, 90 ou 365 jours). Une rotation de mot de passe ERP ou boutique invalide les credentials stockés dans le middleware sans que personne ne soit alerté. Le scénario classique : tout fonctionnait, puis silence total après une mise à jour de sécurité IT.
Mise à jour ERP, boutique ou connecteur
Une montée de version Sage, WooCommerce, module PrestaShop ou app Shopify peut casser un endpoint, renommer un champ ou durcir l'authentification. Les mises à jour automatiques sans environnement de test restent un classique chez les PME qui n'ont pas de staging miroir.
Middleware ou cron arrêté
Make, n8n, script Python sur VPS ou tâche cron : si le serveur qui exécute la sync est down, redémarré sans relance, ou si le cron est mal reconfiguré après migration, plus aucun flux ne part. Le dashboard middleware affiche alors des erreurs rouges que personne ne consulte.
Quotas, rate limiting et changements réseau
Shopify, WooCommerce REST et les API ERP imposent des limites de requêtes par heure. Au-delà, l'API renvoie 429 Too Many Requests et le connecteur boucle en erreur jusqu'à blocage temporaire. Parallèlement, un nouveau VPN entreprise, une IP whitelist côté ERP ou une migration hébergeur boutique peut refuser les connexions entrantes du middleware depuis sa nouvelle adresse.
Données invalides et connecteurs tiers
Une fiche produit avec caractère spécial, un SKU dupliqué ou une commande avec ligne à 0 € peut bloquer tout le lot suivant si le connecteur n'est pas robuste — une seule entité corrompue suffit. De même, une app du marketplace Shopify abandonnée ou un module PrestaShop dont l'abonnement expire laisse le pont sans maintenance.
Diagnostic pas à pas
Commencez par définir précisément ce qui ne passe plus : commandes boutique vers ERP, stocks ERP vers boutique, produits, clients, factures ou expéditions. Un flux peut fonctionner et pas l'autre — cela oriente vers un endpoint ou un mapping spécifique plutôt qu'une panne générale.
Consultez ensuite les logs du middleware (Make, n8n, connecteur natif), la table de suivi sync (last_sync_at, file d'attente) et les alertes email ou Slack. Notez l'heure exacte du dernier succès et corrélez avec un déploiement, une mise à jour ou un incident hébergeur.
Testez les credentials manuellement avec Postman ou curl : appel API ERP (GET produit, GET stock), appel API boutique (GET commande test), vérification expiration token OAuth et scopes. Erreur 401 → credentials. Erreur 403 → droits. Timeout → réseau ou serveur ERP injoignable.
Pour isoler une entité problématique, relancez la sync sur une seule commande ou un seul produit. Si ça passe, le blocage vient d'une entité en amont dans la file — parcourez les logs pour identifier le SKU ou l'ID commande fautif. Terminez par l'infrastructure du pont : le VPS ou worker cron est-il up, l'espace disque plein, les files d'attente (Redis, RabbitMQ) saturées ?
Corrections : urgent, important, plus tard
Urgent — rétablir le flux (heures à 48 h)
L'objectif immédiat est de rétablir le flux avant que l'écart stock ne devienne un litige. Renouvelez les tokens API et mettez à jour les credentials dans le middleware, relancez manuellement le cron ou le scénario Make/n8n, et contactez l'hébergeur ERP si l'IP est bloquée pour whitelist la nouvelle adresse. Désactivez temporairement l'entité bloquante pour débloquer le batch, et activez un double run manuel (resaisie ou export CSV) en attendant la sync auto.
Important — stabiliser (1 à 2 semaines)
Corrigez le mapping des champs cassés par la mise à jour, ajoutez une gestion d'erreur par entité (skip + log au lieu de bloquer tout le lot) et configurez des alertes email ou Slack sur échec sync supérieur à 30 minutes. Documentez la procédure de renouvellement token avec rappel calendrier, et testez en staging avant toute mise à jour ERP ou boutique — voir intégrations e-commerce.
Plus tard — fiabiliser l'architecture
Une file d'attente avec retry exponentiel (trois tentatives, dead letter queue), un monitoring uptime du middleware (Better Stack, Uptime Kuma) et un connecteur sur mesure avec idempotence (éviter les doublons commande) transforment un bricolage en service fiable. Prévoyez un contrat de maintenance connecteur entre 500 et 1 500 €/an selon la complexité.
Coût intervention urgence 2026 : diagnostic + renouvellement token entre 300 et 800 € ; correction post-migration API entre 1 500 et 5 000 € ; refonte connecteur instable entre 5 000 et 15 000 €.
Prévention : ne plus subir une coupure
Une sync ERP–boutique n'est pas un « set and forget ». C'est un service vivant, comme votre site ou votre caisse. Mettez en place un calendrier de renouvellement credentials avec alerte J-15, un environnement staging miroir pour tester les mises à jour, et des logs conservés 30 jours minimum avec codes erreur explicites.
Privilégiez la sync incrémentale (delta) plutôt qu'un full catalog chaque nuit, rédigez un runbook documenté (« si sync en échec, faire X, Y, Z ») et planifiez une revue trimestrielle des dépendances (modules, apps, versions API). Identifiez un contact technique côté ERP et côté agence — pas seulement le commercial.
Scénarios concrets : ce qu'on voit en intervention
PME distribution à Roubaix, WooCommerce + Sage — Coupure après expiration token OAuth non renouvelé. Symptôme : commandes web OK, rien dans Sage depuis 72 h. Correction : renouvellement token + relance delta commandes sur 3 jours + vérification anti-doublon. Délai total : 4 h.
Artisan e-commerce Lille, PrestaShop + Odoo — Sync produits active, flux commandes jamais paramétré lors du lancement. L'équipe pensait que « l'intégration était faite ». Correction : mapping statuts + webhook paiement + tests B2C/B2B. Budget : 2 800 €.
Grossiste HDF, Shopify + EBP via Make — Scénario Make désactivé après quota mensuel dépassé le 28 du mois. Stock figé, commandes en attente. Correction : upgrade plan Make + alerte quota à 80 % + sync horaire au lieu de temps réel non critique.
Ces cas partagent un point commun : personne ne regardait les logs avant que le problème devienne opérationnel. Un dashboard simple — dernière sync réussie, nombre d'erreurs 24 h — évite 90 % des urgences.
FAQ
Combien de temps peut-on tenir sans sync ERP ?
Au-delà de 24 h avec des ventes actives, les écarts stock et la resaisie manuelle deviennent coûteux et risqués (survente, doublons). Au-delà de 72 h, prévoyez un rattrapage commande par commande avec reconciliation stock.
La mise à jour WooCommerce/PrestaShop peut-elle tout casser ?
Oui, si le connecteur ou le middleware n'est pas compatible avec la nouvelle version API. Toujours tester en staging et lire le changelog du module de sync avant mise à jour prod.
Faut-il un middleware ou une intégration directe ?
Middleware (Make, n8n) : flexible, rapide à ajuster, dépendance supplémentaire. Direct API custom : plus robuste à long terme, coût initial plus élevé. PME entre 20 et 100 commandes/jour : middleware bien monitoré suffit souvent.
Comment éviter les doublons de commandes après une reprise ?
Utilisez des identifiants externes idempotents (ID commande boutique dans l'ERP). Avant relance massique, vérifiez quelles commandes sont déjà passées. Ne relancez jamais un batch complet sans filtre date/heure.
Qui est responsable : l'hébergeur, l'ERP ou l'agence web ?
Le pont sync est un périmètre contractuel à clarifier avant projet. En pratique : credentials et dispo API = client + éditeur ERP ; connecteur et middleware = agence ou intégrateur ; infra middleware = hébergeur du worker. Documentez les SLA.
Et maintenant ?
Si votre ERP ne communique plus avec votre boutique, ne attendez pas que l'écart stock devienne un litige client. Vérifiez d'abord les tokens et les logs du middleware — c'est gratuit et ça résout la majorité des coupures.
On dépanne et on fiabilise ces flux pour des e-commerçants de Lille et des Hauts-de-France, sur WooCommerce, PrestaShop, Shopify et ERP Sage, Odoo, Cegid ou EBP.