Connecter ERP, stocks et entrepôt pendant une migration e-commerce
Architecture et tests pour connecter ERP, stocks et entrepôt sans doublons ni commandes perdues pendant une migration.
La boutique affiche le stock. L’ERP porte les références. L’entrepôt prépare les colis. Le transporteur renvoie le tracking. Une migration échoue quand personne ne définit précisément qui commande quoi.
Le connecteur n’est pas une prise. C’est un ensemble de contrats métier.
Définissez les sources de vérité
Créez un tableau par donnée :
| Donnée | Source | Destination | Fréquence | Règle de conflit |
|---|---|---|---|---|
| produit | PIM ou ERP | boutique | planifiée | source écrase |
| prix | ERP | boutique | événement ou lot | dernière version validée |
| stock | WMS/ERP | boutique | quasi temps réel | réserve de sécurité |
| commande | boutique | ERP/WMS | événement | idempotence |
| statut | entrepôt | boutique | événement | mapping contrôlé |
| tracking | TMS/transporteur | boutique | événement | multi-colis autorisé |
Sans règle de conflit, un incident devient une discussion entre systèmes.
Exigez l’idempotence
Rejouer un message ne doit pas créer deux commandes. Utilisez une clé stable par événement et conservez la trace de traitement.
Chaque flux doit avoir :
- identifiant ;
- horodatage ;
- version ;
- statut ;
- nombre de tentatives ;
- erreur ;
- prochaine tentative ;
- résultat.
L’équipe doit pouvoir rechercher une commande sans ouvrir quatre interfaces.
Organisez la période parallèle
Pendant la migration, anciennes et nouvelles plateformes peuvent évoluer en même temps. Définissez :
- date du snapshot initial ;
- données resynchronisées ;
- sens des mises à jour ;
- durée du gel final ;
- traitement des commandes en cours ;
- mécanisme de rapprochement.
Ne laissez jamais deux systèmes modifier librement le même stock sans arbitrage.
Testez les scénarios d’échec
- ERP indisponible ;
- stock reçu en retard ;
- commande envoyée deux fois ;
- produit inconnu ;
- adresse invalide ;
- statut non reconnu ;
- tracking multi-colis ;
- remboursement après expédition ;
- message hors ordre.
Le test est réussi quand l’erreur est visible et récupérable, pas seulement quand le système ne plante pas.
Ce qu’on voit sur le terrain
Les opérations manuelles ne signifient pas toujours que PrestaShop est en cause. Elles signalent souvent une intégration incomplète entre commerce et logistique.
Chez certains marchands, les équipes apprécient PrestaShop mais ressaisissent statuts et tracking. C’est précisément le type de coût que le projet doit supprimer.
La migration d’e-fumeur est en phase finale et le connecteur entrepôt fait l’objet d’une fiabilisation stricte. Nous ne le présentons pas comme terminé tant que les critères de go/no-go ne sont pas satisfaits.
Voir aussi fiabiliser le connecteur entrepôt et synchroniser les stocks.
Le tableau de bord minimal
Affichez :
- événements reçus ;
- succès ;
- échecs ;
- retries ;
- messages en attente ;
- âge du plus ancien échec ;
- commandes sans accusé ;
- écarts de stock ;
- trackings manquants.
FAQ
API ou fichiers ?
Les deux peuvent être fiables. Le contrat, la traçabilité et la reprise comptent davantage que le transport.
Le temps réel est-il obligatoire ?
Non. Il faut un délai compatible avec le risque de survente et l’expérience client.
Qui surveille le connecteur ?
Un propriétaire métier et un propriétaire technique, avec des alertes actionnables.
Faut-il refaire le connecteur pendant la migration ?
Pas forcément. Mais son comportement doit être documenté et testé contre la nouvelle plateforme.
Vous voulez challenger votre architecture de flux ? Réservez une revue ERP/entrepôt.