Convertisseur JSON en YAML

Convertissez JSON en YAML et YAML en JSON dans votre navigateur

Le JSON et le YAML décrivent le même genre de données — cartes imbriquées, listes, chaînes, nombres et booléens — mais ils paraissent très différents et s'emploient à des endroits différents. Si vous passez un peu de temps près des API, des fichiers de conteneurs ou des pipelines d'intégration continue, vous finissez par devoir transformer l'un en l'autre. Cette page effectue cette conversion dans les deux sens, entièrement à l'intérieur de votre navigateur, de sorte que les données que vous collez ne quittent jamais votre machine.

Ce qu'est le JSON et où il vit

Le JSON (JavaScript Object Notation) est un format strict, à crochets et accolades, conçu d'abord pour les machines. Chaque objet est entouré de {}, chaque tableau de [], les clés et les valeurs de chaîne sont entre guillemets doubles, et les éléments sont séparés par des virgules. C'est le format d'échange par défaut des API REST et GraphQL, le corps de la plupart des webhooks, la forme des documents NoSQL, et ce que renvoie votre appel fetch. Presque tous les langages l'analysent d'emblée, et c'est précisément pourquoi il a conquis la couche API : JSON.parse en JavaScript, json dans la bibliothèque standard de Python, et leurs équivalents partout ailleurs. Le revers, c'est que le JSON est verbeux à écrire à la main et interdit les commentaires : c'est donc un mauvais format pour les fichiers qu'un humain édite à longueur de journée.

Ce qu'est le YAML et où il vit

Le YAML (YAML Ain't Markup Language) a été conçu selon la priorité inverse : l'humain d'abord. Il abandonne les accolades et les guillemets, utilise l'indentation pour exprimer l'imbrication, et permet d'écrire des commentaires avec #. Cette lisibilité explique pourquoi il est devenu la lingua franca de la configuration. Les fichiers Docker Compose, les manifestes Kubernetes, les workflows GitHub Actions et GitLab CI, les playbooks Ansible et d'innombrables fichiers de configuration d'applications sont tous en YAML. Un document YAML typique est nettement plus court que le JSON équivalent et bien plus facile à comparer dans une pull request. Le prix de cette élégance est la fragilité, et c'est là que la conversion devient intéressante.

Les différences clés qui comptent

Trois différences guident presque toute décision de conversion. Premièrement, les espaces sont significatifs en YAML et sans importance en JSON. Le YAML utilise des espaces — jamais de tabulations — pour marquer la structure, si bien qu'un seul espace mal aligné peut changer silencieusement le sens d'un document. Le JSON se moque totalement de l'indentation. Deuxièmement, le YAML prend en charge les commentaires et pas le JSON. Tout commentaire # en YAML disparaît simplement quand vous produisez du JSON, faute d'endroit où le mettre. Troisièmement, le YAML possède un typage plus riche et implicite. Il lit volontiers les dates, les horodatages et null sous plusieurs orthographes, et devine les types à partir des valeurs non entre guillemets. Le JSON dispose d'un petit ensemble de types explicites et sans ambiguïté. Notez aussi que le JSON est techniquement un sous-ensemble de YAML 1.2, raison pour laquelle un JSON valide s'analyse généralement proprement comme du YAML, mais l'inverse n'est pas garanti.

Pièges de conversion à surveiller

L'aller-retour n'est pas toujours sans perte, et il vaut la peine de savoir où les choses se brisent :

• Le problème de la Norvège. Selon les règles YAML 1.1, un NO non entre guillemets s'analyse comme le booléen false, et yes, on et off deviennent aussi des booléens. Un code de pays ou un libellé d'interrupteur peut basculer en true/false sans que vous le remarquiez. Mettez entre guillemets les valeurs que vous voulez traiter comme des chaînes.
• Coercition de nombres. Une version comme 3.10 peut perdre son zéro final et devenir 3.1, et 1.0 devient un nombre même quand vous vouliez du texte. Mettez entre guillemets les numéros de version et les identifiants.
• Les ancres et alias disparaissent. Les références &ancre et *alias du YAML n'ont pas d'équivalent JSON. Un bon convertisseur les développe en leur valeur complète, donc les données sont correctes mais la déduplication est perdue — un aller JSON vers YAML vers JSON ne reconstruira pas les ancres d'origine.
• Commentaires et scalaires de bloc. Les commentaires sont supprimés au passage vers JSON. Les scalaires de bloc multilignes (| et >) s'effondrent en chaînes JSON ordinaires avec des échappements \n : l'intention de mise en forme visuelle est donc perdue.
• Indentation au retour vers YAML. Le JSON ne code pas l'indentation, donc le convertisseur choisit un style cohérent. Vérifiez-le avant de coller dans un outil sensible aux tabulations.

Pourquoi le local uniquement compte

Les fichiers de configuration et les charges utiles d'API sont exactement le genre de choses qui ne devraient pas être téléversées vers un serveur quelconque : ils transportent souvent des noms d'hôtes, des jetons, des noms de services internes ou des données client. Ce convertisseur exécute l'étape d'analyse et d'émission dans votre navigateur avec JavaScript. Rien n'est envoyé à un serveur, rien n'est journalisé, et l'outil fonctionne hors ligne une fois la page chargée. Collez un secret Kubernetes ou un workflow d'intégration continue avec l'assurance qu'il reste sur votre machine.

Besoin d'outils connexes ? Parcourez l'ensemble de nos convertisseurs de données, nettoyez une entrée désordonnée avec le formateur JSON, et revenez ici chaque fois que vous devez naviguer entre le monde des API et celui de la configuration.

Questions fréquentes