CSV vs JSON — Quand utiliser chaque format

CSV et JSON sont probablement les deux formats de données les plus courants que vous rencontrerez en tant que développeur. Les fichiers CSV apparaissent dans les exports de feuilles de calcul, les dumps de bases de données et les pipelines de science des données. JSON est partout sur le web — API REST, fichiers de configuration, bases de données NoSQL. Les deux sont du texte brut, les deux sont lisibles par l'homme, et les deux font le travail. Mais ils sont conçus pour différentes formes de données, et choisir le mauvais crée de vrais maux de tête. Cet article passe en revue les différences fondamentales, vous montre des exemples concrets où chaque format brille (et s'effondre), et vous donne un guide de décision pratique pour choisir entre eux.

La différence fondamentale : Tables vs Arbres

CSV — défini dans RFC 4180 — est un format plat et tabulaire. Chaque ligne a les mêmes colonnes, chaque valeur est une chaîne. C'est tout. Il correspond parfaitement à une feuille de calcul ou une table de base de données : lignes vers le bas, colonnes en travers.

JSON — spécifié dans RFC 8259 et décrit sur json.org — est un format hiérarchique. Les valeurs peuvent être des objets, des tableaux, des chaînes, des nombres, des booléens ou null. Les objets s'imbriquent dans des objets, les tableaux contiennent des formes mixtes. Il correspond à la façon dont les données vivent réellement dans le code — des enregistrements avec des relations, des listes de choses différentes, des valeurs typées.

Résumé en une ligne : CSV est une table. JSON est un arbre. Si vos données sont une table, CSV est plus simple et plus petit. Si vos données ont un quelconque imbrication, CSV perdra soit des informations soit vous forcera dans des solutions de contournement pénibles.

Les mêmes données dans les deux formats

Voici où la différence devient concrète. Imaginez un catalogue de produits pour un magasin e-commerce. Les produits ont un nom, un prix et s'ils sont en stock — simple. Mais ils ont aussi des variantes (tailles, couleurs) et des attributs (matériau, poids). Voyons comment ces données se présentent dans les deux formats.

En JSON, c'est naturel :

json

[
  {
    "id": "SHOE-001",
    "name": "Trail Runner Pro",
    "price": 129.99,
    "inStock": true,
    "attributes": {
      "material": "mesh",
      "weightGrams": 280
    },
    "variants": [
      { "size": 9,  "color": "black", "sku": "TR-9-BLK",  "qty": 12 },
      { "size": 9,  "color": "white", "sku": "TR-9-WHT",  "qty": 4  },
      { "size": 10, "color": "black", "sku": "TR-10-BLK", "qty": 7  }
    ]
  },
  {
    "id": "SHOE-002",
    "name": "City Walker",
    "price": 89.99,
    "inStock": true,
    "attributes": {
      "material": "leather",
      "weightGrams": 340
    },
    "variants": [
      { "size": 8,  "color": "brown", "sku": "CW-8-BRN",  "qty": 6  },
      { "size": 9,  "color": "brown", "sku": "CW-9-BRN",  "qty": 15 }
    ]
  }
]

Maintenant, essayez de mettre ça dans un CSV. Vous avez deux options, toutes deux maladroites. Option un : tout aplatir et répéter les données parent pour chaque ligne de variante :

csv

product_id,product_name,price,inStock,material,weightGrams,variant_size,variant_color,sku,qty
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,9,black,TR-9-BLK,12
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,9,white,TR-9-WHT,4
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,10,black,TR-10-BLK,7
SHOE-002,City Walker,89.99,true,leather,340,8,brown,CW-8-BRN,6
SHOE-002,City Walker,89.99,true,leather,340,9,brown,CW-9-BRN,15

Le nom du produit, le prix et les attributs sont répétés pour chaque variante. C'est de la redondance de données — pas un gros problème pour cinq lignes, mais pour un catalogue de 50 000 produits avec 8 variantes chacun, ça s'accumule. Option deux : sérialiser les variantes comme une chaîne JSON à l'intérieur d'une colonne CSV — mais maintenant vous intégrez du JSON dans du CSV pour contourner les limites de CSV, ce qui est une odeur de code si j'en ai jamais vu une.

Où CSV gagne

Malgré cette limitation, CSV est genuinement le meilleur choix dans plusieurs scénarios courants.

Feuilles de calcul et outils BI. Excel, Google Sheets, Tableau, Looker, Power BI — ils ouvrent tous CSV nativement en un clic. Pas d'assistant d'importation, pas de schéma à définir, pas d'étape de transformation. Si vos parties prenantes vivent dans des feuilles de calcul, CSV est le chemin de moindre résistance.
Données purement plates. Si vos données sont genuinement une table — événements d'analyse, journaux de transactions, relevés de capteurs, export d'utilisateurs — CSV est plus petit et plus simple. Pas de clés répétées, pas de crochets, pas de bruit.
Import/export de base de données. Chaque base de données SQL a une commande COPY FROM CSV ou équivalente. C'est le format d'échange standard pour le chargement de données en masse et est de plusieurs ordres de grandeur plus rapide que les instructions INSERT.
pandas et la science des données. pandas.read_csv() est l'une des fonctions les plus utilisées dans le travail de données Python. Tout l'écosystème — NumPy, scikit-learn, Polars — traite CSV comme format d'entrée de première classe.
Taille de fichier pour les grandes tables plates. Sans noms de clés sur chaque ligne, CSV est plus petit pour les tables larges avec beaucoup de lignes. Un CSV d'un million de lignes d'événements d'analyse battra confortablement l'équivalent tableau JSON.

Où JSON gagne

Données imbriquées et hiérarchiques. Dès que vos données ont une structure au-delà d'une table plate — objets imbriqués, tableaux de formes différentes, enregistrements liés — JSON les gère naturellement. CSV ne peut pas représenter cela sans perdre des informations ou créer de la redondance.
Préservation des types. En CSV, tout est une chaîne. true, 42, null, et "true" se ressemblent tous. Vous devez inférer les types du côté récepteur, ce qui conduit à des bugs. JSON a des booléens natifs, des nombres et null. inStock: true est sans ambiguïté un booléen — pas de devinettes nécessaires.
API REST et le web. JSON est le format de données natif du web. Chaque bibliothèque client HTTP, chaque API Fetch du navigateur, chaque API REST et GraphQL parle JSON. Envoyer du CSV via HTTP est possible mais inhabituel — vous auriez besoin d'une analyse personnalisée des deux côtés.
Bases de données NoSQL. MongoDB, DynamoDB, Firestore, Elasticsearch, CouchDB — tous utilisent JSON (ou un sur-ensemble binaire comme BSON) comme format de document natif. Vous écrivez du JSON, vous obtenez du JSON en retour.
Fichiers de configuration. package.json, tsconfig.json, manifest.json — la configuration des outils s'est standardisée sur JSON parce qu'il supporte les structures imbriquées et est facile à générer et valider par programme.
Validation de schéma. JSON Schema vous permet de définir la forme exacte d'un document et de valider les données contre lui — vérifications de type, champs requis, correspondance de motifs, contraintes de tableau. CSV n'a pas d'équivalent standard.

Taille de fichier : la vraie histoire

L'affirmation "CSV est plus petit" est vraie dans un cas spécifique : les grandes tables plates avec de nombreuses lignes. Prenez 100 000 événements d'analyse, chacun avec huit champs fixes. En CSV, les noms de champs apparaissent une fois dans l'en-tête. En JSON, ils apparaissent sur chaque objet. Cette répétition s'accumule — le tableau JSON pourrait être 30 à 50% plus grand que le CSV équivalent.

Mais inversez le scénario avec des données imbriquées et les maths changent. Le CSV aplati de notre catalogue de chaussures répète le nom du produit, le prix et les attributs sur chaque ligne de variante. La version JSON stocke chaque produit une fois. Pour les données profondément imbriquées avec de nombreux champs parent répétés, JSON peut en fait être plus petit.

En pratique, si la taille du fichier est une vraie préoccupation, les deux formats se compriment extrêmement bien avec gzip — les noms de clés répétitifs en JSON et les valeurs de lignes répétées en CSV se compriment tous les deux fortement. Servir du JSON gzippé via HTTP est une pratique courante, et la différence de taille devient généralement négligeable après compression.

Comparaison des outils

L'histoire des outils pour chaque format reflète où il est le plus utilisé.

Outils CSV : Excel, Google Sheets et LibreOffice Calc l'ouvrent nativement. La bibliothèque pandas fait de CSV le format par défaut pour l'analyse des données en Python. Chaque base de données relationnelle a une commande d'import/export CSV. Les outils en ligne de commande comme csvkit et xsv vous permettent de filtrer, joindre et agréger des fichiers CSV sans écrire de code. Le type MIME est text/csv, enregistré auprès de l'IANA.

Outils JSON : Chaque langage de programmation a un analyseur JSON intégré ou de bibliothèque standard. JSON.parse() en JavaScript, json.loads() en Python, encoding/json en Go, serde_json en Rust. La référence JSON MDN est l'une des pages les plus visitées sur MDN. En ligne de commande : jq est indispensable pour interroger et transformer JSON. Les IDE le mettent en forme et le valident automatiquement.

Si vous travaillez avec des pipelines de données qui couvrent les deux mondes — charger des réponses d'API JSON dans un entrepôt de données, ou exporter des enregistrements de base de données pour une feuille de calcul — vous convertirez régulièrement entre les deux. Le convertisseur CSV vers JSON et le convertisseur JSON vers CSV gèrent cela rapidement. Pour nettoyer les fichiers bruts avant traitement, le Formateur CSV et le Formateur JSON valent la peine d'être mis en signet.

L'hybride : JSON Lines (NDJSON)

Il y a une troisième option à connaître : JSON Lines, également appelé NDJSON (Newline-Delimited JSON). L'idée est simple — un objet JSON complet par ligne, sans tableau environnant.

json

{"id":"SHOE-001","name":"Trail Runner Pro","price":129.99,"inStock":true,"variantCount":3}
{"id":"SHOE-002","name":"City Walker","price":89.99,"inStock":true,"variantCount":2}
{"id":"SHOE-003","name":"Summit Hiker","price":159.99,"inStock":false,"variantCount":5}

Ce format vous donne le meilleur des deux mondes pour certains cas d'utilisation. Comme CSV, vous pouvez le diffuser et le traiter ligne par ligne sans charger tout le fichier en mémoire — critique pour les gros fichiers de journaux ou les sorties de pipeline de données. Comme JSON, chaque ligne peut avoir un schéma différent et préserve les types. Vous pouvez utiliser les outils Unix standard (grep, wc -l, head) pour travailler avec, mais aussi passer chaque ligne à travers jq pour des requêtes structurées.

NDJSON est largement utilisé pour l'agrégation de journaux (c'est le format de sortie par défaut pour de nombreux journaliseurs structurés), les étapes de pipeline de données et les exports de données d'entraînement ML. Si vous écrivez un script qui traite des millions d'enregistrements et que chaque enregistrement est un objet JSON, NDJSON est généralement le bon choix par rapport à un grand tableau JSON — vous évitez de charger tout en mémoire et vous pouvez reprendre à partir d'un point de contrôle facilement.

python

import json

# Process a large NDJSON file without loading it all into memory
with open('products.ndjson', 'r') as f:
    for line in f:
        product = json.loads(line.strip())
        if product['inStock'] and product['price'] < 100:
            print(f"{product['name']} — ${product['price']}")

Guide de décision : CSV vs JSON

Voici la version pratique. Quand vous choisissez entre les deux, posez-vous ces questions :

Vos données sont-elles genuinement plates (pas d'imbrication, pas de tableaux) ? Si oui, CSV est plus simple. Sinon, JSON.
Un non-développeur consommera-t-il ce fichier ? Des analystes dans Excel ? Des utilisateurs business dans Google Sheets ? Utilisez CSV.
Servez-vous ou consommez-vous une API HTTP ? Utilisez JSON. Point final.
Faites-vous un import ou export en masse de base de données ? Utilisez CSV — chaque base de données le supporte nativement.
Les données ont-elles des types mixtes (booléens, nombres, nulls) ? Utilisez JSON pour éviter les bugs d'inférence de type du côté récepteur.
Le fichier sera-t-il traité ligne par ligne dans un pipeline de streaming ? Considérez NDJSON comme un compromis.
Stockez-vous une configuration ? Utilisez JSON (ou YAML si les commentaires vous importent).
Le schéma doit-il varier par enregistrement ? JSON. CSV impose les mêmes colonnes sur chaque ligne.

Le défaut honnête : Si vous construisez quelque chose pour que d'autres développeurs ou des machines le consomment, utilisez JSON. Si vous remettez des données à un humain qui les ouvrira dans une feuille de calcul, utilisez CSV. Si vous construisez un pipeline de données qui traite des millions d'enregistrements structurés, considérez NDJSON.

Conclusion

CSV et JSON ne sont pas vraiment en concurrence — ils résolvent des problèmes différents. CSV est le bon outil quand vos données sont une table et que vous voulez une compatibilité maximale avec les outils de feuilles de calcul et de bases de données. JSON est le bon outil quand vos données ont de la structure, des types ou de l'imbrication, et quand vous parlez à des API ou des applications.

La décision n'est généralement pas difficile une fois que vous regardez la forme réelle des données. Des lignes plates de relevés de capteurs ? CSV. Une réponse API avec des profils d'utilisateurs imbriqués et des historiques de commandes intégrés ? JSON. Un flux de journaux d'événements structurés ? NDJSON. Faites correspondre le format à la forme des données et aux outils des deux côtés, et vous ferez rarement fausse route.

← All CSV articles Browse all categories →