Pourquoi Excel abîme vos fichiers CSV

Les dégâts se produisent à l'ouverture

C'est ce qui rend le problème si difficile à diagnostiquer. Un CSV est un fichier texte : chaque valeur n'y est qu'une suite de caractères, et rien dans le fichier n'indique ce qu'elle signifie. Quand Excel en ouvre un, il devine un type pour chaque colonne, convertit les valeurs en conséquence, et ne conserve plus que la version convertie. Enregistrez le fichier, et les conversions y sont écrites.

Le fichier d'origine était donc correct, celui que vous avez enregistré ne l'est plus, et rien ne vous a averti à aucun moment. On en conclut que l'export était défectueux, on exporte à nouveau, et on obtient le même résultat — parce que la corruption se produit sur votre propre machine, après le téléchargement.

Les quatre conversions responsables des dégâts

Les zéros initiaux sont supprimés. Un code postal comme 01234, un code de département, un numéro de compte, un numéro de téléphone commençant par zéro : tout cela ressemble à un nombre, donc le zéro est jeté comme s'il ne servait à rien. Il sert pourtant : il fait partie de l'identifiant.

Les longs nombres sont arrondis. Un tableur stocke les nombres en virgule flottante avec environ quinze chiffres significatifs : une référence de commande, un numéro de carte bancaire, un IMEI ou un identifiant 64 bits est donc arrondi sans prévenir — les derniers chiffres deviennent des zéros. La cellule ressemble à un nombre, mais ce n'est pas le bon.

Tout ce qui ressemble à une date est reformaté, selon les conventions locales. 03/05 signifie mars dans un pays et mai dans un autre : le même fichier ouvert dans deux bureaux donne deux jeux de données différents. Pire, des valeurs qui n'ont jamais été des dates sont converties : un nom de gène comme SEPT1 devient une date, un problème si tenace que les généticiens ont fini par renommer les gènes plutôt que de continuer à se battre.

Les caractères accentués deviennent illisibles. Un CSV ne garde aucune trace de son encodage : un fichier enregistré en UTF-8 et lu dans une ancienne page de codes — ou l'inverse — abîme précisément les lignes qui contiennent des noms accentués.

La solution : importer, pas ouvrir

Ne double-cliquez jamais sur un CSV auquel vous tenez. Un double-clic autorise Excel à deviner, et il devine avec aplomb.

Utilisez plutôt Données → À partir d'un fichier texte/CSV. La boîte de dialogue d'importation vous permet de définir le type de chaque colonne avant toute analyse : marquez la colonne des codes postaux et celle des identifiants comme Texte, et elles arrivent exactement telles qu'elles sont dans le fichier. Vous pouvez aussi y indiquer l'encodage et le délimiteur au lieu de les laisser deviner. Cela prend vingt secondes, et c'est toute la solution.

Même principe dans Google Sheets : Fichier → Importer, puis désactivez « Convertir le texte en nombres, dates et formules ». LibreOffice Calc affiche par défaut la boîte de dialogue des types de colonnes — l'un des rares domaines où il se comporte tout simplement mieux.

Inspectez avant d'importer

Quand le mal est déjà fait, la première chose utile est de regarder le fichier sans qu'un tableur y touche. Afficher le CSV montre les valeurs exactement telles que les octets les décrivent — zéros initiaux présents, longs nombres complets, dates sous forme du texte d'origine. Vous savez aussitôt si c'est l'export ou l'import qui a posé problème.

Vous voyez aussi les deux choses qu'un CSV n'indique jamais sur lui-même : le délimiteur — virgule, point-virgule ou tabulation ; les paramètres régionaux européens exportent des points-virgules, car la virgule y sert de séparateur décimal — et l'encodage. Connaître les deux avant d'importer élimine l'essentiel des devinettes restantes.

Si c'est vous qui produisez le CSV

Quelques choix au moment de l'export évitent tout cela en aval.

Écrivez en UTF-8 avec BOM (marque d'ordre des octets) si le fichier est destiné à Excel sous Windows. Excel s'appuie sur cette marque pour détecter l'UTF-8 et abîme les caractères accentués sans elle — l'un des rares cas où ajouter un BOM est la bonne décision plutôt qu'une nuisance.

Mettez entre guillemets tous les champs qui pourraient être mal interprétés, et toujours les colonnes d'identifiants. Les guillemets n'empêchent pas Excel de convertir à l'ouverture, mais ils rendent l'intention claire pour tous les autres programmes qui liront le fichier.

Envisagez de ne pas utiliser le CSV du tout. Si le destinataire accepte le JSON ou un vrai classeur, les deux indiquent explicitement les types et n'ont aucun de ces défauts. La force du CSV est que tout le monde sait le lire ; sa faiblesse est que personne n'est d'accord sur ce qu'il dit.