Aller de CSV à Excel et retour sans abîmer vos données

Le problème de séparateur commence avant même l’ouverture du fichier

Excel décide comment découper un CSV en colonnes en utilisant le séparateur de liste configuré dans les paramètres régionaux de votre système d’exploitation, sans regarder le fichier lui-même. Sur une machine réglée sur une région européenne, ce séparateur est par défaut le point-virgule, donc une exportation « classique » séparée par des virgules arrive dans Excel dans une seule colonne de texte non découpé. Sur une machine configurée pour les États-Unis, c’est l’inverse qui se produit pour un fichier au point-virgule. Dans les deux cas, cela ne signifie pas que le fichier est cassé. Cela signifie qu’Excel a deviné à partir de réglages qui n’ont rien à voir avec la façon dont le fichier a été écrit. Un convertisseur comme CSV en Excel, qui analyse le fichier avec plusieurs séparateurs possibles et vérifie lequel produit un nombre de champs cohérent sur les lignes échantillonnées, évite complètement cette devinette, au lieu de faire confiance à l’extension du fichier ou à un réglage du système.

Les zéros initiaux et les grands nombres sont les victimes silencieuses

Ce qui abîme le plus les données lors d’une conversion CSV-vers-Excel, c’est de transformer trop facilement du texte en nombre. Un code produit écrit comme 00123 devient le nombre 123 dès que la feuille de calcul décide qu’il « ressemble » à un nombre, et ce zéro initial est irrécupérable ensuite. Il disparaît tout simplement. Les identifiants plus longs se dégradent différemment. Un numéro de carte ou de code-barres à seize chiffres perd ses derniers chiffres sans aucun avertissement, car les nombres standard d’une feuille de calcul ne peuvent pas contenir plus d’environ quinze chiffres significatifs sans arrondir. Dans ces deux cas, la valeur devrait rester du texte au lieu d’être convertie, et la même règle vaut quand la destination est un programme plutôt qu’Excel : CSV en JSON les garde sous forme de chaînes. Les valeurs qui sont vraiment numériques, comme les quantités, les prix et les totaux, doivent en revanche être converties normalement pour pouvoir être additionnées et utilisées dans des calculs.

L’encodage est là où les données non anglophones se brisent

Les fichiers exportés d’anciens systèmes comptables ou bases de données ne sont souvent pas du tout en UTF-8. Windows-1251 pour le texte cyrillique et Windows-1252 pour les caractères accentués d’Europe de l’Ouest sont les cas fréquents, et ouvrir l’un d’eux avec une mauvaise hypothèse produit le fameux mur de caractères illisibles. Détecter l’encodage réel en cherchant d’abord un marqueur d’ordre des octets, puis en validant strictement comme UTF-8, et en se rabattant sur la distribution des octets de forte valeur si cela échoue, permet de corriger cela automatiquement. Personne n’a à deviner dans un menu d’options d’encodage.

Le marqueur d’ordre des octets peut causer ses propres dégâts discrets

Un marqueur d’ordre des octets UTF-8 correspond à trois octets invisibles tout au début d’un fichier, qui indiquent à Excel que le texte qui suit est en Unicode. C’est utile quand Excel est la destination. Cela devient un problème dès que la destination du fichier est autre chose qu’Excel. Un outil en ligne de commande ou une chaîne de traitement plus ancienne qui ne retire pas ces octets les laisse collés au premier caractère de la première cellule d’en-tête. Une colonne censée s’appeler « id » ne correspond alors plus à ce qui attend exactement ce nom. Le fait de conserver ou de supprimer le BOM dépend entièrement de ce qui va lire le fichier ensuite, et non d’un unique réglage par défaut valable pour tous.

Le trajet inverse soulève ses propres choix

Convertir une feuille de calcul vers CSV avec Excel en CSV pose une question qui ne se pose jamais dans l’autre sens. Une cellule contenant une formule a deux valeurs : le texte de la formule elle-même et le nombre qu’elle a produit lors de son dernier calcul, et un CSV ne peut en transporter qu’une seule à la fois. Exporter la valeur calculée est ce que la plupart des systèmes s’attendent à importer. Exporter à la place le texte de la formule est ce qu’une personne chargée de relire veut voir. Les dates demandent la même attention explicite. Les écrire dans un format unique, choisi à l’avance, au lieu de se fier à ce que la feuille de calcul affichait, évite que le même fichier produise des dates d’apparence différente selon les paramètres régionaux de la machine qui a fait la mise en forme.

Erreurs courantes, et le réglage qui évite chacune

Laisser le séparateur décimal sur le point. Un export au point-virgule venant d’un pays qui écrit 1,50 pour un et demi a besoin du séparateur décimal sur Virgule dans CSV en Excel ; sinon chaque prix reste une chaîne et refuse de s’additionner. Confier des identifiants au typage automatique. Il protège les zéros initiaux et tout ce qui dépasse quinze chiffres, mais un numéro de commande ou un code postal sans zéro initial devient quand même un nombre ; si aucune colonne ne sert au calcul, les types de cellules sur Tout en texte reprennent chaque valeur telle qu’elle est écrite. Verser un export de quelques millions de lignes dans un seul classeur. XLSX s’arrête à 1 048 576 lignes, donc un CSV plus long est refusé avec un lien vers Diviser un CSV au lieu d’être tronqué sans un mot.

Au retour, comparez trois réglages par défaut de Excel en CSV avec ce qui lira le fichier ensuite. L’encodage de sortie est UTF-8 avec BOM, celui qu’il faut à Excel ; un script ou un chargeur de base de données veut en général de l’UTF-8 simple. Le format de date est ISO 8601, donc le 14 mars 2026 devient 2026-03-14 sur toutes les machines, avec 14.03.2026, 03/14/2026 et le numéro de série Excel comme variantes. Les fins de ligne sont en CRLF pour Windows, avec LF pour les outils Unix. Un quatrième réglage passe facilement inaperçu : par défaut, seule la première feuille est exportée, donc un classeur avec un deuxième onglet demande Toutes les feuilles, qui renvoie un ZIP avec un CSV par feuille.