À 10 h 12, la boutique confirme une commande de douze articles. L’ERP n’en connaît que dix, l’entrepôt en a réservé neuf et le paiement porte le montant initial. Le service client voit « validée », la logistique « en anomalie » et la finance attend une facture qui ne peut pas correspondre à l’expédition. Chacun corrige son écran ; aucune équipe ne sait désormais quelle décision doit l’emporter.
Le problème se voit quand la boutique et l’ERP embarquent la même logique sous des formes légèrement différentes. Un seuil de stock, une remise ou une règle de facturation change d’un côté avant l’autre. Le premier écart paraît réparable ; les suivants transforment les synchronisations en arbitrages cachés et rendent chaque retry dangereux.
Le vrai enjeu n’est pas de rendre deux bases identiques à chaque seconde. Il consiste à attribuer une autorité à chaque décision, transmettre des faits versionnés et garantir qu’un message retardé ou rejoué ne fabrique pas un second effet. Contre-intuitivement, accepter des états temporaires explicites protège mieux la vente qu’une promesse artificielle de synchronisme intégral.
Dans une démarche de développement web sur mesure, le front e-commerce, l’OMS et l’ERP forment un workflow exploité. La méthode relie stock, commande et facture à des contrats, des seuils locaux et un plan de reprise que commerce, logistique, finance et support peuvent réellement exécuter.
Attribuer une autorité à chaque décision
Écrire une matrice objet-décision-source
« L’ERP est maître » reste trop vague. Pour chaque objet, l’équipe nomme les décisions : publier une offre, calculer un prix, promettre une quantité, accepter une commande, autoriser une expédition, produire une facture ou enregistrer un avoir. Une source peut posséder le référentiel produit sans posséder la promesse commerciale visible à cet instant.
La matrice précise entrée, sortie, version, propriétaire et délai de propagation. Le catalogue peut orchestrer la vendabilité, l’ERP conserver l’article comptable et l’entrepôt détenir le stock physique. Une commande ne choisit pas la source la plus récente au hasard : elle suit la politique écrite pour son canal, son pays et son type de client.
Refuser les corrections sans commande
Une équipe ne modifie pas directement un statut pour faire disparaître un écart. Elle émet une commande métier — annuler une ligne, libérer une réservation, corriger une adresse — avec acteur, motif et version. La source propriétaire décide puis publie le verdict. Cette discipline garde l’histoire lisible et permet de distinguer reprise normale, compensation et dette de données.
Séparer offre vendable et référentiel ERP
Le référentiel ERP décrit souvent unité, fiscalité, compte comptable et contraintes d’approvisionnement. La boutique compose une offre : contenu, médias, canal, disponibilité, options et promesse. Recopier l’un dans l’autre crée des champs sans propriétaire. L’équipe expose plutôt les attributs nécessaires avec leur source et leur date d’effet.
Une variante commerciale conserve un identifiant stable vers l’article ou la nomenclature. Une suppression ERP ne retire pas silencieusement une offre déjà commandée. Elle déclenche une transition : retirer de la vente, écouler, remplacer ou faire revoir. Les commandes historiques gardent le libellé, le prix et les règles appliquées au moment de l’engagement.
Publier une version cohérente
La publication regroupe les changements qui doivent devenir visibles ensemble. Un prix sans son unité ou une variante sans sa règle de livraison reste en attente. Le front affiche la version publiée, non un mélange de mises à jour partielles. Si une dépendance manque, alors l’offre se dégrade selon une politique connue au lieu de compléter avec une valeur par défaut trompeuse.
Distinguer stock, disponibilité et réservation
Le stock physique indique une quantité observée dans un lieu. La disponibilité commerciale applique réservations, sécurité, délai, canal et promesse. Une réservation protège une intention pendant une durée. Employer le même nombre pour ces trois notions provoque survente ou immobilisation. Chaque réponse porte donc type, périmètre, unité, version et heure de calcul.
Le checkout revalide avant engagement. Il ne considère pas le cache de consultation comme une garantie. La réservation possède clé, expiration et résultat par ligne. Un abandon libère, une commande confirme et une réponse perdue retrouve le verdict existant. Le seuil de sécurité est qualifié localement selon la fréquence de mise à jour, la valeur du produit et la capacité de substitution.
Assumer la disponibilité partielle
Lorsque cinq lignes sur six sont disponibles, le métier choisit : tout attendre, fractionner, substituer ou refuser. Cette politique est annoncée avant paiement et versionnée dans la commande. Elle ne doit pas émerger d’un timeout. Une réserve introuvable rejoint une file de réconciliation ; elle n’est ni recréée aveuglément ni transformée en stock négatif pour sauver l’écran.
Construire une commande à états explicites
La commande distingue reçue, contrôlée, réservée, acceptée, refusée, préparée, expédiée et close. Ces états décrivent des verdicts, pas seulement des étapes techniques. « Envoyée à l’ERP » ne dit pas si la vente est acceptée. Le front restitue ce qui est acquis, ce qui attend et la personne ou le système responsable de la prochaine transition.
Une identité commerciale stable accompagne la commande dans tous les systèmes. Les identifiants locaux restent des références secondaires. La correspondance est écrite une fois et contrôlée. Une relance transmet la même clé ; un changement client crée une nouvelle version, pas une réécriture silencieuse du message déjà traité.
Borner les points de non-retour
Avant préparation, certaines corrections restent directes ; après remise au transporteur, elles deviennent compensation, retour ou avoir. Le produit affiche cette frontière. Il ne propose pas une action que l’ERP ou la logistique ne peut plus honorer. Une annulation acceptée signifie que réservation, paiement et préparation disposent chacun d’un verdict rapprochable.
Laisser la finance produire le document opposable
La boutique peut afficher un récapitulatif, mais la facture suit les règles, numéros et contrôles du domaine financier. Le document publié cite commande, expédition, client facturé, devise et version de données. Une correction ne remplace pas un PDF sans trace : elle suit le processus défini avec la finance et conserve le lien entre document initial et rectification.
Le moment de facturation dépend du modèle — engagement, expédition, service rendu — et doit être décidé par les responsables compétents. Le code ne déduit pas une règle universelle. Le workflow transmet les faits nécessaires et reçoit identifiant, statut et document. Toute exigence réglementaire est validée par la finance et le conseil approprié pour les pays concernés.
Réconcilier montant et exécution
Une balance rapproche total commandé, payé, expédié, facturé et remboursé par devise. L’égalité n’est pas exigée à chaque instant si les étapes diffèrent, mais chaque écart possède une cause et un délai. Une remise tardive ou une ligne annulée produit une décision explicite ; le support ne modifie pas les montants dans deux outils pour obtenir visuellement le même total.
Résister aux messages rejoués et hors ordre
Les échanges réseau sont au moins incertains : le producteur peut ne pas savoir si le consommateur a traité. La clé d’idempotence relie une intention stable à son verdict. Elle ne consiste pas à ignorer tout doublon : même clé avec contenu différent ouvre un conflit. La documentation de Symfony Messenger rappelle les mécanismes de messages, retries et transports ; le métier doit encore définir l’unicité de l’effet.
Un événement ancien ne rétrograde pas une commande plus avancée. Le consommateur compare version ou séquence et conserve le message hors ordre pour diagnostic. La reprise peut demander un état courant ou reconstruire une projection. Elle ne réécrit pas l’autorité transactionnelle depuis un flux incomplet.
Choisir la cohérence transactionnelle utile
Dans un service, verdict et message de sortie sont enregistrés dans une même frontière. Les niveaux d’isolation documentés par PostgreSQL aident à raisonner sur lectures concurrentes, sans remplacer les invariants du domaine. Entre systèmes, l’équipe accepte la propagation et construit réconciliation, compensation et observabilité.
Cas concret : commande B2B partiellement disponible
Cas hypothétique : un client B2B commande vingt imprimantes et vingt câbles avec un prix contractuel. Le site affiche vingt unités de chaque. Au checkout, l’entrepôt ne peut réserver que seize imprimantes ; quatre sont attendues dans trois jours. Le contrat autorise un fractionnement, mais seulement si le client confirme les deux dates.
La cible fige le prix et le compte, puis demande une réservation par ligne. Le serveur répond seize disponibles, quatre différées et vingt câbles réservés. Le client accepte le fractionnement. Une commande commerciale conserve cette décision ; deux ordres logistiques y sont rattachés. L’ERP reçoit faits et prix versionnés sans recalculer la remise selon le tarif public.
Le pilote porte cinquante commandes sur deux comptes et trois semaines. Les seuils locaux exigent zéro prix provenant d’un autre compte, zéro seconde réservation après retry et aucun document financier sans rapprochement de l’expédition. Toute différence inexpliquée suspend l’ouverture du compte suivant ; ces seuils protègent ce pilote et ne constituent pas une norme générale.
Éprouver une réponse perdue
Par exemple, si l’ERP accepte la commande puis que sa réponse se perd, alors le retry portant la même clé retourne l’identifiant existant. Si quatre imprimantes arrivent avant la seconde expédition, la logistique confirme la quantité sans modifier le prix contractuel. Le support part de l’identifiant commercial, retrouve réservation, ordre, facture et cause de chaque écart.
Protéger prix, comptes et documents
Le serveur recalcule droits et périmètre sur chaque commande. Un prix envoyé par le navigateur n’est jamais accepté comme autorité. Le compte, le contrat et l’adresse sont reliés à l’organisation autorisée. Les contrôles s’appliquent également aux exports, fichiers, recherches, caches et workers ; un identifiant difficile à deviner ne protège rien.
Les journaux évitent données de paiement et secrets. Ils conservent corrélation, règle et résultat nécessaires au diagnostic. Les documents utilisent des liens bornés et une autorisation au téléchargement. Une révocation ferme session, API et tâches à venir. Le support obtient une vue expliquée, pas un compte universel capable de modifier toutes les filiales.
Mettre en œuvre des contrats reprenables
Séparer commandes, événements et projections
Les entrées sont organisation, objet, version, intention et clé ; les sorties sont verdict, identifiants et prochaine étape. Les dépendances et seuils sont explicites. La journalisation garde corrélation, règle et cause. L’instrumentation relie checkout, API, worker, ERP et entrepôt. Le monitoring suit retard, retries, conflits, réservations orphelines et écarts de balance.
Dans un backend PHP et Symfony, l’API valide puis appelle le service de domaine. Doctrine écrit décision et boîte de sortie ; un worker publie vers l’ERP. Le cache ne sert que la lecture datée. Les tests d’intégration provoquent concurrence, timeout et message hors ordre. La CI vérifie les contrats. Le déploiement active par compte ; le rollback ferme la nouvelle voie sans effacer les verdicts.
Donner un runbook à chaque écart
Le runbook attribue les responsabilités : commerce pour l’offre, logistique pour la réservation, finance pour le document et plateforme pour le transport. Il indique diagnostic, retry, compensation et escalade. Une réparation est jouée en préproduction avec les mêmes droits. Le support sait distinguer incident de projection, décision refusée et effet externe manquant.
Piloter les écarts plutôt que les seuls volumes
Les indicateurs rapprochent commandes acceptées, réservations, expéditions, factures, remboursements et dossiers repris. Le taux de synchronisation ne suffit pas : 99,9 % peut masquer les commandes à plus forte valeur. L’équipe segmente par canal, compte, entrepôt, version de contrat et cause.
Chaque mesure déclenche une action. Un retard de projection peut dégrader l’affichage ; une réservation orpheline exige une reprise ; un prix contesté suspend le compte concerné. Les longues traînes restent visibles. Le comité compare coût du contrôle et coût d’une erreur, puis retire les métriques qui ne conduisent à aucune décision.
Pour qui cette architecture devient-elle nécessaire ?
Elle concerne boutiques reliées à ERP, WMS, OMS, PSP ou moteurs de prix, particulièrement en B2B, omnicanal ou multi-entités. Produit, e-commerce, logistique, finance, sécurité, développement, exploitation et support participent. Les responsables métier décident les autorités ; la technique garantit transport, preuve et reprise.
Une petite boutique mono-stock peut commencer avec un connecteur simple et des contrôles quotidiens. Lorsque réservations, prix contractuels, fractionnements ou plusieurs documents apparaissent, les frontières doivent devenir explicites. Le nombre d’API ne décide pas seul : la conséquence d’un double effet et le coût de diagnostic sont plus déterminants.
Erreurs fréquentes entre commerce et ERP
La première erreur déclare l’ERP maître de tout sans détailler les décisions. La deuxième confond stock et promesse. La troisième recalcule le prix des deux côtés. La quatrième considère « envoyé » comme « accepté ». La cinquième rejoue une commande sans clé stable. La sixième corrige les statuts directement.
Autres pièges : identifiants recréés, facture produite depuis le panier, cache sans date, compte client contrôlé seulement dans le front, message ancien qui rétrograde l’état ou monitoring limité au transport. Enfin, synchroniser davantage ne répare pas un contrat contradictoire ; cela propage seulement l’erreur plus vite.
Décider où placer chaque règle
Bloc de décision. Gardez la règle dans le domaine qui assume son verdict. Projetez ce qui doit être lu rapidement. Revalidez ce qui engage stock, prix ou finance. Automatisez une transition déterministe et reprenable. Dans ce cas, acceptez une propagation visible plutôt que de recopier l’autorité. En revanche, une interaction exigeant un verdict immédiat peut appeler directement le service propriétaire avec un repli explicite.
- Nommer décision, source, version et propriétaire.
- Distinguer lecture, réservation, commande et document.
- Tester retry, concurrence, panne et compensation.
- Étendre seulement avec balance et runbook exécutables.
Le choix oppose parfois disponibilité et fraîcheur. Une projection continue de servir mais peut dater ; un appel direct est actuel mais dépend de la source. Il faut documenter cette contrepartie par cas d’usage, pas chercher une réponse unique pour toutes les pages.
Plan d’action sur huit semaines
Semaines 1 et 2 : cartographier
Rejouez vingt commandes, dont refus, fractionnement, retour et prix contractuel. Écrivez la matrice décision-source, les identifiants et les états. Cartographiez les corrections manuelles, les exports et les tâches sans propriétaire. Définissez les seuils à partir des conséquences locales.
Semaines 3 à 5 : contracter et construire
Implémentez une réservation, une commande idempotente et une projection de suivi. Branchez boîte de sortie, journalisation, instrumentation et balance. Testez droits, version, timeout, réponse perdue, événement hors ordre et cache périmé. Le support suit chaque scénario depuis l’identifiant commercial.
Semaines 6 à 8 : piloter et perturber
Ouvrez à deux comptes. Provoquez indisponibilité ERP, stock concurrent et document retardé. Exécutez le rollback de la nouvelle voie, le retry et une compensation. Mesurez écarts, récupération et charge support avec une base comparable.
La revue finale rapproche cinquante commandes et leurs effets. D’abord, fermer les autorités ; ensuite, stabiliser l’unicité ; puis élargir les comptes. Le groupe suivant ne s’ouvre que si aucune divergence sensible ne reste inexpliquée et si chaque équipe sait exécuter sa responsabilité sans correction directe.
Pendant la semaine qui suit l’ouverture, une balance quotidienne compare intentions, réservations, commandes, expéditions et documents. Le comité tire cinq écarts, vérifie leur cause et chronomètre la reprise. Il consigne version de contrat, dépendance, owner opérationnel et seuil de rollback. Une amélioration du débit ne suffit pas si le support doit encore modifier deux outils. Après deux cycles sans divergence inexpliquée, la fréquence peut diminuer selon le volume et le coût local d’un effet manquant.
- Attribuer les décisions.
- Versionner les faits et les identités.
- Éprouver les doubles effets et les retards.
- Étendre depuis les preuves réconciliées.
Guides complémentaires pour le commerce
Préserver les cas métier pendant une refonte
La refonte e-commerce aide à inventorier les règles qui créent réellement la valeur avant de changer de socle.
Observer les workflows distribués
L’observabilité des workflows métier relie commande, message et effet sans réduire le diagnostic à un statut technique.
- Une autorité par décision.
- Une clé stable par intention.
- Une balance pour chaque effet attendu.
Conclusion : partager les faits, pas les autorités
Relier e-commerce et ERP ne consiste pas à maintenir deux copies identiques. La cohérence vient d’autorités explicites, de faits versionnés et d’états temporaires que les équipes savent expliquer. Stock, disponibilité, réservation, commande et facture restent des objets distincts.
L’idempotence, la boîte de sortie, la réconciliation et le runbook protègent les pannes ordinaires des systèmes distribués. Les seuils sont qualifiés par canal et conséquence. Une anomalie devient une file avec cause et propriétaire, jamais une invitation à modifier deux bases.
Pour transformer ces frontières en contrats exploitables, Dawap peut accompagner le cadrage et l’implémentation dans une démarche de développement web sur mesure. Le résultat attendu est concret : une vente reste explicable depuis la promesse jusqu’au document financier, même lorsqu’un échange est retardé, refusé ou rejoué.
