Faut-il utiliser JSON ou YAML ?

Décidez selon qui lit le fichier. Utilisez JSON quand des machines échangent des données — il parse vite, sans ambiguïté, et chaque langage le lit nativement. Utilisez YAML pour la configuration que des humains maintiennent : l'indentation exprime la structure, les commentaires sont autorisés, et le texte long n'a pas besoin d'échappement. Les deux décrivent le même modèle de données et se convertissent l'un en l'autre, mais les commentaires, ancres et documents multiples de YAML sont perdus lors de la conversion en JSON, et JSON n'a pas de commentaires à reconvertir.

JSON ou YAML

L’essentiel : JSON délimite avec des accolades et YAML avec l'indentation : JSON pour les machines, YAML pour les humains qui éditent de la configuration. Commentaires, ancres et structure multi-documents ne survivent pas.

Débutant~4 min de lecturePublié le 2026-10-30Mis à jour le 2026-10-30

Quand utiliser JSON et quand utiliser YAML

L'essentiel : utilisez JSON pour les données machine-à-machine et YAML pour la configuration que des humains éditent ; préférez YAML quand il faut des commentaires, du texte multi-ligne ou des ancres, et JSON quand chaque langage doit parser la même charge utile sans ambiguïté.

Côte à côte

复制{
  "server": {
    "host": "127.0.0.1",
    "port": 8080
  }
}

复制server:
  host: 127.0.0.1
  port: 8080

Même structure. YAML abandonne la ponctuation et gagne une place pour un commentaire.

Où ils diffèrent

	JSON	YAML
Structure	Accolades et virgules	Indentation
Commentaires	Aucun	Oui
Chaînes	Guillemets doubles, échappement requis	Généralement nues
Texte multi-ligne	Échappements `\n` ou tableaux	Scalaires de bloc `
Réutilisation	Aucune	Ancres `&` et alias `*`
Documents multiples	Envelopper dans un tableau	Séparateurs `---`
Vitesse de parsing	Rapide	Plus lente, règles d'indentation
Ambiguïté	Très faible	`no` interprété comme booléen, indentation décalée

Cette dernière ligne est le vrai coût de YAML. En YAML 1.1, country: NO donne le booléen false, et version: 1.0 peut devenir un flottant. JSON n'a aucune typisation implicite.

Choisir

JSON : corps de requête et de réponse, messages service-à-service, colonnes JSON dans les bases de données, tout ce qui doit parser identiquement dans chaque langage.

YAML : les écosystèmes où c'est le défaut (Kubernetes, Ansible, GitHub Actions, Docker Compose) ; la configuration qui a besoin d'explications ; les fichiers dominés par du texte long comme les certificats, scripts ou SQL.

Ce que la conversion perd

YAML → JSON : tous les commentaires, la réutilisation par ancres (étendue en doublons), tous les documents sauf le premier, et l'orthographe originale des dates et booléens.

JSON → YAML : la distinction chaîne/nombre s'affaiblit, donc "8080" et 8080 ont tous deux besoin de guillemets explicites pour rester sûrs.

Convertissez pour les migrations et l'inspection ponctuelle. Ne maintenez pas le même fichier dans deux formats comme vues parallèles.

FAQ

Comment décider entre JSON et YAML ?

Commencez par qui lit et maintient le fichier : utilisez JSON quand un programme le génère, qu'il franchit des frontières de langages et qu'il doit parser de façon prévisible ; utilisez YAML quand un humain l'édite et a besoin d'explications de champs ou de long texte multi-ligne. Ils se convertissent l'un en l'autre, mais ne maintenez pas la même configuration dans les deux formats à long terme.

Pourquoi YAML produit-il plus d'ambiguïté de types ?

YAML a une typisation implicite, donc des valeurs comme NO, on ou 1.0 peuvent devenir des booléens, dates ou nombres. JSON n'a que des types explicites : une chaîne doit être entre guillemets, ce qui rend le parsing plus prévisible entre langages.

Les commentaires et ancres doivent-ils survivre à une conversion YAML vers JSON ?

Non. Les commentaires, ancres et documents multiples de YAML ne peuvent pas être représentés en JSON ; les ancres sont étendues en contenu dupliqué. Si vous devez les préserver, utilisez une bibliothèque YAML avec une API Document au lieu d'un aller-retour par objet.