Excel affiche des caractères illisibles dans ton CSV ? La solution : le BOM UTF-8
Pourquoi ton CSV est parfait partout... sauf dans Excel
Tu exportes un CSV de ta base de données ou de ton CRM. Tu l'ouvres dans un éditeur de texte, et il est parfait. Caractères accentués, kanji japonais, symboles euro – tout est là et correct. Puis tu double-cliques pour l'ouvrir dans Excel, et c'est le chaos. Tu te retrouves face à des chaînes de caractères illisibles comme 'é' au lieu de 'é', ou '¥' au lieu de '¥', ou une colonne entière de points d'interrogation. Le fichier lui-même n'a pas changé. Le problème, c'est Excel. Lorsque tu ouvres un CSV en double-cliquant, Microsoft Excel – surtout sous Windows – ne suppose pas qu'il est en UTF-8. Il revient à l'ancienne page de codes héritée de ton système. Pour la plupart des gens en Occident, c'est Windows-1252 (aussi appelé CP1252). Pour les utilisateurs au Japon, c'est Shift-JIS. Lorsqu'un fichier UTF-8 est forcé à travers une interprétation Windows-1252, chaque caractère qui utilise plus d'un octet est corrompu, produisant ce charabia connu sous le nom de mojibake. Ce n'est pas un nouveau bug. C'est une frustration de longue date qui a tourmenté Excel 2010, 2013, 2016, 2019, et qui apparaît encore dans Microsoft 365 en 2025. Si tu te contentes de double-cliquer sur un CSV UTF-8 simple, tu joues aux dés. Bien que Microsoft ait ajouté une meilleure détection UTF-8 dans les versions récentes de M365, le comportement est extrêmement incohérent, selon ton environnement linguistique, ta version d'Office, et parfois, semble-t-il, la phase de la lune. La solution fiable est un BOM UTF-8 – un Byte Order Mark. C'est une séquence spéciale, invisible, de trois octets (0xEF, 0xBB, 0xBF) au tout début du fichier qui agit comme un signal pour Excel, lui disant 'Hé ! Ce fichier est en UTF-8, alors lis-le comme tel.' Excel respecte ce signal, même dans les anciennes versions. Le reste de cet article t'explique comment l'ajouter, quand *ne pas* l'ajouter, et comment CocoConvert peut le gérer pour toi.
Ce qu'est réellement le BOM (et ce qu'il n'est pas)
Le Byte Order Mark est apparu à l'origine dans le monde de l'UTF-16 et de l'UTF-32, où l'ordre des octets (big-endian vs. little-endian) est une réelle préoccupation. Le BOM indique à un programme dans quel ordre se trouvent les octets. Mais pour l'UTF-8, l'ordre des octets n'est pas un problème ; il est toujours le même. Donc, d'un point de vue purement technique, le BOM UTF-8 (le caractère U+FEFF encodé en trois octets : EF BB BF) est complètement inutile. Il est inutile, mais il est devenu le code secret qui fait fonctionner Excel. Lorsque Excel voit ces trois octets au début d'un fichier, il bascule immédiatement en mode UTF-8. Sans eux, il utilise ses paramètres régionaux par défaut, et tu obtiens ce mojibake familier. Voici le piège : le BOM qui corrige Excel peut casser beaucoup d'autres logiciels. C'est la partie qui fait trébucher tant de pipelines de données automatisés. La fonction `open()` standard de Python, si tu oublies de spécifier `encoding='utf-8-sig'`, lira le BOM comme faisant partie de ton premier champ de données. L'instruction `LOAD DATA INFILE` de MySQL pensera que le BOM fait partie du nom de la première colonne, corrompant ton en-tête. De nombreux outils classiques de ligne de commande Linux comme `grep`, `awk` et `wc` ne gèrent tout simplement pas bien les fichiers préfixés par un BOM. La commande `COPY` de PostgreSQL est encore plus stricte et échouera dès l'en-tête de la première colonne. Ma règle d'or est simple : n'ajoute un BOM que si tu sais que la destination finale du fichier est un utilisateur qui le double-cliquera dans Excel. Si ton CSV est destiné à une importation dans une base de données, un script Python ou un pipeline Unix, tu veux un UTF-8 propre *sans* BOM. Tu peux toujours l'ouvrir correctement dans Excel, il te suffit d'utiliser l'Assistant d'importation de texte, que nous aborderons plus loin.
Trois façons d'ajouter un BOM UTF-8 manuellement
Si tu es bloqué avec un CSV illisible et que tu as besoin de le réparer tout de suite, tu n'as pas besoin d'un service sophistiqué. Voici trois façons fiables d'ajouter le BOM toi-même. **Avec Notepad++ sous Windows :** C'est souvent la solution la plus rapide. Ouvre ton CSV dans Notepad++. Va dans le menu `Encodage`. Tu verras probablement qu'il est déjà réglé sur 'UTF-8'. C'est ça le problème – c'est de l'UTF-8 *sans* le BOM. Clique sur l'option 'Encoder en UTF-8 BOM' puis enregistre le fichier. C'est fait. Le fichier a maintenant le préfixe magique de trois octets et Excel l'ouvrira correctement. **Avec une ligne de commande Python :** Si tu es à l'aise dans un terminal, cette seule commande est un moyen puissant de convertir n'importe quel fichier UTF-8 en UTF-8 avec un BOM. Elle fonctionne sur n'importe quel OS avec Python 3. ``` python3 -c "open('output.csv','wb').write(b'\xef\xbb\xbf'+open('input.csv','rb').read())" ``` Cette commande lit ton `input.csv` comme des octets bruts, colle les trois octets du BOM au début, et écrit le tout dans `output.csv`. Aucune bibliothèque supplémentaire n'est nécessaire. **Avec l'Assistant d'importation de texte d'Excel :** Au lieu de modifier le fichier, tu peux simplement dire à Excel comment le lire correctement. Va dans `Données → Obtenir et transformer les données → À partir d'un fichier texte/CSV` (dans les versions modernes d'Excel) ou `Données → Données externes → À partir du texte` (dans les anciennes versions). L'étape clé consiste à trouver le paramètre 'Origine du fichier' dans la boîte de dialogue d'importation et à le changer en `65001 : Unicode (UTF-8)`. Cela force Excel à utiliser le bon encodage. L'inconvénient est de taille : cette correction est temporaire et ne s'applique qu'à ta session d'importation. La prochaine personne qui double-cliquera sur le fichier verra le même charabia illisible. Aucune de ces méthodes manuelles n'est idéale pour un processus répétable. C'est là que l'automatisation de la conversion, avec le BOM comme option, commence vraiment à prendre tout son sens.
Comment CocoConvert gère le BOM UTF-8 pendant la conversion de fichiers
Lorsque tu utilises CocoConvert pour transformer un fichier en CSV – qu'il provienne d'Excel, de JSON, de XML ou d'autre chose – nous te donnons un contrôle direct sur ce point. Dans les paramètres de sortie, tu trouveras un interrupteur 'Ajouter un BOM UTF-8 pour la compatibilité Excel'. Nous le laissons désactivé par défaut, car comme nous l'avons vu, le BOM peut causer autant de problèmes qu'il en résout dans des environnements non-Excel. Mais si tu en as besoin, il suffit d'activer l'interrupteur. Pour tout flux de travail qui se termine par l'ouverture d'un fichier par quelqu'un de la comptabilité, le processus est simple. Télécharge ton fichier source, choisis CSV pour la sortie, active l'interrupteur BOM et télécharge. Le CSV résultant s'ouvrira parfaitement dans Excel d'un simple double-clic, sans avoir besoin d'un assistant d'importation manuel. Ce paramètre s'applique également aux conversions par lots, donc si tu as 50 fichiers d'exportation de produits d'une boutique Shopify, tu peux les traiter tous en une seule fois et les avoir tous prêts pour Excel. Il est important d'être clair sur ce que notre outil fait et ne fait pas. CocoConvert ne peut pas corriger par magie les problèmes d'encodage qui étaient déjà présents dans ton fichier source. Si un système hérité te fournit un CSV déjà corrompu par une mauvaise exportation Windows-1252, nous ferons de notre mieux pour le translittérer, mais certaines données pourraient être perdues. Tu recevras un avertissement si cela se produit. Nous ne devinons pas non plus si tu as besoin d'un BOM ; c'est à toi de décider, en fonction de la destination du fichier. L'outil fournit l'option, mais tu dois connaître ton propre flux de travail. Enfin, si tu convertis un format qui connaît déjà son encodage, comme un fichier XLSX, nous lisons correctement cette information. L'interrupteur BOM dans ce cas vise uniquement à rendre le CSV *de sortie* compatible avec Excel, et non à réparer la source.
L'Assistant d'importation de texte d'Excel : quand l'utiliser à la place
Parfois, ajouter un BOM à ton CSV est une mauvaise décision, et l'assistant d'importation d'Excel est la bonne. Le scénario le plus courant est lorsque tu reçois des CSV d'un système externe que tu ne contrôles pas. Si ce système génère des fichiers UTF-8 propres *sans* BOM, tu ne devrais pas avoir à les faire passer par un outil séparé juste pour ajouter trois octets. Dans Excel 2016 et les versions antérieures, navigue vers `Données → À partir du texte`. Lorsque l'Assistant d'importation de texte se lance, la première étape propose un menu déroulant 'Origine du fichier'. Tu dois le modifier du paramètre par défaut (généralement 'Windows (ANSI)') à `65001 : Unicode (UTF-8)`. Après cela, termine l'assistant comme d'habitude, et tes données s'afficheront correctement. Dans Microsoft 365 et Excel 2019, le chemin est `Données → Obtenir les données → À partir d'un fichier → À partir d'un fichier texte/CSV`. Ce nouvel importateur Power Query est meilleur pour la détection automatique de l'UTF-8, mais il n'est pas parfait. Si l'aperçu semble incorrect, trouve le menu déroulant 'Origine du fichier' ou 'Encodage' dans la boîte de dialogue et règle-le manuellement sur UTF-8. La principale limite, comme nous l'avons mentionné, est que cette correction ne 'colle' pas. Le fichier lui-même reste inchangé. Si tu l'envoies par e-mail à un collègue, il le double-cliquera et verra le même texte illisible. L'assistant est un excellent outil si tu es le seul à manipuler le fichier. Si tu le distribues, tu dois vraiment intégrer le BOM dans le fichier lui-même. L'assistant est également le bon choix lorsque ton CSV doit être propre pour d'autres processus, comme une importation de base de données, mais que tu as juste besoin d'un rapide coup d'œil dans Excel.
Problèmes d'encodage de caractères au-delà du BOM
Résoudre le problème du BOM UTF-8 corrige le problème de caractères Excel le plus courant, mais c'est loin d'être le seul casse-tête d'encodage que tu rencontreras avec les CSV. Voici quelques autres coupables à surveiller. **Fichiers source Windows-1252** : De nombreux systèmes plus anciens, en particulier les ERP hérités et les plateformes de commerce électronique de première génération, exportent encore des données en Windows-1252. Cet encodage gère très bien les caractères d'Europe occidentale comme é, ü et ñ, mais il s'effondre complètement pour toute langue en dehors de cet ensemble. Si tu essaies de fusionner ces données avec une source UTF-8, tu as besoin d'une véritable étape de ré-encodage, pas seulement d'un BOM. CocoConvert peut gérer cela si tu spécifies l'encodage source, ou il essaiera de le détecter automatiquement – ce qui, selon nos tests, fonctionne environ 94 % du temps. Les échecs se produisent avec des fichiers qui sont techniquement valides dans plusieurs encodages à la fois. **Confusion de délimiteurs** : Quiconque a passé une heure à déboguer un problème d'« encodage » pour découvrir qu'il s'agissait d'un point-virgule au lieu d'une virgule connaît cette douleur. Si un CSV utilise des points-virgules comme délimiteurs mais que ton environnement Excel attend des virgules, toutes les données seront entassées dans la première colonne. Cela ressemble à un charabia illisible, mais ce n'est pas un problème d'encodage. La solution est d'utiliser l'assistant d'importation et de spécifier le bon délimiteur. **Guillemets « intelligents » et tirets spéciaux d'Excel** : Lorsque des données sont passées par Microsoft Word ou Outlook, elles adoptent souvent des guillemets courbes « intelligents » et de longs tirets cadratins. Ce sont des caractères UTF-8 valides et ils s'affichent correctement dans la plupart des applications modernes, mais ils casseront les requêtes de base de données et les scripts qui attendent une ponctuation ASCII simple. CocoConvert propose une fonctionnalité optionnelle de 'normalisation des guillemets intelligents' pour la sortie CSV qui les remplace par leurs versions ASCII simples. C'est un changement destructeur pour tes données, nous le rendons donc optionnel. **Octets NULL dans les données** : Certaines exportations de bases de données peuvent intégrer des octets NULL (0x00) dans les champs de texte. C'est un obstacle majeur absolu pour presque tous les analyseurs CSV de la planète. Aucune magie d'encodage ne réparera un fichier contenant des octets NULL ; ils doivent être supprimés ou remplacés avant que le fichier puisse être utilisé.
Une liste de contrôle pratique avant de convertir ou d'ouvrir un CSV
Après avoir lutté avec des problèmes d'encodage à travers des milliers de conversions de fichiers, nous avons constaté que cette liste de contrôle permet de détecter la grande majorité des problèmes de caractères CSV avant qu'ils ne commencent. **Avant d'exporter depuis un système source :** Recherche une option d'encodage. Les plateformes modernes comme Salesforce, HubSpot et Shopify te permettent toutes de choisir l'UTF-8 pour les exportations. Utilise-le. Si la seule option est 'par défaut' ou 'encodage système', sois méfiant. Ouvre le fichier de sortie dans un éditeur de texte comme VS Code ou Notepad++ qui affiche l'encodage avant de l'envoyer à qui que ce soit. **Avant d'ouvrir un CSV dans Excel :** Demande-toi : ce fichier a-t-il un BOM ? Dans VS Code, l'encodage est affiché directement dans la barre d'état. Dans Notepad++, vérifie le menu Encodage. S'il indique 'UTF-8' et que tu dois utiliser Excel, tes choix sont d'ajouter un BOM toi-même ou d'utiliser l'assistant d'importation. Ne double-clique jamais en espérant le meilleur. **Avant de donner un CSV à un script ou à une base de données :** Sois attentif à la présence d'un BOM, surtout si le fichier provient d'un utilisateur Windows. En Python, l'utilisation de `encoding='utf-8-sig'` est le moyen le plus propre de le gérer automatiquement. Pour MySQL, tu devras supprimer le BOM avant l'importation ou utiliser une instruction `LOAD DATA` qui spécifie `CHARACTER SET utf8mb4`. Pour PostgreSQL, supprime-le simplement ; la commande `COPY` n'est pas indulgente. Lorsque tu utilises CocoConvert, retiens la règle : n'active l'interrupteur BOM UTF-8 que si tu sais que le fichier est destiné directement à un utilisateur Excel qui le double-cliquera. Pour toute autre destination – une base de données, une API, un script – laisse-le désactivé. Si tu penses que ton fichier source présente des problèmes, prends les dix secondes supplémentaires pour spécifier explicitement son encodage. C'est beaucoup plus rapide que de corriger une mauvaise conversion. Le BOM est une toute petite chose – juste trois octets. Mais il se situe précisément à la ligne de faille entre différentes hypothèses sur le fonctionnement des fichiers texte, causant une quantité disproportionnée de frustration. Savoir quand l'utiliser, quand l'éviter et comment le contourner est la clé pour que tes données CSV circulent proprement entre les outils.