Json To Csv LogoJson To Csv

Qu'est-ce qu'un fichier JSON et CSV ? Guide débutant des deux formats (Guide 2026)

JSON et CSV sont tous deux du texte brut, mais ils stockent les données dans des formes totalement différentes. Ce guide montre les deux formats côte à côte sur les mêmes données, explique les cinq différences qui comptent, et vérifie exactement ce qu'une conversion JSON vers CSV conserve et ce qu'elle abandonne silencieusement.

Mis à jour: 2026-10-219 min de lecture

À quoi ressemble vraiment un fichier JSON

Voici un vrai fichier JSON : deux fiches clients. Lisez-le lentement une fois, car tous les concepts de ce guide y reviennent.

Le fichier entier est un tableau, marqué par des crochets [ ], qui contient deux objets. Chaque objet, marqué par des accolades { }, est un enregistrement. Dans un objet, les données vivent en paires clé-valeur : "id": 101 signifie que la clé "id" contient la valeur 101, et les clés sont toujours des chaînes entre guillemets.

Les valeurs conservent leurs types, et c'est l'un des super-pouvoirs de JSON. "Amelia Chen" est une chaîne (du texte, entre guillemets). 101, 2023 et 4 sont des nombres (sans guillemets). true et false sont des booléens. null est un "pas de valeur ici" explicite, ce qui est différent d'une chaîne vide : lastNote vaut null pour Amelia, ce qui signifie que le champ existe mais n'a pas de valeur, tandis que le lastNote de Bruno contient le texte "Call, don't email".

Vient ensuite l'imbrication, la raison d'être de JSON. "address" est un objet à l'intérieur de l'objet client, avec ses propres clés city et state. "tags" est un tableau à l'intérieur de l'objet client, qui contient deux chaînes. JSON s'imbrique à volonté : des objets dans des tableaux dans des objets, aussi loin que vont vos données. Les espaces sont sans importance, donc la version joliment indentée ci-dessus et une version minifiée sur une seule ligne sont les mêmes données. Une bizarrerie à connaître : si une clé apparaît deux fois dans un même objet, la dernière valeur gagne et la première est perdue silencieusement. Vérifié avec JSON.parse sur la machine de compilation : {"a":1,"a":2} donne 2. Cela arrive rarement en pratique, mais quand cela arrive, rien ne vous prévient.

customers.json : deux enregistrements imbriqués
[
  {
    "id": 101,
    "name": "Amelia Chen",
    "email": "amelia@example.com",
    "vip": true,
    "signupYear": 2023,
    "address": { "city": "Austin", "state": "TX" },
    "orders": 4,
    "tags": ["newsletter", "referral"],
    "lastNote": null
  },
  {
    "id": 102,
    "name": "Bruno Almeida",
    "email": "bruno@example.com",
    "vip": false,
    "signupYear": 2024,
    "address": { "city": "São Paulo", "state": "SP" },
    "orders": 1,
    "tags": ["newsletter"],
    "lastNote": "Call, don't email"
  }
]

À quoi ressemble vraiment un fichier CSV

Voici maintenant les mêmes deux enregistrements en CSV. Cette sortie a été produite par le convertisseur de cette page à partir du fichier JSON ci-dessus, avec l'aplatissement activé : ce que vous voyez est donc exactement ce que fait la conversion, pas une illustration.

La première ligne est la ligne d'en-tête : les noms des colonnes. Chaque ligne suivante est un enregistrement, avec les valeurs dans le même ordre, séparées par des virgules. C'est tout le format : en-tête, lignes, délimiteur. Dix colonnes, deux lignes, aucune imbrication nulle part.

Tout est du texte désormais, et c'est le trait distinctif du CSV. 101, true et 2023 ressemblent à un nombre et à des booléens, mais le fichier ne le sait pas : ce sont des caractères, et c'est le programme qui ouvre le fichier qui décide ce qu'ils signifient. La cellule vide à la fin de la ligne d'Amelia, c'est son lastNote null : null est devenu rien. Ses deux étiquettes sont devenues une seule cellule, "newsletter; referral", jointes par "; ". Et la note de Bruno est entourée de guillemets, "Call, don't email", parce qu'elle contient une virgule : les guillemets sont la façon dont CSV protège une valeur qui contient le délimiteur.

L'objet address est devenu deux colonnes, address.city et address.state. Cet aplatissement en notation pointée est exactement ce que font les convertisseurs, et notre guide sur l'aplatissement explique en détail l'interrupteur qui se cache derrière. Remarquez ce que le CSV ne peut plus dire : que city et state appartenaient à un même objet address, ni que newsletter et referral étaient deux étiquettes distinctes plutôt qu'une seule chaîne avec un point-virgule. La forme a disparu. Les valeurs restent.

Les mêmes deux enregistrements en CSV (sortie vérifiée du convertisseur)
id,name,email,vip,signupYear,address.city,address.state,orders,tags,lastNote
101,Amelia Chen,amelia@example.com,true,2023,Austin,TX,4,newsletter; referral,
102,Bruno Almeida,bruno@example.com,false,2024,São Paulo,SP,1,newsletter,"Call, don't email"

Les cinq différences entre un fichier JSON et un fichier CSV qui comptent vraiment

Mêmes données, deux philosophies. Cinq différences décident du format à choisir, et elles expliquent presque tous les débats "lequel utiliser" que vous entendrez.

Premièrement, la forme : JSON est un arbre, CSV est un tableau. JSON peut contenir une commande qui contient un client qui contient une adresse qui contient une liste d'articles, en s'imbriquant aussi profondément que la réalité l'exige. CSV n'a qu'un seul niveau : des lignes et des colonnes. Tout ce qui est plus profond doit être aplati en colonnes en notation pointée ou sérialisé en texte dans une cellule, et dans les deux cas la structure d'origine n'est plus vraiment là.

Deuxièmement, les types : JSON distingue le nombre 2023 du texte "2023", et le booléen true de la chaîne "true". CSV stocke des caractères ; l'interprétation vient après, dans le programme qui ouvre le fichier. C'est pourquoi la chaîne "007" arrive dans un CSV sous la forme des caractères 007 (vérifié avec le convertisseur de cette page), alors qu'un tableur peut quand même l'afficher comme 7 quand vous ouvrez le fichier : le CSV a fidèlement conservé le texte, et Excel a ajouté sa propre interprétation par-dessus. Le format a fait son travail ; le visualiseur a ajouté une opinion.

Troisièmement, le schéma : JSON se décrit lui-même. Chaque enregistrement porte ses propres clés, donc les enregistrements peuvent différer : un client peut avoir un champ "notes" que les autres n'ont pas, et le fichier reste parfaitement valide. Le schéma du CSV vit dans la ligne d'en-tête et suppose l'uniformité. Une ligne avec une valeur en trop n'a nulle part où la ranger de façon documentée, et des données irrégulières, où les lignes portent des champs différents, deviennent un casse-tête d'alignement de colonnes au lieu d'un non-problème.

Quatrièmement, l'édition à la main : JSON punit les petites erreurs bruyamment. Une virgule ou un guillemet manquant rend le fichier entier invalide, ce qui est agaçant mais honnête, et c'est pour cela que les validateurs JSON existent. CSV punit les petites erreurs silencieusement. Une virgule non protégée par des guillemets à l'intérieur d'une valeur décale toutes les colonnes suivantes, et le fichier s'ouvre quand même, juste faux. Quand vous éditez à la main, un échec bruyant vaut mieux qu'une corruption silencieuse.

Cinquièmement, les producteurs : les formats suivent leurs producteurs. Les API, les applications, les bases de données et les journaux émettent du JSON parce qu'ils pensent en structures imbriquées typées. Les tableurs, les exports métier et les pièces jointes d'e-mails sont en CSV parce que les humains pensent en tableaux. Quand quelqu'un vous tend un fichier, son format vous dit généralement de quel monde il vient, et la conversion est la façon dont les deux mondes se parlent.

Ce que fait vraiment une conversion d'un fichier JSON vers un fichier CSV

Convertir, c'est aplatir : projeter l'arbre sur un tableau. Chaque affirmation de cette section a été vérifiée sur la machine de compilation avec le moteur de conversion exact qu'exécute cette page : ce sont donc les vraies règles, pas des règles idéalisées.

Avec l'aplatissement activé, le moteur applique six règles. Les objets imbriqués deviennent des colonnes en notation pointée : address.city, address.state. Les listes de valeurs simples deviennent une seule cellule jointe par "; " : newsletter et referral sont devenus "newsletter; referral". Null devient une cellule vide. Une liste vide devient aussi une cellule vide, ce qui signifie que null et une liste vide sont indiscernables après conversion. Un objet vide devient le texte littéral {}. Les nombres et les booléens deviennent leurs formes textuelles : 2023 devient les caractères "2023".

La sixième règle couvre le cas délicat : une liste d'objets. Il n'y a pas de façon sensée de joindre des objets avec un séparateur, donc le moteur stocke la liste en texte JSON à l'intérieur de la cellule, avec ses guillemets doublés. Testé sur un enregistrement de test : un objet vide, une liste vide, un null, une imbrication à trois niveaux et une liste d'objets ont produit exactement ceci :

Avec l'aplatissement désactivé, le moteur fait plus simple et moins utile : chaque valeur imbriquée reste en texte JSON dans sa cellule. Le même objet address devient le texte de cellule {"city":"Austin"}, guillemets doublés. Mêmes valeurs, bien moins utilisable comme tableau. Notre guide sur l'aplatissement explique quand chaque réglage est le bon choix.

Encore une règle silencieuse, qui se produit avant même le début de la conversion. Parce que JSON.parse conserve la dernière valeur quand une clé se répète, un enregistrement comme {"code":"A1","code":"B2"} se convertit avec seulement B2. La première valeur a disparu avant que le convertisseur ne voie les données. Rare en pratique, bon à savoir une fois pour toutes.

Cas limites passés dans le vrai moteur (aplatissement activé)
a,b,c,d.e.f,g
{},,,1,"[{""h"":1},{""h"":2}]"

Ce qui survit à la conversion d'un fichier JSON en CSV, et ce qui ne survit pas

Ce qui survit : chaque valeur feuille, en texte. Noms, nombres, dates, notes, adresses e-mail : tout est présent dans le CSV, tout est correct. Si votre question est "ai-je perdu une information que j'ai saisie", la réponse est non. Pour un tableur, un assistant d'importation ou un rapide examen humain, rien de ce dont vous avez besoin ne manque.

Ce qui ne survit pas : les types, d'abord. Le nombre 2023 et le texte "2023" sont identiques en CSV ; true et "true" sont identiques aussi. Le programme qui lira le CSV devinera, et les suppositions varient : Excel transforme notoirement le texte "007" en nombre 7 et "1-2" en date. Ensuite, la forme imbriquée : address.city ne sait plus qu'il a jamais été un objet, et "newsletter; referral" ne sait plus qu'il s'agissait de deux étiquettes. Troisièmement, les clés dupliquées : seule la dernière valeur survit. Quatrièmement, la distinction entre null et une liste vide : les deux deviennent une cellule vide, donc "pas de valeur" et "une liste qui ne contient rien" fusionnent en un seul.

Cela crée le problème du désaplatissement : convertir en sens inverse, c'est deviner. Est-ce que "newsletter; referral" était deux étiquettes ou une seule chaîne qui contenait par hasard un point-virgule ? Est-ce que address.city a jamais été un objet, ou la clé s'est-elle toujours appelée littéralement "address.city" ? Un convertisseur peut deviner, mais le CSV ne s'en souvient pas. La règle de bon sens : gardez le JSON comme source de vérité, et générez le CSV chaque fois que vous avez besoin de la vue tableau. Le stockage est bon marché. Reconstituer la forme ne l'est pas.

Quel format choisir : un fichier JSON ou un fichier CSV ?

Choisissez JSON quand les données ont une forme ou quand le public est un programme. Des données qui vont vers ou viennent d'une API, d'une application ou d'une base de données. Des enregistrements imbriqués ou irréguliers où les lignes ne se ressemblent pas toutes. Des valeurs dont les types doivent survivre, comme des prix en nombres et des indicateurs en booléens. Les journaux, les configurations, et tout ce que du code va traiter. Si vous pourriez avoir besoin de retrouver la structure plus tard, JSON est le seul foyer sûr.

Choisissez CSV quand le public est un humain ou un outil en forme de tableau. Quelqu'un va l'ouvrir dans Excel ou Google Sheets. Vous envoyez des données par e-mail à un collègue non technique. L'outil cible attend des lignes et des colonnes : tableaux de bord BI, assistants d'importation, outils d'envoi de listes de diffusion. Les données sont vraiment plates, et vous voulez le fichier le plus petit : mesuré sur la machine de compilation, 1 000 lignes clients uniformes pesaient 111 433 octets en JSON contre seulement 48 473 octets en CSV, moins de la moitié, parce que JSON répète chaque nom de clé dans chaque ligne. Pour les données imbriquées, la comparaison s'effondre, puisque CSV ne peut pas contenir d'imbrication sans contournements, mais pour les tableaux plats, CSV gagne sur la taille à chaque fois.

La combinaison pratique que la plupart des équipes adoptent : stocker et échanger en JSON, exporter en CSV à la demande. Gardez l'original riche ; générez la copie de travail plate chaque fois que quelqu'un en a besoin. Le convertisseur de cette page existe exactement pour cette deuxième étape, et notre guide des méthodes couvre les trois façons fiables de le faire : le convertisseur en ligne, Power Query d'Excel, et Python.

Passer d'un fichier JSON à un fichier CSV, et inversement

JSON vers CSV est le trajet pour lequel ce site est construit : collez ou téléversez votre JSON sur le convertisseur en haut de cette page, sans inscription, et la conversion s'exécute entièrement dans votre navigateur, donc vos données ne quittent jamais votre machine. Pour un travail répétable ou scripté, notre guide de conversion détaille la même tâche dans Power Query d'Excel et en Python.

CSV vers JSON est le trajet retour, avec l'avertissement honnête de la section précédente : les types doivent être devinés sur le chemin du retour, parce que le CSV ne les a jamais stockés. Notre guide inverse couvre la conversion et montre où les suppositions peuvent se tromper, pour que vous puissiez les vérifier au lieu de leur faire confiance.

Guides associés

Questions fréquentes

JSON et CSV, est-ce la même chose ?

Non. JSON stocke des données imbriquées et typées sous forme d'objets et de tableaux ; CSV stocke des tableaux plats sous forme de lignes de texte. Ils résolvent des problèmes différents : JSON sert aux données structurées que les programmes échangent, CSV sert aux tableaux que les humains ouvrent dans des tableurs. On les convertit constamment l'un vers l'autre, et c'est pourquoi les deux formats refusent de mourir.

Un fichier CSV peut-il contenir des données imbriquées comme un fichier JSON ?

Pas nativement. Un CSV n'a que des lignes et des colonnes, rien de plus profond : l'imbrication doit donc être aplatie (un objet address devient les colonnes address.city et address.state) ou emballée dans une seule cellule en texte JSON. Les deux contournements perdent la forme d'origine, c'est pourquoi vous gardez le JSON chaque fois que l'imbrication compte. Notre guide sur l'aplatissement montre exactement ce que l'interrupteur d'aplatissement fait aux données imbriquées.

Convertir un fichier JSON en CSV fait-il perdre des données ?

Cela fait perdre la forme, pas les valeurs. Chaque valeur feuille survit en texte, mais les types s'effondrent (nombres et booléens deviennent du texte), l'imbrication s'aplatit en colonnes en notation pointée, les clés dupliquées ne gardent que la dernière valeur, et null comme les listes vides deviennent des cellules vides. Pour un tableur ou une importation, rien de ce dont vous avez besoin ne manque. Pour reconvertir en JSON, gardez le fichier d'origine.

Quel est le plus petit : un fichier JSON ou un fichier CSV ?

Pour des données plates et uniformes, le CSV est généralement bien plus petit. Mesuré sur la machine de compilation : 1 000 lignes clients pesaient 111 433 octets en JSON contre seulement 48 473 octets en CSV, moins de la moitié, parce que JSON répète chaque nom de clé dans chaque ligne. Pour les données imbriquées, la comparaison s'effondre, puisque CSV ne peut pas contenir d'imbrication sans la dupliquer ou la sérialiser. Choisissez selon la forme, pas selon la taille.

Excel peut-il ouvrir un fichier JSON ?

Pas directement comme un tableur. Les chemins fiables : convertissez d'abord le JSON en CSV et ouvrez-le, ou utilisez Power Query (Données > Obtenir des données > À partir d'un fichier > À partir de JSON), qui importe correctement JSON dans Excel. Notre guide de conversion de fichiers détaille le chemin Power Query étape par étape.

Un fichier JSON est-il lisible par un humain ?

Oui, c'est du texte brut, et un petit JSON joliment indenté se lit bien. La lisibilité s'effondre avec la taille et la profondeur : un export minifié sur une seule ligne est techniquement lisible et pratiquement hostile. Pour les gros fichiers, joliment indentez d'abord avec un formateur, ou convertissez en CSV et parcourez le tableau à la place.

Pourquoi les API renvoient-elles du JSON plutôt que du CSV ?

Parce que les données d'API sont rarement un tableau plat. Les réponses s'imbriquent (un utilisateur a une adresse, qui a des coordonnées), mélangent les types (nombres, booléens, nulls) et varient d'un enregistrement à l'autre : tout ce que JSON gère et que CSV ne peut pas. CSV brille quand les données sont déjà un tableau et que le public est un humain ; JSON brille quand les données ont une forme et que le public est un programme.

Transformez JSON en CSV dans un seul onglet

Maintenant que vous connaissez les deux formats, convertissez-les ici : collez du JSON, téléchargez du CSV. Gratuit, sans inscription, fonctionne entièrement dans votre navigateur.

Ouvrir le convertisseur JSON en CSV
Tous les guides