Une commande ManoMano apparaît dans la Toolbox mais pas dans Shopify. Le stock continue d’être diffusé, une seconde vente arrive et l’équipe finit par saisir les deux commandes à la main. L’automatisation existe sur le catalogue, mais la promesse client dépend encore d’une personne qui surveille plusieurs écrans.
À l’inverse, un connecteur peut importer toutes les commandes et dégrader la marge : prix Shopify repris sans frais de canal, transport volumineux oublié, promotion non plafonnée ou retour coûteux. La réussite technique ne dit rien de la contribution économique ni du temps de reprise.
Le vrai enjeu est de transformer l’échange ManoMano–Shopify en contrats observables. Chaque domaine — produit, offre, stock, commande et expédition — possède une source, une sortie attendue, un accusé de réception et un repli. L’automatisation accélère seulement les décisions déjà explicites.
En réalité, une agence marketplace capable de concevoir l’intégration ne promet pas un « temps réel » abstrait. La méthode permet de décider quoi automatiser depuis la latence, les limites de l’API, la marge plancher et la reprise sur les exceptions. L’intervention humaine reste réservée aux cas où un jugement crée de la valeur.
Définir ce que l’automatisation doit garantir
Décomposer le flux en cinq engagements
Le catalogue doit transporter une identité et des attributs valides. L’offre doit porter prix, stock et conditions commerciales. La commande doit être importée une fois et réservée sans attendre. L’expédition doit restituer transporteur, colis et suivi. La finance doit pouvoir reconstituer la contribution par ligne.
Chaque engagement reçoit un indicateur aval. Une requête envoyée n’est pas une offre publiée ; un ordre récupéré n’est pas une commande réservée ; un tracking stocké dans Shopify n’est pas un statut accepté par ManoMano. La sortie métier, et non le succès du transport, ferme le traitement.
Choisir les systèmes d’autorité
Shopify peut rester le poste de travail commercial, mais il ne doit pas être désigné automatiquement comme source de toutes les données. Un PIM peut gouverner les caractéristiques techniques, un ERP le prix de revient, un OMS les commandes et un WMS le physique. La matrice d’autorité indique qui peut écrire chaque champ.
Cette frontière prévient les boucles. Le prix rendu ManoMano, calculé avec les coûts du canal, ne revient pas écraser le prix de base Shopify. Le stock diffusé après buffer ne devient pas le nouveau stock physique. Une donnée dérivée garde sa formule et sa destination.
Partir des capacités officiellement documentées
Distinguer l’API ManoMano de la promesse du connecteur
La documentation primaire de la ManoMano Partners API présente notamment une API REST de commandes, des actions d’acceptation ou de refus, la création d’expéditions, une API d’offres ainsi que des API de catégories et de stock produit ManoFulfillment. Elle documente une authentification par clé créée dans la Toolbox et des limites de requêtes.
Ces capacités ne prouvent pas l’existence d’un mapping Shopify officiel, exhaustif et prêt à l’emploi. La façon dont une application tierce crée une commande Shopify, associe les taxes, gère les colis ou relance les erreurs dépend de cette application et de sa configuration. Le vendeur exige donc sa documentation, sa version et un environnement de recette.
Traiter les limites publiques comme une frontière
Une partie des règles catalogue, commissions, attributs de catégorie et contraintes contractuelles peut être fournie dans la Toolbox ou pendant l’onboarding plutôt que sur une page publique stable. L’équipe exporte les spécifications applicables à son contrat et à son pays au moment du projet. Elle ne transforme jamais un exemple générique en règle universelle.
Le dossier de conception distingue donc trois niveaux : fait documenté publiquement, configuration observée dans le compte vendeur et hypothèse à valider. Cette séparation est essentielle lorsqu’un champ obligatoire, un statut ou une politique évolue après la mise en production.
Écrire un contrat de données stable
La table de correspondance relie SKU vendeur, EAN, identifiant ManoMano, produit et variante Shopify. Elle conserve le pays, la catégorie, l’unité de vente et le statut de publication. Un EAN ne remplace pas le SKU vendeur : l’un identifie un produit commercial, l’autre permet de suivre l’offre et les opérations internes.
Chaque message possède une version de schéma, un identifiant, une date source et une date de traitement. Les champs obligatoires, formats, valeurs autorisées et valeurs de repli sont testés avant l’envoi. Une valeur absente n’est pas inventée ; elle met le produit en quarantaine avec le propriétaire de la donnée.
Le contrat décrit aussi la sémantique des mises à jour. Une chaîne vide peut signifier « effacer », « ignorer » ou « invalide » selon le champ. Une quantité nulle peut fermer l’offre, tandis qu’un prix nul doit être rejeté. Ces décisions sont écrites et couvertes par des tests.
Enfin, les données sensibles sont minimisées. Les commandes importent ce qui est nécessaire à l’exécution, au service et aux obligations applicables ; les journaux techniques masquent ce qui n’aide pas le diagnostic. Une traçabilité utile ne consiste pas à dupliquer toute la donnée client.
Publier un catalogue techniquement exploitable
Valider la complétude avant le transport
Les familles bricolage, jardin ou équipement utilisent des dimensions, compatibilités, puissances, matériaux, contenus de colis et informations de sécurité. La liste exacte dépend de la catégorie ManoMano applicable. Le PIM contrôle la complétude avant que le connecteur ne transforme les valeurs.
Un produit est publiable lorsque son identité, sa catégorie, ses attributs et ses médias passent les contrôles. Une offre peut ensuite être activée si prix et stock sont valides. Séparer produit et offre permet de corriger le contenu sans perturber inutilement une condition commerciale saine.
Rapprocher les réponses ligne par ligne
La Partners API documente des réponses multi-statut pour certaines opérations en lot : certaines offres peuvent réussir et d’autres être rejetées. Le connecteur ne classe donc jamais le lot entier comme réussi sur la seule réponse HTTP. Il rattache le résultat à chaque SKU et conserve le message de validation.
Exemple concret illustratif : un pilote de cent offres renvoie quatre rejets sur la même unité de mesure et deux sur un EAN. Les quatre premières restent en quarantaine jusqu’à correction du mapping ; les deux autres demandent une vérification d’identité. Republier les cent lignes brouillerait les deux causes.
Calculer une offre rentable par canal
Passer du prix boutique au prix rendu
Le prix Shopify peut être une entrée, pas une décision finale. Le moteur ajoute ou retranche selon la stratégie les coûts spécifiques : commission contractuelle, transport, emballage, promotion, coût de traitement, provision de retour et TVA selon le contexte. La source contractuelle du barème est datée.
La contribution attendue par commande égale le revenu net moins coût produit et coûts variables. Le calcul conserve les hypothèses : poids volumétrique, zone de livraison, taux de retour et financement de la remise. Une moyenne de catégorie ne remplace pas le coût du SKU lorsque le transport varie fortement.
Bloquer plutôt que vendre sous le plancher
Le plancher de marge est une politique interne validée par la direction, jamais une règle ManoMano. Si le prix calculé tombe sous ce plancher, alors l’automatisme retire ou limite l’offre selon le runbook. Une dérogation porte un montant maximal, un responsable et une expiration.
Scénario illustratif : un meuble vendu 180 € paraît rentable avec 75 € de coût d’achat. Après commission contractuelle, livraison, préparation et provision de retour, la contribution prévue n’est plus que 9 €. Un seuil interne de 12 € peut suspendre cette offre ; il doit être recalibré sur les coûts réels et n’engage aucune plateforme.
Diffuser un stock prudent et explicable
Le stock envoyé à ManoMano part du disponible à promettre, pas du stock physique brut. Il retire commandes engagées, contrôle qualité, réservations et buffer. Le vendeur choisit si Shopify, l’OMS ou le WMS porte ce calcul, puis interdit qu’une quantité dérivée revienne dans la source.
Le rythme d’actualisation se mesure de bout en bout : événement source, traitement, appel, acceptation et visibilité distante. Une promesse « toutes les cinq minutes » ne dit pas combien de temps une offre reste haute lorsqu’un appel échoue. L’âge de la dernière confirmation devient un indicateur de risque.
Le mode dégradé est défini avant l’incident. Si le stock source n’est plus disponible ou si les écritures ManoMano échouent, les SKU faibles sont plafonnés ou suspendus. Les produits profonds peuvent conserver une dernière valeur bornée pendant une durée validée. Le choix dépend de la vélocité et du coût d’annulation.
Le lien avec Shopify est traité plus en détail dans la méthode de réconciliation des stocks Shopify et marketplaces. Ici, l’enjeu spécifique est de ne pas confondre stock accepté par l’API et offre effectivement sûre.
Piloter le cycle de vie des commandes
Importer une fois, réserver immédiatement
La documentation ManoMano expose des filtres de lecture par dates et statuts ainsi que des actions groupées. Le collecteur avance avec un curseur recouvrant légèrement la dernière fenêtre pour ne pas perdre un événement de frontière. La déduplication par contrat, référence de commande et ligne empêche la double création dans Shopify.
Dès qu’une commande entre dans le périmètre métier retenu, elle réserve le stock, même si son enrichissement complet attend. L’équipe distingue récupération, validation, création Shopify et acceptation ManoMano. Une commande bloquée entre deux étapes reste visible avec son âge et son propriétaire.
Mapper les statuts sans inventer d’équivalence
Les statuts ManoMano documentés ne se superposent pas nécessairement aux états internes ou Shopify. La table de transition indique quel statut source autorise création, acceptation, préparation, expédition ou remboursement. Une transition impossible va en exception ; elle n’est pas forcée pour « faire avancer » la commande.
Les refus automatiques restent particulièrement encadrés, car ils affectent le client, le revenu et la qualité de service. Une absence de stock confirmée peut déclencher le runbook ; une donnée d’adresse incomplète exige une vérification. Le connecteur propose le motif et les preuves, tandis que le métier garde le pouvoir lorsque l’impact est irréversible.
Fermer la boucle avec l’expédition
Le flux expédition part du colis réel : commande, lignes, quantités, transporteur, numéro et URL de suivi. La documentation ManoMano prévoit la création d’expéditions et décrit la possibilité de plusieurs colis avec leurs produits. Le modèle Shopify ou OMS doit donc préserver ce niveau de détail au lieu d’écraser plusieurs colis dans un seul tracking.
Le connecteur valide le transporteur et le format avant l’envoi, puis rapproche la réponse. Une expédition créée dans Shopify mais rejetée côté marketplace reste un incident ouvert. La promesse client se juge sur le statut reçu par le canal, pas sur le clic effectué dans l’outil interne.
Une correction de tracking est traitée comme une nouvelle version reliée à la précédente. L’équipe garde la chronologie et informe le support si le client a reçu une donnée erronée. La journalisation ne masque pas l’erreur sous la dernière valeur saine.
Superviser les résultats et non les seuls appels
Le monitoring couvre offres rejetées, âge du stock confirmé, commandes non créées, statuts incohérents, expéditions non acceptées et offres sous plancher. Chaque alerte indique cohorte, valeur économique, dernière preuve et action autorisée. Un compteur global d’erreurs HTTP n’explique pas ce qui menace la promesse.
La réconciliation quotidienne compare commandes ManoMano, commandes Shopify, réservations, expéditions et chiffre attendu. La revue hebdomadaire relie contribution, retours, support et reprises manuelles. Une automatisation saine réduit le coût par commande sans cacher les pertes dans le transport ou le service.
Ciama Marketplace peut réunir ces alertes, mais conserve les liens vers la Toolbox, Shopify et les journaux. Il ne déclare pas une offre rentable sans barème contractuel ni coût logistique à jour.
Recetter les exceptions sur un pilote
Le pilote contient vingt à cent SKU selon diversité : variante technique, produit volumineux, stock faible, promotion, colis multiples et référence arrêtée. Il rejoue création, modification, mise à zéro, commande, doublon, refus contrôlé, expédition et reprise après panne.
Les entrées sont données source, barème, stock, commande et statut ; les sorties attendues sont offre publiée, prix supérieur au plancher, réservation unique, commande exploitable et tracking accepté. Produit, opérations, finance et intégration signent leurs contrôles. Une recette menée uniquement par le développeur ne valide pas la marge ni la préparation.
Seuil interne illustratif : l’ouverture peut exiger 100 % des commandes pilotes importées une seule fois, aucune offre sous plancher et moins de 2 % de lignes nécessitant une reprise explicable. Ces critères doivent être adaptés au volume et au risque ; ils ne proviennent pas de ManoMano.
Le repli arrête le domaine fautif. Une anomalie prix gèle les offres concernées sans stopper l’import de commandes ; un défaut de commande suspend l’ouverture catalogue mais laisse le suivi des commandes existantes actif. Ce découplage protège le client pendant l’enquête.
Pour qui cette architecture est adaptée
Le cadre convient aux vendeurs Shopify qui disposent déjà d’un compte ManoMano et souhaitent supprimer les ressaisies sans perdre la maîtrise du stock ou de la marge. Il est particulièrement utile pour les catalogues techniques, volumineux ou multi-colis.
Une petite équipe peut utiliser un intégrateur existant à condition d’exiger les preuves de mapping, de déduplication et de reprise. Un vendeur doté d’un PIM, d’un OMS ou de règles tarifaires complexes aura intérêt à isoler les contrats de données plutôt qu’à laisser Shopify devenir un pivot implicite.
Erreurs fréquentes d’automatisation
Promettre un connecteur natif sans lire sa couverture
Erreur fréquente : supposer que « connecté à Shopify » couvre catalogue, offres, commandes, colis, annulations et retours. L’équipe demande la matrice fonctionnelle, les statuts pris en charge, les limites et le comportement en panne. Ce qui manque devient un processus assumé.
La Partners API prouve certaines capacités ManoMano, pas la qualité de leur implémentation par une application donnée. La recette reste obligatoire, y compris lorsqu’une solution figure dans un écosystème partenaire.
Automatiser le prix avant de connaître le coût
Erreur fréquente : recopier le prix Shopify et ajouter un pourcentage uniforme. Les commissions, zones de livraison, retours et promotions peuvent varier. Le moteur utilise le barème contractuel et les coûts du SKU, puis bloque lorsque la preuve manque.
Une marge théorique non rapprochée aux ventes réelles finit par dériver. La finance compare chaque mois prévision et réalisé ; un écart durable corrige les hypothèses avant d’étendre l’automatisation.
Relancer les commandes sans déduplication
Erreur fréquente : agrandir la fenêtre de lecture après une panne et recréer les commandes déjà importées. La clé idempotente est enregistrée avant l’effet métier. Le retry reprend une étape, pas toute la commande sans état.
Si l’équipe ne sait pas déterminer si Shopify a accepté la création, elle met la commande en vérification et recherche l’identifiant externe. Créer une deuxième commande pour gagner du temps dédouble stock, préparation et chiffre.
Déployer le canal en quatre semaines
Semaine 1 — établir le modèle économique
L’équipe exporte les règles de son compte ManoMano, vérifie les capacités de l’intégrateur et cartographie les sources. Elle sélectionne le pilote, date les barèmes et définit les statuts. Les responsables catalogue, opérations, finance et technique valident leur sortie.
Les dépendances sont API, Shopify, PIM, ERP, WMS et transport. Le journal conserve identifiant, version, entrée, réponse et décision. Le premier repli consiste à retirer les offres pilotes tout en gardant le traitement des commandes existantes.
Semaine 2 — publier les offres pilotes
Les mappings sont testés sur les catégories du pilote. La réponse ligne par ligne alimente une quarantaine. Le moteur calcule prix rendu, plancher et stock prudent. Les contrôles aval vérifient l’offre réellement visible.
Un échec de source passe en mode dégradé ; une validation métier manque, le SKU ne part pas. L’instrumentation mesure temps de propagation, rejet et fraîcheur. Une publication sans accusé de réception reste en attente, jamais classée comme succès.
Semaine 3 — fermer commande et expédition
Le collecteur gère chevauchement, pagination, limites de requêtes et reprises temporisées. Les commandes sont dédupliquées puis réservées. Les transitions de statut et les colis multiples sont rejoués. Le support vérifie les informations disponibles dans Shopify.
La panne est simulée entre récupération ManoMano et création Shopify. La reprise retrouve l’étape exacte, puis la réconciliation confirme stock, commande et suivi. L’ouverture reste bloquée si une commande peut disparaître sans alerte.
Semaine 4 — ouvrir et mesurer
Le pilote fonctionne sur une fenêtre représentative. La revue mesure offres acceptées, stock frais, commandes sans reprise, promesse tenue et contribution. Les exceptions portent un propriétaire et une date. L’élargissement suit les familles déjà prouvées.
- Valider les capacités du compte et du connecteur avant la conception.
- Séparer identité produit, offre, stock, commande et expédition.
- Calculer le prix rendu depuis des coûts datés.
- Dédupliquer chaque commande avant tout effet métier.
- Contrôler la sortie ManoMano puis ouvrir le catalogue par paliers.
Relier stock, marge et qualité de flux
Le cadre de conception d’un connecteur ERP–marketplace aide à placer chaque responsabilité sans transformer Shopify en système universel.
La méthode de profitabilité marketplace par SKU permet de recalibrer les garde-fous avec le réalisé plutôt qu’avec une marge catalogue.
Conclusion : automatiser une décision contrôlée
Relier ManoMano à Shopify ne consiste pas à déplacer davantage de champs. L’intégration doit garantir une identité stable, une offre rentable, un stock prudent, une commande unique et une expédition confirmée.
La documentation primaire fixe les capacités observables de l’API ; le compte vendeur et le connecteur précisent leur couverture réelle. Nommer cette limite évite de présenter une hypothèse de mapping comme une fonction de plateforme.
Le pilote, la réconciliation et le repli donnent à l’équipe le droit d’automatiser. Le canal peut alors grandir sans multiplier les ressaisies, les surventes ni les ventes sous marge.
Dawap peut cadrer ces contrats, instrumenter les flux et piloter l’ouverture dans son accompagnement d’agence marketplace ManoMano, avec des résultats contrôlables par le métier comme par la technique.
