CSV et JSON sont les deux formats de données tabulaires les plus répandus dans les logiciels modernes ; passer de l’un à l’autre de façon fiable est l’une des tâches d’ingénierie des données les plus fréquentes. CSV est le langage courant des tableurs, des exportations analytiques et des systèmes anciens ; JSON est la norme des API Web, des pipelines de données modernes et des bases de données documentaires. Les sections ci-dessous expliquent les cas limites qui piègent les convertisseurs naïfs, quand choisir chaque format et comment interpréter les résultats de l’inspecteur de données pour repérer les problèmes de qualité avant la mise en production.
Cas limites qui piègent les convertisseurs naïfs
Un analyseur CSV naïf sépare chaque ligne au niveau du délimiteur, mais les fichiers CSV réels présentent plusieurs cas limites qui font échouer cette méthode. Le plus courant concerne les champs entre guillemets : une cellule comme `"Smith, John"` contient une virgule qui fait partie de la valeur et non un séparateur ; l’analyseur doit donc suivre l’état des guillemets tout au long de la ligne. Les retours à la ligne dans les champs entre guillemets sont autorisés par la RFC 4180, mais sont souvent mal analysés : une ligne CSV peut s’étendre sur plusieurs lignes physiques lorsqu’une cellule entre guillemets est renvoyée à la ligne. Les guillemets doubles échappés dans ces champs sont représentés par deux guillemets consécutifs (`"He said ""hello"""`) ; ils doivent être ramenés à un seul guillemet dans le résultat. Les marques d’ordre des octets Unicode (BOM), présentes au début des fichiers enregistrés par Excel sous Windows, créent des octets parasites invisibles dans le premier nom de champ si elles ne sont pas supprimées. Les systèmes utilisent différents marqueurs de fin de ligne (LF sous Unix, CRLF sous Windows et parfois CR seul dans d’anciens fichiers Mac) ; l’analyseur doit gérer les trois pour éviter les lignes vides à la fin. Ce convertisseur traite correctement tous ces cas. Si vous écrivez votre propre convertisseur, n’improvisez pas un analyseur : utilisez une bibliothèque éprouvée, comme Papa Parse en JavaScript, le module csv en Python ou un équivalent.
Quand choisir CSV ou JSON
Le choix du format dépend du destinataire et de la structure des données, plutôt que de leur origine. Choisissez CSV lorsque les données sont fondamentalement tabulaires (lignes d’enregistrements homogènes), que le destinataire est un tableur (Excel, Google Sheets, Numbers), un ancien pipeline ETL ou une personne qui ouvrira le fichier pour l’examiner. CSV n’a aucun surcoût structurel : c’est la représentation tabulaire la plus compacte, ce qui compte lorsque les fichiers atteignent plusieurs gigaoctets. En revanche, CSV n’a pas de système de types (tout est une chaîne), ne prend pas en charge les structures imbriquées (les données hiérarchiques doivent être aplaties) et ne définit pas de représentation officielle des valeurs nulles (souvent une chaîne vide ou un marqueur comme `NULL`). Choisissez JSON lorsque les enregistrements sont hétérogènes, que les données sont naturellement imbriquées (commandes avec lignes d’articles, utilisateurs avec adresses) ou que le destinataire est une API moderne, une application JavaScript ou une base de données documentaire. JSON préserve les types et la structure natifs. Ses inconvénients sont la taille (avec des clés répétées, un fichier JSON est 2 à 5 fois plus volumineux que son équivalent CSV) et le coût d’analyse (JSON nécessite un analyseur complet, tandis que CSV peut être traité en continu). JSONL est un bon compromis pour les très grands jeux de données hiérarchiques : chaque ligne peut être analysée indépendamment, permettant un véritable traitement en continu sans conserver le fichier entier en mémoire.
Utiliser l’inspecteur de données pour repérer les problèmes
L’onglet Inspecteur de données révèle des problèmes de qualité qui, autrement, n’apparaîtraient qu’en aval, lorsqu’une opération échoue. L’indicateur le plus important est le taux de remplissage par colonne : le pourcentage de lignes dont la valeur n’est pas nulle. Une colonne remplie à 100 % est complète ; à 50 %, la moitié des lignes sont vides, ce qui peut être normal pour un champ facultatif ou signaler une corruption des données en amont. Vérifiez les colonnes dont le taux est inférieur à 80 % avant d’envoyer les données pour un usage important. L’inférence des types indique si une colonne contient toujours des nombres, toujours des chaînes ou un mélange. Les colonnes à types mixtes signalent généralement un problème dans la source — par exemple, quelques valeurs textuelles isolées dans une colonne numérique, qui provoqueront des erreurs chez un destinataire exigeant des types stricts. Le nombre de valeurs uniques permet de repérer les clés dupliquées : si une colonne censée être une clé primaire contient moins de valeurs uniques que de lignes, la source comporte des doublons à supprimer avant l’importation. Les valeurs d’exemple permettent de vérifier rapidement que les premières cellules semblent plausibles : dates analysées comme du texte, symboles monétaires encore attachés aux nombres ou espaces finaux qui font échouer les comparaisons de chaînes. Ensemble, ces diagnostics repèrent environ 90 % des problèmes de qualité des données CSV/JSON courants avant que les données ne quittent cet outil.