Une check-list de modification des spécifications produit n'est pas une tâche administrative : c'est ce qui sépare une révision de 20 mm d'un conteneur de litiges. Changez une cote et vous venez de modifier un chiffre déjà publié à neuf endroits au moins. La plupart des fournisseurs en corrigent deux : le champ de la fiche dont ils se souviennent, et rien d'autre.
Tout le reste continue de diffuser l'ancienne valeur. Le flux produit. La photo. Le PDF que votre commercial a envoyé la semaine dernière. Le marquage carton. La notice scellée dans la boîte. Aucun ne vous préviendra qu'il a tort. L'acheteur, lui, le fera — en général une fois le conteneur parti.
Les 9 endroits où vit une même cote
Une check-list de modification des spécifications produit, c'est la liste figée de tous les endroits où une cote, un poids ou une matière sont publiés, utilisée pour qu'une seule révision les atteigne tous avant que quelqu'un en aval ne trouve l'écart. Voici la liste, classée selon la vitesse à laquelle chaque ligne fait mal.
| # | Où vit le chiffre | Champ ou support | Qui le lit | Ce qui casse quand il est périmé | Délai réaliste de correction |
|---|---|---|---|---|---|
| 1 | Attributs article des marketplaces | Dimensions produit / article affichées sur la fiche | L'acheteur, avant de cliquer | Retours pour mauvaise taille, réclamations « non conforme à la description » | Quelques minutes |
| 2 | Attributs colis des marketplaces | Dimensions du colis ou d'expédition | Le transporteur et le moteur de tarification | Devis de transport faux, écarts de refacturation | Quelques minutes |
| 3 | Flux Shopping | product_length / product_width / product_height / product_weight |
Google Shopping, comparateurs, agents d'achat IA | L'article sort des requêtes filtrées par taille ; avertissements dans le flux | Prochaine exécution du flux |
| 4 | Données structurées de votre site | width / height / depth schema.org |
Moteurs de recherche et moteurs de réponse | Votre propre site contredit votre propre fiche | Prochain déploiement |
| 5 | Photo produit ou schéma coté | Des pixels — le chiffre est incrusté | Tous les acheteurs, en premier, avant le moindre texte | Le chiffre faux le plus visible de la page | Des jours, si un graphiste intervient |
| 6 | Contenu enrichi et tableaux comparatifs | Textes et visuels des modules | Les acheteurs qui scrollent sous la galerie | Contradiction silencieuse à l'intérieur de votre fiche | Des jours, souvent avec revalidation |
| 7 | Catalogue, line sheet, offre de prix | Le PDF que votre équipe colle dans ses e-mails | Acheteurs B2B, agents de sourcing, distributeurs | Vous avez chiffré par écrit avec la valeur périmée | Quand quelqu'un y repense |
| 8 | Documents d'expédition et marquage carton | Dimensions carton, poids net et brut | Douane, transitaire, service réception | Plan de chargement faux, marchandise bloquée ou refusée | À chaque expédition |
| 9 | Notice, plan de montage, packaging imprimé | Imprimé et déjà en stock | L'utilisateur final, après livraison | Tickets SAV et avis une étoile | Prochain tirage |
Neuf endroits, cinq propriétaires différents, des délais qui vont de la minute au tirage d'imprimerie. Cette asymétrie est tout le problème : les champs corrigeables en quelques secondes sont ceux dont on se souvient, et ceux qui demandent des jours sont ceux que l'acheteur voit en premier. Une check-list de modification des spécifications produit qui ne nomme pas un responsable par ligne n'est qu'une liste de vœux.
Une cote périmée ne reste pas un problème de données. Elle devient un retour, et un retour a un coût unitaire que la plupart des vendeurs n'ont jamais calculé — le calculateur de coût des retours transforme un taux de retour en un chiffre auquel une direction financière réagit.
Pourquoi un même produit a plusieurs chiffres justes
Avant d'auditer neuf endroits, acceptez un fait inconfortable : deux de ces endroits peuvent se contredire et avoir raison tous les deux. Les règles GS1 qui encadrent les données produit partagées imposent des arrondis précis, et elles n'arrondissent que dans un seul sens.
Selon le standard GS1 GDSN Package Measurement Rules (version 2.5, ratifiée en septembre 2016) :
- Les millimètres sont toujours arrondis à l'entier supérieur. 99.3 mm devient 100 mm.
- Les pouces sont toujours arrondis au 0.05 pouce supérieur. 2.942 pouces deviennent 2.95 pouces.
- En cas de conversion entre systèmes, on convertit d'abord et on arrondit ensuite, avec 1 pouce = 25.4 mm.
- Les trois dimensions linéaires doivent utiliser le même système de mesure et la même unité.
- Mesurez toujours la distance maximale — saillies, bouchons, couvercles et accessoires fixés sur l'emballage sont inclus, pas ignorés.
Mises bout à bout, la conséquence est évidente. Une pièce de 99.3 mm est publiée à 100 mm dans un système alimenté par GDSN et à 3.95 pouces sur un marché impérial — et votre plan indique toujours 99.3. Trois chiffres, une pièce, aucune erreur.
Le standard publie aussi des tolérances. Pour une unité commerciale non destinée au consommateur, par exemple un colis standard (case unit), la tolérance standard GS1 est de 4.0% sur chacune des dimensions profondeur, largeur et hauteur, avec un plancher de 0.25 pouce (7 mm), et de 4.0% sur le poids brut avec un plancher de 0.2 lb (0.1 kg). Une révision inférieure à ce seuil peut n'obliger à toucher à aucune donnée du colis. Une révision supérieure signifie que chaque système détenant l'ancienne valeur est hors tolérance, et pas simplement pas à jour.
Dernière source de désaccord légitime : le nom des axes. GS1 détermine hauteur, largeur et profondeur à partir de la face avant par défaut de l'article — la face que le propriétaire de la marque utilise pour le promouvoir. Votre plan d'usine, lui, utilise presque à coup sûr longueur, largeur et hauteur depuis une tout autre référence. Quel axe est lequel, et pourquoi les acheteurs lisent le triplet de travers, est un piège à part entière — voyez l'ordre longueur, largeur, hauteur avant de supposer que l'acheteur lit vos trois chiffres comme vous les avez écrits.
Dimensions produit et dimensions d'expédition ne sont pas le même champ
C'est l'échec le plus fréquent de toute la check-list, parce que les deux champs acceptent un nombre et qu'aucun des deux ne proteste.
Google Merchant Center les tient parfaitement séparés, et les deux ensembles ne partagent même pas la même plage de valeurs :
| Attributs de mesure du produit | Attributs de dimensions d'expédition | |
|---|---|---|
| Attributs | product_length, product_width, product_height, product_weight |
shipping_length, shipping_width, shipping_height |
| Ce que cela décrit | Le produit lui-même | Le colis dans lequel le produit voyage |
| Unités acceptées | cm, in (poids : lb, oz, g, kg) | cm, in |
| Plage de valeurs | 1–3000 pour cm et in | 1–400 cm, 1–150 in |
| À quoi cela sert | Découverte produit et pertinence des résultats | Frais de port calculés par le transporteur |
| Règle stricte | Utiliser la même unité pour les trois, sinon l'information ne s'affiche pas | Si vous renseignez un attribut de dimension, renseignez-les tous |
La différence de plage est le révélateur. Un champ plafonné à 400 cm n'a jamais été prévu pour une dimension produit, et un champ qui accepte 3000 cm n'a jamais été prévu pour tarifer un carton. Si quelqu'un dans votre équipe colle le même triplet dans les deux, l'un des deux est faux en ce moment même.
Les données structurées ajoutent un troisième vocabulaire. Sur schema.org, un Product a width, height et depth — aucune propriété length n'existe — chacune exprimée comme une QuantitativeValue avec un unitCode. Une révision, trois conventions de nommage, trois systèmes, trois personnes qui ne voient jamais l'écran des autres. Si personne ne les a renseignées sur votre propre site, les données structurées de dimensions produit sont le moins cher des neuf chantiers.
Les marketplaces ajoutent une subtilité de plus : Amazon publie les attributs de chaque type de produit sous forme de schéma JSON via son API Product Type Definitions, donc un champ de dimension qui existe pour un type de produit n'existe pas forcément pour un autre. « Mettre à jour les dimensions partout » n'est pas une action. C'est une action par schéma.
L'endroit qu'on ne met jamais à jour, c'est l'image
Reprenez le tableau. Les lignes 1 à 4 sont des champs texte — un profil ops les change avant midi. Les lignes 7 à 9 sont des documents, et tout le monde admet qu'un document se révise.
La ligne 5 est celle qui reste fausse pendant des années, parce que le chiffre vit dans des pixels. Le corriger suppose de retrouver le fichier source, de retrouver qui l'a fait, de briefer la modification, d'attendre, de vérifier, de recharger sur chaque canal. La réponse honnête dans la plupart des entreprises est donc : on corrigera l'image au prochain shooting. Il n'y a pas de prochain shooting.
Cela coûte cher, parce que l'image est la première chose que l'acheteur lit et la dernière que quelqu'un audite. Un tableau de specs, on le survole. Une cote imprimée sur la photo, on la croit.
La correction pratique consiste à cesser de traiter un schéma coté comme un visuel et à le traiter comme une vue de vos données : mesurer une fois sur les vrais bords du produit, garder la couche d'annotation vivante et modifiable plutôt qu'aplatie dans un JPEG, et réexporter au format image de chaque canal quand un chiffre change. Fait ainsi, la ligne 5 passe d'un chantier graphique à une retouche de deux minutes — la seule raison pour laquelle elle sera réellement faite.
Le choix de l'outil décide si c'est réaliste. Un logiciel qui mesure — qui accroche la ligne de cote au vrai bord de l'objet et garde le chiffre lié à cette géométrie — se met à jour correctement quand vous changez l'entrée. Un générateur d'images qui produit une photo annotée à l'air crédible ne mesure rien : il invente une valeur qui semble raisonnable et qu'on ne peut pas vérifier. Pour un fond marketing, le compromis se défend. Pour le chiffre qu'un acheteur vous opposera dans une réclamation, non. Même logique pour la fiche technique jointe à une offre de prix : sa valeur ne tient pas à son maquettage, mais au fait que chaque chiffre remonte à une mesure.
La check-list de modification des spécifications produit
Copiez cette check-list de modification des spécifications produit dans votre ticket de modification. Une seule passe, quatre blocs, personne ne devine qui possède quoi.
Source de vérité
- La nouvelle valeur est enregistrée une seule fois, avec un indice de révision et une date, dans le fichier que tout le reste recopie
- L'unité et le système de mesure sont indiqués explicitement (mm ou pouce — pas « 1180 »)
- La mesure inclut saillies, poignées, bouchons et couvercles, selon la règle GS1 de distance maximale
- Vous avez vérifié si l'écart dépasse la tolérance colis de 4% / 7 mm, ce qui décide jusqu'où il doit descendre en aval
Champs vus par l'acheteur
- Dimensions article / produit mises à jour sur chaque marketplace, pas seulement la plus grosse
- Dimensions colis ou d'expédition mises à jour séparément, et vérifiées comme étant bien celles du colis
- Attributs produit du flux Shopping mis à jour ; flux réimporté et avertissements contrôlés
- Données structurées de votre propre page produit mises à jour
Supports
- Schéma coté ou photo annotée réexportés et rechargés sur chaque canal qui les héberge
- Contenu enrichi, tableaux comparatifs et toute image contenant l'ancien chiffre remplacés
- Catalogue, line sheet et modèle d'offre régénérés ; ancien PDF supprimé des disques partagés et des modèles d'e-mail
Papier et impression
- Modèles de liste de colisage, facture commerciale et marquage carton mis à jour pour la prochaine expédition
- Notice, plan de montage et packaging imprimé signalés pour le prochain tirage, avec comptage du stock existant
- Offres en cours émises avec l'ancienne valeur identifiées, et acheteurs concernés prévenus avant qu'ils ne le découvrent
Ordre des opérations
L'enchaînement compte plus que la vitesse, parce que certaines de ces étapes sont mises en cache et que d'autres sont lues par des machines.
- Figez d'abord la source de vérité. Si deux personnes éditent encore le chiffre, tout ce qui suit hérite du désaccord.
- Mettez à jour les champs marketplace vus par l'acheteur. Les plus rapides à changer, les plus rapides à faire mal.
- Réexportez l'image avant de toucher au flux. Flux et caches récupèrent la nouvelle URL d'image sur le même cycle que les nouveaux chiffres : aucune fenêtre d'incohérence ne s'ouvre.
- Poussez le flux et relancez l'import. Vérifiez que l'article n'est pas coincé dans les avertissements ; un article rejeté est pire qu'un article périmé.
- Régénérez les documents. Catalogue, line sheet, modèle d'offre — et supprimez l'ancien fichier plutôt que de le renommer.
- Imprimez en dernier. Les tirages sont la seule étape irréversible de la liste.
Puis faites la seule chose que presque personne ne fait : cherchez le nom de votre produit et lisez votre propre fiche comme un acheteur, sur un téléphone, sans être connecté. La contradiction qui vous a échappé sautera aux yeux en huit secondes environ.
FAQ
Comment mettre à jour les dimensions produit d'une fiche sans perdre son positionnement ?
Modifiez l'attribut sur place. Changer un champ de données n'est pas republier l'article : l'historique de la fiche survit. Ce qui fait vraiment mal, c'est de supprimer puis recréer la fiche pour « repartir propre », ce qui jette les avis, l'historique de ventes et l'identifiant que les acheteurs ont mis en favori.
Quelle différence entre dimensions article et dimensions du colis ?
Les dimensions article ou produit décrivent le produit lui-même, et l'acheteur s'en sert pour savoir si ça rentre. Les dimensions colis ou d'expédition décrivent la boîte dans laquelle il voyage, et le transporteur s'en sert pour tarifer l'envoi. Google Merchant Center impose la séparation au niveau du schéma : product_length et ses voisins acceptent jusqu'à 3000 cm ou pouces, alors que shipping_length et ses voisins plafonnent à 400 cm ou 150 pouces.
Faut-il changer la photo produit quand une cote change ?
Oui, et c'est le support prioritaire de la liste, pas le dernier. Un chiffre imprimé sur une image est lu avant le tableau de specs et pèse plus lourd dans un litige, parce que l'acheteur peut le pointer du doigt. Si votre annotation est aplatie dans un JPEG sans source modifiable, c'est le moment de la reconstruire en couche vivante au-dessus de la photo, pour que la prochaine révision prenne quelques minutes.
De combien une cote peut-elle bouger avant qu'il faille prévenir l'acheteur ?
Commercialement, prévenez pour tout écart qui touche l'ajustement, le dégagement ou l'empilage — c'est un jugement, pas un seuil. Pour les données produit partagées, il existe un repère publié : la tolérance standard GS1 pour un colis standard est de 4.0% par dimension avec un plancher de 7 mm. Un écart dans cette bande est du bruit de données. Un écart au-delà signifie que chaque système détenant l'ancienne valeur est hors tolérance.
Quelle unité publier, millimètres ou pouces ?
Publiez le système exigé par votre marché cible, et publiez les trois axes dans cette même unité — GS1 impose aux trois dimensions linéaires un seul système de mesure et une seule unité. Quand vous convertissez, convertissez d'abord et arrondissez ensuite, avec 1 pouce = 25.4 mm, puis appliquez la règle d'arrondi au supérieur propre à l'unité. Convertir un nombre déjà arrondi, c'est ainsi qu'une erreur de 3 mm devient une erreur de 6 mm.
Sources et références
- Centre d'aide Google Merchant Center — product length, product width, product height, product weight : unités, formats et plages de valeurs
- Centre d'aide Google Merchant Center — shipping length, shipping width, shipping height : unités acceptées et limites de valeurs
- GS1 — Package and Product Measurement Standard (standard en vigueur)
- GS1 — GDSN Package Measurement Rules Standard, version 2.5 (ratifiée en septembre 2016) : règles d'arrondi, face avant par défaut et tolérances standard
- schema.org — Product : propriétés width, height, depth et QuantitativeValue
- Amazon Selling Partner API — méta-schéma Product Type Definitions (les attributs sont définis par type de produit)