Convertir CSV en JSON

Le CSV (Comma Separated Values) est le format universel des tableurs, tandis que le JSON est le standard des API web. Convertir du CSV en JSON est une étape fréquente pour les développeurs, analystes de données et intégrateurs qui doivent faire communiquer ces deux mondes.

Le processus utilise la première ligne du CSV comme clés (noms des colonnes), puis chaque ligne suivante devient un objet JSON avec ces clés. Le résultat est un tableau JSON d'objets. Notre outil détecte automatiquement le séparateur utilisé (virgule, point-virgule, tabulation) et gère les valeurs entre guillemets contenant des séparateurs.

Le séparateur n'est pas toujours une virgule, malgré le nom du format

Le sigle CSV signifie « valeurs séparées par des virgules », mais dans la pratique le séparateur varie, et se tromper produit un JSON à une seule clé contenant toute la ligne. Trois séparateurs dominent. La virgule est la convention d'origine et celle des systèmes anglophones. Le point-virgule règne sur les exports de tableurs configurés en français, parce que la virgule y sert de séparateur décimal. La tabulation apparaît sur les exports de bases de données et les copier-coller depuis un tableur. Une détection automatique fiable ne se contente pas de compter les occurrences dans la première ligne. Elle compare, pour chaque séparateur candidat, le nombre de colonnes obtenu sur plusieurs lignes : le bon séparateur est celui qui produit un nombre de colonnes constant. Un fichier contenant des virgules décimales et séparé par des points-virgules piégerait un simple comptage. Deuxième subtilité : la première ligne est-elle un en-tête ou une donnée ? Rien dans le format ne le dit. La convention veut qu'elle contienne les noms de colonnes, qui deviendront les clés du JSON, mais un export brut peut très bien commencer directement par les données. L'indice le plus fiable est le typage : si la première ligne ne contient que du texte alors que les suivantes contiennent des nombres, c'est un en-tête. Enfin, méfiez-vous des noms de colonnes en double. Le CSV les tolère sans broncher, le JSON beaucoup moins : deux clés identiques dans un même objet donnent un résultat imprévisible, la plupart des analyseurs conservant silencieusement la dernière.

Tout est une chaîne dans un CSV : le problème du typage

Un fichier CSV ne contient que du texte. Il n'a aucun moyen de distinguer le nombre 42 de la chaîne « 42 ». Le JSON, lui, distingue les nombres, les chaînes, les booléens et la valeur nulle. La conversion doit donc deviner, et c'est là que les données s'abîment. Le cas le plus coûteux est celui des zéros en tête. Un code postal comme 01000, un numéro de téléphone commençant par zéro, un identifiant produit à longueur fixe : convertis en nombre, ils perdent leur premier caractère et deviennent 1000. L'information est détruite, sans message d'erreur. Ces champs doivent rester des chaînes, toujours. Le deuxième piège concerne les nombres décimaux. Un fichier français écrit 12,50 avec une virgule ; le JSON n'accepte que le point. Une conversion naïve traite « 12,50 » comme une chaîne de caractères et le laisse tel quel, ce qui donne un JSON syntaxiquement valide mais inutilisable pour du calcul. Le troisième concerne les grands nombres. Le JSON n'impose pas de limite, mais la plupart des environnements qui le consomment stockent les nombres en virgule flottante double précision, ce qui garantit l'exactitude jusqu'à environ neuf mille milliards de milliards. Au-delà, les derniers chiffres se mettent à changer silencieusement. Un identifiant très long, un numéro de compte ou un horodatage en nanosecondes doivent donc être conservés en chaîne, même s'ils ne contiennent que des chiffres. Restent les valeurs vides. Une cellule vide doit-elle devenir une chaîne vide, la valeur nulle, ou une clé absente ? Les trois se défendent selon l'usage, mais il faut choisir une convention et s'y tenir sur tout le fichier : rien n'est plus pénible qu'un JSON où l'absence d'information s'exprime de trois façons différentes.

Reconstruire une hiérarchie à partir d'un tableau plat

La conversion inverse, du JSON vers le CSV, aplatit. Celle-ci peut faire le chemin retour, à condition que les noms de colonnes portent l'information de structure. La convention la plus courante est la notation par points. Des colonnes nommées « client.nom » et « client.ville » se regroupent en un objet client contenant deux propriétés, au lieu de deux propriétés séparées au premier niveau. Le procédé se répète sur autant de niveaux qu'il y a de points. Certains exports utilisent des crochets numérotés pour les tableaux : des colonnes « commandes[0].montant » et « commandes[1].montant » se reconstruisent en un tableau de deux objets. C'est le moyen le plus fidèle de faire l'aller-retour sans perte, mais il produit des en-têtes peu lisibles pour un humain. Attention à un point : cette reconstruction n'est pas automatique et ne doit pas l'être. Une colonne légitimement nommée « prix.unitaire » dans un fichier métier, sans intention de hiérarchie, serait transformée à tort en objet imbriqué. Un bon convertisseur propose l'aplatissement inverse comme une option explicite, pas comme un comportement par défaut. La conversion la plus sûre reste donc la plus littérale : une ligne du CSV devient un objet plat du tableau JSON, une colonne devient une clé. C'est ce que veulent la plupart des usages — alimenter une API, charger un jeu de données, produire un fichier de configuration — et cela évite les surprises sur les fichiers dont vous ne maîtrisez pas la provenance.

• Excel français exporte en point-virgule (;) par défaut — notre outil le détecte automatiquement
• Les valeurs entre guillemets peuvent contenir des virgules sans problème
• Vérifiez l'encodage : UTF-8 est recommandé pour les caractères spéciaux (accents)

Questions supplémentaires