How to Clean Messy CSV Data (A Practical Checklist)

Le dernier mardi, j'ai vu une analyste junior passer quatre heures à corriger manuellement un fichier CSV qui aurait dû prendre vingt minutes à nettoyer. Elle copié et collé des cellules une par une, essayant de corriger des formats de dates qui avaient été exportés de trois systèmes différents. Au moment où elle a terminé, ses yeux étaient vitreux, et le fichier avait toujours des incohérences qu'elle n'avait pas remarquées. Je suis ingénieur en données depuis douze ans, et je vois constamment ce scénario se dérouler – des gens intelligents gaspillant des après-midis entiers sur des fichiers CSV en désordre parce qu'ils n'ont pas d'approche systématique.

La vérité est que les fichiers CSV sont à la fois le format de données le plus universel et le plus problématique existant. Chaque système peut les exporter, chaque outil peut les importer, et pourtant ils sont un champ de mines de problèmes d'encodage, de confusion sur les délimiteurs, et d'incohérences structurelles. Selon une enquête de 2023 de l'Institut de Qualité des Données, les professionnels des données passent en moyenne 19,2 heures par semaine sur des tâches de nettoyage de données, avec la gestion des CSV représentant environ 40 % de ce temps. Cela représente près de huit heures chaque semaine—une journée de travail entière—perdue à corriger des problèmes évitables.

Je suis Marcus Chen, et j'ai passé la dernière décennie à construire des pipelines de données pour des entreprises allant de start-ups audacieuses à des entreprises du Fortune 500. J'ai traité des milliards de lignes de données CSV, et j'ai vu toutes les façons imaginables dont ces fichiers peuvent tomber en panne. Ce que j'ai appris, c'est que nettoyer des données CSV en désordre n'est pas une question de malin—c'est une question de systématique. Vous avez besoin d'une checklist, d'un processus répétable qui attrape les problèmes avant qu'ils ne se répercutent sur votre analyse ou votre base de données. Cet article est cette checklist, distillée de milliers d'heures de gestion de données dans le monde réel.

Comprendre pourquoi les fichiers CSV sont si problématiques

Avant de plonger dans le processus de nettoyage, vous devez comprendre pourquoi les fichiers CSV causent tant de maux de tête. Le format semble trompeusement simple : des valeurs séparées par des virgules, une ligne par ligne. Mais cette simplicité est exactement le problème. Contrairement aux formats structurés comme JSON ou XML, le CSV n'a pas de spécification formelle que tout le monde suit. La norme RFC 4180 existe, mais c'est plutôt une suggestion qu'une règle, et la plupart des systèmes l'ignorent complètement.

Une fois, j'ai reçu un fichier CSV d'un système comptable hérité d'un client qui utilisait des points-virgules comme délimiteurs, avait des virgules intégrées dans des valeurs numériques (comme "1,234.56"), utilisait à la fois des guillemets simples et doubles pour la qualification de texte, et mélangeait des fins de ligne Windows et Unix dans le même fichier. Il m'a fallu trois heures juste pour le parser correctement, et c'était avec des outils professionnels. Le fichier avait "bien fonctionné" dans leur système pendant des années parce que leur logiciel avait une logique personnalisée pour gérer toutes ces particularités.

Les problèmes fondamentaux avec les fichiers CSV tombent dans plusieurs catégories. D'abord, il y a le problème des délimiteurs—les virgules sont courantes dans les données, donc les systèmes utilisent des tabulations, des pipes, des points-virgules ou d'autres caractères, mais ils ne vous disent pas toujours lequel. Ensuite, il y a la qualification des textes—quand avez-vous besoin de guillemets autour des valeurs, et que se passe-t-il lorsque vos données contiennent des caractères de guillemets ? Troisièmement, l'encodage—est-ce UTF-8, Latin-1, Windows-1252, ou quelque chose d'autre complètement ? Si vous vous trompez, vous verrez des caractères corrompus là où devraient se trouver des lettres accentuées.

Ensuite, il y a les problèmes structurels. Les fichiers CSV n'ont pas de moyen intégré pour représenter les types de données, donc tout est du texte jusqu'à ce que vous le parsiez. Une date peut être "2024-01-15", "01/15/2024", "15-Jan-24", ou "15 janvier 2024"—et parfois ces quatre formats apparaissent dans la même colonne car différents utilisateurs ont saisi les données différemment. Les nombres peuvent avoir des symboles de devise, des signes de pourcentage, ou des séparateurs de milliers. Les valeurs booléennes peuvent être "vrai/faux", "oui/non", "1/0", "O/N", ou toute combinaison de ceux-ci.

Le pire, c'est que beaucoup de problèmes CSV sont silencieux. Votre outil d'importation peut réussir sans erreurs, mais vos données sont subtilement corrompues. J'ai vu des cas où les zéros non significatifs ont été supprimés des codes produits, transformant "00123" en "123" et brisant les systèmes d'inventaire. J'ai vu des dates interprétées incorrectement parce que le système supposait MM/JJ/AAAA quand le fichier utilisait JJ/MM/AAAA, provoquant des ordres programmés pour des dates impossibles comme le 31 février. Ces erreurs ne se manifestent pas—elles se cachent dans vos données jusqu'à ce que quelqu'un remarque que les chiffres ne correspondent pas.

Étape Un : Inspectez avant d'importer

La plus grande erreur que les gens font avec les fichiers CSV est de les ouvrir directement dans Excel ou de les importer directement dans une base de données. Ne faites pas cela. Votre première étape devrait toujours être l'inspection avec un éditeur de texte ou un outil en ligne de commande. J'utilise une combinaison de head, tail, et wc -l sur les systèmes Unix, ou un éditeur de texte pour programmeurs comme VS Code ou Sublime Text qui peut gérer de grands fichiers sans se bloquer.

"Les fichiers CSV sont les cafards des formats de données—ils survivent à tout, fonctionnent partout, et provoquent des problèmes que vous n'avez jamais prévus."

Commencez par regarder les 20-30 premières lignes du fichier. Cela vous indique le délimiteur, s'il y a une ligne d'en-tête, et à quoi ressemble la structure générale. Mais ne vous arrêtez pas là—regardez aussi les 20-30 dernières lignes. Je ne peux plus compter combien de fois j'ai découvert qu'un fichier commence propre mais se termine par des déchets : des lignes partielles, des messages d'erreur du processus d'exportation, ou des statistiques résumées que quelqu'un a volontiers ajoutées aux données. Le système ERP d'un client ajoutait un pied de page avec "Total des enregistrements : 45 892" à la fin de chaque exportation, ce qui ferait planter n'importe quel processus d'importation naïf.

Vérifiez le nombre de lignes avec wc -l filename.csv et comparez-le à ce que vous attendez. Si le fichier devrait avoir 10 000 enregistrements plus un en-tête, vous devriez voir 10 001 lignes. Si vous voyez 10 247 lignes, quelque chose ne va pas—probablement des sauts de ligne intégrés dans des champs de texte. C'est incroyablement courant dans les fichiers CSV qui contiennent du contenu généré par les utilisateurs comme des commentaires ou des descriptions. Quelqu'un écrit "Ce produit est génial\nRecommande fortement" et soudain vous avez un saut de ligne au milieu d'une ligne.

Recherchez le délimiteur en examinant les premières lignes. Comptez les virgules, tabulations, pipes, ou points-virgules dans chaque ligne. Ils devraient être cohérents. Si la première ligne a 12 virgules et la deuxième en a 15, vous avez un problème—soit le délimiteur est incorrect, soit vous avez des champs de texte non qualifiés qui contiennent le caractère délimiteur. J'ai passé une heure à déboguer un fichier avant de réaliser qu'il utilisait le caractère pipe (|) comme délimiteur, ce qui était presque invisible dans ma police de terminal.

Vérifiez l'encodage en recherchant des caractères non-ASCII. Si vous voyez des symboles étranges comme ’ au lieu d'apostrophes, ou é au lieu de é, vous avez un problème d'encodage. Le fichier est probablement en UTF-8 mais lu comme Latin-1, ou vice versa. Utilisez un outil comme file -i filename.csv sur Unix pour détecter l'encodage, ou utilisez la fonctionnalité de détection d'encodage de votre éditeur de texte. Faire cette erreur tôt signifie que chaque champ de texte dans vos données sera corrompu.

Étape Deux : Validez la structure

Une fois que vous avez inspecté le fichier manuellement, l'étape suivante est la validation structurelle. Chaque ligne devrait avoir le même nombre de champs, et ce nombre devrait correspondre à votre ligne d'en-tête. Cela semble évident, mais c'est constamment violé dans les données du monde réel. J'utilise Python avec le module csv ou pandas pour faire cette validation de manière programmatique, car vérifier des milliers de lignes à l'œil est impossible.

Voici un simple script Python que j'exécute sur chaque fichier CSV que je reçois : il compte les champs dans chaque ligne et rapporte ceux qui ne correspondent pas à l'en-tête. Dans un projet récent, ce script a révélé que 347 des 50 000 lignes avaient des champs supplémentaires parce que le processus d'exportation avait un bug qui dupliquait la dernière colonne dans certaines conditions. Sans cette vérification, ces lignes auraient été silencieusement corrompues lors de l'importation, les données supplémentaires étant soit tronquées soit déplacées dans les mauvaises colonnes.

Faites particulièrement attention aux champs cités. Le CSV utilise des guillemets pour permettre des délimiteurs et des sauts de ligne à l'intérieur des valeurs de champ, mais les règles de citation sont complexes et souvent mal mises en œuvre. Un champ comme "Smith, John" est correctement cité, mais qu'en est-il de "Il a dit "bonjour" à moi" ? Le format correct est "Il a dit ""bonjour"" à moi" avec des guillemets doublés, mais de nombreux systèmes se trompent et produisent "Il a dit "bonjour" à moi", ce qui casse le parsing.

Vérifiez les lignes vides, qui apparaissent souvent à la fin des fichiers ou entre les sections de données. Cela devrait