Convertisseur JSON vers YAML (et YAML vers JSON)

Qu'est-ce qu'un convertisseur JSON vers YAML ?

JSON et YAML servent tous deux à représenter des données structurées, mais ne se lisent pas de la même façon : JSON s’écrit avec des accolades, des crochets et des guillemets partout, tandis que YAML s’appuie sur l’indentation et ressemble presque à du texte brut. Un convertisseur JSON vers YAML transforme l’un en l’autre sans que vous ayez à retaper quoi que ce soit à la main.

Parce que YAML est un sur-ensemble de JSON — tout document JSON valide est déjà du YAML valide — l’outil fonctionne aussi dans l’autre sens : collez du YAML (ou même du JSON, qui reste accepté) et repartez avec du JSON propre, prêt à être consommé par une application. Un seul sélecteur en haut de la page bascule entre les deux sens.

Comment l'utiliser

1. Choisissez le sens de la conversionen haut de la page, entre JSON → YAML et YAML → JSON, puis collez votre contenu dans la zone de texte, ou cliquez sur « Charger un exemple » pour voir l’outil en action.
2. Réglez l’indentation : vers YAML au choix en 2 ou 4 espaces ; vers JSON en 2 ou 4 espaces, en tabulation, ou minifié sur une seule ligne. Le résultat se met à jour immédiatement dans le panneau en lecture seule.
3. Copiez le résultatd’un clic sur le bouton Copier, qui affiche « Copié ! » pendant deux secondes pour confirmer, ou effacez tout pour repartir de zéro. Si l’entrée contient une erreur, la ligne et la colonne exactes s’affichent à la place du résultat.

Ce qui survit à la conversion et ce qui ne survit pas

Le sens JSON vers YAML ne perd presque rien : JSON étant un sous-ensemble de YAML, chaque valeur, chaque type et chaque structure imbriquée se retrouve de l’autre côté, juste réécrite avec une syntaxe plus légère. La seule exception tient aux très grands nombres, détaillée plus bas. Le sens YAML vers JSON, lui, fait apparaître d’autres pertes, parce que YAML autorise des choses que JSON n’a jamais eu besoin de représenter.

La plus connue de ces subtilités s’appelle le « problème norvégien » : en YAML 1.1, un mot nu comme NO — le code pays de la Norvège — était interprété comme le booléen faux, ce qui a provoqué de vrais bugs dans des fichiers de configuration réels. Cet outil s’appuie sur le schéma core de YAML 1.2, qui règle le problème : country: NOressort bien comme la chaîne « NO », tout comme yes, no, on et off restent des chaînes de caractères. Seuls true et false, quelle que soit leur casse, sont lus comme des booléens. La même prudence s’applique aux valeurs qui ressemblent à des nombres ou des dates sans en être : 12:30 reste la chaîne « 12:30 » au lieu de devenir 750 comme le ferait un lecteur YAML 1.1 en base 60, et 2024-01-15 reste une chaîne plutôt que de se transformer en date.

Les nombres, en revanche, perdent réellement la façon dont ils ont été écrits, et ça n’a rien à voir avec la version de YAML : 1.10 ressort en 1.1, et 0123 ressort en 123, parce qu’un nombre YAML devient un nombre ordinaire, qui ne conserve ni les zéros de tête ni les zéros de queue. C’est le genre de détail qui passe inaperçu jusqu’à ce qu’il touche un numéro de version : si vous voulez le garder tel quel, mettez-le entre guillemets avant de convertir.

Les très grands entiers subissent une perte plus sérieuse, et celle-ci vaut dans les deux sens : au-delà d’environ 9 millions de milliards (2⁵³), un nombre n’est plus représentable exactement, si bien que 12345678901234567890 ressort en 12345678901234567000 — les derniers chiffres significatifs disparaissent silencieusement dans la plupart des convertisseurs. Celui-ci ne laisse pas passer ça sans le dire : il détecte la perte et nomme la clé exacte concernée, par exemple rows[0].id, en affichant côte à côte la valeur d’origine et ce qu’elle est devenue.

JSON n’a jamais eu de syntaxe pour les commentaires, donc tout commentaire présent dans votre YAML disparaît à la conversion — l’outil vous prévient quand c’est le cas. La détection comprend le contexte : un #à l’intérieur d’une chaîne entre guillemets n’est pas traité comme un commentaire, et un #!/bin/shen tête d’un bloc littéral est reconnu comme le contenu d’un script, donc pas de fausse alerte sur vos fichiers.

YAML permet aussi de définir un bloc une seule fois avec &defaults et de le référencer ailleurs avec *defaults; JSON n’a pas cette notion de renvoi, donc le contenu est dupliqué à chaque endroit où il était utilisé et le lien entre les copies est perdu — l’outil le signale. Trois autres cas sont refusés plutôt que devinés : les clés en double, parce que YAML les interdit et que garder silencieusement la dernière masquerait un vrai bug dans votre fichier ; les fichiers à plusieurs documents séparés par ---, très courants dans les manifestes Kubernetes mais sans équivalent en JSON, à convertir un par un ; et l’indentation par tabulations, que la spécification YAML n’autorise pas.

Quand a-t-on vraiment besoin de ça ?

YAML domine partout où un humain doit relire et modifier un fichier de configuration à la main : les workflows CI, les manifestes Kubernetes, les fichiers Docker Compose ou encore les spécifications OpenAPI s’écrivent presque tous en YAML pour cette lisibilité, alors que les API et les bibliothèques avec lesquelles ils dialoguent parlent JSON. Ce convertisseur sert exactement ce pont : reprendre la réponse JSON d’une API pour la coller dans un manifeste, ou inversement transformer un docker-compose.yml en JSON pour le manipuler par script.

Pourquoi cet outil est-il gratuit ?

Toute la conversion se déroule dans votre navigateur : aucun fichier n’est envoyé à un serveur, ce qui veut dire qu’elle ne coûte rien à faire tourner, quel que soit le nombre de personnes qui l’utilisent. Il n’y a donc ni compte à créer, ni inscription, ni fichier à téléverser, ni filigrane sur le résultat — juste un outil qui convertit et qui reste gratuit parce qu’il ne consomme aucune ressource serveur.