Votre CSV affiche « é » au lieu de « é » ? Vous n’êtes pas seul. Ce symptôme, appelé mojibake, trahit un problème d’encodage entre la création du fichier et sa lecture. La bonne nouvelle : on le corrige vite en réimportant le fichier avec le bon jeu de caractères ou en le convertissant proprement en UTF-8. Je vous montre comment identifier la cause, réparer sans perdre de données et éviter que ça ne revienne.
Pourquoi les caractères spéciaux déraillent dans un CSV
Un fichier CSV n’est qu’un texte brut avec un délimiteur (virgule, point-virgule ou tabulation) et un encodage. Si l’application qui ouvre le fichier suppose un encodage différent de celui utilisé à l’export, les lettres accentuées se transforment en séquences étranges. Un classique : un fichier en Windows-1252 lu comme UTF-8, ou l’inverse.
Autre piège : les paramètres régionaux. En France, la virgule est séparateur décimal ; beaucoup d’outils exportent alors des CSV au point-virgule. Si vous ouvrez un tel fichier en forçant la virgule, vous mélangez les colonnes. Comprendre ces deux axes (encodage et séparateur) règle 90% des cas.
Règle d’or : alignez encodage et séparateur entre la source et l’outil de lecture. Quand vous hésitez, convertissez vers UTF-8 et documentez-le.
Diagnostic express : encodage, séparateur et autres indices utiles
Avant de “réparer”, identifiez précisément le problème. J’ouvre systématiquement le CSV dans un éditeur qui affiche l’encodage (Notepad++, VS Code : “Reopen with Encoding”). Sous Linux/macOS, la commande suivante donne un premier indice :
# Devine l'encodage d'un fichier
file -i fichier.csv
# Optionnel : détection probabiliste
uchardet fichier.csv
Ensuite, je vérifie le séparateur et l’intégrité des guillemets. Avec un échantillon de 20-30 lignes, on repère vite si c’est « ; », « , » ou « t » (tabulation), et si certaines lignes ont des guillemets mal fermés.
Trois autres points à ne pas négliger : la présence d’un BOM (marque d’ordre des octets) en tête de fichier, la fin de ligne (CRLF vs LF) et la forme Unicode (NFC/NFD sur macOS peut décomposer les accents). Ce sont des détails… jusqu’au jour où ils vous bloquent une importation.
Corriger dans Excel, LibreOffice, Python ou en ligne de commande
Je privilégie d’abord la réimportation propre dans l’outil cible. Dans Excel (Windows/macOS) : Données > À partir du texte/CSV > choisissez l’origine du fichier (65001 : UTF-8, ISO-8859-1, Windows-1252…) et le délimiteur. La prévisualisation vous montre immédiatement si les accents et les colonnes sont corrects. Si l’affichage est bon, validez et enregistrez au format “CSV UTF-8”.
LibreOffice Calc est souvent plus tolérant : Fichier > Ouvrir > cochez “Détecter le séparateur”, puis forcez l’encodage. Vous pouvez ensuite réexporter en UTF-8.
En Python avec pandas, on lit, corrige et réécrit de manière fiable :
import pandas as pd
# 1) Lecture en forçant l'encodage et le séparateur
df = pd.read_csv(
"fichier.csv",
encoding="latin-1", # ou "cp1252", "utf-8"
sep=";", # ou ",", "t"
encoding_errors="replace", # évite l'arrêt sur caractère illégal
on_bad_lines="skip", # ignore lignes mal formées
engine="python" # plus permissif si besoin
)
# 2) (Optionnel) Normaliser les accents en forme NFC
import unicodedata
df = df.applymap(lambda s: unicodedata.normalize("NFC", s) if isinstance(s, str) else s)
# 3) Réécrire un CSV propre en UTF-8 (sans BOM par défaut)
df.to_csv("fichier_corrige.csv", index=False, encoding="utf-8")
En ligne de commande, iconv reste la solution la plus simple pour une conversion directe :
# Convertir de Windows-1252 vers UTF-8
iconv -f WINDOWS-1252 -t UTF-8 fichier.csv > fichier_utf8.csv
# Convertir de ISO-8859-1 (Latin-1) vers UTF-8
iconv -f ISO-8859-1 -t UTF-8 fichier.csv > fichier_utf8.csv
Sur Windows, PowerShell fait le job sans outils tiers :
# PowerShell 5.1 : UTF-8 avec BOM (idéal pour Excel)
Get-Content .fichier.csv | Set-Content -Encoding UTF8 .fichier_utf8_bom.csv
# PowerShell 7+ : explicite sans / avec BOM
Get-Content .fichier.csv | Set-Content -Encoding utf8NoBOM .fichier_utf8.csv
Get-Content .fichier.csv | Set-Content -Encoding utf8BOM .fichier_utf8_bom.csv
Astuce annexe : si les retours à la ligne posent souci, harmonisez-les avant import :
# Unix -> Windows
unix2dos fichier.csv
# Windows -> Unix
dos2unix fichier.csv
Quel encodage choisir ? Ce tableau vous guide
La compatibilité varie selon les outils. Voici un repère rapide pour choisir l’encodage qui vous évitera des surprises.
| Encodage | Origine/Contexte | Couverture des caractères | Excel (Windows) | Usage recommandé |
|---|---|---|---|---|
| UTF-8 (sans BOM) | Standard web, interop | Unicode complet | Parfois mal détecté | Échanges machine-à-machine, ETL, APIs |
| UTF-8 avec BOM | Variante UTF-8 | Unicode complet | Bien détecté | Ouverture fiable dans Excel, partage non-tech |
| Windows-1252 | Windows historique | Europe de l’Ouest | Très bien détecté | Lecture d’archives anciennes |
| ISO-8859-1 (Latin-1) | Ancien standard | Latin de base | Correct | Compatibilité minimale |
| UTF-16 LE | Export Excel “Texte Unicode” | Unicode complet | OK | À éviter pour CSV (poids/interop) |
Cas complexes : champs multi-lignes, guillemets brisés, NFD/NFC
Certains CSV combinent plusieurs pièges : descriptions sur plusieurs lignes, délimiteurs variables, guillemets manquants. Dans ce cas, je bascule sur un parsing plus tolérant (pandas avec engine="python") et je nettoie par étapes plutôt que d’insister sur un import “magique”.
Exemple de lecture robuste avec contrôle fin :
import pandas as pd, csv
df = pd.read_csv(
"fichier.csv",
encoding="cp1252",
sep=";",
quotechar='"',
doublequote=True,
escapechar="",
lineterminator=None, # auto
engine="python",
on_bad_lines="warn"
)
Sur macOS, si vous voyez des combinaisons d’accent “é” décomposé, normalisez en NFC pour éviter les égalités texte qui échouent silencieusement. En shell (icu) :
# Normaliser tout le fichier en NFC
uconv -x any-nfc < fichier.csv > fichier_nfc.csv
Pour des jeux de données volumineux et hétérogènes, j’apprécie OpenRefine : détection, transformations en lot, et export en UTF-8 propre. C’est le couteau suisse quand le CSV mélange encodages et formats.
Mini check-list avant de valider votre CSV
- Les accents s’affichent bien (pas de mojibake), l’encodage est documenté.
- Le séparateur est correct pour vos paramètres régionaux (virgule vs point-virgule).
- Les champs contenant des virgules/points-virgules sont entre guillemets.
- Les fins de ligne sont homogènes (LF ou CRLF), pas de guillemets brisés.
- Si la cible est Excel, privilégiez UTF-8 avec BOM.
Bonnes pratiques pour ne plus revivre ce problème
Standardisez vos exports en UTF-8 et fixez un contrat d’échange explicite : encodage, séparateur, guillemets, fin de ligne. Côté tooling, paramétrez vos scripts pour qu’ils imposent ces choix et les affichent en en-tête d’email ou dans la documentation du flux.
Deux recettes qui m’ont épargné des heures :
1) Quand le destinataire est technique (ETL, data warehouse), j’envoie un CSV UTF-8 sans BOM, séparateur explicite, et un fichier README indiquant ces paramètres. 2) Quand le destinataire ouvre dans Excel, je fournis un CSV UTF-8 avec BOM et j’utilise le point-virgule pour les locales francophones afin d’éviter la collision avec la virgule décimale.
Enfin, testez toujours l’import dans l’outil cible sur un échantillon réel. Un “oui, ça marche chez moi” ne vaut rien face à une locale système ou une version Excel différente.
Le mot de la fin
Réparer un CSV “cassé” n’est pas une loterie. Avec un diagnostic simple (encodage + séparateur), des conversions maîtrisées (iconv, pandas, PowerShell) et quelques garde-fous (BOM, normalisation NFC), vous reprenez le contrôle. Prenez l’habitude de produire des fichiers propres en UTF-8, de documenter clairement vos choix et d’anticiper l’ouverture dans Excel quand c’est le cas. Vos prochains imports seront sans surprise — et vos accents, impeccables.