YAML ou JSON

JSON est un format de données strict et minimal que tous les langages lisent de la même façon : c’est le choix par défaut pour les API et l’échange de données. YAML décrit les mêmes données (objets, listes, chaînes, nombres, booléens, null) avec l’indentation au lieu des accolades et accepte les commentaires, ce qui le rend plus agréable à écrire à la main pour les fichiers de configuration. Tout document JSON est aussi du YAML 1.2 valide, mais YAML a plus de pièges : erreurs d’indentation, valeurs transformées en booléens ou en dates, chargeurs non sûrs.

Convertisseur YAML en JSON →

Les mêmes données dans les deux formats

Une petite configuration de service en JSON :

{
  "name": "web",
  "replicas": 2,
  "ports": [80, 443],
  "env": {"DEBUG": "false"}
}

La même chose en YAML :

# front web
name: web
replicas: 2
ports:
  - 80
  - 443
env:
  DEBUG: "false"

YAML supprime les accolades, crochets, virgules et la plupart des guillemets, et ajoute un commentaire. La structure vient de l’indentation avec des espaces ; les tabulations sont interdites pour indenter.

Côte à côte

	JSON	YAML
Commentaires	Non	Oui (#)
Structure	Accolades et crochets	Indentation (espaces uniquement)
Guillemets sur les chaînes	Toujours	Souvent facultatifs
Plusieurs documents par fichier	Non	Oui (séparés par ---)
Réutiliser un bloc	Non	Ancres et alias (&nom, *nom)
Dates	Pas de type, chaînes	Certains analyseurs transforment 2026-11-10 en date
Usage typique	API, échange de données, package.json	Kubernetes, Docker Compose, GitHub Actions, Ansible, OpenAPI

Quels sont les pièges de YAML ?

Booléens implicites. Avec les analyseurs YAML 1.1, yes, no, on et off sans guillemets deviennent true ou false. Exemple classique : dans une liste de codes pays, NO (Norvège) devient false. Mettez ces valeurs entre guillemets : "NO".
Des nombres qui n’en sont pas. Une version 1.10 devient le nombre 1.1, et un code postal comme 01234 peut perdre son zéro ou être lu en octal. Mettez entre guillemets tout ce qui est en réalité un identifiant.
Indentation. Un espace de trop déplace une clé sous le mauvais parent, sans aucune erreur. Utilisez un éditeur qui montre l’indentation et validez le fichier.
Chargeurs non sûrs. Certaines bibliothèques YAML peuvent construire des objets arbitraires à partir de balises, ce qui a causé des failles d’exécution de code. Utilisez la fonction de chargement sûre (par exemple yaml.safe_load en Python) ; js-yaml 4 est sûr par défaut.

Lequel choisir ?

De machine à machine (réponses d’API, files de messages, journaux) : JSON, plus simple à analyser, sans ambiguïté et lu nativement par les navigateurs.
Fichiers modifiés par des personnes (configs de déploiement, pipelines CI) : YAML, pour les commentaires et la lisibilité, en mettant les valeurs ambiguës entre guillemets et en validant en CI.
L’outil décide le plus souvent : Kubernetes accepte les deux, GitHub Actions seulement YAML, package.json seulement JSON.

La conversion entre les deux ne perd pas de données ; seuls les commentaires, ancres et séparateurs de documents YAML n’ont pas d’équivalent en JSON. Pour voir exactement quelles valeurs sont devenues des chaînes, nombres ou booléens, convertissez votre YAML en JSON et lisez le résultat.

FAQ

Le JSON est-il du YAML valide ?

Oui pour YAML 1.2 : un document JSON peut être lu par un analyseur YAML 1.2. Les anciens analyseurs YAML 1.1 lisent aussi presque tout le JSON.

Peut-on mettre des commentaires dans un fichier JSON ?

Pas en JSON standard. Certains outils acceptent JSONC ou JSON5, mais un analyseur JSON strict les refusera.

Comment convertir du YAML en JSON ?

Collez le YAML dans le convertisseur YAML en JSON de ce site ; le convertisseur JSON en YAML fait l’inverse. Les deux fonctionnent dans votre navigateur.

Mis à jour : novembre 2026. Les fichiers sont traités dans votre navigateur et ne sont pas envoyés.

2026-11-12