Quelle est la principale différence entre YAML et JSON ?

YAML est conçu pour la lisibilité humaine — indentation plutôt que crochets, commentaires autorisés, chaînes le plus souvent sans guillemets. JSON est conçu pour la lisibilité machine et l'échange de données — strict, sans commentaires, tout explicite avec accolades et guillemets. YAML 1.2 est un superset de JSON, un JSON valide est aussi un YAML valide.

La conversion YAML vers JSON perd-elle des données ?

Les commentaires sont toujours perdus — JSON n'a pas de syntaxe de commentaires. Les ancres et alias YAML sont résolus et inlinés. Les tags YAML personnalisés sont abandonnés à moins que le parseur sache les gérer. Pour les fichiers de configuration standard avec de simples scalaires, maps et séquences, la conversion est sans pertes.

Quels sont les pièges des booléens YAML ?

En YAML 1.1, yes, no, on, off, true et false sont tous traités comme des booléens. Donc 'country: no' devient le booléen false en JSON. YAML 1.2 a limité les booléens à true et false seulement, mais beaucoup de parseurs utilisent encore les règles 1.1. Toujours mettre des guillemets si on veut des chaînes.

Le roundtrip JSON-vers-YAML-vers-JSON est-il sûr ?

Structurellement oui — objets, tableaux, chaînes, nombres et booléens mappent proprement dans les deux sens. Ce qui ne peut pas être récupéré : les commentaires (n'existent pas en JSON) et les choix de formatage YAML manuscrits. Le YAML issu d'une conversion JSON-vers-YAML a l'air généré par une machine.

YAML est-il un superset de JSON ?

Selon la spécification YAML 1.2, techniquement oui. En pratique, les anciens parseurs YAML 1.1 ont des cas limites — notamment autour des nombres avec des zéros initiaux (que JSON n'autorise pas) et du jeu de booléens élargi. Pour la plupart des usages réels, traiter JSON comme YAML valide est sûr.

YAML vers JSON — Quand convertir, comment ça fonctionne et ce qui est perdu

Il y a quelques années, j'aidais une équipe à migrer son pipeline CI/CD d'une plateforme à une autre. L'ancien système utilisait JSON pour ses définitions de pipelines. Le nouveau utilisait YAML. Pas un gros problème en théorie — les deux formats décrivent les mêmes données hiérarchiques, non ?

En pratique, j'ai passé une quantité embarrassante de temps à convertir manuellement des accolades en indentation, à enlever les guillemets des clés, et à me souvenir que le null de JSON devient ~ ou null en YAML selon l'humeur du parseur. Un travail fastidieux et source d'erreurs. Finalement, quelqu'un m'a montré un outil de conversion et je me suis senti vraiment stupide de ne pas en avoir utilisé un dès le début.

Cette expérience est courante. YAML et JSON sont partout dans le développement moderne — configs CI, Docker Compose, manifestes Kubernetes, réponses d'API, métadonnées de packages — et ils se recoupent assez souvent pour qu'on doive un jour déplacer des données de l'un à l'autre.

Ce que YAML et JSON sont vraiment

Aucun des deux n'est un langage de programmation. Ce sont des formats de sérialisation de données — des façons de représenter des données structurées sous forme de texte pour que différents systèmes puissent les lire et les écrire.

JSON (JavaScript Object Notation) a été conçu au début des années 2000 comme alternative légère à XML pour envoyer des données entre clients web et serveurs. Strict, minimal et explicite : chaque chaîne entre guillemets, chaque objet entre accolades, chaque tableau entre crochets, exactement six types de valeurs (chaîne, nombre, objet, tableau, booléen, null). Pas de commentaires, pas de chaînes multi-lignes sans échappement, pas de moyen de référencer une valeur définie précédemment.

YAML (YAML Ain't Markup Language — oui, récursif) est arrivé plus tard et a été explicitement conçu pour la lisibilité humaine. Indentation pour exprimer l'imbrication, chaînes non quotées la plupart du temps, commentaires avec #, et ancres et alias pour définir une valeur une fois et la référencer ailleurs. YAML 1.2 se définit comme un superset de JSON.

En pratique, JSON est le format qu'on utilise pour communiquer avec des APIs et avoir une communication fiable entre machines. YAML est le format qu'on utilise quand des humains écrivent et maintiennent la configuration — l'indentation est plus rapide à parcourir que les crochets, les commentaires sont précieux dans les fichiers de config.

Quand on a vraiment besoin de convertir

Migration de plateforme CI/CD : Différentes plateformes ont différentes préférences. GitHub Actions utilise YAML, certaines vieilles configs Jenkins utilisent JSON. Migrer signifie convertir les définitions de pipelines.

Kubernetes et REST APIs : kubectl accepte YAML, l'API Kubernetes elle-même fonctionne en JSON. Scripter directement contre l'API ? JSON. Écrire des manifestes pour les humains ? YAML.

Fichiers de configuration et defaults d'applications : Beaucoup d'applications livrent leurs configs par défaut en JSON (parce que générées par machine) mais les documentent en YAML (parce que les humains lisent les docs).

Déboguer des réponses d'API : Les APIs retournent du JSON. Parfois on veut inspecter une réponse, l'éditer et la rejouer — en YAML c'est parfois plus facile à lire.

Ce que fait un convertisseur YAML-vers-JSON

La conversion se fait en deux étapes : parser le YAML en structure de données en mémoire, puis sérialiser cette structure en JSON.

Les ancres et alias YAML sont résolus : YAML permet de définir une valeur avec &anchor et de la référencer avec *alias. En JSON il n'y a pas d'équivalent — la valeur référencée est simplement répétée inline partout où elle est utilisée. Le JSON résultant est correct mais plus verbeux.

L'inférence de types se produit : YAML fait du typage implicite. Un true nu devient un booléen, 42 un entier, 3.14 un flottant. JSON ne connaît pas les dates et ne distingue pas les entiers des flottants.

Les commentaires sont supprimés : C'est la perte la plus douloureuse. Les commentaires utiles qui expliquent pourquoi un timeout est à 30 secondes ou ce que fait un flag cryptique — disparus après la conversion. JSON n'a pas de syntaxe de commentaires.

Le cauchemar des booléens YAML 1.1 vs 1.2

En YAML 1.1, les valeurs suivantes sont toutes traitées comme des booléens :

true, false, yes, no, on, off
TRUE, FALSE, YES, NO, ON, OFF
True, False, Yes, No, On, Off

Ça signifie que l'innocent activé: yes devient "activé": true. Et pays: NO — peut-être un code pays ISO ? — devient "pays": false.

YAML 1.2 a réglé ça en 2009 en restreignant les booléens à true et false uniquement. Mais étonnamment, beaucoup de parseurs YAML implémentent encore les règles 1.1.

La règle sûre : dans tout fichier YAML qui pourrait être converti, mettre entre guillemets toute chaîne qui ressemble à un booléen. Écrire pays: "NO" et activé: "oui" si on veut des chaînes. C'est le genre de bug qui prend trois heures à tracer et cinq secondes à corriger.

Le roundtrip est-il sûr ?

YAML vers JSON vers YAML : Les commentaires sont perdus, les définitions d'ancres sont perdues (on obtient des valeurs répétées), tous les choix de formatage du YAML original sont perdus. Le YAML résultant est correct mais ressemble à du code machine.

JSON vers YAML vers JSON : Pour du JSON standard, c'est en fait très sûr. Puisque JSON est un subset de YAML, le roundtrip préserve toutes les données.

Conclusion pratique : utiliser la conversion pour les tâches unidirectionnelles ou dans la même direction. Si on doit maintenir une config YAML et une représentation JSON en parallèle, garder l'une comme source de vérité et générer l'autre à partir d'elle.

L'outil YAML-vers-JSON sur ToolboxHubs

Le convertisseur YAML-vers-JSON gère tout ce qui est décrit ci-dessus :

Coller le YAML — Accepte tout, des simples configs clé-valeur aux manifestes Kubernetes profondément imbriqués.
La sortie JSON apparaît immédiatement — La conversion s'exécute dans le navigateur, rien n'est envoyé à un serveur.
Copier le résultat — Appuyer sur le bouton de copie, c'est terminé.

L'outil gère les ancres, les chaînes multi-lignes, tous les types booléens, les valeurs null et les structures imbriquées. Il valide aussi le YAML pendant la saisie — en cas d'erreur d'indentation ou de document malformé, un message d'erreur s'affiche plutôt qu'une sortie silencieusement incorrecte.

Pour aller dans l'autre sens, le convertisseur JSON-vers-YAML est disponible. Même principe, direction inverse.

YAML vs JSON : la prise de position

YAML quand les humains sont les auteurs et lecteurs principaux : Fichiers de configuration, définitions de pipelines CI, manifestes Kubernetes, playbooks Ansible — ces fichiers vivent dans le contrôle de version et sont lus, révisés et débogués par des personnes. La lisibilité de YAML et le support des commentaires comptent vraiment.

JSON quand les machines sont les productrices ou consommatrices principales : Réponses d'API, enregistrements de base de données, configuration générée, échange de données entre services — ces données ne bénéficient pas de la lisibilité car personne ne les écrit à la main. La rigueur et le support universel de JSON sont ce qui compte.

À la frontière — recevoir du JSON d'une API mais configurer un système basé sur YAML, ou l'inverse — la conversion est juste un outil dans le workflow. L'important est de comprendre ce qui peut changer dans la conversion et de vérifier quand quelque chose se passe mal.

Outils complémentaires

Validateur YAML — Avant de convertir, vérifier que le YAML est valide.

Formateur JSON — Après la conversion, le JSON peut sortir en une seule longue ligne. Le formateur le met en forme avec une indentation configurable.

JSON vers YAML — La direction inverse. Même workflow.

En conclusion

YAML et JSON sont tous deux de bons formats de données, adaptés à des situations différentes. Travailler à leur frontière — les humains écrivent du YAML, les systèmes attendent du JSON, ou l'inverse — fait de la conversion une tâche routinière.

Le convertisseur YAML-vers-JSON prend en charge la partie mécanique. Comprendre ce qui est perdu dans la conversion — commentaires, ancres, formatage — c'était l'objectif de cet article.