Comment créer un CSV à partir de JSON : 7 décisions qui transforment des données brutes en fichier fonctionnel (Guide 2026)

Créer n'est pas la même chose que convertir

On dit « créer un CSV » et « convertir du JSON en CSV » comme si c'était la même chose. Ce n'est pas le cas. La conversion est mécanique : le même JSON produit toujours le même CSV avec les mêmes réglages. La création est un acte de rédaction : le fichier que vous remettez à un collègue, importez dans une base de données ou transmettez à un outil d'analyse doit survivre dans des environnements que vous ne contrôlez pas — Excel dans un autre pays, un chargeur de base de données aux règles strictes, un collègue qui ouvre tout en double-cliquant.

L'écart entre « converti » et « créé » tient en sept décisions. Sautez-les et le fichier se convertira quand même ; il cassera simplement plus loin, au pire moment possible. La bonne nouvelle : chaque décision prend quelques secondes, et une fois que vous aurez compris de quoi il s'agit, vous ne pourrez plus l'ignorer. Chaque exemple ci-dessous a été exécuté sur le vrai moteur de conversion de ce site — le même JavaScript qui tourne quand vous appuyez sur Convertir — donc les sorties montrées sont exactement celles que vous obtiendrez.

Décision 1 : aplatissez l'arborescence avant de rédiger la grille

On ne peut pas rédiger des colonnes à partir de JSON imbriqué. Un CSV est une grille — des lignes et des colonnes, chaque cellule contenant une seule valeur plate — et les objets imbriqués n'ont aucune colonne où vivre. La première décision consiste donc à aplatir : les objets imbriqués deviennent des colonnes en notation pointée (customer devient customer.name et customer.city), les listes de valeurs simples se rejoignent dans une seule cellule, et les null deviennent des cellules vides. C'est l'étape mécanique, et c'est celle que le convertisseur fait pour vous avec son interrupteur d'aplatissement.

Pourquoi commencer par là ? Parce que chaque décision ultérieure — noms d'en-têtes, délimiteurs, guillemets — s'applique au résultat aplati. Si vous renommez les en-têtes avant d'aplatir, vous nommez des colonnes qui n'existent pas encore. Le moteur ici aplatit par défaut sous le nom d'option flattenNested : en pratique, cette décision se résume à le laisser activé, jeter un œil à l'aperçu et vérifier que les noms de colonnes sont bien ceux que vous attendez.

Décision 2 : nommez vos colonnes comme un contrat

Les noms de la ligne d'en-tête sont un contrat avec tous les outils qui toucheront un jour le fichier. Les mauvais noms d'en-têtes sont la façon la plus discrète de fabriquer un mauvais CSV : ils n'échouent jamais au moment de la conversion, ils échouent trois semaines plus tard, lors de l'import dans la base de données. Quatre règles couvrent à peu près tout :

Pas d'espaces dans les noms d'en-têtes. "order id" est lisible pour vous et un rapport de bug pour un chargeur SQL ; utilisez orderId ou order_id. Le moteur d'aplatissement produit déjà des noms pointés sans espaces (customer.name) : seules vos clés de premier niveau demandent de l'attention.
Pas de doublons. Deux en-têtes identiques signifient que la seconde colonne écrase silencieusement la première dans de nombreux importeurs. Si votre JSON contient à la fois "user.name" comme clé littérale et un objet imbriqué user: { name }, l'aplatissement les fusionne en une seule colonne — la valeur imbriquée gagne et l'autre est perdue. Renommez avant de convertir si les deux valeurs comptent.
Pas de chiffre en tête. Les noms de colonnes comme "2024-sales" cassent dans de nombreux dialectes SQL et certains outils de BI. Préférez sales_2024.
Stables et explicites. Un en-tête est une API : abréger en "qty" passe, mais "q" embrouillera quelqu'un dans six mois. Choisissez des mots entiers une fois pour toutes et réutilisez-les d'un fichier à l'autre.

Une chose à ne pas craindre : les en-têtes non ASCII. Si vos colonnes s'appellent product_name et des étiquettes japonaises comme "商品名", UTF-8 les transporte sans problème (la décision 6 couvre l'encodage). Le moteur écrit les cellules d'en-tête avec les mêmes règles de guillemets que les cellules de données, donc même un en-tête contenant une virgule ou un guillemet est échappé correctement — nous avons vérifié la logique d'échappement dans le code source : les guillemets s'appliquent par cellule, en-têtes inclus.

Décision 3 : choisissez le délimiteur délibérément

La virgule est le délimiteur par défaut, et pour la plupart des fichiers c'est le bon. Mais le délimiteur n'est pas une formalité : c'est le caractère selon lequel tout le fichier est analysé. Le convertisseur propose la virgule, le point-virgule, la tabulation, la barre verticale et un délimiteur personnalisé, et voici quand chacun mérite sa place :

Virgule : le choix par défaut. Utilisez-la sauf raison contraire. Tous les outils la lisent.
Point-virgule : quand vos données regorgent de virgules. Les exports européens l'utilisent beaucoup — ce n'est pas un hasard, car de nombreuses locales européennes emploient la virgule comme séparateur décimal, si bien qu'un fichier délimité par des virgules serait ambigu. Si vos champs de texte sont pleins de virgules, le point-virgule garde les cellules lisibles sans dépendre des guillemets.
Tabulation : quand des humains liront le fichier brut. Les valeurs séparées par des tabulations se collent directement dans les tableurs et restent lisibles dans un éditeur de texte. Pratique pour les flux copier-coller.
Barre verticale : quand votre texte contient des virgules, des guillemets ET des points-virgules — messages de journal, adresses, prose. La barre verticale est rare dans le texte naturel, donc elle entre rarement en collision.

Le hic, en toute honnêteté : les guillemets existent précisément pour rendre le choix du délimiteur sans danger. Quand une cellule contient le délimiteur, le moteur l'entoure de guillemets automatiquement (décision 4), donc une adresse pleine de virgules dans un fichier délimité par des virgules s'analyse quand même. Le choix du délimiteur relève de la lisibilité et des habitudes de votre public, pas de la justesse — la justesse, c'est le travail du moteur de guillemets. Un vrai avertissement, toutefois : si vous choisissez le point-virgule pour un public américain ou britannique, prévenez-le — son Excel s'attend peut-être par défaut à des virgules et ouvrira votre fichier comme une seule longue colonne.

Décision 4 : laissez les guillemets en automatique

Les guillemets sont la partie la plus mal comprise du CSV. La règle est simple : une cellule qui contient le délimiteur, un guillemet ou un saut de ligne doit être entourée de guillemets doubles, et tout guillemet intérieur doit être doublé. Voici ce que le moteur produit réellement — vérifié, pas illustré :

Guillemets en action (vérifié sur le moteur réel)

name,city,qty
"Say ""hi"", friend",Oslo,3

Lisez attentivement : la cellule Say "hi", friend est devenue "Say ""hi"", friend" — entourée de guillemets parce qu'elle contient une virgule, et ses guillemets intérieurs doublés. C'est la sortie correcte, conforme aux standards, et tous les vrais tableurs l'analysent pour retrouver exactement le texte d'origine.

Décision 4 : laissez les guillemets en automatique (suite)

Changez le délimiteur pour le point-virgule et regardez les guillemets s'adapter :

Mêmes données, délimiteur point-virgule (vérifié)

name;city;qty
"Say ""hi"", friend";Oslo;3

La virgule ne déclenche plus l'entourage, mais le guillemet le fait toujours — le moteur met des guillemets selon le délimiteur réellement utilisé, pas selon une idée figée de ce qui est "spécial". Cette conscience du délimiteur, c'est ce que signifie "automatique", et c'est le réglage à ne pas toucher. Le moteur propose aussi les modes de guillemets always et never ; never est un piège, et en voici la preuve :

Décision 4 : laissez les guillemets en automatique (suite)

quoteMode "never" : le piège (vérifié)

note,code
line1
line2,007

Avec les guillemets désactivés, une cellule contenant un vrai saut de ligne reste brute — et ce saut de ligne ressemble désormais à une frontière de ligne pour tous les analyseurs du monde. Votre fichier de 2 lignes se lit comme 3 lignes, dont une poubelle. Les guillemets sont quand même doublés (le moteur le fait inconditionnellement), mais rien n'est entouré. N'utilisez "never" que lorsqu'un système en aval exige explicitement une sortie sans guillemets et que vous avez vérifié qu'aucune de vos cellules ne contient de délimiteur, de guillemet ni de saut de ligne. Dans tous les autres cas : automatique.

Décision 5 : rendez les valeurs lisibles comme du texte

JSON a des types — nombres, booléens, null. CSV n'a qu'un seul type : le texte. Le moment de la conversion est celui où chaque valeur devient sa forme textuelle finale, et c'est la décision que la plupart des gens ne prennent jamais consciemment. Trois formes de valeurs méritent votre attention :

D'abord, les zéros initiaux. Une chaîne JSON comme "007" reste 007 dans le CSV — nous l'avons vérifié, sans guillemets, exactement comme tapé. Mais ouvrir ce fichier dans Excel affichera quand même 7, parce qu'Excel réinterprète les cellules à l'ouverture. Le CSV est correct ; le visualiseur a ses opinions. Si les zéros initiaux doivent survivre à Excel, la correction se fait côté réception (importer en texte), pas dans le fichier — sachez-le avant d'accuser le convertisseur.

Ensuite, les dates. JSON n'a pas de type date, donc vos "dates" sont des chaînes comme 2026-10-14 ou des horodatages comme 1697000000. Quelle que soit la forme convertie, le CSV la conserve ; choisissez donc la forme lisible par l'humain avant d'exporter : l'ISO 2026-10-14 se trie correctement comme texte ; 10/14/2026 non, et sera mal lue par la moitié du monde. Prenez la décision dans le JSON, pas une fois le CSV créé.

Enfin, les décimales et les booléens. Un nombre comme 19.99000001 devient exactement ce texte ; les booléens deviennent true/false. Si vos données source ont du bruit de flottants, arrondissez avant la conversion — le CSV n'arrondira pas pour vous.

Décision 6 : choisir UTF-8 en connaissance de cause (et la question du BOM)

L'encodage est la décision que personne ne prend avant que le mojibake ne l'y force. UTF-8 est la réponse en 2026 : il transporte toutes les langues, et tous les outils modernes le lisent. La subtilité, c'est le BOM — la marque d'ordre des octets invisible que certains outils Windows veulent en début de fichier.

Voici le fait honnête sur le convertisseur de ce site : le téléchargement est en UTF-8 pur, sans BOM — nous avons lu le code de téléchargement, qui crée un Blob text/csv avec charset=utf-8 et sans marque initiale. C'est correct pour les téléversements web, les bases de données, Google Sheets et Python. Le seul endroit où ça coince : le double-clic sur le fichier dans certaines versions d'Excel sous Windows, qui peut deviner le mauvais encodage et massacrer les caractères non ASCII.

La correction n'est pas d'exiger un BOM du convertisseur — c'est un import de 20 secondes : dans Excel, Données → À partir du texte/CSV → choisissez 65001 (UTF-8) dans la liste déroulante d'encodage. Vos caractères ressortent parfaits et le fichier reste propre pour tous les autres outils. Décidez de votre encodage une fois par flux de travail et documentez-le à côté du fichier ; les surprises d'encodage sont toujours un échec de communication, jamais un échec de données.

Décision 7 : validez le fichier final avant qu'il ne vous quitte

La création se termine par un contrôle, et il prend moins d'une minute. Quatre étapes :

Ouvrez-le d'abord dans un éditeur de texte, pas dans un tableur. Un éditeur de texte vous montre le fichier ; un tableur vous montre son interprétation. Vérifiez la ligne d'en-tête, le délimiteur, et que les cellules entre guillemets ont l'air saines.
Comptez les lignes. Le moteur affiche les nombres de lignes et de colonnes dans ses statistiques — comparez-les à la longueur de votre tableau JSON. Un écart signifie une surprise d'analyse (généralement un saut de ligne non entouré en mode quoteMode "never", ou un JSON d'entrée mal formé).
Réimportez-le. Collez le CSV en retour ou ouvrez-le dans l'outil auquel vous l'envoyez. S'il s'y ouvre correctement, il s'ouvrira correctement pour le destinataire.
Vérifiez les bords : première ligne, dernière ligne, et une ligne avec les caractères les plus étranges. La corruption se concentre aux frontières.

Cette liste est aussi la réponse à "pourquoi mon CSV semble cassé" : d'après notre expérience, c'est le visualiseur ou les réglages d'import neuf fois sur dix, et le fichier lui-même la dixième. L'habitude de l'éditeur de texte d'abord, c'est ce qui tranche en quelques secondes.

La recette en 60 secondes : les sept décisions réunies

Collez ou téléversez votre JSON dans le convertisseur. Laissez l'aplatissement activé et jetez un œil à l'aperçu des colonnes — ces noms pointés sont vos en-têtes, alors renommez d'abord dans la source toute clé fautive. Gardez le délimiteur virgule sauf si votre texte regorge de virgules (alors point-virgule). Laissez les guillemets en automatique. Mettez les dates et les nombres en forme comme le texte que vous voulez voir affiché avant de convertir. Téléchargez le fichier UTF-8, ouvrez-le une fois dans un éditeur de texte, réimportez-le là où il va. Terminé — un fichier créé, pas simplement converti.

Ouvrir le convertisseur JSON vers CSV gratuit

Guides associés

Questions fréquentes

Comment créer un fichier CSV à partir de JSON ?

Collez ou téléversez votre JSON dans un convertisseur, aplatissez les données imbriquées en colonnes, vérifiez les noms d'en-têtes et le délimiteur, puis téléchargez. La liste complète : aplatir d'abord, nommer les colonnes sans espaces, garder la virgule sauf si vos données regorgent de virgules, laisser les guillemets en automatique, mettre les dates et les nombres en forme comme le texte que vous voulez voir, télécharger en UTF-8, et réimporter le fichier une fois pour le valider.

Quel est le meilleur délimiteur pour un CSV créé à partir de JSON ?

La virgule est le choix par défaut et le bon pour la plupart des fichiers. Utilisez le point-virgule quand vos champs de texte regorgent de virgules (fréquent dans les exports européens, où la virgule est aussi le séparateur décimal), la tabulation pour la lisibilité en copier-coller, et la barre verticale quand le texte contient des virgules, des guillemets et des points-virgules. Des guillemets corrects rendent chacun de ces choix sûr à l'analyse — le choix relève des habitudes de votre public, pas de la justesse.

Comment nommer les colonnes CSV créées à partir de JSON ?

Traitez les noms d'en-têtes comme un contrat : pas d'espaces (order_id, pas "order id"), pas de doublons, pas de chiffre en tête (sales_2024, pas 2024-sales), et des mots entiers plutôt que des abréviations cryptiques. Les clés imbriquées aplaties sortent déjà en noms pointés sans espaces comme customer.name — seules vos clés de premier niveau demandent généralement de l'attention.

Pourquoi mon CSV s'ouvre mal dans Excel après l'avoir créé à partir de JSON ?

Neuf fois sur dix, le fichier est bon et c'est le visualiseur le problème. Causes fréquentes : Excel devine le mauvais délimiteur (un fichier en point-virgule ouvert comme de la virgule), mauvaise devinette d'encodage sur du texte non ASCII (réimportez via Données → À partir du texte/CSV avec l'encodage 65001 UTF-8), ou Excel réinterprète les cellules (suppression des zéros initiaux comme 007, ou reformatage des dates). Ouvrez d'abord le fichier dans un éditeur de texte — s'il y a l'air correct, le fichier est correct.

Faut-il des guillemets autour de chaque cellule d'un CSV ?

Non — les guillemets automatiques (au besoin) sont corrects et suffisants : les cellules contenant le délimiteur, des guillemets ou des sauts de ligne sont entourées de guillemets doubles, avec les guillemets intérieurs doublés. "Always" ajoute du bruit, et "never" est dangereux : un saut de ligne non entouré dans une cellule ressemble à une frontière de ligne pour tous les analyseurs et corrompt silencieusement votre nombre de lignes.

Mon CSV issu de JSON doit-il avoir un BOM ?

Généralement non. Un fichier UTF-8 sans BOM fonctionne partout : bases de données, téléversements web, Google Sheets, Python. Certaines versions d'Excel sous Windows lisent mal les fichiers sans BOM au double-clic — la correction est un import propre (Données → À partir du texte/CSV, encodage 65001) plutôt que d'ajouter un BOM, qui peut perturber d'autres outils. Le convertisseur de ce site télécharge de l'UTF-8 pur sans BOM.

Comment vérifier que mon CSV généré est correct ?

Quatre étapes rapides : ouvrez-le dans un éditeur de texte (pas un tableur) pour voir le fichier réel, comparez le nombre de lignes à la longueur de votre tableau JSON, réimportez-le dans l'outil auquel vous l'envoyez, et inspectez la première ligne, la dernière ligne et la ligne aux caractères les plus étranges. La corruption se concentre aux frontières — si les bords sont bons, le fichier est bon.

Créez votre CSV maintenant — aplatissement, guillemets et en-têtes pris en charge

Collez du JSON ou téléversez un fichier : les données imbriquées s'aplatissent en colonnes propres, les délimiteurs et les guillemets sont automatiques, et le téléchargement est en UTF-8 pur. Gratuit, sans inscription, tout se passe dans votre navigateur.

Ouvrir le convertisseur JSON vers CSV

Tous les guides