Pourquoi ton CSV casse les accents et les dates dans Excel

Trois pannes, une seule plainte

La phrase est toujours la même : le CSV est cassé. Ce qu'elle recouvre est l'une de trois choses différentes, et ces trois-là n'ont rien de commun sinon l'extension du fichier. Les accents sont faux, c'est un problème d'encodage. Tout est dans la première colonne, c'est un problème de séparateur. Les valeurs sont bonnes mais mal formées — 03/04 est devenu une date, un code postal a perdu son zéro, une longue référence s'est muée en quelque chose avec un E dedans — et ce n'est ni l'un ni l'autre : cela se produit après que le fichier a été lu correctement.

Les distinguer demande un seul geste : ouvrir le CSV dans un éditeur de texte simple plutôt que dans un tableur. Bloc-notes, TextEdit, gedit, n'importe quoi qui montre les octets sous forme de texte sans chercher à t'aider. Dans cette fenêtre il n'y a ni colonnes, ni cellules, ni types — juste des lignes avec des caractères entre les champs. Si les accents y sont corrects, le fichier est bon et la faute est entièrement dans la manière dont Excel le lit. S'ils y sont faux aussi, la faute est en amont, dans ce qui a écrit le fichier, et aucun réglage d'import ne la réparera.

Les accents : trois octets manquants en tête de fichier

En UTF-8, une lettre sans accent occupe un octet et une lettre accentuée en occupe deux. C'est là tout le mécanisme. Quand un programme lit un fichier UTF-8 en le croyant écrit dans une page de codes héritée à un octet, il affiche chacun de ces deux octets comme un caractère distinct, et le charabia qui en résulte est parfaitement déterministe. Un é seul devient é. Le mot créé devient créé, ça coûte devient ça coûte, Noël devient Noël et œuvre devient Å“uvre. Chaque lettre accentuée gagne exactement un caractère, et le premier de la paire est presque toujours un Ã, d'où l'allure si reconnaissable du désastre.

Le remède sur lequel toute l'industrie a convergé tient en trois octets tout en tête du fichier : EF BB BF, la marque d'ordre des octets UTF-8. Elle ne code aucun caractère et n'imprime rien ; elle existe uniquement pour qu'un lecteur sache ce qu'il regarde. La page de Microsoft sur le sujet le dit en une ligne — un CSV UTF-8 s'ouvre normalement s'il a été enregistré avec une marque d'ordre des octets — et propose un chemin d'import pour ceux qui en sont dépourvus. Cette seule phrase explique pourquoi presque tous les boutons d'export sur lesquels tu as appuyé produisent un fichier qui commence par trois octets invisibles.

Le convertisseur de ce site n'en ajoute pas. Le CSV qu'il te remet est en UTF-8 sans marque d'ordre des octets, et le premier octet du fichier est le premier caractère de ton premier en-tête de colonne. C'est ce qu'il faut produire du point de vue de la norme — la RFC 4180 définit le format et ne mentionne jamais de marque — et ce qu'il ne faut pas double-cliquer sur une machine Windows européenne. La suite de cet article traite pour l'essentiel de ce qu'il convient de faire de ce constat, et la version courte est : importe le fichier au lieu de l'ouvrir.

Le séparateur : c'est ton système qui décide, pas le fichier

Le nom valeurs séparées par des virgules laisse penser que la virgule fait partie du format, et la RFC 4180 la définit bien ainsi. Excel ne lit pas le format : il lit un réglage. La page de dépannage de Microsoft le dit sans détour : modifier le séparateur de listes dans les paramètres régionaux de Windows affecte le délimiteur employé à l'ouverture comme à l'enregistrement d'un fichier de valeurs séparées par des virgules, parce qu'Excel utilise le caractère séparateur de listes de Windows comme délimiteur des fichiers .csv. Elle ajoute que la virgule est le séparateur de listes par défaut de la locale anglaise américaine.

Si le réglage n'est pas une virgule partout, c'est une affaire d'arithmétique et non de goût. Là où la virgule sert de séparateur décimal, elle ne peut pas en plus séparer les champs sans ambiguïté : une ligne portant un prix de mille deux cent trente-quatre virgule cinq serait indiscernable de deux champs. Windows livre donc un point-virgule comme séparateur de listes dans les locales française, allemande, espagnole, italienne et portugaise, et une virgule dans les anglaises. Voilà toute la ligne de partage, et voilà pourquoi un export écrit par un service américain et ouvert à Lyon, Leipzig, León, Livourne ou Lisbonne arrive sous la forme d'une seule colonne très large.

Deux conséquences que l'on comprend souvent de travers. La première : modifier le séparateur de listes de Windows pour réparer un fichier est un changement global qui affecte toutes les applications de la machine, et la documentation de Microsoft prévient elle-même ; ce n'est pas un remède au cas par cas et tu oublieras l'avoir fait. La seconde : le délimiteur est une propriété du fichier et le réglage une propriété du lecteur, si bien qu'un fichier n'est jamais bon ou mauvais dans l'absolu — il est bon pour un lecteur à qui tu as dit la vérité. La boîte de dialogue d'import existe précisément pour te permettre de la lui dire.

Les types : Excel devine, et il devine à l'ouverture

Un CSV n'a pas de types. Tout champ est du texte, et la RFC 4180 n'assigne aux guillemets qu'une seule tâche : protéger un champ qui contient une virgule, un guillemet ou un saut de ligne. Nulle part dans le format on ne peut dire ceci est une chaîne, n'y touche pas. Un tableur qui en ouvre un doit donc deviner, champ par champ, et les suppositions sont taillées pour le cas courant, pas pour le vôtre. Un champ valant 03/04 ressemble à une date et en devient une. Un champ valant 01234 ressemble à un nombre et perd son zéro. Un champ de seize chiffres ressemble à un très grand nombre, et la page de Microsoft énonce la limite sans l'adoucir : Excel a une précision maximale de 15 chiffres significatifs, si bien que pour tout nombre de 16 chiffres ou plus, tout ce qui suit le quinzième est arrondi à zéro et la valeur s'affiche en notation scientifique.

Le cas des dates mérite son propre paragraphe pour la manière dont il échoue. Un champ valant 02/03/2026, c'est le 2 mars à Paris et le 3 février à Chicago, et les deux lectures sont légitimes — rien dans le fichier ne dit laquelle était voulue. Mais un champ valant 13/03/2026 n'a pas de treizième mois : un lecteur qui attend le mois en premier ne peut pas l'analyser comme une date et le laisse en texte. Passe une année entière de dates et près de deux sur cinq sont ambiguës : 144 des 365 jours tombent le douze du mois ou avant. La colonne obtenue est donc pour partie faite de dates silencieusement permutées, pour partie de texte aligné à gauche, et sans le moindre message d'erreur. C'est la panne silencieuse la plus coûteuse du travail de bureau.

Une partie des dégâts survient avant même qu'Excel n'intervienne, et ce convertisseur n'en est pas innocent. Une cellule de tableur, c'est une valeur brute plus un format d'affichage, et le CSV ne peut porter qu'un des deux : ce qui est écrit, c'est le texte formaté. Passe le même 2 mars 2026 avec un format jour d'abord et le fichier reçoit 02/03/2026 ; passe la valeur identique avec un format mois d'abord et le fichier reçoit 3/2/26. Pire, un identifiant de seize chiffres dans une colonne au format standard sort du classeur déjà écrit 1.23457E+15, parce que c'est ainsi que le classeur l'affichait. L'identifiant a été détruit par le format, pas par le lecteur. Rien en aval ne peut le récupérer.

Ce qui règle réellement chacun des cas

Importer au lieu d'ouvrir. Ce seul changement règle d'emblée les deux premiers problèmes et te donne l'outil pour traiter le troisième. Données, puis À partir d'un fichier texte/CSV, ouvre un aperçu où l'origine du fichier et le délimiteur sont tous deux visibles et modifiables, et l'aperçu se redessine à chaque changement : tu vois les accents se remettre en place et les colonnes se séparer avant de valider. Choisir Transformer les données plutôt que Charger permet ensuite de fixer le type d'une colonne à Texte — la documentation de Microsoft sur la conservation des zéros initiaux renvoie exactement à ce chemin — et une colonne typée Texte garde ses zéros, garde ses seize chiffres et ne devient pas une date.

Il existe un levier plus récent et plus durable que trop peu de gens connaissent. Sous Microsoft 365 et Excel 2024, sur Windows comme sur Mac, Fichier, Options, Données contient une section Conversion automatique des données avec quatre cases : supprimer les zéros initiaux et convertir en nombre ; conserver les 15 premiers chiffres des nombres longs et les afficher en notation scientifique si nécessaire ; convertir les chiffres entourant la lettre E en notation scientifique ; et convertir les combinaisons de lettres et de chiffres ressemblant à une date en date. Décocher les deux premières est le meilleur emploi de dix secondes pour quiconque manipule des données de référence, car cela arrête la destruction à la source au lieu d'exiger un rituel d'import à chaque fois.

Ce qui ne marche pas mérite aussi d'être listé, car ce sont les conseils qu'on te donnera. Entourer un champ de guillemets n'empêche pas la conversion : les guillemets sont structurels, ils disent où le champ finit, et Excel les retire avant de commencer à deviner. Renommer le fichier pour qu'il ne soit plus un .csv change le chemin de code qui l'ouvre, effet réel mais fragile sur lequel s'appuyer. Formater la colonne en Texte une fois le fichier ouvert ne fait rien, car les chiffres ont été perdus au chargement et Microsoft le dit — un format texte n'affecte que ce que tu saisis ensuite. Quant à mettre un signe égal devant une valeur entre guillemets, cela force bien du texte, mais fait du champ une formule et non une valeur, s'affiche en caractères littéraux dans tout autre programme qui lit le fichier, et un signe égal en tête est le vecteur classique de l'injection de formule dans un tableur. N'envoie cela à personne.

Ce que ce convertisseur met dans le fichier

Lu dans le code source plutôt que dans l'argumentaire : l'outil Excel en CSV lit ton classeur dans le navigateur, te laisse choisir une feuille, et écrit cette feuille avec une virgule entre les champs, un encodage UTF-8 et aucune marque d'ordre des octets. Les champs ne sont mis entre guillemets que lorsque c'est nécessaire — s'ils contiennent une virgule, un guillemet double ou un saut de ligne — ce qu'exige exactement la RFC 4180 et rien de plus. Un champ contenant un guillemet le voit doublé, selon la même règle. Rien n'est téléversé : le classeur est analysé sur ta machine et le CSV ne la quitte jamais.

Deux de ces choix mordront le lecteur européen qui double-clique sur le résultat, et il vaut mieux savoir lesquels. La virgule mettra tout dans la colonne A sur une machine dont le séparateur de listes est le point-virgule. L'absence de marque d'ordre des octets abîmera les accents sur une machine qui retombe sur une page de codes héritée. Les deux se soignent par la même procédure d'import et aucun ne se soigne en se plaignant du fichier, lequel est conforme à la norme. Si tu envoies le CSV à une personne plutôt qu'à un programme, indique le séparateur et l'encodage employés : une ligne dans le courriel épargne un après-midi.

Une habitude vaut mieux que tous les réglages de cet article : corrige le classeur avant l'export, pas le CSV après. Passe les colonnes d'identifiants en Texte dans le tableur, pour que les codes postaux et les numéros de compte soient déjà des chaînes au moment de la conversion. Passe les colonnes de dates dans un format non ambigu — l'année d'abord, sur quatre chiffres, puis le mois, puis le jour — pour que le texte exporté ne puisse pas se lire de deux façons dans aucune locale du monde. Fais-le une fois, et tous les exports de ce classeur seront propres pour tous les lecteurs, à jamais, quels que soient leurs paramètres régionaux.

Questions fréquentes

J'ai ouvert le fichier et chaque ligne tient dans la colonne A. Le CSV est-il cassé ?

Presque certainement pas. Ce que tu vois, c'est Excel qui découpe sur un caractère que ton fichier n'emploie pas. Microsoft documente qu'Excel prend le délimiteur des fichiers .csv dans le séparateur de listes de Windows : un fichier séparé par des virgules sur une machine réglée sur le point-virgule ne trouve aucun point-virgule et en conclut que chaque ligne est un champ énorme. Ouvre le fichier dans un éditeur de texte et regarde la première ligne : le caractère placé entre les en-têtes est le vrai délimiteur. Referme, va dans Données puis À partir d'un fichier texte/CSV, et choisis ce caractère dans l'aperçu. Deux choses à éviter : ne fractionne pas la colonne à la main, car tu recommenceras le mois prochain ; et réfléchis à deux fois avant de modifier le séparateur de listes de Windows, puisque la documentation de Microsoft prévient qu'il s'agit d'un changement global affectant toutes les applications de la machine.

Pourquoi mettre un champ entre guillemets n'empêche-t-il pas Excel d'en faire une date ?

Parce que les guillemets d'un CSV sont de la ponctuation, non de l'annotation. La RFC 4180 ne leur confie qu'une tâche : marquer où un champ commence et finit lorsque ce champ contient lui-même une virgule, un guillemet double ou un saut de ligne. Ils ne portent aucune information sur le sens du champ, et le format n'offre nulle part ailleurs où loger une telle information — un CSV n'a réellement aucune notion de type. Le lecteur retire donc les guillemets pendant l'analyse, exactement comme il le doit, et ce n'est qu'ensuite qu'il se met à deviner ce qu'il tient. Voilà pourquoi tous les remèdes publiés par Microsoft se situent du côté de la lecture et non de l'écriture : importer la colonne en Texte, ou désactiver les conversions automatiques. Rien de ce que tu écriras dans le fichier ne contraindra la supposition.

Dois-je simplement mettre sep=; sur la première ligne pour qu'Excel s'y retrouve ?

Cela fonctionne dans Excel et c'est un piège partout ailleurs. Cette première ligne est une extension propre à Excel : la RFC 4180, qui définit le format CSV, n'en parle pas et aucun analyseur conforme n'est tenu de la comprendre. Le fichier devient donc plus facile pour un programme et plus difficile pour tous les autres — un script, un import de base de données, un logiciel comptable ou un collègue sur Mac liront cette ligne comme une ligne de données contenant un champ nommé sep=; et échoueront ou importeront silencieusement un enregistrement parasite en tête de ta table. Si le fichier part vers un humain qui l'ouvrira dans Excel et nulle part ailleurs, c'est une commodité raisonnable. S'il part dans une chaîne de traitement, ou vers quelqu'un dont tu ignores les outils, ne le mets pas : envoie le fichier propre et précise en une phrase le séparateur et l'encodage employés.

Ma référence à 16 chiffres se termine maintenant par des zéros. Où sont passés les chiffres ?

Ils ont été arrondis, et ils sont irrécupérables depuis ce fichier. Microsoft énonce la règle directement : Excel a une précision maximale de 15 chiffres significatifs, et pour tout nombre de 16 chiffres ou plus, tout ce qui suit le quinzième est arrondi à zéro. La valeur s'affiche ensuite en notation scientifique parce qu'elle ne tient plus utilement dans la colonne. Le point important est qu'il ne s'agit pas d'un problème d'affichage : élargir la colonne ou changer le format de nombre ne ramènera pas les chiffres, car ils ont disparu de la valeur stockée. Reviens à la source d'origine, importe la colonne en Texte, et ne laisse jamais un numéro de référence, un numéro de compte, un numéro de carte ou un long code article exister comme nombre où que ce soit dans la chaîne. Sous Microsoft 365 et Excel 2024, la conversion se désactive aussi purement et simplement : Fichier, Options, Données, et décoche l'option sur la conservation des 15 premiers chiffres des nombres longs.

Virgule ou point-virgule — lequel est réellement correct ?

Selon la norme, la virgule. La RFC 4180 définit le format avec des virgules entre les champs, un retour chariot suivi d'un saut de ligne à la fin de chaque enregistrement, et des guillemets doubles autour de tout champ contenant l'un de ces caractères. Tous les langages de programmation, bases de données et outils de données la suivent : la virgule est donc ce qu'il faut employer pour tout ce qu'une machine lira. En pratique cependant, le point-virgule est ce qu'attend un tableur dans la plus grande partie de l'Europe continentale, pour la raison arithmétique que la virgule y sert déjà de séparateur décimal. La règle praticable est de décider par destination plutôt que par principe : virgule pour les machines et pour tout ce qui franchit une frontière, point-virgule quand le fichier va droit dans l'Excel d'un collègue dont tu connais les paramètres régionaux. Et quel que soit ton choix, dis-le : une ligne indiquant le séparateur et l'encodage prévient toute la classe de problèmes dont traite cet article.