Erreurs de données à l'import CSV : causes et solution
Des prix doublés. « café » transformé en « café ». Trois copies de chaque produit. Quand un import tourne mal, le réflexe est d'accuser le fichier, mais un « mauvais fichier » n'est presque jamais la cause : deux systèmes se sont contredits, silencieusement, sur ce que signifiait une virgule, un guillemet ou un nombre, et rien n'a signalé le désaccord avant que les mauvaises données ne se retrouvent déjà sous vos yeux.
Sept façons dont un fichier d'apparence propre ment
Chacun de ces cas arrive avec le bon nombre de lignes et aucun message d'erreur.
Incohérences d'encodage — un fichier écrit en Windows-1252 et lu en UTF-8 (ou l'inverse) transforme « café » en « café » et un tiret cadratin en trois caractères illisibles. Rien ne plante ; les valeurs sont simplement fausses, sur les colonnes que vous ne pensez pas à faire défiler.
Le séparateur n'est pas vraiment une virgule — une grande partie de l'Europe continentale enregistre les CSV avec des points-virgules, car ces locales utilisent la virgule pour les décimales. Supposez le mauvais séparateur et vous obtenez soit une seule colonne géante non découpée, soit la virgule décimale d'un prix éclatée en colonnes qui n'existent pas.
« L'aide » du tableur avant l'export — Excel stocke un code postal saisi comme 01234 sous forme du nombre 1234, et affiche un code-barres à 16 chiffres en notation scientifique, arrondi au-delà de 15 chiffres. Au moment où le CSV est écrit, la valeur d'origine n'existe plus nulle part.
Des nombres qui signifient deux choses différentes — 1.234,56 et 1,234.56 représentent le même montant selon deux conventions régionales. Lisez l'un avec les règles de l'autre et il s'interprète sans erreur — comme 1.23, ou comme 1234560.
Des en-têtes qui bougent — un export ajoute ou réordonne une colonne, « postcode » devient « postal_code », et un importeur qui fait correspondre par position écrit silencieusement des descriptions dans des champs de prix. Rien dans un CSV ne garantit que la colonne 4 signifie la même chose deux fois.
Réimporter sans clé stable — corrigez trois lignes, réimportez 2 000, et un importeur sans identité stable par enregistrement crée 2 000 doublons au lieu d'en mettre trois à jour. Les noms changent ; une référence externe, une référence produit ou un numéro de commande, non.
Des caractères invisibles — une espace insécable collée depuis une page web, ou « Blue » avec un espace final, s'affiche à l'identique de la valeur propre et échoue à toute correspondance exacte — si bien que la même catégorie est créée deux fois, et les vérifications de doublons ne se déclenchent jamais.
Avant de téléverser : la vérification qui détecte la plupart de ces cas
1
Ouvrez-le une fois en texte brut
Avant de vous fier à l'aperçu d'un outil, ouvrez le fichier dans un éditeur de texte brut, pas dans un tableur : un tableur réinterprète le fichier à l'instant même où il l'ouvre, ce qui masque précisément les problèmes que vous cherchez. Regardez le tout début brut de la première ligne pour repérer quoi que ce soit placé avant le premier nom d'en-tête.
2
Vérifiez que le séparateur correspond bien à celui que vous supposez
Comptez les délimiteurs à l'œil sur quelques lignes différentes. Un fichier réellement délimité par des points-virgules mais supposé délimité par des virgules n'affiche aucune virgule en dehors des valeurs elles-mêmes — une vérification de cinq secondes qui intercepte toute une classe d'erreurs avant qu'elle ne commence.
3
Testez une ligne contenant une virgule, un guillemet et un saut de ligne
Trouvez, ou créez délibérément, une ligne de test contenant une virgule à l'intérieur d'un champ texte, un guillemet et une note sur plusieurs lignes, puis vérifiez que l'importateur conserve chacun comme un seul champ au lieu de le scinder. Cette seule ligne met à l'épreuve le mécanisme exact qui, mal géré, décale silencieusement toutes les colonnes suivantes.
4
Testez un petit lot avant le fichier entier
Commencer par dix ou vingt lignes, relues une à une, permet de repérer une erreur de correspondance systématique — une colonne inversée, une mauvaise devise, un format de date erroné — quand il n'y a encore que dix lignes à corriger, et non dix mille.
5
Décidez ce que « terminé » signifie par ligne, pas par fichier
Un simple succès ou échec pour tout le fichier ne vous dit rien sur les lignes à corriger. Exigez un résultat ligne par ligne — créée, mise à jour, ignorée, en échec, et pourquoi — avant de confier à un outil d'import quoi que ce soit d'important.
Presque toujours une incompatibilité d'encodage. Le fichier a été écrit dans un encodage de caractères — souvent Windows-1252 ou Latin-1 — et lu comme de l'UTF-8, ou l'inverse. Réenregistrez explicitement le fichier source en UTF-8 et vérifiez s'il faut supprimer la marque d'ordre des octets, selon ce qu'attend l'importateur.
Un tableur enregistre comme un nombre tout ce qui ressemble à un nombre, et les nombres ne conservent pas les zéros initiaux. Cela s'est produit avant l'écriture du CSV, au moment où la valeur a été saisie ou mise en forme automatiquement, et c'est irrécupérable à partir du seul CSV : la colonne source doit être formatée en texte, pas corrigée après coup.
L'importateur n'avait aucun moyen stable de reconnaître une ligne du nouveau fichier comme « le même enregistrement » qu'il avait déjà enregistré, très probablement parce que la correspondance se faisait sur un nom ou une description plutôt que sur un identifiant fixe comme une référence externe, un numéro de commande ou un SKU. Sans cette clé stable, chaque import ressemble à un premier import.
C'est autant un problème de restitution qu'un problème de données — un bon importateur vous indique le résultat de chaque ligne, pas seulement celui du fichier dans son ensemble. Si l'outil que vous utilisez ne donne qu'un succès/échec global pour tout l'envoi, prenez-le comme un signal : testez par petits lots jusqu'à pouvoir voir les résultats ligne par ligne.
Presque toujours un décalage entre le séparateur décimal et le séparateur de milliers. 1.234,56 et 1,234.56 sont deux représentations valides du même nombre selon des conventions régionales différentes, et lire l'une en supposant l'autre ne provoque pas d'erreur : cela produit simplement une valeur fausse. Vérifiez quelle convention utilise votre export et indiquez-la explicitement à l'outil d'import plutôt que de le laisser deviner.
Attention : ouvrir puis réenregistrer un CSV dans un tableur est exactement l'étape qui introduit plusieurs des problèmes évoqués sur cette page : zéros initiaux, conversion automatique des dates, notation scientifique. Si vous devez modifier quelques lignes à la main, un éditeur de texte brut est plus sûr qu'un aller-retour complet par un tableur.
Comment Olmira gère cela
Le connecteur d'import de fichiers d'Olmira est construit exactement contre cette liste : un analyseur RFC 4180 strict qui gère les virgules entre guillemets et les sauts de ligne intégrés, un retrait automatique d'un BOM UTF-8 en tête de fichier, et des fichiers trop volumineux rejetés d'emblée plutôt que tronqués en silence. Une ligne dont le nombre de colonnes ne correspond pas à l'en-tête échoue seule, sans interrompre le reste, et une clé de déduplication signifie que réimporter deux fois le même fichier met à jour ou ignore les enregistrements existants — selon la règle que vous avez choisie — plutôt que de les dupliquer.
Pour les catalogues de produits et de services, l'import par CSV ajoute un aperçu ligne par ligne — y compris tout champ rempli par l'IA, clairement signalé — avant qu'une seule ligne ne soit enregistrée. La plateforme de connecteurs complète, avec récupérations planifiées et webhooks signés en plus de l'import de fichiers, se trouve sur Integrations.