Comment importer 10 000 produits depuis un CSV mal formé ?

Le fichier arrive par courriel, il pèse quarante mégaoctets, il s'appelle catalogue et il est censé contenir dix mille produits. Ouvert dans un tableur, il affiche des caractères abîmés, des colonnes décalées à partir de la ligne trois mille et des prix écrits de quatre façons différentes. C'est la situation ordinaire, et l'import d'un CSV mal formé ne se règle ni en le corrigeant à la main, ce qui prendrait des jours, ni en le poussant tel quel dans la boutique, ce qui produirait un catalogue inexploitable. Elle se règle par une chaîne de traitement écrite une seule fois, rejouable à l'identique, et dont chaque étape produit un rapport lisible de ce qu'elle a corrigé, transformé ou écarté.

Diagnostiquer le fichier avant d'y toucher

La première erreur consiste à ouvrir le fichier dans un tableur et à l'enregistrer, ce qui modifie irrémédiablement l'encodage, les séparateurs et parfois les valeurs numériques. Le fichier reçu doit être conservé intact, archivé avec sa date, et copié avant tout traitement, comme n'importe quelle donnée source. Ce réflexe fait partie des précautions que nous appliquons systématiquement sur les projets de la rubrique e-commerce.

Identifier l'encodage réel

Un fichier fournisseur français est rarement en UTF-8. Il arrive le plus souvent dans un jeu de caractères occidental hérité, parfois avec une marque d'ordre des octets en tête que certains outils ne savent pas ignorer, parfois dans un mélange des deux si le fichier a été assemblé à partir de plusieurs sources. La détection se fait en lisant les premiers milliers d'octets et en testant les décodages plausibles, en retenant celui qui ne produit aucune erreur et dont les caractères accentués sont cohérents. Cette vérification prend une minute et évite de découvrir après import que huit cents descriptions sont abîmées, chose qu'aucun retour en arrière simple ne corrigera.

Trouver le vrai séparateur

Le point virgule domine dans le monde francophone, la virgule dans les fichiers produits par des outils anglophones, et la tabulation apparaît dès qu'un exportateur a voulu éviter les deux. La détection fiable consiste à compter les occurrences de chaque candidat sur les premières lignes et à retenir celui dont le nombre est le plus régulier d'une ligne à l'autre, plutôt que le plus fréquent. Un fichier dont les descriptions contiennent des points virgules piège tous les détecteurs naïfs, et c'est malheureusement le cas le plus courant sur les catalogues, les descriptions commerciales en étant truffées.

Compter les colonnes ligne par ligne

Le contrôle qui révèle le plus de choses consiste à compter le nombre de champs de chaque ligne et à afficher la distribution. Un fichier sain donne une valeur unique ; un fichier abîmé en donne trois ou quatre, et le nombre de lignes concernées par chaque anomalie indique immédiatement l'ampleur du problème. Les causes habituelles sont les guillemets non fermés, les retours à la ligne à l'intérieur d'une description, et les séparateurs présents dans une valeur non protégée.

Regarder les valeurs, pas seulement la structure

Un fichier structurellement correct peut être inexploitable sur le fond. Il faut donc échantillonner chaque colonne : dix valeurs prises au hasard, plus la valeur la plus longue et la plus courte, plus le nombre de valeurs vides. Cet examen fait apparaître en cinq minutes les colonnes inutilisables, celles qui mélangent deux informations, celles dont le format change au milieu du fichier, et les colonnes prétendument obligatoires qui se révèlent vides sur un tiers des lignes.

Établir la fiche d'identité du fichier

Le diagnostic doit produire un court document conservé avec le fichier : encodage, séparateur, caractère de protection, présence d'une ligne d'en tête, nombre de lignes, nombre de colonnes attendu, anomalies constatées et leur volume. Ce document sert deux fois, à l'import initial et lors de la prochaine livraison du même fournisseur, qui produira très probablement un fichier affecté exactement des mêmes défauts. Sur un catalogue alimenté mensuellement, cette fiche devient la spécification de la chaîne de traitement.

Se donner les bons outils

Le choix de l'outil de traitement pèse plus qu'on ne le croit sur la suite. Le tableur est à écarter d'emblée : au delà de quelques milliers de lignes il devient pénible, il modifie silencieusement les valeurs qui ressemblent à des dates, il tronque les identifiants longs commençant par un zéro, et surtout il ne laisse aucune trace reproductible de ce qui a été fait. Un script, en Python ou dans n'importe quel langage disponible, présente l'avantage inverse : il documente le traitement par sa seule existence, il se rejoue à l'identique sur la livraison suivante, et il traite dix mille lignes en quelques secondes. La bibliothèque de lecture de fichiers séparés de la bibliothèque standard suffit très largement, à condition de lui indiquer explicitement l'encodage, le séparateur et le caractère de protection plutôt que de la laisser deviner. Sur les fichiers réellement abîmés, une lecture ligne par ligne, sans bibliothèque, donne parfois de meilleurs résultats parce qu'elle permet de décider soi même quoi faire de chaque anomalie.

Nettoyer sans perdre d'information

Le nettoyage doit être mécanique, documenté et réversible. Chaque transformation appliquée doit être justifiable et son effet mesurable, sinon le fichier obtenu devient une boîte noire que personne ne saura reproduire à la livraison suivante. La démarche est la même que pour l'extraction de contenus décrite dans notre article sur la manière de parser du HTML en Python sans casser l'encodage.

Réparer les lignes coupées

Les retours à la ligne à l'intérieur d'une description non protégée par des guillemets coupent un enregistrement en deux, ce qui décale tout ce qui suit dans les analyses naïves. La réparation consiste à parcourir le fichier ligne par ligne, à détecter les lignes dont le nombre de champs est inférieur à l'attendu, et à les fusionner avec la suivante jusqu'à retrouver le compte. Cette heuristique fonctionne dans la grande majorité des cas et doit toujours produire un journal des fusions effectuées, afin qu'un humain puisse en vérifier un échantillon avant de valider.

Normaliser les nombres

Les prix arrivent avec une virgule ou un point décimal, parfois avec un séparateur de milliers, parfois avec un symbole monétaire collé, parfois entre parenthèses pour signifier un montant négatif. La normalisation consiste à retirer tout ce qui n'est ni chiffre ni séparateur décimal, à unifier ce dernier, puis à convertir. Toute valeur qui échoue à cette conversion doit être écartée et signalée, jamais remplacée par zéro : un prix à zéro passé en production se vend, et cette erreur là coûte immédiatement de l'argent.

Nettoyer les chaînes sans les appauvrir

Les libellés arrivent avec des espaces en trop, des espaces insécables, des majuscules intégrales, des codes de mise en forme hérités d'un traitement de texte, et parfois des balises HTML mal fermées. Le traitement retire les espaces superflus, convertit les espaces insécables en espaces ordinaires, et normalise la casse quand elle est manifestement fautive. Il ne faut en revanche pas supprimer les caractères inconnus sans les journaliser : ce sont souvent des symboles techniques qui portent une information utile, un signe de degré, de diamètre ou de micromètre par exemple, dont la disparition rend une caractéristique technique fausse.

Traiter les colonnes qui en contiennent deux

Un fichier fournisseur mélange fréquemment plusieurs informations dans un même champ : une désignation qui contient la marque, une dimension qui contient l'unité, une référence qui contient le coloris. Ces séparations se font par expression régulière, à condition de mesurer le taux de réussite sur l'ensemble du fichier plutôt que sur les cinq premières lignes. Une règle qui fonctionne à quatre vingt dix pour cent laisse mille produits mal découpés sur dix mille, ce qui n'est pas acceptable : il vaut mieux isoler les cas restants et les traiter séparément que d'accepter une découpe approximative appliquée à tout le catalogue.

Conserver la valeur d'origine

La règle qui sauve le plus souvent consiste à ne jamais écraser une valeur d'origine mais à écrire le résultat du nettoyage dans une colonne supplémentaire. Le fichier intermédiaire est deux fois plus gros, ce qui est sans importance, et il permet de vérifier n'importe quelle transformation, de la corriger et de rejouer sans repartir du fichier brut. C'est aussi ce qui rend possible la comparaison, colonne par colonne, entre l'entrée et la sortie, contrôle qui révèle immédiatement les transformations trop agressives, celles qui ont vidé une colonne ou tronqué des valeurs légitimes.

Faire correspondre les colonnes au catalogue

Une fois le fichier propre, reste à décider ce que chaque colonne devient dans la boutique. C'est un travail de modélisation bien plus que de technique, et il rejoint ce que nous décrivons sur la manière de structurer un catalogue à attributs variables.

Écrire la table de correspondance

Le cœur de l'import est un document listant, pour chaque colonne du fichier, sa destination dans le catalogue, le traitement à appliquer et le comportement attendu si la valeur est absente. Ce document se relit, se discute avec le commerçant et se corrige avant toute exécution. Il est bien plus efficace de passer une demi journée dessus que de lancer un import et de découvrir après coup que la colonne poids contenait des grammes alors que la boutique attend des kilogrammes, erreur qui se répercute directement sur les frais de port facturés.

Décider ce qui est obligatoire

Trois valeurs conditionnent l'existence d'un produit vendable : une référence unique, un libellé et un prix. Toute ligne à laquelle il en manque une doit être écartée plutôt qu'importée avec une valeur par défaut. Les autres champs peuvent être absents sans conséquence grave, à condition que la fiche reste présentable. Cette distinction se pose explicitement dans la table de correspondance et évite les longues discussions au moment de l'exécution, quand la pression du calendrier pousse toujours à accepter des compromis douteux.

Gérer les variantes du fichier

Un fichier fournisseur ne distingue pas toujours le produit de ses déclinaisons : il livre souvent une ligne par combinaison vendable, avec un libellé qui répète le nom du produit. Reconstituer le regroupement suppose de repérer la partie commune des libellés et la partie variable, ou de s'appuyer sur une colonne de référence parente quand elle existe. C'est l'étape la plus délicate de l'import, celle qui demande le plus de contrôle manuel, et celle qu'il faut impérativement valider sur une trentaine de cas choisis avant de traiter l'ensemble du fichier.

Traiter les catégories du fournisseur

L'arborescence du fournisseur ne correspond jamais à celle de la boutique, et la reprendre telle quelle produit une navigation illisible. La correspondance se fait par une table écrite à la main, catégorie source vers catégorie cible, ce qui représente quelques dizaines de lignes et se réutilise à chaque livraison. Toute catégorie source non prévue doit provoquer un signalement plutôt qu'un rangement par défaut, faute de quoi les nouveaux produits atterrissent dans une catégorie fourre tout que personne ne surveille et qui grossit à chaque livraison.

Prévoir les images

Les images arrivent sous forme d'adresses distantes, d'archive séparée ou de noms de fichiers à retrouver. Leur récupération doit être traitée comme une étape à part, exécutable indépendamment de l'import des données, avec sa propre reprise sur incident : sur dix mille produits, quelques centaines d'adresses seront mortes. Il faut également décider du traitement des images déjà présentes, et ne jamais retélécharger l'ensemble à chaque livraison, ce qui saturerait autant le serveur du fournisseur que le sien et rallongerait le traitement de plusieurs heures.

Exécuter un import qu'on peut annuler

La dernière partie est la plus simple techniquement et la plus exposée : c'est le moment où l'on écrit dans le catalogue réel.

Traiter par lots avec reprise

Un import de dix mille produits ne s'exécute pas en une seule transaction. Il se découpe en lots de quelques centaines, chacun enregistrant son avancement, de sorte qu'une interruption se reprenne à la ligne suivante plutôt qu'au début. Ce découpage permet aussi d'espacer les lots pour ne pas dégrader le site pendant l'opération, et de suivre l'avancement, ce qui change beaucoup l'expérience quand le traitement dure deux heures et que l'on ne sait pas s'il progresse ou s'il est bloqué.

Rendre l'opération rejouable

Un import doit pouvoir être relancé sans créer de doublons ni cumuler d'effets. Cela suppose que la référence produit serve de clé de rapprochement et que chaque ligne soit traitée comme une mise à jour si la référence existe déjà. Cette propriété est ce qui permet de corriger un problème en cours de route et de relancer, plutôt que de nettoyer d'abord ce qui a été créé. C'est aussi ce qui rend possible la livraison mensuelle suivante sans aucun travail supplémentaire, la chaîne se contentant de reprendre le fichier neuf.

Faire un essai à blanc

Avant toute écriture, l'import doit pouvoir tourner en mode simulation, produisant le rapport complet de ce qu'il ferait sans rien modifier : nombre de créations, de mises à jour, de lignes écartées et pour quel motif. Ce rapport se relit en dix minutes et attrape la quasi totalité des erreurs de correspondance. Un import qui ne propose pas ce mode devrait être considéré comme inachevé, au même titre qu'un script sans gestion d'erreur.

Prévoir le retour en arrière

Une sauvegarde de la base prise juste avant reste la garantie la plus solide, mais elle annule aussi les commandes passées entre temps, ce qui la rend inutilisable sur une boutique active. La parade consiste à enregistrer, pour chaque produit modifié, ses valeurs précédentes dans un fichier daté. La restauration devient alors ciblée et n'affecte rien d'autre. Ce filet coûte quelques lignes de code et une centaine de mégaoctets, et il transforme un import redouté en opération parfaitement réversible, ce qui change entièrement le rapport de l'équipe à ce genre de chantier.

Rendre compte de ce qui n'est pas passé

Le rapport final doit lister nommément les lignes écartées avec leur motif, et ce fichier doit être remis au commerçant plutôt que classé. C'est lui qui permet de retourner vers le fournisseur avec des demandes précises, et c'est souvent le seul moyen d'obtenir une amélioration du fichier à la livraison suivante. Un import qui annonce simplement neuf mille huit cents produits traités laisse deux cents produits invisibles dont personne ne saura jamais rien, et ces deux cents là seront précisément ceux que le commerçant cherchera dans trois semaines. Le rapport doit donc lister ces lignes rejetées avec leur numéro d'origine et le motif exact du rejet, seule forme qui permette de reprendre le fichier source et de corriger sans relancer l'import complet.