Une quantité correcte dans Shopify peut devenir une promesse fausse sur ManoMano si l’ERP a déjà réservé le stock, si une autre boutique vend en parallèle ou si le délai fournisseur a changé. Le symptôme arrive ensuite : annulation, message client, commande bloquée et marge consommée par le support.
En réalité, la qualité d’un connecteur ne se mesure pas au nombre de mises à jour envoyées. Elle se mesure à la capacité de publier une offre réellement vendable, d’importer chaque commande une fois et d’expliquer tout écart entre canal, Shopify, ERP et logistique.
Cette méthode relie sources de vérité, règles de stock, prix, délai et reprise. Le cadre est celui d’une intégration API observable ; la stratégie d’assortiment et de canal peut ensuite être travaillée avec l’agence ManoMano marketplace.
Deux garde-fous orientent tout le dispositif :
- Publier la quantité promettable : le stock visible tient compte des réservations, du risque et du délai réel.
- Conserver une preuve par commande : chaque import, statut, expédition et reprise reste corrélé à la source.
1. Traiter la promesse avant le flux
Relier donnée publiée et capacité d’exécution
Une offre n’est pas vendable parce qu’un endpoint accepte son payload. Elle l’est lorsque le produit est autorisé, la quantité disponible, le prix soutenable et la livraison réalisable. Le connecteur doit évaluer ces conditions avant la publication et contrôler le résultat après traitement.
La promesse combine donc plusieurs systèmes : information produit, coût, stock, réservation, préparation, transport et calendrier. Une donnée fraîche mais isolée peut rester fausse. La règle de publication documente les dépendances et suspend l’offre lorsque l’une d’elles devient trop ancienne.
Le périmètre commence par les familles qui exposent le plus le client et la marge. Un produit volumineux, une variante complexe ou un réassort incertain mérite plus de sécurité qu’un SKU stable et immédiatement disponible. Cette hiérarchie guide le premier lot.
2. Attribuer Shopify, ERP et PIM
Donner un owner à chaque attribut
Shopify peut porter le contenu de la boutique et certaines règles commerciales. Le PIM peut posséder les caractéristiques, médias et catégories. L’ERP conserve souvent références, coûts, disponibilité et facturation. Cette répartition doit être explicitée champ par champ, sans supposer qu’un outil possède tout.
Le mapping indique source, transformation, valeur de repli et comportement en conflit. Une correction manuelle dans ManoMano n’est pas une nouvelle vérité par défaut : elle expire, remonte ou bloque la prochaine publication selon une règle validée. Sinon la valeur oscille au gré du dernier flux.
Les identifiants croisés relient produit, variante, offre et commande. Le connecteur conserve l’identifiant source et la version du mapping afin de migrer un SKU sans perdre son historique. Les objets inconnus rejoignent une quarantaine plutôt qu’une association approximative.
3. Calculer un stock publiable
Passer du stock physique à la quantité promettable
Le stock publiable retire les réservations confirmées, commandes en cours, quantités dédiées à d’autres canaux et marge de sécurité. Il peut intégrer les approvisionnements uniquement si leur date et leur fiabilité permettent réellement de tenir la promesse client.
La formule est versionnée par famille ou entrepôt. Par exemple, si douze unités existent mais que quatre sont réservées, deux protégées pour le B2B et deux conservées en tampon, alors quatre seulement sont proposées. Le calcul garde ses entrées pour expliquer la quantité envoyée.
Le système applique aussi un seuil de fraîcheur. Si l’ERP n’a pas été lu depuis la durée admise, il réduit ou ferme l’offre selon le risque. Continuer à republier la dernière quantité connue transformerait une panne de collecte en survente silencieuse.
4. Protéger les variantes sensibles
Contrôler la bonne référence au bon niveau
Une quantité juste au niveau produit peut masquer une erreur sur la dimension, le coloris, le pack ou la compatibilité. Le mapping doit travailler au niveau réellement commandable et refuser toute variante dont la correspondance avec Shopify, ERP et marketplace reste ambiguë.
Les familles sensibles reçoivent des règles dédiées : stock tampon plus fort, contrôle de poids, validation de transporteur ou fermeture plus rapide en cas de donnée périmée. La décision tient compte du coût d’une annulation et du délai de réassort, pas seulement du volume moyen.
La surveillance recherche les anomalies discrètes : une variante toujours à zéro, une quantité identique sur toutes les tailles ou un écart durable entre ventes et décrément. Ces signaux peuvent révéler un mauvais identifiant sans déclencher d’erreur technique.
5. Encadrer prix et marge
Refuser une mise à jour économiquement dangereuse
Le prix cible réunit coût, frais de canal, préparation, transport, promotion, fiscalité et marge minimale. La règle précise les données obligatoires et leur fraîcheur. Une valeur manquante ne doit pas être remplacée silencieusement par zéro ou par un ancien calcul.
Les garde-fous détectent variation extrême, prix sous plancher, incohérence avec le pack et promotion expirée. Le lot dangereux rejoint une quarantaine avec l’entrée, le calcul et le seuil franchi. L’owner choisit correction, validation exceptionnelle ou maintien de l’ancienne valeur.
Paradoxalement, bloquer une baisse peut protéger davantage le chiffre d’affaires que publier plus vite. Une offre non mise à jour pendant un contrôle court coûte parfois moins qu’une famille entière vendue sans marge. Cette politique est mesurée, datée et limitée.
6. Construire un délai réaliste
Additionner préparation, transport et incertitude
Le délai client dépend du lieu de stock, du cut-off, des jours ouvrés, de la préparation, du transporteur et parfois du fournisseur. Le connecteur ne copie pas une durée générique : il sélectionne la règle associée au SKU et au mode logistique.
Une promesse courte n’a de valeur que si elle est tenue. La règle ajoute une marge lorsque le réassort ou le transport devient instable et ferme l’offre si aucune estimation défendable n’existe. Le changement garde sa cause pour être expliqué au commerce.
Le monitoring compare promesse publiée, date d’expédition et livraison observée lorsque la donnée est disponible. Il segmente par famille, entrepôt et transporteur. Une moyenne globale ne doit pas cacher le segment qui produit l’essentiel des retards et du support.
7. Importer les commandes une fois
Protéger création, lignes et réservations
Le collecteur persiste la commande source avant de créer l’objet dans l’ERP ou l’OMS. Il conserve identifiant ManoMano, lignes, montants, livraison et horodatages. Une clé d’idempotence empêche qu’un webhook et un polling créent deux commandes.
Le mapping vérifie chaque SKU au niveau variante. Une ligne inconnue bloque ou isole selon la règle décidée ; elle n’est jamais rattachée au produit le plus proche. Le système réserve le stock une seule fois et journalise l’effet produit dans la cible.
Un timeout après création est traité comme un résultat inconnu. Le retry commence par rechercher la commande via la référence métier avant de répéter l’écriture. Cette réconciliation protège commandes, stock et comptabilité contre les doubles effets.
8. Prouver expédition et tracking
Rendre la promesse visible jusqu’à la sortie
L’expédition associe commande, colis, transporteur, numéro de suivi et date. Le connecteur contrôle les champs requis et la transition autorisée avant l’appel. Il conserve ensuite l’accusé ou le rejet au lieu de considérer l’envoi comme une preuve de réception.
Une commande multi-colis exige une règle explicite : suivi par colis, expédition partielle et dernière ligne terminée. Le support doit voir ce qui est parti et ce qui reste à préparer. Un statut global ne doit pas masquer une ligne encore bloquée.
Les rejets de tracking sont prioritaires parce qu’ils affectent information client et qualité du canal. L’alerte indique cause, commande, transporteur et prochaine action. Une correction rejoue uniquement l’expédition concernée avec sa nouvelle preuve.
9. Rejouer sans survente
Limiter le périmètre et simuler les effets
La reprise sélectionne flux, SKU, commande, période et cause. Un mode simulation calcule offres, stocks ou statuts qui changeraient. L’opérateur vérifie le volume et le seuil d’arrêt avant d’autoriser la queue de rejeu.
Chaque message conserve la version du contrat, du mapping et de la règle de stock. Le retry applique un backoff, respecte le rate limit et s’arrête sur l’erreur fonctionnelle. Le rollback rétablit la dernière règle stable sans effacer les événements reçus.
Le rapport compare objets ciblés, appels réussis, éléments ignorés par idempotence et exceptions restantes. La reprise n’est fermée qu’après contrôle dans la marketplace et le système interne. Un compteur de réponses HTTP ne suffit pas à prouver le retour au nominal.
10. Superviser les risques métier
Voir stock, promesse, commande et marge
Le monitoring technique suit endpoint, latence, timeout, rate limit, queue et retries. Le niveau métier mesure offres attendues et actives, stock périmé, variations bloquées, commandes manquantes, expéditions rejetées et délais dépassés.
Les seuils sont segmentés. Un retard sur une famille volumineuse ou à forte marge n’a pas le même impact qu’une anomalie isolée. Le dashboard relie le signal au chiffre d’affaires exposé, au nombre de clients et à l’owner capable d’agir.
La revue quotidienne transforme chaque alerte en correction, observation ou acceptation documentée. Elle contrôle aussi le silence : une absence soudaine de commandes ou de stock peut venir d’une collecte cassée. Une sonde synthétique vérifie régulièrement la chaîne sans créer de vraie vente.
11. Éviter les erreurs fréquentes
Repérer les raccourcis qui cassent la promesse
La première erreur est de publier le stock physique sans réservations ni concurrence multi-canal. La deuxième est de laisser Shopify et l’ERP modifier la même donnée sans arbitrage. La troisième est de relancer une commande après timeout sans vérifier son existence.
Une autre dérive consiste à utiliser une règle unique pour toutes les familles. Les variantes, poids, fournisseurs et transporteurs n’exposent pas le même risque. L’automatisation doit accepter des politiques distinctes tant qu’elles restent documentées et observables.
Enfin, les corrections manuelles non journalisées créent une vérité parallèle. Une action d’urgence doit garder auteur, motif, valeur avant/après et durée. Elle passe ensuite dans le backlog si la cause nécessite une règle durable.
- Ne pas publier une donnée périmée sans repli explicite.
- Ne pas fusionner produit et variante dans le mapping.
- Ne pas confondre appel réussi et offre active.
- Ne pas rejouer sans simulation ni contrôle final.
12. Plan d’action pour ManoMano
Livrer une chaîne verticale maîtrisée
La première étape choisit une famille représentative et cartographie Shopify, PIM, ERP, entrepôt et ManoMano. L’équipe nomme la source de chaque champ, documente les identifiants et calcule le stock publiable avec des commandes et réservations témoins.
La deuxième étape versionne schéma, payloads et règles. Une sandbox teste variante absente, stock périmé, prix sous plancher, délai inconnu, doublon de commande et timeout. Les accès OAuth2 ou tokens sont séparés par environnement et masqués dans les logs.
La troisième étape branche queue, retry, monitoring et quarantaine. Le flux publie un lot limité, contrôle le résultat et importe les commandes correspondantes. Support et logistique valident la chronologie jusqu’au tracking, tandis que la finance contrôle les références utiles.
La quatrième étape ouvre progressivement les familles selon risque, volume et marge. Le rapport mesure surventes, annulations, délais, rejets et corrections manuelles. Chaque extension possède un rollback et des critères d’arrêt définis avant la mise en production.
Prioriser la fiabilité commerciale
D’abord, attribuer les sources et sécuriser le stock. Ensuite, fiabiliser commande et tracking. En priorité, traiter les familles qui concentrent annulations, support ou marge. À différer : l’automatisation des attributs sans impact sur la vente. À refuser : toute publication impossible à expliquer.
Le premier succès n’est pas un catalogue complet, mais une famille dont l’offre, la commande et l’expédition peuvent être prouvées. Cette base révèle les vraies contraintes et rend l’extension plus rapide, car les mécanismes de reprise existent déjà.
- D’abord : définir la quantité promettable.
- Ensuite : tester le cycle commande-expédition.
- En priorité : protéger variantes et familles à risque.
- À différer : les enrichissements sans effet commercial.
- À refuser : une bascule sans monitoring ni rollback.
Homologuer les scénarios qui menacent la promesse
Le premier scénario reproduit une vente simultanée sur Shopify et ManoMano alors que le stock franchit le tampon. Le protocole injecte les deux commandes dans un ordre variable, contrôle la réservation ERP et vérifie la quantité republiée. Une seule commande peut consommer chaque unité ; l’autre suit la décision métier prévue, sans correction directe en base. La chronologie doit montrer les heures sources, le mapping de variante, l’effet dans l’OMS et l’accusé du canal. Si le résultat dépend de l’ordre d’arrivée, le mécanisme de verrouillage ou de compensation est revu avant l’ouverture.
Le deuxième scénario dégrade la fraîcheur. L’ERP cesse de répondre après un dernier stock positif, tandis que Shopify continue à recevoir des ventes. Le connecteur doit détecter le watermark dépassé, appliquer le repli choisi pour la famille et alerter l’owner. Le test mesure le délai entre la panne et la réduction effective de l’offre ; il contrôle aussi la restauration, car un retour de l’API ne justifie pas de republier immédiatement une quantité accumulée sans recalculer réservations, commandes en attente et tampon courant.
Le troisième scénario porte sur la marge et le délai. Une promotion active croise une hausse du coût transport et un fournisseur repousse son réassort. Le moteur recalcule le prix et la promesse, bloque toute valeur hors seuil puis présente les entrées au commerce. L’équipe valide qu’un refus reste visible dans la quarantaine et que l’ancienne offre n’est pas conservée silencieusement si elle est devenue elle-même dangereuse. Le verdict peut être maintenir, modifier, fermer ou escalader ; chaque option possède une durée et une preuve.
Le dernier scénario suit une commande jusqu’au support. Un webhook arrive deux fois, la création ERP subit un timeout et le tracking est d’abord rejeté. Le système recherche l’effet avant retry, évite le doublon, corrige uniquement l’expédition et conserve les réponses. Le support doit pouvoir expliquer au client ce qui est confirmé sans lire les logs bruts. La recette se termine seulement lorsque stock, commande, colis et statut ManoMano sont cohérents. Ces cas deviennent ensuite des tests de non-régression exécutés à chaque évolution du contrat ou du mapping.
Organiser les trente premiers jours de run
Après la bascule, une revue quotidienne compare stocks publiés, commandes reçues, annulations et expéditions avec les systèmes sources. Les écarts sont qualifiés le jour même, même lorsqu’ils restent sous les seuils d’alerte. Cette observation construit une référence réelle par famille et permet d’ajuster les tampons sans confondre saisonnalité, panne et erreur de règle.
À la fin de la période, le bilan classe incidents, interventions manuelles et promesses non tenues. Chaque correction récurrente devient une évolution de contrat, de mapping ou de runbook avec un owner. L’équipe décide alors quelles familles ouvrir, lesquelles maintenir sous surveillance et lesquelles fermer jusqu’à une donnée fournisseur ou logistique plus fiable. La décision et ses preuves restent accessibles lors de la revue suivante.
13. Approfondir le run marketplace
Relier les règles ManoMano au modèle transverse
Pour concevoir les statuts, l’idempotence et la reprise communs aux canaux, poursuivez avec la normalisation des flux marketplace. Cette base évite que chaque connecteur réinvente son propre runbook.
Pour une autre combinaison stock, prix et logistique, relisez le run API Cdiscount. La comparaison aide à isoler les invariants du SI et les adaptations réellement propres au canal.
L’intégration technique et l’exploitation vendeur restent liées mais distinctes. Le connecteur garantit la donnée et la preuve ; l’équipe marketplace arbitre assortiment, compétitivité et animation. Un passage clair entre les deux accélère le diagnostic.
14. Conclusion : stock fiable, promesse fiable
Faire du connecteur un garde-fou commercial
ManoMano API crée de la valeur lorsqu’elle aligne Shopify, ERP, variantes, stock, prix et délai autour d’une promesse réaliste. La vitesse d’échange n’a d’intérêt que si la donnée publiée reste vendable.
La fiabilité se voit dans les exceptions : quantité périmée, prix dangereux, commande ambiguë ou tracking rejeté. Une chaîne observable isole ces cas, protège les effets et donne au support une preuve exploitable.
Le meilleur départ est une famille critique traitée de bout en bout avec sa reprise et son monitoring. Une fois cette preuve acquise, l’extension du catalogue devient une décision contrôlée.
Dawap peut vous accompagner pour structurer sources, garde-fous et runbook : cadrez votre intégration API.
