Nettoyer l'import CSV

Que fait précisément cet outil ?

L’outil prend un fichier CSV et exécute quatre étapes qui sont presque toujours nécessaires sur des exports tableurs francophones :

1. Détecter le jeu de caractères. À partir des premiers octets, on détermine si le fichier est en UTF-8, Latin-1 ou Windows-1252. Une Byte-Order-Mark (BOM) présente est respectée ; sinon, une heuristique exploite les caractères spéciaux typiques (€, « », smart quotes, lettres accentuées) pour la désambiguïsation.
2. Détecter le séparateur. À partir des dix premières lignes, on identifie le séparateur de colonne le plus cohérent — virgule, point-virgule, tabulation ou pipe. Les guillemets sont respectés au comptage pour que les virgules embarquées dans des champs quoted ne biaisent pas le résultat.
3. Nettoyer les données. Les lignes vides sont supprimées, les noms de colonnes en double reçoivent des suffixes compteur (_2, _3), et les formats de nombre européens comme 1 234,56 sont convertis en 1234.56 lisible machine — ce dernier optionnellement, avec une heuristique conservatrice (les numéros de version comme 1.234 restent intacts).
4. Générer la sortie. Trois formats au choix : CSV avec BOM UTF-8 (compatible Excel par double-clic), CSV sans BOM (pour Pandas, SQL, R) ou un vrai tableau Excel (.xlsx) avec typage des nombres.

Toutes les étapes s’exécutent entièrement dans l’onglet du navigateur. Le code ne charge aucun script externe au runtime, n’envoie pas de télémétrie et ne laisse rien dans le stockage navigateur.

Détection d’encodage — comment ça marche techniquement ?

Un fichier CSV ne contient pas de métadonnées sur son jeu de caractères. Qui l’ouvre doit deviner — et de l’UTF-8 mal deviné est exactement la raison pour laquelle « Müller » devient soudain « MÃ``¼ller ».

La détection se déroule en trois étapes :

1. Sonde BOM. Si le fichier commence par les octets EF BB BF, c’est sûrement de l’UTF-8 avec Byte-Order-Mark — pas d’analyse supplémentaire nécessaire.

2. Validation UTF-8 stricte. Le décodeur essaie d’interpréter les octets complets comme UTF-8. Si cela échoue (séquence multi-octets invalide), ce ne peut pas être UTF-8. Si cela réussit, on suppose UTF-8 — pour les fichiers ASCII purs, c’est toujours le cas, parce qu’ASCII est un sous-ensemble d’UTF-8.

3. Heuristique CP1252 vs Latin-1. Si UTF-8 échoue, l’outil examine la plage d’octets 0x80–0x9F. C’est précisément dans cette plage que les deux codepages diffèrent : Latin-1 laisse ces octets vides, Windows-1252 les occupe avec le symbole euro, les guillemets typographiques, les em-dash et en-dash. Si ces octets diagnostiques apparaissent, CP1252 est choisi — sinon Latin-1.

Ces trois étapes couvrent plus de 99 % des exports tableurs francophones, sans qu’il faille charger une bibliothèque externe.

Détection de séparateur — quand Excel se rabat-il sur le point-virgule ?

Les versions Excel francophones exportent les CSV par défaut avec point-virgule, parce que la virgule en France est réservée comme séparateur décimal. Excel US exporte avec virgule. Qui ouvre un CSV US dans Excel FR (ou inversement) obtient une unique méga-colonne, parce qu’Excel attend le mauvais séparateur.

La détection compare dans les dix premières lignes la fréquence de quatre candidats — virgule, point-virgule, tabulation, pipe. Sont évalués :

• Médiane par ligne. Un séparateur qui apparaît trois fois dans chaque ligne est plus probable qu’un qui apparaît parfois sept fois et parfois pas du tout.
• Cohérence. Dans combien des lignes échantillonnées le séparateur apparaît-il en général ? Un gagnant doit apparaître dans la plupart des lignes.
• Quote-awareness. Les virgules à l’intérieur de "… , …" ne comptent pas — elles font partie du contenu, pas du séparateur.

En cas d’ambiguïté, la virgule gagne comme défaut RFC 4180. Un override manuel est disponible à tout moment.

Quels problèmes CSV apparaissent le plus souvent sur données francophones ?

Ces cinq classes de problèmes rencontrent analystes de données et comptables presque chaque jour — et c’est précisément pour cela que l’outil est conçu :

Problème 1 : Les accents deviennent du mojibake. Symptôme : « Größe » devient « GrÃ``¶``Ã``Ÿe » (en français : « créé » devient « crÃ``©``Ã``© »). Cause : le fichier est encodé en Latin-1 ou CP1252, le lecteur l’interprète comme UTF-8. Solution : la détection d’encodage auto bascule sur le bon décodeur, l’outil restitue le fichier comme UTF-8 propre.

Problème 2 : Toutes les colonnes dans une cellule. Symptôme : à l’ouverture dans Excel, toute la ligne atterrit dans la colonne A. Cause : le CSV utilise virgule, le locale Excel attend point-virgule (ou inversement). Solution : la détection de séparateur reconnaît le séparateur réel indépendamment du locale, la sortie peut être basculée sur le séparateur cible souhaité.

Problème 3 : Power BI / Pandas / SQL ne reconnaissent pas les nombres. Symptôme : des montants comme « 1 234,56 » sont importés comme texte au lieu de nombre, les agrégations ne fonctionnent pas. Cause : les outils hors espace francophone ne comprennent que le point comme décimal. Solution : l’option de normalisation des nombres transforme les cellules au format machine 1234.56, sûr et réversible — les numéros de version et IDs restent intacts.

Problème 4 : Noms de colonnes en double. Symptôme : Pandas lit le fichier, mais la deuxième colonne « Date » est silencieusement ignorée. Cause : beaucoup de bibliothèques DataFrame ne permettent pas les en-têtes en double. Solution : les en-têtes en double reçoivent un suffixe _2/_3, les en-têtes vides deviennent column_N. Noms de colonnes uniques garantis.

Problème 5 : Lignes vides issues d’un export Excel. Symptôme : les outils statistiques lèvent des erreurs sur les lignes vides, Pandas génère des séries NaN. Cause : Excel exporte souvent avec une ligne vide à la fin ou entre sections. Solution : les lignes entièrement vides sont supprimées sans que les cellules à contenu ne soient perdues.

Protection des données — 100 % dans le navigateur

Les offres concurrentes de nettoyage CSV — qu’il s’agisse de convertisseurs Web comme Convertio, OnlineConvertFree, CSVtoTable ou Browserling — chargent le fichier sur un serveur pour traitement. La plupart de ces services le mentionnent dans les CGU ; certains stockent le fichier « jusqu’à deux heures pour traitement », d’autres plus longtemps.

Pour les données CSV, c’est un risque plus grand que pour les images : un fichier tableau contient souvent des noms en clair, adresses, écritures comptables, données bancaires ou IDs salariés. Un upload serveur de telles données n’est conforme RGPD qu’avec contrat de sous-traitance — que les rares fournisseurs free-tier ne signent pas.

Cet outil rend l’upload serveur structurellement impossible : le traitement se déroule exclusivement dans l’onglet du navigateur, livré via hosting statique. Il n’y a pas d’endpoint backend qui pourrait accepter le contenu de fichier. Même la sortie Excel optionnelle est entièrement assemblée dans le navigateur — sans appels serveur externes.

Quels formats CSV sont pris en charge ?

Entrées acceptées :

• CSV standard avec virgule, point-virgule, tabulation ou pipe comme séparateur
• TSV (Tab-Separated-Values, .tsv/.tab)
• Tables plaintext (.txt) avec séparateur de colonne reconnaissable
• UTF-8 (avec ou sans BOM), Latin-1 (ISO-8859-1), Windows-1252
• Champs quoted selon RFC 4180 avec guillemets doublés comme escape
• Fins de ligne arbitraires (\n, \r\n, \r)

Sorties acceptées :

• CSV avec BOM UTF-8 — s’ouvre correctement dans Excel par double-clic
• CSV sans BOM — convient à Pandas, R, importeurs SQL, outillage Linux
• Tableau Excel (.xlsx) — les nombres sont typés comme cellules numériques, en-têtes en gras

Délibérément hors scope :

• CSV compressés ZIP/GZIP — décompresser avant
• CSV à colonnes de largeur fixe sans séparateur — cas particulier, pipeline propre nécessaire
• Tableaux multi-feuilles — un CSV est par définition une feuille

Questions fréquentes

Les questions les plus fréquentes sur l’utilisation et la protection des données :

Pourquoi mon fichier CSV affiche-t-il des caractères mojibake cassés au lieu des accents ?

Le fichier a été sauvegardé avec un autre jeu de caractères que celui attendu par le programme qui l’ouvre. Les exports Excel et ERP francophones utilisent souvent Windows-1252 ou Latin-1 au lieu d’UTF-8 — si un lecteur UTF-8 l’ouvre, il interprète chaque octet d’accent comme deux caractères. L’outil détecte le jeu de caractères d’origine et le convertit en UTF-8.

Comment l’outil détecte-t-il si mon CSV est séparé par virgule ou point-virgule ?

L’outil compte dans les dix premières lignes combien de fois chaque séparateur candidat apparaît en dehors des guillemets. Le caractère avec la fréquence la plus cohérente par ligne gagne. Sont détectés virgule, point-virgule, tabulation et pipe. La détection automatique se laisse écraser à tout moment via le menu déroulant.

Que signifie l’option « Convertir les nombres français » ?

Les tableurs francophones écrivent les milliers avec espace fin et les décimales avec virgule — donc « 1 234,56 ». Pandas, R et SQL attendent le point comme décimal — « 1234.56 ». Cette option transforme toute cellule strictement conforme au format européen vers le format machine. Les numéros de version comme « 1.234 » restent inchangés.

Mes données CSV sont-elles téléversées sur un serveur ?

Non. Toute la détection et la conversion se déroulent dans l’onglet de votre navigateur. Le fichier n’est pas téléversé, pas stocké, pas analysé.

Quels outils liés existent ?

D’autres outils du cluster données et documents :

• JSON vers CSV — exporter des tableaux JSON dans un CSV, avec notation point pour champs imbriqués.
• CSV vers Markdown — convertir des tableaux CSV en tables Markdown à barres, idéal pour les README GitHub et la documentation.
• Vérificateur de hash de fichier — calculer des hashes SHA-256/512/BLAKE3 et vérifier contre des fichiers sidecar, entièrement dans le navigateur.