Convertir CSV en JSON

Que fait le convertisseur ?

Le convertisseur lit un fichier CSV ou TSV et le convertit en JSON — en trois variantes de structure, selon l’usage du résultat. À la lecture, il reconnaît le séparateur, devine les types de colonne et respecte les zéros de tête, pour qu’un code postal français comme 01234 ne se transforme pas en nombre 1234.

Pur client. Chaque entrée reste dans votre navigateur. Pas de serveur, pas de mur de cookies, pas de tracking. Même les gros fichiers au-delà de cinq mégaoctets sont traités en local — via la sortie NDJSON qui évite le gonflement en un seul énorme tableau.

Quels dialectes CSV le convertisseur comprend-il ?

CSV n’est pas un standard unifié. Quatre presets couvrent les dialectes les plus fréquents qui apparaissent dans les workflows francophones.

RFC 4180 strict

RFC 4180 est la spécification qui sert depuis 2005 de standard international de facto. Virgule comme séparateur, point comme décimal, guillemets doubles comme escape — donc "O""Connor" pour un nom avec apostrophe. Les API anglophones, les exports de recherche et la plupart des tableurs US suivent ce profil.

Excel français

Excel français exporte par défaut différemment : point-virgule comme séparateur, virgule comme décimal, BOM UTF-8 en tête de fichier. Qui passe un CSV Excel français par un parseur RFC 4180 obtient une seule grosse colonne, parce que la virgule ne distingue pas le point milliers de la virgule décimale. Le profil Excel français prend en compte les trois particularités d’un seul clic.

Tabulé (TSV)

TSV utilise le caractère tabulation comme séparateur. Sans caractère visible, le TSV est en pratique plus robuste contre les conflits virgule ou point-virgule dans le contenu — la plupart des exports de recherche issus de R, Pandas et SPSS atterrissent donc en TSV. Ligne d’en-tête et quoting restent comme en CSV, seul le séparateur change.

Séparé par pipe

Le caractère pipe | comme séparateur est répandu dans les exports mainframe, SAP et ERP. L’avantage : le pipe n’apparaît pratiquement jamais en langage naturel, les collisions sont donc rares. L’inconvénient : Excel ne connaît pas le format par défaut et nécessite un choix de séparateur à l’import.

Quelles structures JSON le convertisseur livre-t-il ?

Trois structures, trois systèmes cibles.

Array of Objects

[{"name": "Alice", "age": 30}, {"name": "Bob", "age": 25}] — la forme la plus fréquente pour les API REST. Chaque ligne du CSV devient un objet ; la ligne d’en-tête fournit les clés. Lisible pour les humains, directement traitable par tout frontend JavaScript qui attend des données sous forme de listes de records.

Object of Arrays

{"name": ["Alice", "Bob"], "age": [30, 25]} — la forme orientée colonnes. Les bibliothèques comme Pandas, R DataFrames et D3.js aiment travailler avec cette structure, parce qu’elle est plus efficace pour les opérations de colonne (moyenne, filtre, plot) que la conversion depuis un tableau de records.

NDJSON

NDJSON — un objet JSON par ligne, sans tableau englobant :

{"name":"Alice","age":30}
{"name":"Bob","age":25}

Streamable : un lecteur NDJSON lit ligne par ligne et n’a pas besoin de charger tout le fichier en mémoire. Pour des fichiers CSV au-delà de cinq mégaoctets, le convertisseur suggère automatiquement NDJSON, parce qu’un tableau de 100 000 objets en chaîne JSON atteint immédiatement plusieurs centaines de mégaoctets.

Comment le convertisseur protège-t-il les zéros de tête ?

Les zéros de tête sont l’erreur la plus fréquente en conversion CSV vers JSON. Dès qu’une cellule comme 01234 (code postal français) est interprétée comme nombre, le zéro disparaît et la base d’adresses est cassée. Trois heuristiques l’empêchent :

Zéros de tête cohérents

Si l’analyseur de colonne détecte que chaque cellule non vide d’une colonne commence par 0 et fait au moins trois chiffres, il classifie la colonne comme chaîne — même si le reste de la cellule est composé de chiffres. Une colonne code postal avec 01234, 75001, 13001 devient ainsi automatiquement chaîne, pas nombre.

Détection IBAN

IBAN a un motif clair : deux lettres (code pays), deux chiffres de contrôle, puis 10 à 30 caractères alphanumériques. Si l’outil reconnaît le motif dans chaque ligne d’une colonne, elle reste chaîne — même si les IBAN FR ne contiennent que des chiffres après le code pays.

Détection téléphone

Les numéros de téléphone contiennent souvent +, des tirets, des parenthèses ou des espaces. Dès qu’une colonne contient des valeurs avec dix chiffres ou plus ET au moins un caractère non-chiffre, l’analyseur la classifie comme chaîne. Ainsi +33 1 23 45 67 89 reste chaîne téléphone, au lieu de devenir un nombre absurde.

Override manuel

L’heuristique est conservatrice — elle se trompe plutôt en faveur de chaîne qu’en faveur de nombre. Qui veut quand même une colonne zéro-de-tête détectée comme nombre change le type par colonne via le dropdown du panneau colonne. Le changement vaut dès le prochain rendu de la sortie.

Comment fonctionne la notation point pour JSON imbriqué ?

Un en-tête CSV plat comme name,email,cp donne un objet JSON plat. Si les données source sont structurées — par exemple une table d’adresses — la notation point vaut la peine :

user.name,user.email,user.address.cp
Ada,[email protected],75001

devient

[
  {
    "user": {
      "name": "Ada",
      "email": "[email protected]",
      "address": { "cp": "75001" }
    }
  }
]

Plusieurs chemins sous le même préfixe atterrissent automatiquement dans le même objet. Le chemin inverse (tab JSON-vers-CSV) reconvertit les arbres imbriqués en en-têtes CSV plats via la même notation — un format roundtrip-able.

Quand le mode bidirectionnel vaut-il la peine ?

Certains workflows nécessitent le chemin dans les deux sens : exporter CSV, ajuster dans l’éditeur JSON, retourner en CSV. Le second tab JSON-vers-CSV utilise le même profil et le même choix de séparateur que le chemin aller. Qui colle un tableau d’objets en JSON obtient un CSV avec ligne d’en-tête et quoting RFC 4180 ; les champs imbriqués sont aplatis en notation point.

Quelles limites de taille s’appliquent en pratique ?

Pur client ne veut pas dire « arbitrairement grand ». Trois seuils déterminent le comportement du convertisseur selon les tailles de fichier.

Sous 5 Mo — mode standard

Jusqu’à cinq mégaoctets CSV — typiquement quelques milliers de lignes — le convertisseur convertit directement. Array of Objects ou Object of Arrays fonctionnent sans friction. Le panneau résultat affiche le JSON immédiatement, copiable d’un clic.

5 à 50 Mo — NDJSON recommandé

À partir de cinq mégaoctets, le convertisseur suggère la sortie NDJSON via bannière. Contexte : un tableau de 100 000 objets atterrit en chaîne JSON rapidement à 30 ou 80 mégaoctets, ce qui ralentit visiblement le rendu et fige le copy-to-clipboard pendant plusieurs secondes. NDJSON contourne cela parce qu’il est streamable ligne par ligne.

Au-delà de 50 Mo — splitter

La mémoire du navigateur suffit généralement à cent mégaoctets, mais le temps de rendu pour un énorme champ résultat rend l’UI lente. Pour plusieurs centaines de mégaoctets de CSV, il est plus rapide de splitter le fichier hors du navigateur — par exemple avec un script shell — et de convertir bloc par bloc.

Quels outils liés existent ?

• Nettoyer CSV — pour les fichiers CSV défectueux avec mojibake, séparateurs mélangés ou en-têtes en double. Étape préalable à ce convertisseur, si l’input n’est pas propre.
• JSON vers CSV — la direction inverse spécialisée, si vous n’avez besoin que de JSON-vers-CSV sans les options d’entrée CSV.
• CSV vers Markdown — si le format cible doit être une table Markdown au lieu de JSON.
• Formateur JSON — formate et valide le JSON généré, avant de le traiter plus loin.