ERP et ecommerce : le problème n’est pas d’intégrer, mais de décider qui commande quand quelque chose casse

Une activité ecommerce peut vendre correctement pendant des mois tout en déstabilisant silencieusement l’exploitation. Le scénario est classique : le catalogue semble juste, les commandes arrivent, l’ERP reçoit les données, tout paraît maîtrisé jusqu’au moment où les exceptions apparaissent. Puis viennent les retours partiels, les changements de prix en cours de journée, le stock réservé, les factures qui ne devraient pas encore partir ou les commandes qui n’auraient jamais dû être expédiées.

La plupart des intégrations n’échouent pas par manque de technologie. Elles échouent parce que personne n’a défini quel système a le dernier mot quand le processus cesse d’être standard.

Ma thèse est simple : une intégration ERP-ecommerce ne doit pas être pensée comme un simple pont de données, mais comme un système de décision opérationnelle. Si vous ne définissez pas qui décide dans chaque cas, vous obtenez deux systèmes cohérents en apparence, mais contradictoires dans la réalité.

Le symptôme habituel : tout se synchronise, mais l’exploitation reste désordonnée

Beaucoup d’équipes pensent que le problème vient de la qualité du connecteur. Parfois oui, mais rarement c’est la cause principale. Le plus souvent, l’entreprise a accumulé des règles implicites qui n’ont jamais été documentées :

• Le ecommerce accepte des commandes alors que le stock est déjà engagé ailleurs.
• L’ERP corrige les prix après l’achat du client.
• Le service client modifie les commandes sans qu’un événement clair soit visible pour la finance.
• La logistique travaille avec ses propres statuts, différents de ceux du front.

Le résultat est prévisible : davantage de tickets internes, davantage de corrections manuelles et davantage de réunions pour expliquer pourquoi deux écrans affichent des vérités différentes.

Un signal très clair d’une intégration mal conçue est celui-ci : si vous devez revoir manuellement les cas “normaux” tous les jours, l’architecture ne soutient plus l’activité. Il n’est pas nécessaire d’attendre un incident majeur pour le constater. Il suffit de mesurer combien d’exceptions sont devenues routinières.

Ce qu’il faut décider avant de toucher à l’intégration

Avant de parler d’API, de queues ou de middleware, il faut répondre à des questions très concrètes. Ce ne sont pas seulement des questions techniques ; ce sont des questions de gouvernance opérationnelle.

1. Qui est la source de vérité pour chaque donnée critique ?

   • Prix : ERP, ecommerce ou PIM ?
   • Stock disponible : ERP, WMS ou couche intermédiaire de réservation ?
   • Statut de commande : système de vente ou système d’expédition ?
   • Référentiel client : CRM, ERP ou ecommerce ?

2. Quels événements sont automatiques et lesquels exigent une revue ?

   • Un changement d’adresse peut être automatique avant expédition.
   • Une modification de prix après paiement ne devrait peut-être pas l’être.
   • Une commande partielle peut nécessiter une file de revue humaine.

3. Quelle latence est acceptable ?

   • Tout ne doit pas être en temps réel.
   • Certains processus fonctionnent mieux en quasi temps réel.
   • D’autres s’améliorent avec des synchronisations par lot, validées et traçables.

4. Que se passe-t-il en cas de conflit entre systèmes ?

   • La commande est-elle bloquée ?
   • Passe-t-elle en attente ?
   • La règle de l’ERP s’applique-t-elle avec notification au front ?
   • Ou le conflit reste-t-il simplement visible pour l’exploitation ?

L’essentiel est d’écrire ces décisions avant le développement. Si elles sont réglées en production, ce ne sont plus des décisions : ce sont des rustines.

Mini-cas : quand le connecteur n’était pas le vrai problème

Dans un cas composite très courant, une entreprise B2B avec ecommerce et ERP pensait avoir besoin d’une “intégration plus robuste”. Le symptôme : certaines commandes étaient confirmées avec des prix obsolètes et d’autres étaient bloquées sans explication claire.

Après analyse, le vrai problème est apparu : l’équipe commerciale pouvait publier des tarifs promotionnels dans le front, tandis que la finance appliquait d’autres règles pour les remises par client. En plus, le stock et les réservations étaient mis à jour sur des fenêtres différentes. Personne n’avait défini quel système devait l’emporter lorsqu’une promotion expirait pendant une session d’achat.

La solution n’a pas été de “synchroniser plus vite”. Trois changements plus utiles ont été mis en place :

• Une source de vérité a été définie par champ, et non par système entier.
• Une file d’exceptions a été créée pour les conflits de prix et de stock.
• L’équipe a accepté que certaines commandes ne devaient pas être automatisées à 100 %.

Le résultat opérationnel était moins spectaculaire que “l’automatisation totale”, mais bien plus précieux : moins de corrections manuelles, moins de réclamations et une traçabilité suffisante pour expliquer pourquoi une commande avait été traitée d’une certaine manière.

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

Voici l’une des décisions les plus inconfortables, et pourtant les plus saines : certaines intégrations s’améliorent lorsqu’elles cessent d’être instantanées.

Cela va à l’encontre de l’intuition de beaucoup d’équipes. On a l’impression que si une donnée met plus de quelques secondes à circuler, le système est moins bon. Mais en exploitation réelle, le temps réel peut amplifier les erreurs :

• Si une réservation de stock arrive avant validation, on peut sur-vendre.
• Si une promotion se propage sans contrôle, on peut facturer incorrectement.
• Si un statut change automatiquement sans revue, on peut lancer la logistique pour la mauvaise commande.

Il est parfois préférable d’introduire une validation intermédiaire, une queue ou un état “en attente de confirmation”. Ce n’est pas un abandon de l’automatisation. C’est une manière d’éviter qu’une petite exception ne devienne une erreur coûteuse.

Autre décision peu populaire : tous les processus ne doivent pas être traités de la même façon. Une commande standard n’a pas besoin du même niveau de supervision qu’un compte négocié, une condition spéciale ou une commande multi-expéditions.

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

Il existe des signaux opérationnels très concrets :

• L’équipe utilise Excel pour rapprocher les commandes entre systèmes.
• Les tickets support répètent les mêmes trois causes.
• Les corrections manuelles augmentent exactement quand le volume augmente.
• Finance et opérations débattent de “quelle donnée est la bonne”.
• Chaque changement commercial nécessite une petite intervention technique.

Si cela se produit, le problème n’est pas seulement logiciel. Le modèle opérationnel a pris du retard.

La façon la plus utile d’aborder une intégration ERP-ecommerce est de partir du flux critique, pas de l’outil. Cartographier les exceptions, définir la responsabilité par donnée et accepter que certains processus aient besoin d’un contrôle humain est plus efficace que d’ajouter une couche d’automatisation sans discernement.

Chez Codefuente, nous commençons souvent par ces décisions métier et opérationnelles, parce qu’elles déterminent si l’intégration aide vraiment ou si elle ne fait qu’ajouter de la complexité élégante.