wc-product-export.csv attend une colonne sku unique par produit. L’export natif de Lightspeed, lui, mélange dans un même champ deux informations qui n’ont pourtant rien à voir : la référence interne attribuée par le logiciel de caisse, et le code-barres fournisseur figurant sur l’emballage physique. Cette confusion, invisible tant que la boutique reste uniquement physique, devient un problème réel dès qu’il faut synchroniser un catalogue en ligne avec le même référentiel produit.
Reprendre une boutique qui vend déjà en magasin physique pour lui ajouter une vitrine WooCommerce impose une contrainte que beaucoup de migrations de catalogue classiques n’ont pas : le référentiel produit ne peut pas être réinventé, il doit rester compatible avec le système de caisse existant, sous peine de désynchronisation permanente entre stock physique et stock en ligne.
Ce que l’export Lightspeed ne dit pas clairement
Le fichier d’export produit de Lightspeed contient un champ nommé de façon ambiguë selon les versions du logiciel, qui peut correspondre soit à la référence interne générée automatiquement par le système, soit au code EAN du fournisseur, selon la façon dont le produit a été saisi à l’origine. Sur un catalogue construit progressivement sur plusieurs années par différentes personnes, les deux conventions coexistent souvent sans qu’aucune documentation ne le signale.
Importer directement ce champ comme sku WooCommerce sans vérification préalable produit un catalogue en ligne où certains produits sont identifiés par leur code-barres fournisseur et d’autres par une référence interne arbitraire, rendant impossible toute recherche cohérente côté back-office comme côté intégrations tierces (comparateurs de prix, marketplaces).
Construire une table de correspondance avant l’import
La méthode qui a permis d’éviter les doublons silencieux sur ce projet consiste à traiter la migration en deux temps distincts : d’abord une table de correspondance intermédiaire, ensuite seulement l’import WooCommerce proprement dit.
id_lightspeed,reference_interne,code_barre_ean,statut
LS-00142,REF-INT-0091,3401560789456,verifie
LS-00143,REF-INT-0092,,manquant
LS-00144,REF-INT-0093,3401560789463,doublon_detecte
Cette table intermédiaire fait apparaître deux catégories de problèmes qu’un import direct aurait masquées : les produits sans code-barres renseigné (souvent des articles vendus uniquement au poids ou fabriqués sur place), et les doublons de code-barres provenant de saisies successives d’un même produit sous deux fiches distinctes dans Lightspeed.
Traiter les codes-barres manquants avant la mise en ligne
Un produit sans code-barres ne pose pas de problème en magasin, où la vente peut se faire par recherche de nom. En ligne, l’absence de code-barres complique l’intégration avec des flux tiers qui l’exigent comme identifiant unique. Sur ce projet, les produits sans code-barres ont reçu une référence interne générée spécifiquement pour la boutique en ligne, tout en conservant un champ de métadonnée séparé indiquant l’absence de code-barres fournisseur d’origine — une information utile pour le service achats.
update_post_meta( $product_id, '_code_barre_origine_absent', 'oui' );
Vérifier les codes-barres avant, pas après, la mise en ligne
La tentation, sous pression de délai, est de lancer l’import et de corriger les anomalies au fil de l’eau une fois la boutique en ligne. Sur ce projet, ce choix aurait été risqué : un doublon de code-barres non détecté avant mise en ligne peut entraîner une commande en ligne qui décrémente le stock d’un produit différent de celui réellement vendu en magasin, un problème invisible jusqu’à ce qu’un client réclame un article jamais expédié.
- Étape 1 : exporter le catalogue Lightspeed complet, sans filtrage
- Étape 2 : construire la table de correspondance et isoler les doublons de code-barres
- Étape 3 : résoudre manuellement chaque doublon avec l’équipe magasin, qui seule sait quel produit est réellement actif
- Étape 4 : importer uniquement le catalogue assaini dans WooCommerce, avec le champ
skucorrectement attribué
Un import de catalogue qui va vite mais confond deux référentiels différents ne fait pas gagner de temps : il déplace le travail de correction vers un moment où il coûtera bien plus cher à corriger, une fois la boutique déjà en ligne.
Ce que cette migration n’a pas traité
Ce retour d’expérience concerne exclusivement la correspondance des références produit entre les deux systèmes. Il ne couvre pas la synchronisation de la caisse physique elle-même avec WooCommerce, qui repose sur une intégration distincte, mise en place dans un second temps une fois le catalogue fiabilisé.
En résumé
Migrer un catalogue Lightspeed vers WooCommerce sans perdre les codes-barres fournisseurs demande de traiter la migration comme un problème de correspondance de données avant d’être un problème d’import technique. La confusion entre référence interne et code-barres fournisseur, invisible en boutique physique, devient le principal risque d’une mise en ligne précipitée. Une table de correspondance intermédiaire, construite avant tout import, reste la meilleure protection contre les doublons silencieux.
