Demander si l’ERP, le PIM ou l’OMS est la source de vérité produit une réponse trop globale. La responsabilité varie selon l’objet, l’attribut et l’état du cycle : description, prix, stock disponible, allocation et commande ne naissent pas au même endroit.
Le vendeur a besoin d’une matrice assez précise pour expliquer une valeur et assez simple pour être utilisée pendant un incident.
Découper la vérité par objet et attribut
Listez catalogue, offre, stock, prix, commande, expédition, retour et avoir. Pour chacun, distinguez création, enrichissement, validation et état opposable au client.
Le PIM peut posséder le contenu éditorial tandis que l’ERP porte une référence commerciale. L’OMS peut calculer le disponible à promettre sans devenir propriétaire du stock physique.
Ajouter le moment de vérité
Une valeur peut être indicative avant commande et engageante après validation. La matrice précise quand la responsabilité change et quel événement matérialise ce passage.
Cette chronologie évite qu’une estimation tardive réécrive un engagement déjà pris.
Construire la matrice ERP, PIM, OMS
Pour chaque champ, nommez le système maître, les consommateurs, la fréquence, la clé et la règle en cas d’absence. Ajoutez le responsable métier qui peut trancher une ambiguïté.
Une cellule « partagé » est insuffisante. Elle doit indiquer qui peut écrire dans quel état et comment les modifications sont rapprochées.
Séparer stockage et décision
Un système peut recopier une valeur pour servir rapidement sans obtenir le droit de la modifier. Conservez source, version et date métier avec la copie.
Le cache et les index de recherche suivent la même règle : ils accélèrent la lecture mais ne deviennent pas une autorité.
Arbitrer les écritures concurrentes
Définissez les champs qui refusent une version ancienne, ceux qui acceptent une correction humaine et ceux qui exigent un workflow. « Dernière écriture gagnante » n’est pas une politique suffisante pour le prix ou la commande.
Une contradiction va en quarantaine avec les deux valeurs, leurs versions et l’impact. Le support ne choisit pas silencieusement la donnée la plus pratique.
Rejouer sans dupliquer
Les événements utilisent une clé d’idempotence et un numéro de version. Reprendre une file doit confirmer la même transition ou produire un conflit lisible.
Les créations de référentiel sont séparées des mises à jour transactionnelles afin qu’un retry ne fabrique pas un second produit ou client.
Conserver l’origine et la version
Les journaux métier indiquent objet, attribut, ancienne valeur, nouvelle valeur, source, règle et corrélation. Les données sensibles sont masquées sans perdre la capacité d’expliquer la décision.
Un dashboard de rapprochement suit les écarts par objet et leur âge. Il distingue retard de propagation, rejet technique et contradiction métier.
Le runbook part de l’identifiant commercial et reconstitue le chemin entre systèmes sans demander plusieurs exports manuels.
Changer de responsabilité sans rupture
Une migration commence par un shadow mode : la nouvelle règle calcule sans écrire et ses décisions sont comparées à l’autorité actuelle. Les écarts sont qualifiés avant bascule.
La date de transfert, les objets concernés et le rollback sont explicites. Les événements en attente sont traités selon leur version, pas rejoués aveuglément sur le nouveau modèle.
Après stabilisation, retirez les anciennes permissions d’écriture et les synchronisations devenues inutiles.
Conclusion : une vérité distribuée mais explicite
ERP, PIM et OMS peuvent chacun porter une part de vérité si les responsabilités, transitions et conflits sont documentés au niveau utile.
Dawap peut vous accompagner pour transformer cette matrice en contrats d’intégration et preuves de run.
