Codes-barres multiples sur Shopify : le piège de la troncature silencieuse

Shopify accepte maintenant 20 codes-barres par variante

Le 8 septembre 2026, Shopify a annoncé une nouveauté qui passe inaperçue chez la plupart des marchands : une variante peut désormais porter jusqu’à 20 codes-barres, chacun avec son type. Avant, il n’existait qu’un seul champ barcode. Les codes supplémentaires finissaient là où ils pouvaient : un metafield, un tag, un attribut de ligne dans l’ERP, ou nulle part.

Le besoin est réel. Un même article peut être identifié par un UPC fabricant et un EAN de marque distributeur, par un GTIN enregistré auprès de GS1, par un ISBN réédité, ou par un ASIN Amazon pour une fiche marketplace. Shopify donne ces exemples dans son changelog, et décrit en une phrase ce que je retrouve chez mes clients : les identifiants secondaires vivent en dehors de Shopify, donc personne ne sait vraiment lesquels sont à jour.

Il y a en fait deux changements. Le premier est côté API, le 8 septembre : la connexion barcodes sur ProductVariant, et l’input barcodes sur les mutations productSet, productVariantsBulkCreate et productVariantsBulkUpdate. Le second est côté caisse, annoncé le 1er septembre : Shopify POS v11.14 sait retrouver une variante en scannant ou en cherchant n’importe lequel de ses codes associés, et pas seulement le principal.

Les types de codes, et ce que Shopify valide

Chaque code peut déclarer son standard :

• UPC : 12 chiffres (UPC-A) ou 8 (UPC-E), usage principalement nord-américain.
• EAN : 13 chiffres (EAN-13) ou 8 (EAN-8), usage surtout hors Amérique du Nord.
• GTIN : accepte 8, 12, 13 et 14 chiffres. À utiliser quand le code est enregistré auprès de GS1, sous forme GTIN-8, GTIN-12, GTIN-13 ou GTIN-14.
• ISBN : 10 ou 13 chiffres. Un ISBN-13 est aussi un EAN-13, ce qui explique pas mal de doublons dans les catalogues de livres.
• ASIN : l’identifiant Amazon, unique à son catalogue.
• NS_PID : identifiant produit non standardisé, du type référence ou numéro de pièce fabricant, utilisé dans les déclarations douanières européennes. Aucune validation de format, la valeur est stockée telle quelle.

Quand tu déclares un type, Shopify vérifie les caractères, la longueur, le préfixe et la clé de contrôle. Sans type, la valeur passe comme avant, sans contrôle. Un point à garder en tête : une même valeur peut satisfaire plusieurs standards, un ISBN-13 est un EAN-13, donc c’est à toi de déclarer celui que le fournisseur a réellement assigné.

Cette validation rend un service réel. Combien de catalogues j’ai ouverts avec un EAN à 12 chiffres saisi par erreur, ou un zéro de tête perdu parce que le champ avait été passé en numérique dans un tableur ? Une valeur typée invalide est maintenant refusée à l’écriture au lieu d’entrer en base sans que personne ne s’en aperçoive.

Le piège : la troncature silencieuse

C’est le passage à lire deux fois.

Le champ historique barcode n’est pas supprimé, il est déprécié. Il continue de fonctionner, et proprement : en lecture, il renvoie le premier code de la liste ; en écriture, il met à jour ce premier code et laisse les autres intacts. Rien ne casse aujourd’hui, et Shopify s’engage à annoncer une date de retrait avec une version d’API complète de préavis.

Le problème arrive dès qu’une deuxième valeur existe sur une variante. Toute intégration qui lit uniquement barcode en voit une seule, sans le moindre signal qu’il y en a d’autres. Shopify le dit noir sur blanc dans son changelog : c’est de la troncature silencieuse. Et la liste des coupables est donnée telle quelle : ERP, marketplaces, POS, flux fournisseur.

Traduisons en incidents concrets. Ton ERP pousse le champ barcode vers ta marketplace, et celle-ci indexe une fiche sur le mauvais code. Ton logisticien prépare les colis avec un identifiant qui n’est plus le principal. Ton export fournisseur de printemps rejoue l’ancien code sans que personne ne le voie. Dans les trois cas : aucune erreur, aucun log, aucune alerte. Le mauvais identifiant part chez le partenaire et tu le découvres le jour où le stock ne colle plus.

Mon conseil tient en une phrase : ne remplis pas un deuxième code-barres avant d’avoir audité ce qui lit le premier. Sinon tu transformes une amélioration de catalogue en incident de synchronisation, trois mois plus tard, un vendredi après-midi.

Ce qu’il faut auditer avant de bouger

Fais la liste de tout ce qui touche au code-barres :

1. Ton ERP et son connecteur, c’est là que ça casse le plus souvent.
2. Les flux vers les marketplaces et les comparateurs, Google Shopping et les catalogues Meta inclus.
3. Ton POS et le matériel de réception en entrepôt.
4. Les apps tierces : gestion de stock, WMS, préparation de commandes, import et export CSV.
5. Tes scripts maison et tes automatisations, Shopify Flow, jobs planifiés et webhooks compris.
6. Les exports que tu envoies à tes fournisseurs ou à ton transporteur.

Si un seul de ces points lit barcode et rien d’autre, deux options : le migrer vers barcodes, ou décider consciemment de laisser ce code en première position. Shopify te laisse ce contrôle, puisque le premier code envoyé est celui que renvoie barcode et celui qui trie en premier dans la connexion. C’est ta surface de compatibilité pour les systèmes que tu n’as pas encore migrés.

Migrer en GraphQL

La connexion est disponible en API 2026-10. En lecture :

query {
  productVariants(first: 1, query: "sku:TSHIRT-BLK-M") {
    nodes {
      id
      sku
      barcode
      barcodes(first: 20) {
        nodes {
          type
          value
        }
      }
    }
  }
}

barcode continue de renvoyer le premier code. barcodes renvoie la liste complète, avec le type déclaré, ou null si aucun type n’a été fourni à l’écriture.

En écriture, trois mutations acceptent l’input barcodes : productSet, productVariantsBulkCreate et productVariantsBulkUpdate. Exemple sur une variante existante :

mutation {
  productVariantsBulkUpdate(
    productId: "gid://shopify/Product/1234567890"
    variants: [{
      id: "gid://shopify/ProductVariant/9876543210"
      barcodes: [
        { value: "3612345678901", type: EAN },
        { value: "9780262033848", type: ISBN }
      ]
    }]
  ) {
    productVariants {
      id
      barcode
      barcodes(first: 20) { nodes { type value } }
    }
    userErrors { field message }
  }
}

Trois règles à retenir, toutes dans la documentation :

• Envoyer barcodes remplace l’ensemble des codes de la variante. Si tu n’en renvoies que deux alors qu’il y en avait trois, le troisième a disparu.
• Un même input de variante ne peut pas contenir barcode et barcodes en même temps. Il faut choisir.
• Le filtre barcode des requêtes products et productVariants matche désormais n’importe quel code de la variante, et plus seulement le premier. Pratique pour retrouver un article par l’ASIN de sa fiche Amazon.

À la caisse, ce que ça change pour tes équipes

Depuis POS v11.14, un vendeur peut scanner n’importe lequel des codes associés à la variante pour la retrouver. Le cas typique : ton fournisseur A livre en EAN, ton fournisseur B en UPC, ton revendeur travaille avec sa propre référence, et jusqu’ici quelqu’un cherchait à la main au moment de la réception. Attention à l’ordre des choses : les codes doivent d’abord être associés à la variante dans l’admin Shopify, c’est ce travail de saisie qui rend le scan utile.

Côté vitrine, rien à faire. Le code-barres est une donnée interne de l’admin, il n’est pas exposé au storefront, et aucun de mes thèmes sur mesure n’a besoin d’être touché pour ça. Quand je branche un catalogue sur une caisse ou un système de gestion, ça se joue de l’autre côté, par exemple sur une connexion ERP ou une intégration sur mesure.

Mon plan en cinq étapes

1. Inspecte les lectures de barcode dans tes intégrations et tes scripts, avant tout le reste.
2. **Passe les lectures à la connexion barcodes** avec l’API 2026-10, en gardant une gestion propre du cas « un seul code » pour ne rien casser.
3. Choisis l’ordre consciemment. Le premier code envoyé est celui que verront les systèmes non migrés : mets en tête celui que ton logisticien ou ton POS utilise réellement tous les jours.
4. Teste sur une boutique de développement. La CLI Shopify 4.8 sait créer des boutiques de dev avec shopify store create dev, et la limite est passée à 250 boutiques de dev par organisation. Tu peux peupler, casser, réinitialiser, sans approcher la production.
5. Ne remplis pas les 20 emplacements. Ajoute seulement les codes dont tes canaux ont besoin. Chaque code en plus est une surface de synchronisation en plus, donc une chose de plus à maintenir.

En résumé

La fonctionnalité est bonne : elle met enfin de l’ordre dans des identifiants qui vivaient dans des metafields ou dans des tags. Le risque n’est pas dans la nouveauté, il est dans l’ancien champ, qui continue de renvoyer un seul code sans prévenir personne.

La migration ne se joue pas côté thème. Sur les catalogues que je maintiens, comme Näak, Wise Trail Running ou Slicy, l’identifiant produit sert au réapprovisionnement, à la caisse et aux échanges avec les partenaires, jamais à l’affichage. C’est donc du côté de tes intégrations que le travail se trouve.

Si tu veux avancer cette semaine, commence par la seule information qui compte : la liste de ce qui lit le champ barcode aujourd’hui, chez toi. Tant que tu ne l’as pas, tu ne sais pas si tu peux ajouter un deuxième code maintenant, ou si tu dois d’abord migrer une intégration.