Synchroniser les données de stock entre magasin et boutique en ligne : règles et pièges

Deux points de vente, deux états de données : où ça bloque au quotidien

Les exploitants de boutiques en ligne doivent maintenir des données à jour et propres dans tous les systèmes utilisés. Selon l'expérience tirée de la pratique de l'intégration, une boutique non connectée au reste de l'informatique fonctionne souvent mal et génère beaucoup de travail. La tâche devient particulièrement fastidieuse lorsqu'il s'agit de différents groupes de clients, comme le B2B et le B2C, avec des conditions différentes, ou en présence d'un vaste catalogue de produits.

Sans connexion, les mêmes informations doivent être gérées à deux endroits distincts. Une modification de prix saisie uniquement dans le système de gestion des marchandises manque alors dans la boutique ; un article vendu au comptoir reste commandable en ligne. Les solutions intégrées évitent cette double saisie en synchronisant continuellement les données entre le système de gestion des marchandises et la boutique web. Ainsi, les modifications telles que les nouveaux prix n'ont pas besoin d'être mises à jour dans plusieurs systèmes.

Des cas concrets rendent le problème visible : un prix qui diffère entre la caisse et la boutique ; une image qui montre encore l'article précédent ; un produit rangé dans la mauvaise catégorie ; une commande qui arrive alors que la marchandise n'est plus disponible. De telles divergences sont le résultat de deux états de données différents – que la boutique ne soit pas du tout connectée ou seulement de manière rudimentaire.

Clarifier la souveraineté des données : quel système gère quelle information

La première règle : pour chaque type de donnée, un système leader est désigné et le sens du flux est défini. Généralement, la maîtrise des articles repose sur l'ERP.

Dans le cadre d'une connexion e-commerce à SAP Business One, par exemple, les informations sur les articles, les images, les documents et les prix proviennent directement du système de gestion des marchandises et sont toujours à jour dans la boutique. Inversement, cela vaut pour tout ce qui est généré lors de la vente : les mouvements de stock et les commandes naissent là où la vente a réellement lieu – au comptoir du magasin ou dans la boutique en ligne – et doivent être rapportés au système de gestion des marchandises.

La double saisie à plusieurs endroits est la cause principale d'états contradictoires. Celui qui peut modifier les textes des articles à la fois dans la boutique et dans l'ERP perd le contrôle de la version faisant foi. Une direction claire supprime cet effort : les modifications comme les nouveaux prix sont saisies une seule fois dans le système leader et distribuées à partir de là, au lieu d'être mises à jour dans les deux systèmes.

Concrètement, cela signifie définir par écrit, pour chaque type de donnée, qui a le droit d'écrire et qui ne fait que lire : les données maîtres des articles, les prix et groupes de prix, les stocks, les données clients et d'adresses, les commandes et les pièces justificatives. Il faut également déterminer ce qui prévaut lorsque les deux côtés pourraient modifier la même information – par exemple un stock qui diminue à la fois par les ventes en magasin et par les commandes en ligne. Sans cette attribution, il reste impossible de savoir quel état est correct en cas de différence.

Échange de fichiers ou connexion directe : la voie de la synchronisation

Il existe deux mécanismes pour l'échange de données entre le système de gestion des marchandises et la boutique : dans l'approche basée sur les fichiers, une information est écrite dans un fichier et transmise ; avec l'API, les systèmes communiquent directement entre eux. Le système ERP suisse europa3000™ de la société europa3000 AG, basée dans le canton d'Argovie, propose exactement ces deux variantes pour la connexion à une boutique Shopware 6 ou WooCommerce : un module XML-Talk et une solution WEB-API plus moderne. Selon l'abonnement, ces modules doivent être réservés en supplément.

La voie choisie détermine la rapidité avec laquelle une modification arrive et l'actualité possible du stock dans la boutique. Via une API, une modification peut être transmise immédiatement ; avec l'échange de fichiers, l'information n'arrive qu'une fois le fichier écrit et lu de l'autre côté. Lors de la nouvelle connexion d'une boutique, il convient de clarifier avant le choix du module à quel point les prix et les stocks doivent être visibles en temps réel – et si le module choisi est inclus dans le niveau de licence existant.

Du backoffice à la boutique : l'étape qui rend les modifications visibles

Une synchronisation réussie des données ne signifie pas encore que le client voit la modification. Dans les systèmes de boutique avec des zones séparées, une étape de synchronisation propre copie les données de la boutique du backoffice vers le frontstore ; ce n'est qu'ainsi qu'elles deviennent visibles dans la boutique en ligne. Cette étape de publication constitue une source d'erreur à part entière.

Celui qui l'oublie cherche l'erreur pendant des heures dans l'interface, alors que les données ont été livrées correctement. Lors du diagnostic, il faut d'abord vérifier si la publication a été déclenchée et si les articles concernés sont marqués comme modifiés – et seulement ensuite, si l'interface a transmis correctement les données.

Sources d'erreur pour les articles, les prix et les groupes de clients

Lors de la synchronisation des produits, plusieurs bases de données doivent correspondre entre elles : dans les systèmes de boutique, il s'agit notamment des fichiers produits, catégories, marques, clients et groupes de prix, ainsi que d'un fichier prix-produit-groupe de prix et d'un fichier client-groupe de prix. S'y ajoutent les images et documents provenant du système de gestion des marchandises. Déjà une seule affectation non transférée – par exemple un article sans catégorie valide ou sans groupe de prix – fait apparaître l'article incorrectement, voire pas du tout, dans la boutique.

Deux domaines sont particulièrement sujets aux pannes. Premièrement, les prix : les clients B2B voient en ligne leur prix individuel, qui résulte des conditions et des groupes de prix enregistrés. Si l'affectation d'un client à son groupe de prix fait défaut, la boutique affiche un prix erroné. Deuxièmement, la langue et le jeu de caractères : les contenus multilingues doivent être gérés dans toutes les langues ; un jeu de caractères mal choisi altère les umlauts et les caractères spéciaux dans les textes des produits.

Pour la recherche d'erreurs, il est utile de se demander si l'information est correcte dans le système leader. Si le bon prix ou la bonne catégorie y figurent mais que la boutique affiche autre chose, le problème réside dans la synchronisation ou dans une affectation manquante. Si la valeur est déjà fausse dans le système leader, il s'agit d'une erreur de saisie. Une affectation fiable suppose également des noms de produits uniques, non attribués plusieurs fois ; si un article est déplacé dans une autre catégorie, ce changement doit être transmis correctement.

Sources d'erreur pour le stock : différences entre magasin et boutique

Le stock est la grandeur la plus sensible lors de la synchronisation. L'objectif est que les stocks correspondent en temps réel et que ni au comptoir ni en ligne ne soit vendu ce qui n'est plus disponible. Chaque retard ouvre précisément cette brèche : l'unité vendue a disparu du magasin, mais est encore disponible dans la boutique.

La possibilité d'une actualisation continue dépend de la méthode de synchronisation. Une connexion API directe peut transmettre chaque mouvement immédiatement. Un échange de fichiers périodique – courant avec les anciennes interfaces – ne livre inévitablement que des états à des moments précis et entraîne des divergences entre-temps. Celui qui l'utilise doit s'attendre à des écarts et gérer la boutique de manière à ce qu'aucune commande non exécutable n'en résulte – par exemple en ne proposant en ligne qu'une quantité réservée ou indiquée comme approximative.

Pour la recherche d'erreurs, il est utile de distinguer entre un mouvement manquant et un mouvement transmis incorrectement : si une vente en magasin n'a pas été comptabilisée dans le système de gestion des marchandises, la base fait déjà défaut avant la synchronisation. Si elle a été comptabilisée mais n'arrive pas dans la boutique, la cause réside dans la voie de transmission – dans l'absence du prochain transfert pour l'échange de fichiers, ou dans la transmission elle-même pour l'API.

Commandes qui refluent : pourquoi la synchronisation doit aussi aller dans l'autre sens

La synchronisation n'est pas à sens unique. Dans une solution connectée, la commande d'un client de la boutique atterrit directement dans le système de gestion des marchandises sans saisie manuelle et y est traitée davantage ; les pièces justificatives nécessaires sont créées. Le traitement des commandes, la facturation et la comptabilité se mettent à jour automatiquement par la suite.

Une boutique seulement partiellement connectée ne réduit donc pas vraiment la charge de travail. Si les articles et les stocks sont bien poussés vers la boutique, mais que les commandes sont transmises manuellement au système de gestion des marchandises, la double saisie subsiste précisément dans le domaine où les erreurs coûtent le plus cher : les commandes, les prix et les pièces justificatives. Le sens retour doit donc impérativement faire partie de l'examen lors de l'évaluation d'une solution – de la commande à la création des pièces justificatives jusqu'à la comptabilisation.

Données personnelles qui suivent le mouvement : ce qu'exige la LPD révisée

Lors de la synchronisation, outre les articles et les stocks, des données personnelles circulent également : adresses, commandes, comptes clients. Selon l'art. 5 let. a LPD, les données personnelles sont toutes les indications qui se rapportent à une personne physique déterminée ou déterminable – cela inclut également les identifiants en ligne comme une adresse IP ou un numéro ID dans un cookie. Le traitement désigne toute opération liée à ces données, notamment l'obtention, la conservation, le stockage, l'utilisation, la modification, la communication, l'archivage, l'effacement ou la destruction.

En Suisse, la loi révisée sur la protection des données est en vigueur depuis le 1er septembre 2023. Elle apporte plus de transparence, des exigences plus élevées en matière de sécurité des données et de nouvelles obligations d'information. Concrètement, des mesures techniques et organisationnelles appropriées doivent être prises pour la sécurité des données, l'infrastructure IT doit être optimisée régulièrement et, dès l'acquisition de solutions techniques, le moins possible de données personnelles doivent être collectées.

Pour les données particulièrement sensibles – comme les données de santé ou financières – une analyse d'impact relative à la protection des données doit être réalisée et documentée. Un registre des activités de traitement aide à prouver la conformité ; les collaborateurs doivent être formés en conséquence.

Pour l'interface entre la boutique et le système de gestion des marchandises, deux obligations sont particulièrement pertinentes. Premièrement, l'information lors de la collecte de données personnelles selon l'art. 19 LPD.

Sont exigés, entre autres, l'identité et le contact du responsable, le but du traitement, les catégories de destinataires, des indications sur les transferts de données à l'étranger avec le mécanisme de garantie, une mention des droits des personnes concernées ainsi que – en cas de décisions individuelles automatisées – une indication selon l'art. 21 LPD.

Deuxièmement, la notification des violations de données : le Préposé fédéral à la protection des données et à la transparence (PFPDT) supervise l'application des dispositions fédérales en matière de protection des données ; les violations de données doivent lui être notifiées selon l'art. 24 LPD, la littérature spécialisée évoquant un délai de notification de 72 heures.

Étant donné que l'hébergement, le fulfilment, la logistique, le CRM ou les plateformes d'évaluation participent à la synchronisation, le traitement des commandes avec ces prestataires de services doit être réglé contractuellement. Si la boutique concerne également des personnes dans l'UE – par exemple via des livraisons, des langues de l'UE ou des prix en euros – le RGPD s'applique en plus. Ces indications ne remplacent pas un conseil juridique, mais nomment les points à clarifier lors de la connexion d'une boutique.

Cadres légaux pertinents pour la synchronisation des données

Comment reconnaître une synchronisation viable

Une synchronisation fonctionnelle se reconnaît à quelques signes vérifiables au quotidien. Les stocks correspondent en temps réel entre le comptoir et la boutique. Les données produits sont à jour partout ; les clients B2B voient en ligne leur prix individuel.

Les commandes atterrissent sans saisie manuelle dans le système de gestion des marchandises, où les pièces justificatives nécessaires sont créées. La comptabilité se met à jour automatiquement.

Pour un test personnel, deux interventions suffisent. Premièrement : une modification dans le système leader – par exemple un nouveau prix – et ensuite mesurer combien de temps elle prend pour devenir visible dans la boutique ; cela montre immédiatement si l'étape de publication a été déclenchée. Deuxièmement : une vente au comptoir et le contrôle si la quantité vendue disparaît de la boutique.

Si l'une des deux vérifications échoue, la cause réside dans la voie de synchronisation ou dans l'absence de retour d'information, et non dans la boutique elle-même.