Importer un catalogue fournisseur sans perdre une donnée

La crainte d'un responsable catalogue n'est pas qu'un import échoue. Un import qui échoue se voit, se corrige et se relance. Ce qui fait peur, c'est l'import qui réussit et qui écrase six mois de travail : des descriptions retravaillées remplacées par deux lignes de fournisseur, des visuels sélectionnés par vos équipes remplacés par des packshots génériques, des prix négociés revenus au tarif public. Cet article décrit les garde-fous qui rendent une écriture dans le référentiel vérifiable avant, et réversible après.

Précisons le périmètre, parce que trois moments différents sont souvent confondus. La récupération des fichiers — FTP, SFTP, EDI, planification des collectes — est traitée dans automatiser vos imports fournisseurs en FTP et EDI. La transformation des valeurs — unités, encodages, mapping d'attributs, doublons — est traitée dans normaliser les données de vingt fournisseurs. Ici, le fichier est arrivé et les valeurs sont propres. Il reste le moment le plus risqué : l'écriture dans votre référentiel.

Le scénario redouté

Un mardi matin, l'import du fournisseur principal tourne comme les cinquante fois précédentes. Le mercredi, un commercial signale qu'une fiche affiche une description de trois lignes au lieu du texte réécrit l'hiver dernier. En cherchant, l'équipe découvre que des milliers de références sont concernées, que les images éditorialisées ont été remplacées et que personne ne sait dire quand. Le fichier source, lui, a déjà été écrasé par celui du lendemain.

Trois causes reviennent presque toujours.

• Le fichier partiel pris pour un fichier complet — le fournisseur a envoyé un extrait d'une gamme, l'import était configuré en remplacement intégral. Tout ce qui n'était pas dans l'extrait a été désactivé ou vidé.
• La colonne vide interprétée comme une valeur vide — c'est la cause la plus sournoise. Une cellule sans contenu ne veut pas dire « la valeur est vide », elle veut dire « ce fournisseur ne renseigne pas ce champ ». Sans distinction explicite entre absent et vide, un export où la colonne description n'est plus remplie efface toutes vos descriptions.
• Le mapping modifié sans relecture — quelqu'un a ajouté une correspondance en urgence un vendredi soir pour intégrer une nouvelle colonne. La modification était juste pour les vingt lignes testées et fausse pour les trente mille autres.

Le point commun de ces trois cas : aucun n'a produit d'erreur technique. L'import s'est déroulé exactement comme on le lui avait demandé. C'est pourquoi la surveillance des échecs ne protège de rien ici — il faut surveiller les succès.

Un import est une transaction, pas une copie

Le réflexe naturel consiste à voir un import comme une recopie : je prends le fichier, je pousse les valeurs dans les fiches. C'est ce modèle mental qui produit les dégâts. Un import est une transaction : un ensemble d'opérations qu'on applique en bloc, ou pas du tout, après vérification. Quatre conditions devraient donc être vraies avant qu'une seule valeur ne soit écrite en base.

• La structure du fichier est conforme — les colonnes attendues sont présentes, dans un format lisible. Un fichier auquel il manque une colonne obligatoire ne se traite pas en dégradé, il s'arrête.
• Le volume est plausible — un seuil de variation compare le nombre de lignes reçues au dernier import réussi. Une chute de moitié suspend le traitement et demande une validation humaine, parce que c'est presque toujours une troncature de transfert, pas un déréférencement massif.
• Le périmètre d'écriture est déclaré — cet import a le droit de toucher tel fournisseur, telle famille, tels champs. Rien en dehors. Un import fournisseur qui peut écrire partout est une bombe à retardement.
• L'état précédent est conservé — avant écriture, la version courante des fiches concernées est historisée. Sans cette photo, aucun retour arrière n'est possible, quelle que soit la qualité du reste du dispositif.

La simulation à blanc

La simulation applique toutes les règles au fichier reçu et produit le compte rendu de ce qui se passerait, sans rien écrire. C'est le seul moment où corriger coûte quelques minutes au lieu de plusieurs jours.

Un rapport de simulation utile tient sur un écran et répond à cinq questions.

L'échantillon avant/après est la partie que les équipes lisent le moins et qui rattrape le plus d'erreurs. Triez-le par nombre de champs modifiés décroissant : les lignes les plus impactées remontent en premier et une anomalie de mapping s'y voit immédiatement. Une simulation qui annonce un total de mises à jour sans dire lesquelles ne sert à rien.

Les champs verrouillés

Un catalogue mélange deux natures de données : celles que le fournisseur possède et celles que vous avez produites. Confondre les deux est la vraie cause des écrasements. Le verrouillage consiste à déclarer, une fois pour toutes, qui fait autorité sur quoi.

Le verrouillage se déclare à trois granularités, à combiner selon les cas.

• Par champ — le réglage de base, valable pour tout le catalogue : personne n'écrase la description longue par un import.
• Par famille — utile quand la règle dépend du type de produit. Sur des consommables, la désignation fournisseur suffit ; sur une gamme premium retravaillée, elle est verrouillée.
• Par origine de la donnée — le plus fin : le champ reste modifiable par un import, mais uniquement si la valeur en place provient elle aussi d'un import. Dès qu'un humain a touché le champ, il se verrouille automatiquement. C'est le réglage qui demande le moins d'entretien, à condition que chaque valeur porte son origine et sa date.

Un verrouillage ne doit jamais faire disparaître la donnée entrante : la valeur du fournisseur reste conservée à côté et peut être adoptée d'un geste. Le verrouillage protège de l'écriture automatique, il n'empêche pas la décision humaine.

Versionnage et retour arrière

Même avec une simulation lue et des champs verrouillés, un import passera un jour. Il faut donc pouvoir revenir en arrière sans redemander un fichier au fournisseur. Chaque exécution devient pour cela un objet identifié : date, fournisseur, fichier source conservé, règles de mapping dans leur version du jour, opérateur, rapport de simulation associé. Garder le fichier source compte autant que garder le résultat — c'est la seule façon de rejouer un import quand on découvre que la règle, et non la donnée, était fausse.

Le retour arrière se pense ensuite à trois granularités, du plus large au plus chirurgical.

• L'import entier — on annule le lot complet et le référentiel retrouve son état de la veille. C'est la réponse aux erreurs de configuration découvertes dans l'heure.
• Un fournisseur ou un périmètre — on annule ce qu'un flux a écrit sans toucher aux autres imports intervenus depuis. Indispensable quand plusieurs fournisseurs alimentent les mêmes fiches.
• Un produit ou un champ — le cas le plus fréquent en réalité : une fiche signalée par un commercial, restaurée à sa version précédente sans remettre en cause le reste de l'import.

Une précision qui évite un piège : annuler un import ne doit jamais supprimer les fiches qu'il a créées si elles ont depuis été commandées ou publiées. Le retour arrière restaure des valeurs et des statuts, il ne détruit pas d'objets métier.

Le journal d'erreurs

Un journal technique qui affiche une exception de parseur ne sert à personne dans une équipe catalogue. Le journal utile est écrit pour la personne qui va corriger, c'est-à-dire un gestionnaire, pas un développeur. Une ligne par anomalie, et sur chaque ligne quatre informations : où (ligne du fichier et référence produit), quoi (le champ et la valeur reçue), pourquoi (la règle violée en français), et ce qui a été fait (valeur rejetée, ligne ignorée, valeur remplacée par le défaut, champ verrouillé donc non écrit).

Trois propriétés font la différence entre un journal consulté et un journal ignoré : il se filtre par fournisseur, par champ et par type d'anomalie ; il s'exporte pour être renvoyé tel quel au fournisseur ; il se rejoue une fois les corrections faites. Un gestionnaire traite alors ses anomalies lui-même au lieu d'ouvrir un ticket. C'est l'approche retenue dans les modules d'import et de qualité de données de Pixee PIM : simulation avant écriture, journal par ligne, historique par import et règles conservées par fournisseur.

Ce qu'il faut surveiller après coup

Les garde-fous décrits plus haut protègent l'import du jour. Reste à détecter ce qui se dégrade lentement, sur des semaines, sans jamais déclencher d'erreur. Trois indicateurs suffisent, relevés à chaque exécution et comparés à l'historique du même flux.

• Le volume de champs modifiés par import — un flux stable écrit un nombre de champs comparable d'une semaine sur l'autre. Un doublement soudain signale un changement de format côté fournisseur ou un mapping qui a bougé, bien avant que quelqu'un ne s'en plaigne.
• Le taux de rejet — utile surtout dans sa dérive. Un taux qui grimpe progressivement pendant un mois annonce un export fournisseur qui se détériore. Un taux qui tombe brutalement à zéro est tout aussi suspect : une règle de validation a peut-être été désactivée.
• La dérive silencieuse — la plus difficile à voir : nombre de champs verrouillés qui reçoivent une proposition, proportion de fiches dont la description redevient celle du fournisseur, score de complétude par famille. Aucune de ces mesures ne déclenche d'alerte technique, mais leur pente raconte l'érosion de votre travail d'enrichissement.

Questions fréquentes

Faut-il verrouiller un champ ou le laisser en proposition ?

Les deux se combinent. Le verrouillage empêche l'écriture automatique, la proposition conserve la valeur entrante et la présente pour arbitrage. Le mauvais réglage est celui qui verrouille en jetant la donnée : vous ne saurez plus jamais que le fournisseur avait actualisé sa fiche technique.

Combien de temps conserver l'historique des imports ?

Assez longtemps pour couvrir le délai entre une erreur et sa détection, rarement immédiat : une anomalie de description remonte par un commercial ou un client, pas par une alerte. Plusieurs cycles d'import complets est un bon repère — le coût de stockage est sans commune mesure avec celui d'un ré-enrichissement.

La simulation ralentit-elle le cycle d'import ?

Elle ajoute une étape, pas nécessairement une intervention. Sur un flux nouveau ou dont le format vient de changer, la lecture humaine du rapport est indispensable. Sur un flux stabilisé, elle s'exécute automatiquement et ne réclame une validation que si un seuil est franchi — volume anormal, champ inattendu, suppressions détectées.

Peut-on tester ces garde-fous sans engager tout le catalogue ?

Oui, et c'est la bonne façon de procéder : un fournisseur, une famille de produits, un cycle complet observé sur quelques semaines avant d'élargir. L'essai gratuit de 30 jours de Pixee PIM — 2 000 produits et 2 fournisseurs, sans carte bancaire — suffit à valider une configuration de verrouillage et à lire ses premiers rapports de simulation. Le détail des volumes par offre est sur la page tarifs.