Pour corriger les données invalides d’un flux produit, il faut contrôler chaque champ contre le format attendu par la marketplace (type, unité, liste de valeurs, longueur, URL), regrouper les erreurs par famille, puis corriger la source ou poser une règle de conversion qui s’appliquera à chaque envoi. Une donnée invalide n’est pas une donnée absente : l’information existe, mais sous une forme que la marketplace ne peut pas lire.
Sur les mises en place de catalogues accompagnées par Iziflux, les données invalides sont le troisième motif de rejet le plus fréquent, après les attributs manquants ou non conformes et la mauvaise catégorisation. Ce sont aussi les erreurs les plus faciles à automatiser une fois repérées. Ce tuto passe en revue les cinq familles de données invalides, la façon de les détecter et les corrections durables.
Qu’est-ce qu’une donnée invalide dans un flux produit ?
Une donnée invalide est une valeur présente dans le flux, mais refusée par la marketplace parce qu’elle ne respecte pas le format attendu : un nombre écrit comme du texte, une unité absente, un code-barres à la clé de contrôle fausse, une image inaccessible, un prix incohérent. Le produit est alors rejeté, ou l’attribut concerné est ignoré.
La différence avec un attribut manquant est importante : un attribut manquant se corrige en associant ou en ajoutant une information ; une donnée invalide se corrige en la transformant. Le tuto pour corriger un attribut manquant ou non conforme traite le premier cas ; celui-ci traite le second.
Constat sur les mises en place Iziflux
Les données invalides arrivent en troisième position des motifs de rejet à l’intégration, derrière les attributs manquants ou non conformes et la mauvaise catégorisation. L’absence pure et simple de code EAN reste très rare : quand un code-barres pose problème, c’est le plus souvent son format qui est en cause, pas son absence.
Les 5 familles de données invalides
Schéma : les 5 familles de données invalides dans un flux produit
| Famille | Exemples |
|---|---|
| 1. Format | EAN à la clé de contrôle fausse, date mal écrite, texte dans un champ numérique |
| 2. Unités | « 120 » sans unité, centimètres au lieu de mètres, virgule au lieu du point |
| 3. Valeurs hors liste | « Bleu nuit » au lieu de « Bleu », marque absente du référentiel |
| 4. Images | URL inaccessible, format refusé, taille sous le minimum, texte incrusté |
| 5. Prix et stock | Prix à zéro, prix barré inférieur au prix de vente, stock négatif |
1. Les erreurs de format
Chaque champ a un type : nombre entier, nombre décimal, texte, date, booléen, URL. Une erreur de format survient quand la valeur ne correspond pas au type attendu. Les cas les plus fréquents :
- Codes-barres : un code EAN-13 doit compter 13 chiffres, sans espace ni lettre, et son dernier chiffre est une clé de contrôle calculée à partir des 12 premiers. Un code tapé à la main ou tronqué par un tableur (qui supprime le zéro initial ou passe en notation scientifique) devient invalide. GS1 explique le calcul et propose un outil de vérification de la clé de contrôle.
- Nombres : « 18V », « env. 2 kg » ou « 1 200 » (avec une espace) ne sont pas des nombres pour une marketplace qui attend 18, 2 ou 1200.
- Dates : le format attendu est souvent normalisé (année-mois-jour), alors que la boutique stocke parfois « 19/10/2026 ».
- Texte : balises HTML dans un champ qui les refuse, caractères spéciaux mal encodés (« é » au lieu de « é »), majuscules intégrales dans un titre.
2. Les erreurs d’unité
Les dimensions, poids, volumes et puissances sont des pièges classiques. La marketplace impose une unité (mètres, kilogrammes, watts) et parfois un séparateur décimal. Une largeur de « 120 » envoyée dans un champ en mètres signifie 120 mètres. Le produit n’est pas forcément rejeté, mais il s’affiche avec une dimension absurde, ce qui génère des retours.
3. Les valeurs hors liste
De nombreux attributs n’acceptent qu’une liste fermée de valeurs : couleur, matière, marque, type de fixation, classe énergétique. Toute valeur absente de la liste est invalide, même si elle est juste pour un humain. La correction passe par une table de correspondance : « Bleu nuit », « Navy » et « Bleu marine » deviennent « Bleu ».
4. Les images
Une image peut être refusée pour une URL inaccessible (lien mort, protocole non sécurisé, page de connexion), un format non accepté, une taille insuffisante ou un contenu interdit sur la photo principale (texte, logo, filigrane). Ce point se durcit : Google a annoncé que les images envoyées dans image_link et additional_image_link devront mesurer au moins 500 x 500 pixels pour toutes les catégories à partir du 31 janvier 2027, avec des avertissements affichés dans Merchant Center depuis avril 2026. Le détail figure dans l’annonce de mise à jour des spécifications des données produit de Google. Profitez-en pour vérifier aussi la taille minimale exigée par chacune de vos marketplaces.
5. Les prix et les stocks incohérents
Un prix à zéro, un prix barré inférieur au prix de vente, un stock négatif ou des frais de port manquants provoquent des rejets d’offres. Ces erreurs viennent souvent d’une règle de calcul mal paramétrée, d’une promotion expirée dans la boutique ou d’un produit désactivé. Dans Iziflux, la configuration générale du compte permet notamment de choisir de ne pas communiquer les prix promotionnels de la boutique vers les marketplaces, ce qui évite d’envoyer des prix barrés incohérents.
Comment repérer les données invalides avant l’envoi ?
Trois contrôles permettent de détecter l’essentiel des données invalides avant que la marketplace ne les refuse :
- Le contrôle de type : chaque champ numérique ne contient que des chiffres et un séparateur ; chaque URL commence par https et répond.
- Le contrôle de liste : chaque valeur d’un attribut à liste fermée figure dans la liste de la marketplace.
- Le contrôle de cohérence : prix de vente supérieur à zéro, prix barré supérieur au prix de vente, stock positif ou nul, poids cohérent avec la catégorie.
Dans Iziflux, ces contrôles alimentent l’onglet Anomalies de chaque marketplace, qui liste les données manquantes, incorrectes ou non conformes aux exigences du support, produit par produit. Le suivi des intégrations distingue les références intégrées, refusées ou nécessitant une optimisation.
Comment corriger les données invalides durablement ?
| Erreur | Correction ponctuelle | Correction durable |
|---|---|---|
| EAN à la clé fausse | Ressaisir le code | Corriger dans la boutique et protéger la colonne en texte dans vos imports |
| « 18V » dans un champ numérique | Remplacer par 18 | Règle d’extraction du nombre |
| Centimètres au lieu de mètres | Diviser par 100 | Règle de conversion par marketplace |
| Couleur hors liste | Choisir la valeur la plus proche | Table de correspondance des couleurs |
| Image trop petite | Remplacer l’image | Imposer une taille minimale à l’import des photos |
| Prix barré incohérent | Supprimer le prix barré | Règle de contrôle avant envoi ou désactivation des prix promotionnels |
La règle d’or reste la même que pour tous les rejets : ne corrigez pas dans l’interface de la marketplace. La correction serait écrasée au prochain envoi. Corrigez dans la boutique, ou posez une règle dans votre gestionnaire de flux. Avec le moteur de règles CONDITIONS → ACTIONS d’Iziflux, une conversion d’unité ou une table de valeurs se définit une fois et s’applique à chaque envoi, sur tous les produits concernés. Les règles peuvent être décrites en langage naturel, l’IA les traduisant en conditions et actions que vous validez.
Scénario type : des dimensions mille fois trop grandes
Ce scénario est une illustration de la méthode, pas un cas client. Un fabricant de mobilier envoie 300 tables et bureaux sur une marketplace maison. Les produits sont acceptés, mais les fiches affichent des largeurs de 1 600 mètres. La boutique stocke les dimensions en millimètres, la marketplace les attend en mètres. Une seule règle de conversion, appliquée aux attributs largeur, profondeur et hauteur, corrige les 300 fiches au renvoi suivant, et tous les futurs produits de mobilier.
Données propres, meilleure visibilité dans les moteurs IA
Les assistants d’achat comme ChatGPT et les moteurs de recherche comparent les produits à partir de données structurées : dimensions, poids, couleurs, prix. Une valeur invalide fausse la comparaison ou fait disparaître le produit d’une réponse. La qualité des données est donc un enjeu de visibilité bien au-delà des marketplaces. Pour aller plus loin, lisez notre définition du GEO (Generative Engine Optimization).
Checklist avant chaque envoi
- Les codes-barres comptent le bon nombre de chiffres et leur clé de contrôle est valide.
- Les champs numériques ne contiennent que des nombres, sans unité ni texte.
- Les unités correspondent à celles imposées par chaque marketplace.
- Les valeurs des attributs à liste fermée figurent dans la liste.
- Les URL d’images répondent, en https, et respectent la taille minimale.
- Les prix sont positifs, les prix barrés supérieurs aux prix de vente, les stocks positifs ou nuls.
- Les textes sont correctement encodés, sans balises interdites.
Pour les autres causes de rejet, consultez notre tuto pour corriger les rejets produits sur Amazon, Cdiscount et ManoMano, celui pour associer ses catégories à celles d’une marketplace, ainsi que notre définition du code EAN.
Questions fréquentes
Quelle différence entre une donnée invalide et un attribut manquant ?
Un attribut manquant est vide ou non associé. Une donnée invalide est présente, mais dans un format que la marketplace refuse : mauvais type, unité, valeur hors liste, image inaccessible ou prix incohérent.
Comment vérifier qu’un code EAN est valide ?
Un EAN-13 compte 13 chiffres, et le dernier est une clé de contrôle calculée à partir des 12 premiers. Les outils de vérification de GS1 permettent de contrôler cette clé.
Pourquoi mes codes EAN sont-ils modifiés dans mon fichier ?
Les tableurs convertissent souvent les longs nombres : ils suppriment les zéros initiaux ou passent en notation scientifique. Formatez la colonne en texte avant d’ouvrir ou d’importer le fichier.
Quelle taille d’image faut-il prévoir ?
Elle dépend de chaque marketplace. Pour Google, les images devront mesurer au moins 500 x 500 pixels à partir du 31 janvier 2027. Prévoir des photos nettement plus grandes laisse de la marge sur tous les canaux.
Peut-on corriger les données invalides sans modifier sa boutique ?
Oui, pour les conversions et correspondances : unités, valeurs de liste, extraction de nombres. Un gestionnaire de flux applique ces règles à chaque envoi. Une information fausse à la source, comme un code-barres erroné, doit en revanche être corrigée dans la boutique.
Et si on s’en occupait ensemble ?
Vous savez maintenant repérer les cinq familles de données invalides. Avec Iziflux, les anomalies remontent marketplace par marketplace et vos règles de conversion s’appliquent à chaque envoi. Testez sur votre catalogue pendant 30 jours, sans engagement.
