Convertisseurs de données

Déplacer des données entre CSV, JSON, YAML et XML

Les données restent rarement figées dans un seul format. Un rapport arrive en feuille de calcul, une API veut du JSON, un pipeline de déploiement attend du YAML, et quelque part au sous-sol un service hérité parle encore XML. La majeure partie des frictions quotidiennes dans le travail sur les données ne vient pas des données elles-mêmes, mais du fait de les amener de la forme que vous avez à celle qu'autre chose réclame. C'est tout le rôle d'un convertisseur de données : prendre du texte structuré dans une notation et le réémettre dans une autre, sans en perdre le sens au passage.

Les convertisseurs de Speedor s'exécutent entièrement dans votre navigateur. Vous collez, vous cliquez, vous copiez le résultat. Rien n'est téléversé, rien n'est journalisé, et rien ne quitte votre machine. Pour quiconque a déjà hésité avant de déposer un export de clients dans un site web au hasard, c'est tout l'intérêt de cette conception purement locale.

Ce à quoi excelle réellement chaque format

Il est utile de savoir pourquoi ces formats existent avant de se mettre à passer de l'un à l'autre, car chacun a été conçu pour un travail différent.

CSV est la grille plate, séparée par des virgules, que les feuilles de calcul adorent. Il est tabulaire par nature : lignes et colonnes, rien d'imbriqué. Ouvrez-le dans Excel, Google Sheets ou Numbers et ça marche tout seul. Le hic, c'est que le CSV n'a aucune notion de type. La valeur 007 peut être une chaîne, un nombre ou un code postal, et le CSV ne vous dira pas lequel.

JSON est la lingua franca du web moderne. Presque toutes les API que vous appellerez le parlent. Le JSON gère l'imbrication, les tableaux et une poignée de vrais types (chaînes, nombres, booléens, null), ce qui le rend bien plus expressif qu'une table plate. Il est compact, adapté aux machines, et pris en charge partout.

YAML est le cousin plus lisible du JSON. Il utilise l'indentation plutôt que des accolades, prend en charge les commentaires, et tend à être le format de prédilection pour les fichiers de configuration, Docker Compose, les manifestes Kubernetes et les pipelines CI. Quand un humain doit éditer quelque chose à la main, le YAML est généralement plus doux pour les yeux.

XML est le doyen. Verbeux, lourd en balises, et toujours profondément ancré dans les systèmes d'entreprise, les services SOAP, la messagerie financière et des standards de documents comme le RSS. Vous le croiserez moins souvent dans les nouveaux projets, mais quand vous en avez vraiment besoin, vous en avez vraiment besoin.

Où les conversions ont vraiment lieu

Les scénarios deviennent assez concrets dès qu'on y regarde de près. Disons que le marketing vous remet une feuille de calcul de 4 000 contacts et que l'API d'inscription n'accepte qu'un tableau JSON. Vous exportez la feuille en CSV, vous la passez par CSV vers JSON, et vous avez une charge utile prête à envoyer en POST. Pas de script de bricolage, pas de pandas, pas d'attente d'un ingénieur.

Ou bien vous récupérez un morceau de JSON de cette même API et vous voulez le déposer dans un fichier de configuration que votre service lit au démarrage. Convertissez-le avec JSON vers YAML et vous obtenez quelque chose de propre et commentable qui s'insère parfaitement dans votre dépôt. L'inverse marche aussi quand un outil n'accepte que le JSON mais que votre configuration vit en YAML.

Et puis il y a l'intégration que personne n'apprécie : un système partenaire qui n'ingère que du XML. Vous construisez votre charge utile en JSON parce que c'est ainsi que votre application pense, puis vous convertissez en XML à la frontière. La forme reste la même, seule la syntaxe change.

Les pièges à connaître

La conversion de format n'est pas toujours sans perte, et prétendre le contraire mène à des bugs. Quelques points à garder en tête :

Le CSV oublie les types. Comme chaque cellule n'est que du texte, les nombres, booléens et dates ressortent tous comme des chaînes, à moins que le convertisseur ne devine pour vous. Si true doit être un booléen et non le mot « true », vérifiez la sortie avant de l'expédier.

Le YAML est attentif aux espaces. L'indentation n'est pas cosmétique en YAML, elle est structurelle. Une espace égarée peut changer la clé à laquelle appartient une valeur, et les tabulations sont carrément interdites. Après tout aller-retour JSON vers YAML, un coup d'œil rapide s'impose, ou repassez le résultat par un formateur de JSON pour confirmer que la structure a survécu.

XML et JSON ne se correspondent pas proprement. Le JSON a des tableaux ; le XML a des éléments répétés. Le JSON n'a d'attributs nulle part ; le XML en a partout. La plupart des convertisseurs adoptent une convention raisonnable, mais si votre XML utilise beaucoup d'attributs, le JSON qu'il produit aura une allure un peu différente d'un JSON écrit à la main. C'est attendu, pas un défaut.

La profondeur d'imbrication compte. Le CSV est plat, donc un JSON profondément imbriqué ne peut pas toujours se ramener en colonnes sans aplatir les clés (pensez à address.city). Dans l'autre sens, un CSV plat devient un tableau plat, jamais un arbre.

Pourquoi le tout-local compte ici

Beaucoup de données que vous voudrez convertir ne sont pas les vôtres à partager. Fiches d'utilisateurs, configurations internes, clés d'API enfouies dans une réponse, lignes financières. Bien des convertisseurs en ligne envoient discrètement votre collage à un serveur pour faire le travail. Speedor, non. La logique de conversion s'exécute dans votre onglet de navigateur, les données ne traversent jamais le réseau, et fermer l'onglet suffit comme nettoyage. C'est aussi plus rapide, puisqu'il n'y a pas d'aller-retour de téléversement, et ça fonctionne hors ligne une fois la page chargée. Gratuit, sans inscription, sans quota.

Questions fréquentes