Json To Csv LogoJson To Csv

Comment aplatir JSON en CSV : ce que fait vraiment l’interrupteur (Guide 2026)

Aplatir, c’est transformer du JSON imbriqué en lignes taillées pour un tableur : les objets deviennent des colonnes en notation pointée, les listes se rejoignent ou se sérialisent, les vides suivent des règles précises. Voici ce que fait vraiment l’interrupteur, cellule par cellule, vérifié contre le moteur réel.

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

Pourquoi le JSON résiste à l’aplatissement : des arbres contre des grilles

Un CSV, c’est une grille : des lignes et des colonnes, chaque cellule contenant une seule valeur plate. Le JSON, c’est un arbre : des objets dans des objets, des listes dans des objets, des objets dans des listes. Aplatir, c’est la traduction entre ces deux formes, et c’est la seule partie de la conversion JSON vers CSV où un convertisseur doit prendre des décisions à ta place — parce qu’il n’existe pas de réponse unique \"correcte\".

Prends l’enregistrement imbriqué le plus simple : { \"id\": 1, \"customer\": { \"name\": \"Ana\", \"city\": \"Madrid\" } }. Une grille n’a aucun moyen de contenir un \"customer\" qui contient deux choses à la fois. Le convertisseur doit donc choisir : donner à customer sa propre colonne et y fourrer l’objet sous forme de texte, ou éclater l’objet en colonnes customer.name et customer.city. Tous les convertisseurs prennent cette décision avec la même poignée de règles — et une fois que tu les connais, tu peux prédire ton CSV avant même de cliquer sur convertir.

L’exemple fil rouge que nous allons aplatir

Tout ce qui suit est démontré sur un seul fichier — trois commandes avec trois niveaux d’imbrication, une liste de valeurs simples, une liste vide, un objet vide, un null et une liste d’objets. Nous avons passé ce fichier exact dans le vrai moteur de conversion de ce site (le même JavaScript qui s’exécute quand tu appuies sur Convertir), et chaque sortie affichée est bien ce que le moteur a réellement produit :

orders-nested.json
[
  { "orderId": "A-101", "customer": { "name": "Ana Ruiz", "contact": { "email": "ana@example.com", "city": "Madrid" } }, "items": ["book", "pen"], "tags": [], "meta": {} },
  { "orderId": "A-102", "customer": { "name": "Ken Sato", "contact": { "email": "ken@example.com", "city": "Osaka" } }, "items": ["lamp"], "tracking": [{ "code": "TX-1", "status": "shipped" }, { "code": "TX-2", "status": "pending" }] },
  { "orderId": "A-103", "customer": { "name": "Lina Noor", "contact": { "email": null, "city": "Berlin" } }, "items": ["mug", null, "plate"] }
]

Règle n°1 : les objets imbriqués deviennent des colonnes en notation pointée

La première et la plus importante des règles : chaque niveau d’imbrication d’objet devient un nom de colonne avec les niveaux reliés par des points. customer.contact.email, ce ne sont pas trois colonnes — c’est une seule colonne dont le nom est le chemin complet dans l’arbre. Voici la sortie réelle du moteur avec l’aplatissement activé :

CSV output — flattening ON (verified against the real engine)
orderId,customer.name,customer.contact.email,customer.contact.city,items,tags,meta,tracking
A-101,Ana Ruiz,ana@example.com,Madrid,book; pen,,{},
A-102,Ken Sato,ken@example.com,Osaka,lamp,,,"[{""code"":""TX-1"",""status"":""shipped""},{""code"":""TX-2"",""status"":""pending""}]"
A-103,Lina Noor,,Berlin,mug; ; plate,,,

La profondeur d’imbrication n’a pas de limite pratique dans la règle elle-même — nous avons aussi testé un objet à quatre niveaux ({ a: { b: { c: { d: \"deep\" } } } }) et le moteur a produit une seule colonne nommée a.b.c.d avec la valeur deep. Les noms pointés se trient et se filtrent normalement dans un tableur ; tu peux renommer les en-têtes après coup en une passe si customer.contact.city est trop long à ton goût.

Règle n°2 : les listes de valeurs simples se rejoignent en une seule cellule

Quand une liste ne contient que des valeurs simples — chaînes, nombres, booléens, nulls — toute la liste s’effondre en une seule cellule avec les valeurs reliées par \"; \" (point-virgule-espace). Regarde la colonne items ci-dessus : [\"book\", \"pen\"] est devenue la cellule unique book; pen, et [\"mug\", null, \"plate\"] est devenue mug; ; plate — le null s’est transformé en segment vide, et non en segment sauté.

Deux conséquences pratiques. D’abord, si tu choisis ensuite le point-virgule comme délimiteur CSV, cette cellule jointe est automatiquement mise entre guillemets (\"book; pen\") pour que le séparateur à l’intérieur de la cellule ne puisse pas la couper — le moteur applique les règles de guillemets CSV cellule par cellule, vérifié dans le test ci-dessus. Ensuite, la jointure perd l’information de découpage : après aplatissement, book; pen est du texte, plus une liste. Si tu as besoin de redécouper les items en lignes, voir la règle n°3.

Règle n°3 : les listes d’objets s’effondrent en une seule cellule de texte JSON

C’est la règle qui surprend les gens. Quand une liste contient des objets — comme le tableau tracking avec ses entrées { code, status } — elle ne peut pas devenir des colonnes (les objets ont une structure, pas juste des valeurs) et elle ne peut pas se rejoindre comme des valeurs simples. Le moteur stocke donc toute la liste sous forme de cellule de texte JSON entre guillemets. Ci-dessus, la colonne tracking pour A-102 contient le tableau JSON complet en texte, échappé selon les règles CSV.

Est-ce une limitation ? Honnêtement : oui, pour cette forme-là. Aucun interrupteur d’expansion de lignes n’existe dans ce convertisseur — il ne crée jamais une ligne CSV par élément de liste. Si tu as vraiment besoin d’une ligne par événement de tracking, restructure avant de convertir : sors le tableau interne (convertis [{ \"code\": \"TX-1\", \"status\": \"shipped\" }, ...] tout seul) et tu obtiens des lignes code/status propres. Une colonne de texte JSON, c’est l’alternative honnête à inventer silencieusement des lignes que tu n’avais pas demandées.

Règle n°4 : les vides et les nulls suivent des règles exactes

Les nulls et les vides, c’est là que commence la plupart des \"pourquoi mon CSV est bizarre\", alors voici les comportements vérifiés, sans devinettes :

  • Une valeur null devient une cellule vide. Le email: null de Lina Noor a produit une cellule vide sous customer.contact.email — pas de texte \"null\", pas de guillemets.
  • Une liste vide devient une cellule vide. Le tags: [] de A-101 a laissé la cellule blanche. (Note : c’est le comportement avec aplatissement ACTIVÉ ; avec l’aplatissement désactivé, la même liste apparaît comme le texte littéral [].)
  • Un objet vide devient le texte {}. Le meta: {} de A-101 a produit une cellule contenant {} — le moteur n’a rien à développer, alors il écrit la forme littérale de l’objet.
  • Un null à l’intérieur d’une liste devient un segment joint vide — mug; ; plate ci-dessus — plutôt qu’être sauté ou écrit comme \"null\".

Ce sont des choix de conception, pas une loi universelle, mais ils sont cohérents : null veut dire \"rien ici\", et le CSV ne dit rien.

Aplatissement ACTIVÉ contre DÉSACTIVÉ, octet pour octet

Même fichier, aplatissement désactivé. Chaque clé de premier niveau garde sa propre colonne et les structures imbriquées sont stockées sous forme de texte JSON entre guillemets :

CSV output — flattening OFF (verified against the real engine)
orderId,customer,items,tags,meta,tracking
A-101,"{""name"":""Ana Ruiz"",""contact"":{""email"":""ana@example.com"",""city"":""Madrid""}}","[""book"",""pen""]",[],{},
A-102,"{""name"":""Ken Sato"",""contact"":{""email"":""ken@example.com"",""city"":""Osaka""}}","[""lamp""]",,,"[{""code"":""TX-1"",""status"":""shipped""},{""code"":""TX-2"",""status"":""pending""}]"
A-103,"{""name"":""Lina Noor"",""contact"":{""email"":null,""city"":""Berlin""}}","[""mug"",null,""plate""]",,,

Note les détails du mode désactivé : les colonnes se réduisent aux clés de premier niveau (customer, items, tags, meta, tracking), chaque valeur imbriquée est du JSON brut sérialisé avec le doublement des guillemets CSV, et la liste vide et l’objet vide apparaissent comme le texte littéral [] et {}. Désactivé, c’est la représentation honnête-mais-moche — juste quand tu dois préserver la structure imbriquée exacte (par exemple avant de réinjecter les lignes dans un système qui attend des champs en forme de JSON). Pour l’analyse — filtres, tableaux croisés dynamiques, graphiques — l’aplatissement activé est le bon choix, et c’est pour ça que c’est le réglage par défaut.

D’où viennent les lignes : tableaux, enveloppes d’API et JSON Lines

L’aplatissement décide des colonnes ; autre chose décide des lignes. Le moteur regarde ta valeur de premier niveau et suit trois cas :

Cas n°1 : ton premier niveau est un tableau d’objets — chaque objet devient une ligne. C’est l’exemple des commandes ci-dessus : trois objets, trois lignes. Cas n°2 : ton premier niveau est un seul objet — tu obtiens une seule ligne. Le cas n°3 est le plus utile : ton premier niveau est un objet qui enveloppe un tableau, comme le font les réponses d’API — { \"data\": [ ... ], \"total\": 2 }. Le moteur détecte le tableau interne (il vérifie des clés d’enveloppe courantes comme data, results, users, items) et fait de chaque élément une ligne, en écartant les champs de l’enveloppe. Nous l’avons vérifié : { \"data\": [{ \"a\": 1, \"b\": 2 }, { \"a\": 3, \"b\": 4 }], \"total\": 2 } a produit exactement les deux lignes de data avec les colonnes a et b — total a disparu.

Une autre forme d’entrée à connaître : le moteur accepte aussi le JSON Lines (NDJSON) — un objet JSON par ligne. Si ton export fait dix mille lignes au lieu d’un grand tableau, colle-le tel quel ; la conversion fonctionne pareil.

Données irrégulières : les clés manquantes laissent juste des cellules vides

Les exports réels sont irréguliers : la commande A-102 a tracking mais pas meta, A-101 a meta mais pas tracking, A-103 n’a ni l’un ni l’autre. Le moteur construit la liste des colonnes comme l’union de chaque clé trouvée dans chaque ligne, dans l’ordre — donc la ligne d’en-tête ci-dessus a bien les huit colonnes — et toute ligne à qui il manque une clé obtient simplement une cellule vide en dessous.

C’est pour ça que les en-têtes sortent dans l’ordre d’insertion (orderId d’abord, puis les premières clés imbriquées rencontrées) plutôt qu’en ordre alphabétique : les colonnes suivent la forme de tes données au fur et à mesure que le moteur les parcourt. Si une ligne plus loin introduit un tout nouveau chemin imbriqué, la colonne apparaît quand même — rien n’est silencieusement abandonné.

Trois cas limites qui piquent

Premier : les clés qui contiennent déjà des points. Si ton JSON a à la fois une clé littérale \"user.name\" et un objet imbriqué user: { name: ... }, les deux veulent la même colonne. Nous l’avons testé : la valeur imbriquée gagne et la valeur de la clé littérale est perdue ([{ \"user.name\": \"x\", user: { name: \"y\" } }] a produit une seule colonne user.name contenant y). Renomme les clés pointées avant de convertir si les deux valeurs comptent.

Deuxième : les listes à types mixtes. Une liste comme [1, \"a\", { \"b\": 2 }] n’est pas \"que des primitives\", donc le moteur la traite comme une liste d’objets et sérialise le tout en une seule cellule de texte JSON — même si la plupart était simple. Garde tes listes homogènes si tu veux le comportement de jointure avec \"; \".

Troisième : l’imbrication profonde passe, mais surveille les noms de colonnes. Dix niveaux d’imbrication te donnent un nom de colonne pointé en dix parties, ce qui est techniquement correct et pratiquement illisible. Aplatis tout, puis renomme les trois colonnes qui t’intéressent vraiment.

La checklist d’aplatissement en 30 secondes

Si tu ne retiens rien d’autre : laisse l’aplatissement activé pour l’analyse, désactive-le seulement pour préserver la structure ; attends-toi à des colonnes en notation pointée et à des listes jointes par \"; \" ; sors les listes d’objets et convertis-les séparément quand tu veux une ligne par élément ; et considère les cellules vides comme la représentation honnête des nulls — pas comme des erreurs. L’interrupteur ne prend qu’un clic, mais maintenant tu sais exactement ce que ce clic fait.

Guides liés

Questions fréquentes

Que veut dire aplatir du JSON en CSV ?

Aplatir, c’est l’étape qui transforme du JSON imbriqué en une grille de tableur plate : les objets imbriqués deviennent des colonnes en notation pointée (customer.contact.city), les listes de valeurs simples se rejoignent en une seule cellule avec "; ", et les listes d’objets s’effondrent en une seule cellule de texte JSON. Sans aplatissement, les valeurs imbriquées sont stockées sous forme de texte JSON brut entre guillemets, une colonne chacune.

Comment aplatir des objets JSON imbriqués en colonnes CSV ?

Utilise un convertisseur avec une option d’aplatissement et laisse-la activée — les objets imbriqués sont développés en colonnes à notation pointée automatiquement, à n’importe quelle profondeur (customer.contact.email, ou même a.b.c.d). Sur le convertisseur de ce site, l’aplatissement est le réglage par défaut : colle ou téléverse ton JSON, convertis, et chaque chemin imbriqué devient sa propre colonne triable et filtrable.

Que deviennent les tableaux quand on aplatit du JSON en CSV ?

Ça dépend de ce que contient le tableau. Les listes de valeurs simples (chaînes, nombres) se rejoignent en une seule cellule avec "; " — ["book", "pen"] devient book; pen. Les listes d’objets sont stockées en une seule cellule de texte JSON entre guillemets, parce que les objets ne peuvent pas devenir des valeurs plates. Les listes vides deviennent des cellules vides. Les listes mixtes sont sérialisées en entier, alors garde des listes homogènes pour des résultats prévisibles.

Pourquoi mon CSV aplati a-t-il autant de cellules vides ?

Les cellules vides sont normales et honnêtes : une valeur null devient une cellule vide, une liste vide devient une cellule vide, et quand les lignes ont des clés différentes (données irrégulières), les clés manquantes laissent des blancs. Vérifie si les vides correspondent à des nulls dans ton JSON source — si oui, la conversion est correcte.

Faut-il activer ou désactiver l’aplatissement pour convertir du JSON en CSV ?

Laisse-le activé pour l’analyse — les colonnes en notation pointée sont ce dont les tableaux croisés dynamiques, les filtres et les graphiques ont besoin. Désactive-le seulement quand tu dois préserver la structure imbriquée exacte, par exemple avant de réinjecter les lignes dans un système qui attend des champs en forme de JSON. Le mode désactivé stocke chaque valeur imbriquée sous forme de texte JSON brut entre guillemets, ce qui est correct mais inutilisable pour un tableur.

Peut-on obtenir une ligne CSV par élément d’un tableau imbriqué d’objets ?

Ce convertisseur ne développe pas les listes d’objets en lignes — il les stocke en une seule cellule de texte JSON. La solution fiable : extrais le tableau interne et convertis-le tout seul (par exemple convertis juste [{"code":"TX-1"},{"code":"TX-2"}]) pour obtenir une sortie propre avec une ligne par élément. Fais l’extraction avant de convertir, pas après.

Existe-t-il un outil gratuit pour aplatir du JSON en CSV en ligne ?

Oui — le convertisseur de ce site est gratuit, ne demande aucune inscription, et aplatit le JSON imbriqué par défaut (colonnes en notation pointée, listes jointes avec "; ") entièrement dans ton navigateur, donc tes données ne quittent jamais ton appareil. Téléverse un fichier ou colle du JSON, laisse l’aplatissement activé, choisis ton délimiteur, et télécharge le CSV.

Tu as du JSON imbriqué ? Aplatis-le maintenant — rien à installer

Colle ton JSON imbriqué ou téléverse le fichier : les objets deviennent des colonnes en notation pointée, les listes se rejoignent proprement, et la conversion tourne entièrement dans ton navigateur. Gratuit, sans inscription.

Ouvrir le convertisseur JSON vers CSV
Tous les guides