Shopify connecté au reste de vos opérations

« Synchroniser l'ERP avec Shopify » ne suffit pas à décrire un projet.

Il faut décider quel système fait autorité pour chaque objet. Le PIM peut posséder les descriptions et attributs produit. L'ERP peut garder les prix de référence, les comptes clients et la disponibilité comptable. L'OMS peut arbitrer l'allocation des stocks. Shopify peut rester la source des paniers, du checkout et de certaines données client. Le 3PL renvoie les statuts d'expédition et les numéros de suivi.

Ces choix varient selon l'organisation. Nous les écrivons avant de construire. Une matrice de flux précise le propriétaire, le déclencheur, la fréquence, les règles de transformation, le niveau de criticité et le comportement attendu en cas d'erreur.

Produit et catalogue

Nous documentons les identifiants, variantes, options, métachamps, taxonomies, statuts de publication et relations entre produits. Les limites du modèle Shopify sont traitées dans le mapping, pas découvertes pendant l'import final.

Médias et contenus

Le DAM peut fournir images, vidéos, documents et métadonnées. Le connecteur doit préciser les formats acceptés, l'ordre, les textes alternatifs, les règles de remplacement et ce qui se passe lorsqu'un asset manque.

Prix, promotions et catalogues

Un prix n'est pas toujours une valeur unique. Il peut dépendre du marché, de la devise, du compte entreprise, d'une liste tarifaire ou d'une règle commerciale. Nous séparons ce qui relève de Shopify, de l'ERP et des mécanismes de catalogue pour éviter des priorités contradictoires.

Stock et disponibilité

Le stock affiché doit correspondre à une définition partagée. Stock physique, disponible à la vente, réservé et en transit ne veulent pas dire la même chose. La fréquence de mise à jour, le traitement des réservations et le comportement en cas de retard sont décidés avec les opérations.

Commandes, paiements et fulfillment

Nous mappons les lignes, remises, taxes, modes de livraison, statuts de paiement, annulations, remboursements et informations de fulfillment. Le flux retour mérite son propre cadrage. Il traverse souvent plusieurs systèmes et expose rapidement les incohérences d'identifiants.

Clients et comptes entreprises

Les règles de consentement, d'adresse, de déduplication et de rapprochement doivent être explicites. Pour le B2B, il faut aussi traiter la société, ses établissements, les acheteurs autorisés, les catalogues et les conditions de paiement.

Nous ne partons pas du principe qu'un connecteur sur mesure est toujours la meilleure réponse.

Une app existante convient lorsque le périmètre est standard, le mapping limité et le modèle d'exploitation accepté. Un middleware devient utile lorsque plusieurs systèmes, transformations et files de traitement doivent être observés au même endroit. Un développement spécifique se justifie lorsque les règles métier différencient réellement l'entreprise ou qu'aucune solution existante ne couvre le besoin proprement.

La décision tient compte de critères concrets:

• Couverture fonctionnelle réelle, pas seulement présence d'un logo dans une marketplace.
• Accès aux données nécessaires dans Shopify et dans le système tiers.
• Gestion des erreurs, rejouabilité et visibilité pour les équipes.
• Coût de maintenance et dépendance à l'éditeur.
• Besoin de traitements en temps réel, planifiés ou par lots.
• Capacité à tester les changements sans toucher à la production.

Nous documentons aussi la sortie. Une intégration saine doit pouvoir être remplacée sans rendre les données incompréhensibles.

Le parcours nominal est rarement le plus difficile. Les incidents arrivent lorsque deux événements sont reçus dans le mauvais ordre, qu'une requête expire après avoir été traitée, qu'un identifiant change ou qu'un système reste indisponible pendant plusieurs heures.

Nous définissons le comportement attendu avant le développement:

• Une clé d'idempotence ou un mécanisme équivalent limite les doubles traitements.
• Les tentatives sont encadrées pour ne pas amplifier une panne.
• Les erreurs fonctionnelles sont séparées des erreurs techniques.
• Les messages en échec peuvent être revus, corrigés et rejoués selon le périmètre retenu.
• Un rapprochement détecte les écarts silencieux sur les données critiques.
• Les alertes vont à l'équipe capable d'agir, avec assez de contexte pour comprendre le problème.

Ces mécanismes ne rendent pas un SI infaillible. Ils réduisent le temps passé à découvrir ce qui s'est produit.

Shopify peut exposer des événements utiles via webhooks et des données via ses API. Nous choisissons entre traitement événementiel, synchronisation planifiée et opérations par lots selon le besoin.

Un changement de statut de commande peut déclencher un flux rapide. Une reprise complète du catalogue se traite autrement. Chercher à tout faire en temps réel ajoute parfois de la fragilité sans bénéfice opérationnel. À l'inverse, un export nocturne ne suffit pas lorsque la promesse de disponibilité doit suivre les ventes de près.

Le design d'architecture précise donc la latence acceptable, le volume attendu, le comportement lors d'un pic et le plan de rattrapage.

Une intégration manipule souvent plus de données que le storefront n'en affiche. Nous limitons les accès aux objets et opérations nécessaires au flux. Les secrets ne sont pas inscrits dans le code ou les documents partagés, et les environnements de test n'utilisent pas par défaut une copie complète des données de production.

Le cadrage identifie aussi les données personnelles qui traversent chaque système, leur utilité et les équipes autorisées à les consulter. Lorsqu'un journal technique suffit avec un identifiant de référence, il n'a pas besoin de recopier l'adresse, l'email ou le contenu complet d'une commande.

Les responsabilités restent explicites: qui crée les accès, qui les révoque, qui valide une évolution du périmètre et qui examine une alerte. Les contrôles exacts dépendent de l'architecture et des politiques du client. 

1. Cartographier l'existant

Nous recensons les systèmes, propriétaires, flux actuels, fichiers manuels, dépendances et incidents connus. Les contournements des équipes sont particulièrement utiles. Ils montrent où l'architecture officielle ne couvre plus la réalité.

2. Définir le modèle cible

Nous fixons les objets, identifiants, systèmes maîtres, transformations et règles de priorité. Les choix sont relus par e-commerce, opérations et technique. Une décision qui simplifie le connecteur mais bloque le service client n'est pas une bonne décision.

3. Concevoir le contrat d'échange

Chaque flux décrit ses entrées, sorties, statuts, erreurs et règles de reprise.

4. Construire et tester

Les tests couvrent le cas nominal, les doublons, les données manquantes, les formats invalides, l'indisponibilité d'un système et la reprise. La recette métier complète la recette technique.

5. Lancer avec observation

La mise en production prévoit un contrôle des premiers flux, un rapprochement et des responsabilités claires. Les modalités exactes dépendent du contrat et ne sont pas présentées ici comme un SLA.

Selon le périmètre, le travail peut comprendre:

• Une cartographie d'architecture et un catalogue de flux.
• Une matrice des systèmes maîtres et des règles de transformation.
• Un choix argumenté entre app, middleware et développement spécifique.
• Des spécifications techniques et fonctionnelles.
• Le connecteur et ses mécanismes de suivi.
• Un plan de test, une recette et une documentation d'exploitation.
• Une liste claire des responsabilités et dépendances externes.

Nous restons Shopify-only. Nous concevons l'intégration côté commerce et travaillons avec vos équipes ou partenaires sur les systèmes tiers. Le rôle de chacun est défini avant le développement.

Chez les Laboratoires SVR, la boutique Shopify Plus fonctionne avec un connecteur ERP, au service d'un déploiement international sur plusieurs boutiques.

Chez Tecnifibre, marque française d'équipement de tennis et de squash depuis 1979, le connecteur ERP accompagne des boutiques d'extension internationales, des catalogues par marché et une gestion de la précommande.