Aller au contenu principal
ToolsByUs

JSON vs CSV

Choisissez CSV pour des données à plat, façonnées en lignes, destinées à des tableurs, des imports en masse ou des outils orientés colonnes — il circule en flux à moindre coût et s’ouvre partout. Choisissez JSON quand les enregistrements s’imbriquent, que les types comptent ou qu’un programme consomme les données. CSV est une table et JSON est un arbre ; convertissez quand le consommateur change, pas quand les données changent.

100 % local

JSON vs CSV en clair

CSV est le format sous lequel les données arrivent du monde physique : exports de tableur, relevés bancaires, relevés de capteurs, téléchargements de CRM. Il paraît d’une simplicité enfantine — des valeurs séparées par des virgules — et c’est précisément cette simplicité apparente qui explique qu’on le manipule si souvent maladroitement. La RFC 4180 définit une discipline de guillemets précise que la plupart des fichiers réels suivent mollement, et les dialectes se multiplient à partir de là. JSON, à l’inverse, est le format d’échange entre programmes : une petite grammaire, six types, et de l’imbrication aussi profonde que les données l’exigent.

La différence essentielle est la forme. Un fichier CSV est une table à deux dimensions : des lignes de colonnes, une valeur par cellule, et tout est texte. Un document JSON est un arbre : des objets dans des tableaux dans des objets, chaque valeur portant son propre type. Ni l’un ni l’autre n’est meilleur ; ils répondent à des questions différentes. Mais l’essentiel des souffrances de conversion — et des conversions les plus cassées — vient du fait de forcer un arbre dans une table, ou de prêter à une table une structure qu’elle n’a pas.

Cette page les compare là où les décisions se prennent réellement : structure, typage et guillemets, comportement d’Excel, taille en masse et flux. Les deux sens de conversion sont liés ci-dessous et s’exécutent entièrement dans votre navigateur, avec des règles d’aplanissement et d’inférence de types documentées plutôt que cachées.

Transformer une réponse d’API en quelque chose qu’un analyste peut ouvrir est la traversée classique — le convertisseur JSON vers CSV aplanit un tableau d’enregistrements en colonnes en un seul collage, entièrement dans votre navigateur.

Ingérer l’export de tableur d’un fournisseur dans du code ? Le convertisseur CSV vers JSON ajoute types et structure localement, avant même que le fichier n’atteigne votre parseur.

Forme : une table contre un arbre

Un fichier CSV est une suite d’enregistrements, tous de la même largeur : nom, e-mail, montant, répétés à chaque ligne. Une ligne d’en-tête — conventionnelle, pas garantie — nomme les colonnes une fois pour tout le fichier. Les enregistrements JSON, eux, transportent leurs clés avec eux : chaque objet se décrit seul, et un objet peut contenir un tableau d’objets contenant eux-mêmes des tableaux. Cette asymétrie décide du choix de format plus que n’importe quelle liste de fonctionnalités.

AspectJSONCSV
FormeArbre — objets et tableaux s’imbriquent librementUne seule table plate de lignes et de colonnes
TypesSix types, déclarés dans la syntaxeAucun — chaque cellule est du texte
ClésChaque objet porte les siennesUne ligne d’en-tête, par convention
ImbricationProfondeur illimitéeImpossible sans aplanissement ni fichiers supplémentaires
NormeRFC 8259, une seule grammaireRFC 4180, plus des dialectes réels bien ancrés
Valeurs videsnull, déclaré délibérémentCellule vide — ou colonne entière manquante

Types et guillemets : déclarés contre inférés

En JSON, le type d’une valeur est visible : des guillemets signifient chaîne, des chiffres nus signifient nombre, et true, false et null sont des jetons exacts. En CSV, le fichier n’affirme rien — 007 et 7 sont tous deux du simple texte de cellule, et chaque consommateur réinfère les types selon ses propres règles. La RFC 4180 spécifie en revanche précisément les guillemets : les champs contenant des virgules, des guillemets doubles ou des sauts de ligne sont enveloppés de guillemets doubles, et les guillemets internes sont doublés. Les fichiers qui s’en dispensent produisent les classiques bugs de ligne cassée que tout ingénieur données a déjà débogués.

L’étape de réinférence est l’endroit où les données se corrompent en silence. Un code postal 02134 devient le nombre 2134 ; 1.20 devient 1.2 ; un long numéro de compte devient 4.2E+12. JSON a la règle miroir — les nombres ne peuvent porter aucun zéro initial, donc un code postal doit y être une chaîne lui aussi — mais au moins la déclaration est explicite plutôt qu’une devinette faite par le tableur de quelqu’un d’autre.

Excel, gros volumes et terrains de victoire de chaque format

Le comportement d’Excel mérite son propre paragraphe tant il brûle de pipelines. Excel ouvre le CSV nativement mais retape le type de chaque cellule selon les paramètres régionaux de la machine : les zéros initiaux disparaissent, les horodatages ISO se déforment en dates locales, et dans une bonne partie de l’Europe c’est le dialecte à points-virgules qui règne parce que la virgule est un séparateur décimal. L’enregistrement réécrit ensuite le fichier avec ces inférences gravées pour de bon. JSON ne passe jamais par Excel, ce qui suffit à expliquer la préférence des intégrations.

À grande échelle, la platitude de CSV est un atout : les lignes se lisent une à une avec une mémoire constante, voilà pourquoi les exports de plusieurs gigaoctets et les outils orientés colonnes parlent encore CSV d’abord. JSON gagne partout où le consommateur est un programme et la structure réelle : charges utiles d’API, configuration, documents imbriqués. Choisir selon le consommateur plutôt que selon la mode règle la plupart des débats en une phrase.

Quand choisir l’un ou l’autre — et comment se comporte la conversion

Choisissez CSV quand la destination est tabulaire : tableurs, chargements en masse en base de données, outils de BI et de data science. Choisissez JSON quand la structure s’imbrique ou que le consommateur est du code. La recommandation s’inverse sans arrêt dans les pipelines réels : une API renvoie du JSON, un analyste veut du CSV, un fournisseur envoie du CSV qu’un service doit ingérer — la conversion est de l’entretien de routine, pas un projet de migration.

La conversion a des limites qu’il faut dire. JSON vers CSV doit aplanir : un tableau d’objets devient des lignes, l’union de leurs clés devient des colonnes, et tout tableau ou objet imbriqué doit être sérialisé en chaîne, joint ou abandonné. CSV vers JSON doit inférer : les cellules vides deviennent null ou des chaînes vides, et les cellules d’allure numérique deviennent des nombres. Les convertisseurs de ce site documentent ces règles exactes au lieu de deviner en silence.

Questions fréquentes

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

Non — la RFC 4180 ignore le concept d’imbrication ; une cellule est une cellule. Les contournements : aplanir (address_city comme nom de colonne), sérialiser un fragment JSON dans une cellule entre guillemets, ou éclater en plusieurs fichiers reliés par une clé. JSON Lines — un objet JSON à plat par ligne — est le terrain d’entente habituel pour les données en enregistrements.

Pourquoi Excel modifie-t-il mes valeurs quand j’ouvre un CSV ?

Excel réinfère un type pour chaque cellule au chargement : 02134 perd son zéro initial, un numéro de compte à seize chiffres devient 1.23457E+12, et 2026-09-19 devient une date dépendante des paramètres régionaux. Ces inférences sont réenregistrées dans le fichier. Importer via l’assistant d’importation de texte d’Excel en forçant les colonnes en texte évite le dégât ; JSON, analysé par un programme, ne retape jamais rien.

Les convertisseurs JSON et CSV envoient-ils mes fichiers ?

Non. Analyse, aplanissement et mise entre guillemets se passent tous dans votre onglet ; il n’existe aucun point d’envoi, et la Content-Security-Policy du site n’autorise les requêtes réseau que vers elle-même. Observer le panneau Network de DevTools pendant une conversion le confirme — rien ne quitte l’onglet, et c’est bien là l’intérêt des outils qui s’exécutent localement.

CSV est-il une vraie norme ?

Le cœur de CSV est la RFC 4180 : fins de ligne CRLF, délimiteur virgule, doublage des guillemets internes, et une ligne d’en-tête optionnelle que la norme note explicitement comme courante. Les dialectes réels persistent malgré tout — délimiteur point-virgule dans une bonne partie de l’Europe, variantes séparées par des tabulations, encodages incohérents avec ou sans BOM. La grammaire de JSON, qui tient sur une page, laisse bien moins de place aux dialectes.

Quel format gère mieux les très gros fichiers ?

CSV, en général. Les lignes peuvent être analysées puis jetées une à une avec une mémoire constante, si bien que la taille du fichier pèse à peine sur un lecteur en flux. JSON est typiquement analysé comme un document entier avant usage, pour une mémoire proportionnelle à la taille — des parseurs JSON en flux existent mais ne sont pas la norme. Pour d’énormes exports à plat, restez en CSV ; pour d’énormes exports imbriqués, pensez à JSON Lines.

Comment la conversion JSON vers CSV choisit-elle les colonnes ?

En parcourant les enregistrements et en prenant l’union des clés, dans l’ordre de première apparition, comme ligne d’en-tête ; les enregistrements à qui manque une clé reçoivent une cellule vide. Les objets et tableaux imbriqués ne peuvent pas tenir dans une colonne, donc les convertisseurs doivent les sérialiser en chaîne ou les joindre — le convertisseur de ce site documente le choix qu’il fait au lieu de le laisser à la surprise.

Où puis-je lire les normes citées ici ?

  • RFC 4180 — Format commun et type MIME des fichiers CSV (valeurs séparées par des virgules)
  • RFC 8259 — Le format d’échange de données JavaScript Object Notation (JSON)
Équipe ToolsByUs · Comment nous vérifions nos outils