Normalisation multi-fournisseurs : 5 défis et comment les surmonter

Le fichier fournisseur est arrivé, il est complet, il s'ouvre sans erreur. C'est maintenant que le travail commence. Vingt fournisseurs, c'est vingt façons d'écrire un poids, vingt vocabulaires d'attributs et vingt niveaux de propreté du texte. Cet article passe en revue les cinq défis de normalisation qui reviennent chez tous les distributeurs, et la manière de les traiter pour que le résultat soit reproductible d'une semaine sur l'autre.

Une précision de périmètre : nous ne parlons pas ici de la façon d'aller chercher les fichiers. Le FTP, le SFTP, l'EDI PRICAT et la planification des collectes font l'objet d'un article dédié, automatiser vos imports fournisseurs en FTP et EDI. Ici, le transfert est déjà réussi. Tout ce qui suit se passe entre la lecture de la première ligne et l'écriture dans votre référentiel produits.

Défi 1 — Les unités et les formats de valeur

C'est le défi le plus banal et le plus coûteux. Un fournisseur exprime ses longueurs en millimètres, son voisin en centimètres, un troisième en pouces : chacun exporte dans l'unité de son propre système. Le problème naît quand les trois fichiers atterrissent dans la même colonne.

• Les longueurs — 45 peut valoir 45 mm ou 45 cm. Sans unité déclarée dans le fichier, la seule source fiable est la fiche de cadrage du fournisseur, à conserver avec la règle d'import.
• Le poids brut et le poids net — deux notions distinctes que beaucoup de catalogues fusionnent dans une colonne POIDS. Le brut inclut l'emballage, le net non.
• Le séparateur décimal — 1,250 vaut 1,25 kg dans un export français et 1250 dans un export anglo-saxon. Une même colonne peut contenir les deux conventions si le fournisseur a lui-même agrégé plusieurs sources.
• Les devises — un prix sans devise explicite est inutilisable : stockez-la à côté du montant, avec la date de la grille appliquée.
• La TVA — HT ou TTC, à quel taux, avec ou sans éco-participation. Une grille reçue en TTC et importée comme du HT décale toute votre marge sans déclencher la moindre erreur technique.

Les conséquences se voient sur les frais de port, calculés au poids réel et au poids volumétrique — une dimension interprétée en millimètres au lieu de centimètres change la tranche tarifaire — et sur les fiches publiées : un téléviseur annoncé en 55 mm de diagonale déclenche des retours produits et des rejets marketplace.

La parade est de ne jamais convertir implicitement. Chaque champ numérique de votre modèle cible porte une unité canonique unique — longueurs en millimètres, poids en grammes, prix HT dans une devise pivot — et chaque connecteur déclare l'unité source à convertir. Une valeur dont l'unité est inconnue n'entre pas : elle part en anomalie.

Défi 2 — Les encodages et la propreté du texte

Le second défi ne casse rien : il salit. Les lignes s'importent sans erreur, et six mois plus tard vous découvrez des centaines de fiches publiées avec des accents cassés.

• UTF-8 contre Latin-1 — un fichier Windows-1252 lu comme de l'UTF-8 produit les fameux é et °. Le pire cas est le double transcodage : le fichier a été ouvert et réenregistré une fois, et la valeur d'origine n'est plus récupérable.
• Les espaces parasites — espaces insécables, espaces en fin de valeur, tabulations dans une désignation. Deux libellés visuellement identiques ne se rapprochent plus, et vos facettes se dédoublent.
• Les majuscules intégrales — PERCEUSE SANS FIL 18V COFFRET est lisible dans un ERP, pas sur une fiche produit. Prévoyez une règle de recasse avec un dictionnaire d'exceptions pour les marques et les sigles.
• Le HTML échappé — vous recevez <p>Texte</p> au lieu de balises réelles, ou l'inverse : du HTML brut avec styles inline qui casse la charte de votre site. Décidez si votre champ description stocke du texte riche ou du texte brut, et nettoyez les attributs de style à l'entrée.
• Les codes-barres mangés par le tableur — un EAN passé dans Excel sans format texte revient en 3,60421E+12, tronqué et irrécupérable tel quel. Le sujet est détaillé dans notre article sur la validation automatique des codes-barres GS1.

Concrètement, voici le passage d'une ligne brute à une ligne propre.

Défi 3 — Les attributs absents ou nommés différemment

Un fournisseur appelle REF_FAB ce que le suivant nomme MPN et le troisième Code constructeur. Le mapping fait converger ces colonnes vers un modèle d'attributs cible unique, qui est le vôtre et ne bouge pas quand un fournisseur change son export.

Poser le modèle cible avant de mapper

L'ordre compte. On définit d'abord les attributs que votre catalogue doit porter, famille par famille, puis on branche chaque fournisseur dessus. Construire le modèle au fil des fichiers reçus produit un référentiel à deux cents attributs dont la moitié sont des synonymes.

Réconcilier les valeurs de liste

Le mapping ne s'arrête pas aux noms de colonnes. Pour un attribut de type liste, Noir, NOIR, black et RAL 9005 désignent la même chose et doivent tomber sur la même entrée. La règle qui compte : toute valeur inconnue est signalée, jamais créée silencieusement. Sans ce garde-fou, vos filtres de navigation deviennent inutilisables.

Ce qu'on fait d'une donnée manquante

Déclarez pour chaque famille les attributs sans lesquels un produit ne peut pas sortir vers un canal de vente — une perceuse sans tension d'alimentation n'est pas une fiche publiable. Vous disposez alors d'un critère objectif pour choisir entre trois réponses.

• Le rejet — la ligne n'entre pas. À réserver aux champs qui rendent la fiche inexploitable : identifiant, désignation, prix d'achat.
• La valeur par défaut — utile quand la valeur est prévisible. Jamais sur un champ qui engage, comme un poids ou une garantie.
• L'enrichissement — la donnée manque chez ce fournisseur mais existe ailleurs, chez un autre fournisseur du même produit ou dans une base de référence. Le produit entre avec un statut incomplet et le module d'enrichissement complète les attributs avant publication.

Défi 4 — Les doublons

Dès que deux fournisseurs référencent la même marque, vous recevez le même produit deux fois. Sans rapprochement, vos stocks consolidés sont faux et deux fiches concurrentes de votre propre maison se retrouvent en ligne. Le rapprochement se fait en cascade, du plus fiable au plus incertain.

• Par code-barres — c'est le seul identifiant réellement partagé entre acteurs. Encore faut-il qu'il soit valide : un rapprochement sur un EAN au checksum faux crée des fusions absurdes. La validation précède toujours le rapprochement.
• Par marque et référence fabricant — quand l'EAN manque, le couple marque + MPN est le meilleur recours, à condition de normaliser les deux termes avant de comparer : tirets, espaces et suffixes varient d'une source à l'autre.
• Par similarité, en dernier recours — désignation et attributs techniques proches. Ce niveau ne fusionne jamais automatiquement : il alimente une file de rapprochements à confirmer.

Attention au faux positif le plus fréquent : les lots et les conditionnements. Un flacon vendu à l'unité et le même flacon vendu par carton de douze partagent la marque et souvent une racine de référence, mais ce sont deux articles distincts. Le conditionnement est donc un critère structurant du rapprochement, au même titre que la référence.

Reste à décider quelle valeur gagne une fois la fusion actée : une priorité de source définie champ par champ — le fabricant fait foi sur la fiche technique, la source la plus récente sur le prix d'achat — et non un dernier arrivé qui écrase tout.

Défi 5 — Les mises à jour partielles

Le cinquième défi est le plus dangereux : il détruit des données au lieu d'en ajouter de mauvaises. Certains fournisseurs envoient leur catalogue complet, d'autres uniquement les lignes modifiées, d'autres un extrait par gamme. Traiter un extrait comme un catalogue complet vide la moitié de votre référentiel.

• Différentiel par défaut — un fichier met à jour les références qu'il contient et ne touche pas aux autres. C'est le comportement sûr tant que le fournisseur n'a pas confirmé que son export est exhaustif.
• Remplacement complet, sous condition — réservé aux flux déclarés exhaustifs et encadré par un garde-fou de variation : si le fichier du jour contient nettement moins de lignes que le précédent, l'import se suspend et demande une validation humaine plutôt que de propager une troncature.
• Retraits de référence — le bon signal est une ligne de suppression explicite. À défaut, une référence absente de plusieurs imports exhaustifs consécutifs passe en fin de vie. Dans les deux cas on change un statut, on ne supprime pas la fiche : l'historique de commandes en dépend.
• Champs pilotés par vous — une description retravaillée ou un visuel choisi par vos équipes ne doit pas être écrasé à l'import suivant. Marquez ces champs comme verrouillés, sinon vous referez le même travail à chaque cycle.

Rendre tout cela reproductible

Ces cinq défis se traitent une première fois avec de la patience. Ce qui compte sur la durée, c'est de pouvoir rejouer le même traitement le mois suivant, quand la personne qui l'avait configuré est en congés. Trois éléments y suffisent.

Des règles de normalisation versionnées

Conversions d'unités, tables de valeurs, priorités de source et verrouillages de champs sont de la configuration, pas des scripts jetables dans un dossier partagé. Chaque modification doit être datée, attribuée et réversible : le jour où un prix bascule, la première question utile est de savoir quelle règle a changé depuis le dernier import correct.

Une simulation avant l'import réel

Aucun fichier ne devrait entrer en production sans passage à blanc. La simulation applique les règles et produit le compte rendu de ce qui se passerait — créations, mises à jour, rejets, valeurs qui varient anormalement — sans rien écrire. C'est le seul moment où corriger coûte des minutes plutôt que des jours.

Un journal d'erreurs lisible par un non-technicien

Un log qui affiche une exception de parseur ne sert à personne dans une équipe catalogue. Un journal exploitable indique la ligne, la référence, le champ fautif, la valeur reçue et l'action attendue ; il se filtre, s'exporte et se rejoue une fois les corrections faites. Un gestionnaire traite alors lui-même ses anomalies au lieu d'ouvrir un ticket. C'est la logique retenue dans les modules d'import et de qualité de données de Pixee PIM : mapping visuel, simulation, journal par ligne, règles conservées par fournisseur.

Questions fréquentes

Faut-il conserver la valeur brute du fournisseur après normalisation ?

Oui, systématiquement. Garder la valeur reçue à côté de la valeur normalisée permet de rejouer un import quand une règle se révèle fausse, et de répondre à un fournisseur qui conteste une donnée. Sans cet historique, il faut redemander un fichier qui n'existe souvent plus.

Faut-il rejeter tout le fichier si quelques lignes sont invalides ?

Non, dans la grande majorité des cas. Le rejet doit être granulaire : les lignes conformes entrent, les autres partent en anomalie avec leur motif. Le rejet global ne se justifie que si le fichier lui-même est suspect — colonnes manquantes, encodage illisible, volume anormalement faible.

Que faire quand un fournisseur change ses en-têtes sans prévenir ?

Validez la structure avant le contenu : l'import vérifie que les colonnes attendues sont présentes et s'arrête sinon, plutôt que de mapper par position et d'écrire des prix dans un champ poids. Un rapprochement par nom de colonne tolérant à la casse absorbe les variations cosmétiques sans masquer les vrais changements de format.

Combien de temps faut-il pour cadrer un nouveau fournisseur ?

Selon nos estimations internes, l'essentiel du travail se concentre sur le premier fichier : comprendre les unités, écrire le mapping, réconcilier les valeurs de liste. Les imports suivants ne demandent plus qu'une surveillance du journal d'anomalies, et le facteur déterminant n'est pas le volume de références mais le nombre d'attributs à mapper. L'essai gratuit de 30 jours de Pixee PIM, limité à 2 000 produits et 2 fournisseurs, suffit à cadrer un premier flux ; le détail des volumes par offre est sur la page tarifs.