Comment aplatir un JSON imbriqué en CSV : 5 stratégies et matrice de décision

Un problème de géométrie

Vous butez à chaque fois sur le même mur. Une API renvoie du JSON imbriqué, et l’analyste sur Slack ne veut qu’un tableur. mongoexport produit des enveloppes $oid et trois niveaux de métadonnées, tandis que BigQuery attend une table plate. Aplatir un JSON imbriqué en CSV n’est pas un problème de syntaxe. C’est un problème de géométrie. JSON est un arbre, CSV est une grille, et vous ne pouvez pas faire entrer un arbre dans une grille sans choisir comment les branches s’effondrent.

Il existe exactement cinq stratégies d’effondrement. Choisissez la mauvaise et vous livrerez 200 colonnes à Excel, perdrez de la précision sur un identifiant Twitter, ou casserez l’aller-retour dont dépend votre pipeline. Choisissez la bonne et la conversion tient en une ligne.

Stratégie	Une ligne	Idéale pour
Notation pointée	customer.address.city	Analyse Excel/Sheets
Underscore	customer_address_city	Colonnes compatibles SQL
Tableaux indexés	items.0.sku, items.1.sku	Tableaux de taille fixe
Expansion de lignes	Répéter le parent pour chaque enfant	Analytique Pandas/BigQuery
Stringify	"{\"city\":\"Seattle\"}" dans une cellule	Aller-retour sans perte

Les sections qui suivent décrivent chaque stratégie, une matrice de décision indexée par consommateur (Excel, Pandas, BigQuery, Postgres) et quatre charges utiles réelles où la bonne stratégie n’est pas celle qui saute aux yeux. Pour une vue bidirectionnelle générale (bibliothèques de parseurs, streaming, pièges d’encodage), voyez le guide de conversion CSV ↔ JSON.

Pourquoi le JSON imbriqué ne tient pas dans un CSV

Le JSON porte trois types de structure qui manquent au CSV. La hiérarchie, c’est un objet à l’intérieur d’un objet. La séquence, c’est un tableau. Le mixte, c’est la combinaison : tableaux d’objets, objets avec tableaux, tableaux de tableaux. Une commande e-commerce typique combine les trois.

Le CSV a exactement deux dimensions : lignes et colonnes. Il n’y a pas de troisième axe pour dire « cette colonne contient trois enfants ». Quand vous exigez une grille à partir d’un arbre, quelque chose cède. Soit vous répartissez les enfants sur plus de colonnes (et vous vivez avec des noms comme items.0.options.0.value), soit vous les répartissez sur plus de lignes (les champs parents se répètent), soit vous les entassez dans une seule cellule sous forme de texte et cessez de les traiter comme une structure.

Chaque stratégie ci-dessous répond différemment à cette question. Certaines préservent la lisibilité et perdent la sécurité d’aller-retour. D’autres font l’inverse. Aucune n’est universelle. Adaptez la réponse à celui ou celle qui lira le fichier ensuite.

Comparatif des 5 stratégies d’aplatissement

Stratégie 1 : Notation pointée (customer.address.city)

La notation pointée parcourt l’arbre de la racine aux feuilles et utilise . pour relier les clés. Chaque objet imbriqué devient une colonne par feuille, le chemin étant encodé dans le nom de la colonne.

{ "customer": { "address": { "city": "Seattle" } }, "email": "alice@example.com" }

devient

customer.address.city,email
Seattle,alice@example.com

En Pandas, une ligne suffit :

import pandas as pd

data = [{"customer": {"address": {"city": "Seattle"}}, "email": "alice@example.com"}]
df = pd.json_normalize(data, sep='.')
df.to_csv("out.csv", index=False)

En JavaScript, une petite fonction récursive fait l’affaire :

function flattenDot(obj, prefix = '', acc = {}) {
  for (const [k, v] of Object.entries(obj)) {
    const key = prefix ? `${prefix}.${k}` : k;
    if (v && typeof v === 'object' && !Array.isArray(v)) {
      flattenDot(v, key, acc);
    } else {
      acc[key] = v;
    }
  }
  return acc;
}

Avantages : lisible par un humain, valeur par défaut de Pandas, préserve le chemin d’origine. Inconvénients : les noms de colonnes peuvent devenir longs (les specs Kubernetes produisent des noms comme spec.template.spec.containers.0.resources.limits.memory), et le point devient ambigu si une vraie clé contient un . (les paramètres d’événements Google Analytics 4, par exemple).

Stratégie 2 : Notation underscore (customer_address_city)

Même idée, séparateur différent. Remplacez . par _ et le résultat est compatible SQL : SELECT customer_address_city FROM events fonctionne sans devoir quoter l’identifiant. BigQuery, Snowflake et Postgres préfèrent tous cette forme.

import pandas as pd
df = pd.json_normalize(data, sep='_')

Le choix entre point et underscore dépend uniquement de l’outil aval. Les analystes Excel lisent le point plus naturellement ; les moteurs SQL acceptent l’underscore sans broncher. Basculez en changeant un seul argument.

Avantages : noms de colonnes compatibles SQL, identifiants conformes à BigQuery, aucun quotage requis. Inconvénients : l’ambiguïté demeure si une clé contient _ (moins courant que ., mais toujours possible).

Stratégie 3 : Tableaux indexés (items.0.sku, items.1.sku)

Les objets s’aplatissent proprement parce que les clés sont uniques. Les tableaux non, parce que la longueur n’est pas bornée. La stratégie indexée traite les positions du tableau comme des segments de chemin : items[0] devient items.0.

{ "id": "ord-001", "items": [{"sku": "A"}, {"sku": "B"}] }

devient

id,items.0.sku,items.1.sku
ord-001,A,B

C’est le comportement par défaut de Flatten dans notre Convertisseur JSON vers CSV. Chaque feuille obtient sa propre colonne ; la position est consignée dans le nom.

Avantages : chaque valeur obtient sa propre cellule, position préservée, aucune duplication de lignes. Inconvénients : le nombre de colonnes explose (100 éléments = 100 colonnes) ; des lignes avec des tableaux de longueurs différentes produisent des tables irrégulières ; l’agrégation aval est cassée (pas de SUM(items.*.qty)).

Stratégie 4 : Expansion de lignes (tableau vers plusieurs lignes)

Au lieu d’élargir la table pour accueillir le tableau, allongez-la. Répétez les champs parents une fois par élément du tableau, et laissez chaque élément devenir sa propre ligne.

{ "order_id": "ord-001", "customer": "Alice", "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}] }

devient

order_id,customer,items.sku,items.qty
ord-001,Alice,A,2
ord-001,Alice,B,1

En Pandas, une seule ligne fait à la fois l’expansion et la normalisation :

import pandas as pd

orders = [{"order_id": "ord-001", "customer": "Alice",
           "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}]}]
df = pd.json_normalize(orders, record_path='items', meta=['order_id', 'customer'])
df.to_csv("orders.csv", index=False)

En SQL, UNNEST fait la même chose :

SELECT order_id, item.sku, item.qty FROM orders, UNNEST(items) AS item;

Avantages : Pandas et BigQuery traitent cette forme nativement, les agrégations fonctionnent (GROUP BY order_id), le schéma reste étroit. Inconvénients : les champs parents se dupliquent dans chaque ligne enfant (gonflement de stockage), la frontière 1-à-plusieurs est implicite (il vous faut un order_id), et deux tableaux au même niveau produisent un produit cartésien si vous ne faites pas attention à les UNNEST séparément.

Stratégie 5 : Stringify (JSON dans une cellule)

L’option radicale : ne pas aplatir du tout. Sérialisez la valeur imbriquée entière sous forme de chaîne JSON et placez-la dans une seule cellule. La table extérieure reste plate ; la structure est préservée mot pour mot à l’intérieur.

{ "id": "ord-001", "items": [{"sku": "A"}, {"sku": "B"}] }

devient

id,items
ord-001,"[{""sku"":""A""},{""sku"":""B""}]"

C’est le mode Stringify de notre Convertisseur JSON vers CSV. Le nombre de colonnes n’explose jamais, la forme d’origine est préservée octet pour octet, et le trajet retour reconstitue l’entrée à l’identique.

Avantages : 100 % sans perte, nombre de colonnes prévisible, aller-retour sûr s’il est associé à Inférer les types au retour. Inconvénients : les utilisateurs Excel voient des guillemets échappés, les moteurs SQL ont besoin de fonctions JSON pour interroger la valeur (JSON_EXTRACT_SCALAR dans BigQuery, ->>'key' dans Postgres), et les formules de tableur ne peuvent pas atteindre l’intérieur de la cellule.

Les 5 stratégies côte à côte

Même entrée pour les cinq : {"id":"ord-001","customer":{"name":"Alice"},"items":[{"sku":"A","qty":2},{"sku":"B","qty":1}]}.

Stratégie	Colonnes	Aller-retour sûr	Meilleur consommateur
Notation pointée	croît avec le tableau	Non	Analyste Excel
Underscore	croît avec le tableau	Non	Entrepôt SQL
Tableaux indexés	2 par emplacement de tableau	Non (ambigu au retour)	Tableaux de taille fixe
Expansion de lignes	étroit, 1 ligne par enfant	Partiel (nécessite une clé)	Pandas / BigQuery
Stringify	fixe	Oui	Aller-retour pipeline

Matrice de décision : quelle stratégie pour quel consommateur

Repérez le consommateur dans la première colonne ; la stratégie recommandée suit.

Consommateur	Stratégie recommandée	Pourquoi
Excel / Sheets (analyste)	Notation pointée + Stringify pour les gros tableaux	Noms de colonnes lisibles ; les grands tableaux ne font pas exploser la feuille
Excel-EU (DE/FR/IT/ES)	Pointée + délimiteur ; + BOM UTF-8	Point-virgule requis ; le BOM évite la déformation d’encodage
Pandas (json_normalize + explode)	Underscore + Expansion de lignes	Colonnes compatibles SQL ; l’expansion s’accorde bien avec groupby
BigQuery / Snowflake	TSV + Stringify ou Expansion	La tabulation évite les pièges de guillemets ; JSON_EXTRACT interroge la cellule
PostgreSQL COPY	RFC 4180 + Underscore + plat	Colonnes compatibles SQL ; quotage RFC strict
ETL MongoDB → BigQuery	Charger directement le NDJSON, sauter le CSV	BigQuery charge nativement le NDJSON ; le CSV est un détour

Excel / Google Sheets : le piège de la locale

Les noms de colonnes Excel n’ont pas de limite de longueur pratique. Trois pièges méritent l’attention.

D’abord, le clivage des locales. L’Excel européen (Allemagne, France, Italie, Espagne) attend ; comme délimiteur parce que , est le séparateur décimal. Un CSV délimité par virgule s’ouvre avec chaque ligne effondrée dans la colonne A. Le préréglage Excel de notre outil Convertisseur JSON vers CSV bascule vers ; + CRLF + BOM UTF-8 en un clic.

Ensuite, la notation scientifique. Excel voit 9007199254740993 et affiche 9.00719925474E+15. Stockez les grands entiers comme des chaînes dans le JSON source et activez le BOM pour qu’Excel garde la cellule en texte. Notre convertisseur détecte automatiquement les grands entiers.

Enfin, la limite pratique de colonnes. Excel prend théoriquement en charge 16 384 colonnes, mais tout ce qui dépasse environ 500 devient ingérable. Stringify les sous-arbres lourds ou pré-projetez avec jq avant la conversion.

Pandas : json_normalize + explode

Le motif standard pour les tableaux imbriqués est record_path + meta en une seule passe :

import pandas as pd

orders = [{
    "order_id": "ord-001",
    "customer": {"name": "Alice", "city": "Seattle"},
    "items": [{"sku": "SKU-100", "qty": 2}, {"sku": "SKU-205", "qty": 1}]
}]

df = pd.json_normalize(orders, record_path='items',
    meta=['order_id', ['customer', 'name'], ['customer', 'city']], sep='_')
df.to_csv("orders.csv", index=False)

La sortie est une ligne par article avec order_id, customer_name et customer_city répétés. Cela vaut mieux que de lancer explode d’abord et json_normalize ensuite : record_path saute la colonne objet intermédiaire et meta vous laisse contrôler quels champs parents se propagent. Pour les entrées où les éléments du tableau contiennent des objets imbriqués, fixez max_level= pour limiter la profondeur.

BigQuery / Snowflake : TSV + JSON dans la cellule

Le LOAD DATA de BigQuery est strict sur le quotage CSV et analyse souvent mal les fichiers contenant des virgules à l’intérieur de texte quoté. Le TSV est plus sûr car les tabulations n’apparaissent presque jamais dans les champs textuels :

bq load --source_format=CSV --field_delimiter='\t' \
  dataset.orders gs://bucket/orders.tsv \
  order_id:STRING,customer:STRING,items:STRING

Lorsque vous chargez des données imbriquées sous forme de JSON stringifié dans une seule colonne, BigQuery interroge tout de même son contenu avec JSON_EXTRACT_SCALAR :

SELECT order_id, JSON_EXTRACT_SCALAR(items, '$[0].sku') AS first_sku
FROM dataset.orders;

Snowflake offre la même capacité via VARIANT, avec des requêtes de chemin comme items:0.sku::STRING. Dans les deux moteurs, Stringify + requêtes par chemin JSON l’emporte sur l’aplatissement complet quand les tableaux imbriqués sont gros ou de longueur variable.

PostgreSQL COPY : RFC 4180 strict

COPY ... FROM ... WITH (FORMAT csv, HEADER true) est le lecteur RFC 4180 le plus strict que vous rencontrerez couramment. Deux comportements piègent les gens.

D’abord, COPY n’accepte pas de BOM UTF-8. La marque d’ordre des octets devient un préfixe littéral sur le nom de la première colonne (id au lieu de id), et toute requête référençant id échoue silencieusement. Désactivez le BOM pour les cibles Postgres.

Ensuite, COPY ne sait pas analyser nativement les données imbriquées. Soit vous explosez les tableaux en plusieurs lignes avant le chargement, soit vous définissez la destination en jsonb et stringifiez la valeur imbriquée :

CREATE TABLE orders (order_id text PRIMARY KEY, customer text, items jsonb);
COPY orders FROM '/tmp/orders.csv' WITH (FORMAT csv, HEADER true);
SELECT order_id, items->0->>'sku' AS first_sku FROM orders;

Pour les pipelines qui parlent déjà JSON de bout en bout, sautez le CSV et utilisez COPY ... FROM ... WITH (FORMAT text) avec une entrée JSON-line à la place.

Études de cas sur des charges utiles réelles

Cas 1 : commandes e-commerce (client + tableau d’articles)

Une commande typique combine des informations client imbriquées avec un tableau d’articles de longueur variable :

[{ "id": "ord-001",
   "customer": { "name": "Alice", "address": {"city": "Seattle", "country": "US"} },
   "items": [{"sku": "SKU-100", "qty": 2}, {"sku": "SKU-205", "qty": 1}] }]

La bonne stratégie dépend de qui lira le fichier. La finance veut une ligne par article pour calculer le chiffre d’affaires par SKU ; c’est la stratégie d’expansion, qui produit deux lignes avec id et customer.name répétés. Les opérations veulent une ligne par commande pour les tableaux de bord de préparation ; c’est la notation pointée avec items stringifié pour que le tableau ne fasse pas exploser le nombre de colonnes. Même entrée, deux sorties, toutes deux correctes pour leur consommateur.

Essayez directement : collez la charge utile dans notre Convertisseur JSON vers CSV et basculez entre Flatten et Stringify sur l’option Nested. L’exemple « Commandes e-commerce imbriquées » charge la même forme.

Cas 2 : API Issues de GitHub (tableau labels + objet user)

L’endpoint /repos/{owner}/{repo}/issues renvoie une forme imbriquée mixte :

[{ "id": 1001, "title": "Bug: login 404", "state": "open",
   "labels": ["bug", "priority:high"], "user": {"login": "alice"} }]

user est un objet avec un seul champ utile ; labels est un tableau de chaînes de longueur non bornée. L’aplatissement pragmatique est hybride : notation pointée sur user (vous ne vous souciez que de user.login), et jointure en ligne sur labels vers une seule cellule séparée par ; :

id,title,state,labels,user.login
1001,Bug: login 404,open,bug;priority:high,alice

Vous ne pouvez pas capturer à la fois « joindre les tableaux dans une cellule » et « aplatir les objets avec des points » dans une seule stratégie. Notre convertisseur gère automatiquement l’aplatissement des objets ; prétraitez les labels avec jq (map(.labels = (.labels | join(";")))) ou acceptez le comportement par défaut de stringify des tableaux.

Cas 3 : MongoDB mongoexport ($oid + métadonnées)

mongoexport --jsonArray produit des enveloppes Extended JSON :

[{ "_id": {"$oid": "6634a1b2c3d4e5f600000001"},
   "email": "alice@example.com",
   "metadata": { "signupDate": "2026-01-15T10:30:00Z",
                 "preferences": {"newsletter": true, "theme": "dark"} } }]

L’enveloppe $oid produit une colonne littéralement nommée _id.$oid, que la plupart des moteurs SQL rejettent. Prétraitez avec jq pour la déballer :

mongoexport --collection=users --jsonArray | jq 'map(._id = ._id."$oid")' > users.json

Pour le bloc profondément imbriqué metadata.preferences, choisissez selon le consommateur. Export pour analyste : aplatissez le tout en notation pointée ; metadata.preferences.theme se lit bien. Aller-retour pipeline : stringify metadata pour préserver la structure intacte. Pour les motifs jq complets qui s’associent aux pipelines CSV, consultez notre Aide-mémoire jq.

Cas 4 : spec de Pod Kubernetes (profondément imbriquée)

Une réponse kubectl get pod -o json est un pire cas pour les stratégies plates. La structure descend couramment à six niveaux (spec.template.spec.containers.0.resources.limits.memory). Un aplatissement pointé naïf produit des noms de colonnes dépassant 70 caractères et plus de 200 colonnes en sortie. Deux stratégies fonctionnent.

Pré-projetez avec kubectl jsonpath. Sélectionnez uniquement les champs dont vous avez réellement besoin :

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\t"}{.status.phase}{"\n"}{end}' > pods.tsv

Stringifiez la spec, aplatissez les métadonnées. Gardez metadata (nom, namespace, labels) à plat et stringifiez spec dans une seule cellule :

kubectl get pods -o json | jq 'map({name: .metadata.name, namespace: .metadata.namespace, spec: (.spec | tostring)})'

Collez ensuite dans le convertisseur en mode Flatten. La colonne spec devient une cellule JSON ; les colonnes métadonnées restent lisibles. Évitez l’anti-motif kubectl get pod -o json | json-to-csv flatten sans pré-projection. Le nombre de colonnes sera ingérable.

Sécurité d’aller-retour : Flatten est avec perte, Stringify est sans perte

Un point que la plupart des guides évitent. La notation pointée, la notation underscore, les tableaux indexés et l’expansion de lignes sont toutes des projections à sens unique. Une fois aplati avec l’une d’elles, le JSON d’origine ne peut pas être parfaitement reconstruit à partir du CSV seul.

Les contre-exemples sont faciles à construire. Une colonne nommée customer.address.city est ambiguë entre {"customer": {"address": {"city": "..."}}} et {"customer": {"address.city": "..."}}. Les tableaux indexés paraissent réversibles, mais le CSV ne peut pas dire si items.0.sku doit se reconstruire en tableau ou en objet avec une clé numérique. L’expansion de lignes requiert une clé de regroupement ; sans order_id, vous ne pouvez pas dire quelles lignes appartenaient au même parent.

Seul Stringify survit à l’aller-retour. La valeur imbriquée est préservée mot pour mot comme une chaîne JSON, de sorte que le convertisseur inverse lit la cellule, la parse et réinsère l’original intact. Convertissez avec Stringify, sauvegardez le CSV, collez-le dans notre Convertisseur CSV vers JSON, activez Inférer les types, et vous obtenez des octets identiques à l’entrée.

La règle pratique : aller-retour pipeline → Stringify. Analyse ou reporting ponctuel → pointée, underscore ou expansion selon le consommateur.

Le faire dans notre outil navigateur

Le Convertisseur JSON vers CSV expose directement deux des cinq stratégies : Flatten (combinant notation pointée et tableaux indexés) et Stringify (préservant la structure à l’intérieur d’une cellule). Les trois autres (underscore, expansion de lignes, préréglages cibles SQL) ne sont qu’à une étape de prétraitement.

Une session typique tient en cinq clics :

1. Validez l’entrée avec notre Formateur JSON pour que les erreurs de syntaxe ne deviennent pas des échecs silencieux de conversion.
2. Collez le JSON dans le Convertisseur JSON vers CSV. La conversion s’exécute instantanément.
3. Réglez Nested sur Flatten pour des clés pointées et indexées, ou sur Stringify pour garder les tableaux et objets dans une seule cellule.
4. Choisissez un préréglage : RFC 4180 pour les pipelines, Excel pour les tableurs EU, TSV pour les entrepôts, Pipe pour le texte riche en virgules.
5. Cliquez sur Swap direction et utilisez le Convertisseur CSV vers JSON avec Inférer les types activé pour vérifier un aller-retour Stringify.

Tout s’exécute dans votre navigateur. Les données personnelles, les exports internes et les secrets de production ne quittent jamais la page ; aucune requête réseau ne part après le chargement. Cela convient aux données sensibles, là où téléverser vers un site tiers n’est pas envisageable.

Pièges courants

1. Explosion du nombre de colonnes. Les specs Kubernetes et les fils de revue de PR GitHub produisent des centaines de chemins jusqu’aux feuilles. Solution : pré-projeter avec jq ou kubectl jsonpath, ou stringifier les sous-arbres lourds tout en aplatissant les métadonnées.
2. Décalage de longueur de tableau. La ligne 1 a 3 articles, la ligne 2 en a 5. Les tableaux indexés produisent des cellules vides dans items.3.sku et items.4.sku pour la ligne 1. Solution : passer à l’expansion de lignes.
3. Clés d’index traitées comme des chaînes au retour. Quand le CSV-vers-JSON voit items.0.sku, le 0 est techniquement une clé chaîne. Certains convertisseurs inverses reconstruisent {"0": {"sku": "A"}} au lieu de [{"sku": "A"}]. Solution : utiliser Stringify pour les aller-retours.
4. Clés qui contiennent déjà le séparateur. Les événements GA4 ont des clés comme event_params.key contenant des points littéraux ; aplatir avec . produit des chemins ambigus. Solution : utiliser l’underscore, ou renommer les clés problématiques. Voyez notre guide De JSON5 à JSONC pour le contexte sur les formats JSON à clés étendues.
5. Types mélangés selon le niveau. Certaines lignes ont address comme objet, d’autres comme null. L’aplatissement produit des cellules vides là où l’objet était null. L’avertissement de notes de schéma sur notre convertisseur le signale pour que vous puissiez vérifier le consommateur aval.
6. Grands entiers tronqués par Excel. Un Long $oid, un identifiant snowflake Twitter ou un resourceVersion K8s dépasse la plage sûre de JavaScript (2^53 - 1) et se voit arrondi silencieusement. Excel les affiche alors comme 9.00719925474E+15. Solution : stocker les identifiants comme chaînes dans le JSON source, activer le BOM et utiliser le préréglage Excel.

FAQ

Quelle est la meilleure manière d’aplatir un JSON imbriqué en CSV ?

La meilleure manière d’aplatir un JSON imbriqué en CSV dépend du consommateur aval. Utilisez la notation pointée pour Excel ou Google Sheets. Utilisez l’expansion de lignes lorsque Pandas ou BigQuery va agréger les données. Utilisez Stringify lorsque le CSV doit revenir vers du JSON sans perte de données. Adaptez la stratégie au prochain lecteur.

Comment convertir un tableau JSON en plusieurs lignes CSV ?

Convertissez un tableau JSON en plusieurs lignes CSV avec la stratégie d’expansion : dupliquez les champs parents une fois par élément du tableau pour que chacun devienne sa propre ligne. En Pandas, pd.json_normalize(data, record_path='items', meta=['order_id']) le fait en un seul appel. En SQL, UNNEST(items) produit la même forme. Les clés parents se répètent sur les lignes étendues.

Puis-je faire l’aller-retour du CSV vers le JSON imbriqué d’origine ?

L’aller-retour du CSV vers le JSON imbriqué d’origine ne fonctionne qu’avec le mode Stringify. La notation pointée, l’underscore, les tableaux indexés et l’expansion de lignes sont des projections à sens unique avec perte ; le convertisseur inverse ne peut pas reconstruire parfaitement l’arbre. Stringify préserve les tableaux et les objets en JSON à l’intérieur d’une seule cellule, de sorte que l’aller-retour complet est identique octet pour octet lorsque Inférer les types est activé.

Pourquoi Excel affiche-t-il mon JSON aplati comme une seule longue colonne ?

Excel affiche votre JSON aplati comme une seule longue colonne quand vous êtes dans une locale européenne (Allemagne, France, Italie, Espagne) où la virgule est réservée aux décimales et Excel attend des points-virgules comme délimiteur. Le préréglage Excel sur Convertisseur JSON vers CSV bascule vers ; + CRLF + BOM UTF-8 en un clic.

Faut-il utiliser la notation pointée ou underscore pour les noms de colonnes ?

Utilisez la notation pointée quand la cible est Excel, Google Sheets ou Pandas ; les points sont la valeur par défaut de json_normalize et se lisent naturellement. Utilisez l’underscore quand la cible est SQL : Postgres, BigQuery et Snowflake exigent un quotage autour des identifiants contenant des points, alors que les underscores sont acceptés sans quotage partout.

Comment json_normalize de pandas gère-t-il les tableaux d’objets ?

json_normalize de Pandas gère les tableaux d’objets à travers les arguments record_path et meta. pd.json_normalize(data, record_path='items', meta=['order_id']) étend items en une ligne par élément avec order_id répété. Pour des objets imbriqués sans tableau, le plus simple pd.json_normalize(data, sep='_') produit des noms de colonnes séparés par underscore comme customer_address_city. Utilisez max_level= pour plafonner la profondeur sur des arbres profonds.

Quelle est la limite de colonnes lors de l’aplatissement d’un JSON profondément imbriqué ?

La limite de colonnes lors de l’aplatissement d’un JSON profondément imbriqué est de 16 384 dans Excel et effectivement non bornée dans le CSV lui-même, mais au-delà de 500 colonnes la sortie devient ingérable. Les specs de Pod Kubernetes ou les réponses GraphQL dépassent facilement ce seuil. Stringifiez les sous-arbres lourds avec le Convertisseur JSON vers CSV ou pré-projetez avec jq ou kubectl jsonpath.

jq est-il un bon outil pour aplatir le JSON avant la conversion CSV ?

Oui, jq est l’outil indiqué pour aplatir le JSON avant la conversion CSV. Il gère la pré-projection (map({id, name})), la pré-explosion (.[] | {id, item: .items[]}) et la normalisation de forme en une seule ligne. Le pipeline jq s’exécute avant l’étape CSV et contrôle exactement quels champs atteignent le convertisseur. Voyez notre Aide-mémoire jq pour les motifs.

Conclusion

Cinq enseignements :

1. JSON vers CSV est un problème de géométrie, pas de syntaxe. Un arbre ne peut pas tenir dans une grille sans choisir comment les branches s’effondrent.
2. Cinq stratégies couvrent l’univers pratique (pointée, underscore, tableaux indexés, expansion de lignes, Stringify). Choisissez selon le consommateur.
3. Stringify est le seul chemin sans perte. Utilisez-le pour les aller-retours pipeline.
4. Excel-EU et BigQuery ont des préréglages pour une raison. Utilisez-les.
5. Les charges utiles réelles (mongoexport, specs Kubernetes, réponses GitHub) ont généralement besoin d’une étape de pré-projection jq ou kubectl jsonpath au préalable.

Essayez votre propre charge utile dans le Convertisseur JSON vers CSV. L’outil tourne en local, gère les cinq stratégies et fait l’aller-retour sans perte avec Stringify. Aucun téléversement, aucune inscription, et la donnée reste sur votre machine.