Convertir JSON en CSV

C’est la seule chose à comprendre avant de convertir quoi que ce soit. Le JSON décrit un arbre : un objet peut contenir un autre objet, qui peut contenir un tableau d’objets, à n’importe quelle profondeur. Le CSV décrit une grille : des lignes et des colonnes, et rien à l’intérieur d’une cellule.

La conversion n’est donc pas une traduction entre deux manières d’écrire la même chose. C’est une projection, et quelque chose doit céder. Pour des données qui sont vraiment une liste d’enregistrements plats — ce que la plupart des exports sont — rien n’est perdu. Pour tout ce qui est profondément structuré, le CSV est une approximation lisible et le JSON reste le vrai fichier.

Un objet imbriqué est aplati en joignant les noms de clés, si bien qu’un enregistrement avec un client qui contient une ville produit une colonne nommée pour les deux. Un niveau d’imbrication produit un tableau que n’importe qui sait lire. Deux, c’est en général encore correct.

Au-delà, cela se dégrade vite : les noms de colonnes s’allongent, le tableau devient très large, et la plupart des cellules de la plupart des lignes sont vides parce que les enregistrements s’imbriquent différemment. Si une conversion produit soixante colonnes à partir d’un export qui semblait simple, c’est la forme des données qui transparaît plutôt qu’un défaut de la conversion.

Un enregistrement avec trois étiquettes, quatre lignes de commande ou une liste d’adresses précédentes n’a pas de représentation correcte en tableau. Il y a trois réponses habituelles et chacune est fausse pour quelque chose : une colonne par position, qui casse quand un enregistrement en a cinq ; une colonne avec les valeurs jointes par un séparateur, qui devient inanalysable si les valeurs contiennent ce séparateur ; ou une ligne par élément de tableau, qui duplique l’enregistrement parent et change ce que signifie une ligne.

Quand les tableaux portent le sens — une commande avec ses lignes, un billet avec ses commentaires — la réponse honnête n’est pas de convertir. Gardez le JSON, ou produisez deux tableaux à la manière d’une base de données : un pour les commandes, un pour les lignes, joints par un identifiant.

Les enregistrements d’un export JSON ne sont pas obligés d’avoir les mêmes clés. Une API renvoie les champs qui existent et omet ceux qui n’existent pas, si bien que cent enregistrements peuvent présenter quatre-vingts formes différentes.

La conversion résout cela en parcourant les enregistrements pour construire l’ensemble complet des colonnes et en laissant une cellule vide là où un enregistrement n’a pas de valeur. C’est en général ce qu’on veut, et cela explique une surprise fréquente : convertir un échantillon de dix enregistrements produit moins de colonnes que convertir le fichier entier, parce que l’échantillon n’avait pas les champs les plus rares.

Produire un CSV correct ne le protège pas de ce qui se passe ensuite. Excel l’ouvre en devinant un type par colonne, ce qui supprime les zéros initiaux des codes, convertit tout ce qui ressemble à une date en date, et tronque les identifiants au-delà de quinze chiffres.

Le remède est le même que toujours : importer plutôt qu’ouvrir — Données, Depuis un fichier Texte/CSV — et mettre les colonnes d’identifiants en Texte avant de charger. Si le destinataire est une personne plutôt qu’un programme, convertir en XLSX à la place retire la devinette, parce que les types sont déclarés dans le fichier.

Les exports de données des services d’IA sont désormais l’une des raisons les plus fréquentes d’ouvrir un fichier JSON, et l’archive ChatGPT est le cas habituel. Son fichier `conversations.json` n’est pas une liste de lignes : c’est un ensemble d’arbres de messages, chaque nœud pointant vers son parent, ce qui est la manière dont les conversations branchées et éditées sont représentées. Il n’y a pas de grille honnête dedans.

Le convertir en CSV produit quelque chose techniquement valide et pratiquement inutilisable — une ligne par nœud, avec la structure du fil perdue. Si l’objectif est de relire vos conversations, c’est le fichier HTML exporté dans la même archive qu’il faut ouvrir. Le CSV est la bonne cible pour les exports plus plats à côté, comme les enregistrements d’usage et de facturation, où chaque entrée est réellement une ligne.

Un tableau JSON doit être complet avant de pouvoir être analysé, parce que c’est le crochet fermant qui le rend valide. Un très gros fichier doit donc être lu en entier, et c’est une propriété du format plutôt que d’un outil particulier.

Si vous contrôlez comment les données sont produites, demandez plutôt du NDJSON — un objet JSON complet par ligne. Cela doit encore être lu en mémoire en entier ici, exactement comme un tableau, mais chaque ligne est analysée à part : une ligne corrompue ou tronquée échoue avec son propre numéro de ligne au lieu d’invalider le document entier. C’est ce qu’utilisent les pipelines de logs et les gros exports de données pour exactement cette raison, et tout outil qui lit du JSON le lit avec un changement d’une ligne.

La conversion tourne dans votre navigateur, sur votre propre processeur. Le fichier n’est jamais envoyé nulle part, il n’y a pas de compte et pas de quota journalier, et un fichier allant jusqu’à 100 Mo est traité dans l’onglet.

Cela vaut plus ici que sur la plupart des conversions. Un export JSON est presque toujours la sortie brute d’une API — fiches clients, historiques de commandes, soumissions de formulaires, comptes utilisateurs — et il contient en général des champs auxquels personne n’a pensé parce que personne n’était censé les lire. Ne l’envoyer nulle part est la réponse simple.