Attribuez une source de vérité à chaque famille de données.
Le PIM peut porter les titres, descriptions, médias, attributs et traductions. L’ERP peut rester maître des références, tarifs, stocks, comptes clients et commandes. La boutique assemble ces informations pour vendre et conserve les données propres au parcours, comme le panier et la session de paiement.
Ce partage varie selon l’entreprise. Écrivez-le dans un tableau avec quatre colonnes : donnée, système maître, systèmes destinataires et règle de modification. Une exception doit être nommée. Par exemple, une promotion créée dans la boutique peut primer temporairement sur le tarif ERP si sa période et son périmètre sont explicites.
Une référence visible n’est pas toujours une clé technique.
Les SKU changent, les variantes se regroupent, les EAN peuvent manquer et les clients possèdent plusieurs comptes. Utilisez des identifiants stables, conservez les correspondances et définissez les règles de fusion. La suppression physique d’un produit peut casser l’historique ; un statut d’archivage est souvent plus sûr.
Pour chaque objet, testez la création, la modification, l’archivage et la réactivation. Faites de même avec les commandes annulées, les remboursements partiels, les adresses corrigées et les colis multiples. Les cas rares sont précisément ceux qui révèlent une architecture fragile.
Le temps réel est une exigence métier, pas un argument décoratif.
Un stock faible peut nécessiter une réservation immédiate. Une description enrichie peut attendre un traitement planifié. Un prix contractuel peut être calculé à la connexion du client. Classez les flux selon leur délai acceptable et les conséquences d’une information en retard.
Les webhooks déclenchent rapidement un traitement, mais peuvent être reçus plusieurs fois ou dans le désordre. Les imports planifiés rattrapent les écarts, mais créent une fenêtre de décalage. Une architecture robuste combine souvent événements, files d’attente et réconciliation régulière.
Le tableau des erreurs fait partie du produit.
Chaque échange doit produire un statut exploitable : reçu, validé, envoyé, refusé ou à reprendre. Une alerte doit indiquer l’objet, la règle en défaut et la prochaine action. Les données sensibles ne doivent pas être recopiées inutilement dans les journaux.
Prévoyez la relance sans doublon, la correction manuelle et la réconciliation complète. Notre article sur les erreurs d’un connecteur API détaille ces mécanismes. Pour préparer le besoin, utilisez aussi le guide de cadrage d’un connecteur e-commerce.
- Carte des systèmes et propriétaire de chaque donnée.
- Identifiants stables et règles de correspondance.
- Déclencheur, fréquence et délai acceptable par flux.
- Cas d’erreur, reprise et responsabilité opérationnelle.
- Volumétrie, sécurité, recette et surveillance.