Shopify et ERP : quand l’intégration cesse d’être un connecteur et devient une décision opérationnelle

Une entreprise vend bien sur Shopify. L’ERP existe déjà, la finance fait confiance à ses chiffres et les opérations suivent leur propre cadence. Puis arrive la demande “simple” : tout connecter pour que les commandes remontent automatiquement, que le stock se mette à jour en temps réel et que la facturation ne dépende plus de tâches manuelles.

Le problème n’est généralement pas d’intégrer Shopify à l’ERP. Le problème est de découvrir trop tard que chaque équipe avait sa propre définition d’une commande, d’un stock et d’un retour.

Ma thèse est simple : une intégration Shopify-ERP ne doit pas être conçue comme un tuyau de données, mais comme une décision de gouvernance opérationnelle. Si l’on ne décide pas à l’avance quel système porte chaque événement, l’intégration ne fera que déplacer le chaos plus vite.

L’échec classique : automatiser des règles encore discutées

Dans beaucoup de projets, la discussion technique commence avant la discussion opérationnelle. On parle de plugins, de webhooks, de middleware, de files d’attente, de champs personnalisés et de fréquence de synchronisation. Tout cela compte. Mais il existe une question préalable bien plus coûteuse : que signifie exactement “stock disponible” pour votre entreprise ?

Cela peut vouloir dire plusieurs choses :

• stock physique dans l’entrepôt
• stock réservé mais non expédié
• stock engagé sur d’autres canaux
• stock disponible en précommande
• stock vendable avant même la réconciliation comptable

Si Shopify affiche un chiffre et l’ERP un autre, vous n’avez pas un problème d’intégration. Vous avez une définition ambiguë.

Même logique pour les commandes. Pour l’ecommerce, une commande “existe” quand le paiement est capturé. Pour les opérations, elle peut exister quand la disponibilité est confirmée. Pour la finance, quand la facture est émise. Sans séquence claire, vous obtiendrez des doublons, des retours mal traités ou des factures émises trop tôt.

Ce que l’entreprise doit décider avant de connecter les systèmes

Avant de toucher à la technologie, cinq décisions opérationnelles doivent être verrouillées :

1. Système de référence par donnée. Qui fait foi pour le client, le produit, le prix, le stock, la commande et la facture ?
2. Événement source. Quel système crée l’enregistrement et lequel ne fait que le répliquer ?
3. Gestion des exceptions. Que se passe-t-il s’il manque du stock, si un paiement échoue ou si une commande arrive incomplète ?
4. Latence acceptable. Avez-vous besoin du temps réel, d’un passage toutes les 5 minutes ou de synchronisations par lot plusieurs fois par jour ?
5. Responsable de correction. Qui contrôle et corrige quand deux systèmes divergent ?

Ce point gêne souvent parce qu’il oblige à choisir. Et choisir, c’est renoncer à une partie de la flexibilité. Mais une intégration sans propriétaire opérationnel finit en usine à incidents.

Règle pratique : si une décision touche à l’argent, au stock ou à la conformité fiscale, elle ne doit pas dépendre d’une synchronisation “best effort”. Il faut un comportement explicite en cas d’échec.

Mini-cas : quand le stock Shopify était juste… jusqu’à ce qu’il ne le soit plus

Cas composite, très réaliste : une entreprise de pièces détachées industrielles vend via Shopify et via un canal commercial interne. L’ERP servait de référence pour les achats et la comptabilité, tandis que Shopify affichait un stock quasi temps réel.

Au début, tout semblait fonctionner. Le problème est apparu dans trois situations :

• réservations manuelles pour les grands comptes
• retours avec contrôle différé
• articles répartis sur plusieurs entrepôts

L’intégration continuait de “fonctionner”, mais pas le business. Les ventes voyaient des unités disponibles déjà engagées par les opérations. Le support promettait un réassort avant validation par les achats. La finance recevait des corrections tardives.

La solution n’a pas été “plus d’intégration”. Elle a consisté à redéfinir le processus :

• l’ERP est devenu le référent du stock engagé
• Shopify n’a affiché que le stock réellement vendable selon des règles conservatrices
• les retours ont été classés par statut avant remise en stock
• une file d’exception a été créée pour les commandes non rapprochées

Résultat concret : moins d’automatisme apparent, mais beaucoup moins d’incidents et beaucoup moins de travail manuel invisible.

La décision inconfortable : tout ne doit pas être en temps réel

Voici le point le plus controversé. Beaucoup d’équipes demandent du temps réel parce que cela sonne comme du contrôle et de la modernité. En pratique, le temps réel peut être un mauvais choix si :

• la donnée change souvent et crée du bruit
• le processus métier n’est pas encore stabilisé
• plusieurs entrepôts ou canaux appliquent des règles différentes
• la correction manuelle après coup est fréquente

Dans ces cas, une synchronisation par lot bien conçue peut être préférable à une intégration instantanée. Non pas parce qu’elle est plus élégante, mais parce qu’elle ralentit la propagation des erreurs.

Autre erreur courante : tout pousser dans le middleware. Le middleware ne devrait pas inventer la politique métier ; il devrait exécuter des règles déjà décidées. S’il devient l’endroit où l’on improvise, il devient un autre ERP parallèle.

Les signaux qu’il faut redessiner l’intégration

Il n’est pas nécessaire d’attendre une panne majeure. Les premiers signaux sont assez nets :

• l’équipe vérifie encore des exports manuels “pour confirmer” ce qui est déjà intégré
• les exceptions de stock augmentent sans gros changement de catalogue
• le support voit des commandes que la finance ne voit pas, ou l’inverse
• quelqu’un dit “on corrige ça après en général”
• chaque incident finit en explication artisanale

Quand plusieurs de ces signaux apparaissent, le problème n’est plus la connexion des systèmes. C’est de décider quel processus doit survivre à l’intégration.

Conclusion

Intégrer Shopify et l’ERP peut être une excellente décision. Mais seulement si l’entreprise accepte que la vraie question n’est pas technique, mais opérationnelle : quelle donnée fait foi, quelles exceptions sont tolérées et qui répond quand la réalité ne suit pas le flux idéal. Sur ce type de projet, Codefuente commence justement par ces décisions avant de construire la couche technique.