CSV vs JSON vs Excel: I've Wasted Hours Using the Wrong Format

Le mardi dernier à 3 heures du matin, j’ai vu mon script Python s’étouffer avec un fichier CSV de 47 Mo pour la troisième fois cette semaine. Le message d’erreur se moquait de moi : « Échec de l’allocation de mémoire. » J'étais data engineer depuis huit ans à ce moment-là, et je commettais encore des erreurs de débutant avec les formats de fichiers.

Cette nuit sans sommeil a coûté à mon équipe six heures de temps de traitement et a failli dérailler notre pipeline analytique trimestriel. La pire partie ? Je savais mieux. Je venais juste de devenir paresseux et de me tourner vers le CSV parce que c'était « simple. » Cette décision a entraîné une série de problèmes d'encodage, de mémoire et de confusion des types de données qui auraient pu être évités entièrement.

Je suis Marcus Chen, et j'ai passé la dernière décennie à construire des pipelines de données pour tout, des startups fintech aux détaillants du Fortune 500. J'ai traité des milliards de lignes à travers des milliers de projets, et j'ai appris cela à mes dépens : choisir le mauvais format de données n'est pas seulement inconvenant, c'est coûteux. Vraiment coûteux. J'ai un jour calculé que de mauvais choix de format ont coûté à ma précédente entreprise environ 180 000 $ par an en temps de calcul perdu, en heures de développement et en tâches de lot échouées.

Cet article n'est pas une autre comparaison technique sèche. C'est un guide de terrain écrit depuis les tranchées, où les décisions de format ont de réelles conséquences. Je vais vous montrer exactement quand utiliser CSV, JSON ou Excel, soutenu par des scénarios spécifiques que j'ai rencontrés et les métriques qui comptent. À la fin, vous saurez comment éviter les erreurs qui m'ont coûté collectivement des centaines d'heures.

Le piège CSV : Quand le simple devient compliqué

Les fichiers CSV vous séduisent par leur simplicité. Ils sont lisibles par l'homme, universellement supportés et semblent être le choix sûr. Pendant mes trois premières années en tant qu'analyste de données, j'ai par défaut utilisé le CSV pour presque tout. Puis j'ai rejoint une équipe d'analytique de santé qui traitait des dossiers patients, et le CSV a failli nous détruire.

Le problème a commencé innocemment. Nous exportions 2,3 millions de dossiers de visites de patients de notre base de données. Le CSV semblait parfait : léger, rapide à générer, facile à partager avec nos partenaires de recherche. En deux semaines, nous avons eu cinq problèmes critiques qui ont interrompu notre analyse.

Tout d'abord, le cauchemar de l'encodage. Les noms des patients contenaient des caractères provenant de 47 langues différentes. Nos exports CSV étaient par défaut en ASCII, déformant des noms comme « José García » en « Jos? Garc?a » et détruisant complètement des noms en mandarin, arabe et cyrillique. Nous avons passé quatre jours à déboguer avant de réaliser que nous avions besoin de UTF-8 avec BOM (Byte Order Mark) pour la compatibilité Excel, mais de UTF-8 sans BOM pour nos scripts Python. C'est exact : nous avions besoin de deux variantes différentes de CSV pour différents outils.

Ensuite, le désastre des types de données. Le CSV n'a aucun concept de types de données. Tout est du texte jusqu'à ce que vous l'analysiez. Notre colonne « patient_id » contenait des valeurs comme « 00123 » que Excel a gentiment converties en « 123 », détruisant les zéros initiaux nécessaires pour les recherches dans la base de données. Les dates étaient encore pire : « 03/04/2023 » pouvait signifier le 4 mars ou le 3 avril selon les paramètres régionaux. Nous avons perdu tout un week-end à traquer pourquoi 18 % de nos jointures de dates échouaient.

Enfin, le chaos des délimiteurs. Les notes médicales contenaient des virgules, des points-virgules et des tabulations. Nous avons essayé le délimiteur par virgule, puis par point-virgule, puis par tabulation. Chaque changement interrompait le script d'importation de quelqu'un. Finalement, nous nous sommes arrêtés sur un délimiteur par pipe (|) car il n'apparaissait que dans 0,003 % de nos champs de texte, mais d'ici là, nous avions perdu 12 heures et généré six versions de fichiers incompatibles.

Voici ce que j'ai appris : le CSV fonctionne à merveille pour des données simples et plates avec des types cohérents et sans caractères spéciaux. C'est parfait pour exporter 50 000 lignes de transactions de vente avec des ID numériques propres, des dates au format ISO (AAAA-MM-JJ), et aucun champ de texte plus long qu'une phrase. Au moment où vous ajoutez de la complexité—données imbriquées, types mixtes, caractères internationaux, ou grands blocs de texte—le CSV devient une responsabilité.

Les chiffres de performance racontent l'histoire. Pour un fichier de 10 Mo avec 100 000 lignes de données numériques simples, l'analyse du CSV prend environ 0,8 secondes en Python avec pandas. Mais ajoutez des champs de texte avec des guillemets échappés et des virgules, et cela passe à 3,2 secondes. Ajoutez la détection d'encodage, et vous en êtes à 5,1 secondes. Pour le traitement par lots de milliers de fichiers, ces secondes s'accumulent en heures.

Les coûts cachés de JSON : Quand la flexibilité devient une surcharge

Après mes désastres CSV, je me suis engagé à fond vers JSON. Il a résolu tout ce que le CSV ne pouvait pas gérer : données imbriquées, types explicites, support Unicode, et une spécification claire. Pendant deux ans, j'étais un évangéliste JSON. Puis j'ai construit un tableau de bord d'analyse en temps réel pour une plateforme e-commerce, et JSON m'a appris des leçons coûteuses.

"Choisir le mauvais format de données n'est pas seulement une décision technique—c'est une décision financière. J'ai vu des entreprises brûler des six chiffres chaque année parce que les développeurs se tournaient par habitude vers le CSV."

Le projet semblait simple : ingérer les données de flux de clics de 200 000 utilisateurs actifs quotidiens, les traiter en temps réel et afficher les métriques sur un tableau de bord. Chaque événement de clic était un objet JSON avec environ 30 champs comprenant des propriétés d'utilisateur imbriquées, des détails de produit et des métadonnées de session. De magnifiques données structurées et auto-documentées.

Le premier problème nous a frappés lors de la troisième semaine : explosion de la taille des fichiers. Nos fichiers CSV équivalents faisaient en moyenne 2,1 Mo par heure de données. Les versions JSON ? 8,7 Mo. C'est 4,1 fois plus grand pour les mêmes informations. Le coupable était la verbosité de JSON : chaque nom de champ était répété pour chaque enregistrement. Dans le CSV, « user_id » apparaît une fois dans l'en-tête. Dans JSON, il apparaît 50 000 fois si vous avez 50 000 enregistrements.

Ce n'était pas seulement un problème de stockage. Nous transférions ces fichiers entre les services via le réseau. À 8,7 Mo par heure multiplié par 24 heures multiplié par 30 jours, nous déplacions 6,3 Go par mois au lieu de 1,5 Go. Nos coûts de transfert de données AWS ont sauté de 47 $ à 201 $ par mois. Multipliez cela par 15 microservices, et nous avions ajouté 2 310 $ de coûts d'infrastructure mensuels en choisissant JSON.

Le deuxième problème était la performance d'analyse. L'analyse JSON est coûteuse en ressources car elle nécessite de construire un arbre d'objets en mémoire. Pour nos données de flux de clics, analyser un fichier JSON de 100 Mo a pris 12,3 secondes en Python en utilisant la bibliothèque json standard. L'équivalent CSV ? 3,1 secondes avec pandas. Quand vous traitez des fichiers toutes les cinq minutes, cette différence de 9,2 secondes par fichier s'accumule à 26,5 heures de temps de calcul mensuel.

Mais voici où cela devient intéressant : JSON brille dans des scénarios spécifiques que le CSV ne peut pas toucher. Lorsque j'ai déménagé dans une startup fintech construisant une API de paiement, JSON est devenu indispensable. Nous gérions des charges utiles de webhook contenant des données de transaction profondément imbriquées : méthodes de paiement contenant des adresses de facturation contenant des coordonnées géographiques. Essayer de les aplatir dans un CSV aurait nécessité plus de 40 colonnes, la plupart d'entre elles vides pour une transaction donnée.

Le véritable pouvoir de JSON se trouve dans les API et les fichiers de configuration. Pour nos webhooks de paiement, la nature auto-descriptive de JSON signifiait que nos consommateurs d'API pouvaient analyser les réponses sans consulter la documentation. La structure imbriquée correspondait parfaitement à notre modèle de domaine. Et lorsque nous devions ajouter de nouveaux champs, nous pouvions le faire sans casser les intégrations existantes—quelque chose d'impossible avec des formats CSV positionnels.

La règle que j'ai développée : utilisez JSON pour l'échange de données entre systèmes, surtout dans les API, et pour les fichiers de configuration où la lisibilité humaine et la flexibilité importent plus que la taille ou la vitesse. Évitez le JSON pour le stockage de données à grande échelle ou le traitement par lots où vous déplacez la même structure à maintes reprises. Dans ces cas, la taxe de verbosité devient prohibitive.

Excel : Le format que tout le monde aime détester (mais dont on a secrètement besoin)

J'ai passé des années à rejeter les fichiers Excel comme « pas de vrais formats de données. » C'étaient ce que les utilisateurs métiers créaient quand ils ne savaient pas mieux. Puis je suis devenu responsable d'une équipe de données dans une entreprise d'analytique de détail, et j'ai appris que les fichiers Excel (.xlsx) sont souvent le seul format qui fonctionne réellement dans le monde réel.

Le coup de fouet est venu lors d'un projet avec notre équipe de merchandising. Ils avaient besoin de rapports de ventes hebdomadaires décomposés par région, catégorie et SKU, avec un formatage conditionnel pour mettre en valeur les produits sous-performants. J'ai construit un magnifique pipeline automatisé qui générait des fichiers CSV et