YAML et JSON sont deux formats populaires de fichiers de configuration pour stocker des données structurées, mais ils font des compromis très différents. YAML est conçu pour être lisible par les humains, en utilisant l'indentation et une ponctuation minimale, tandis que JSON est un format strict et convivial pour les machines, basé sur les accolades et les chaînes entre guillemets. Le choix entre les deux dépend généralement de qui (ou quoi) lira le fichier le plus souvent.
Table des matières
Qu'est-ce que YAML et JSON ?
Les deux formats sont utilisés pour la sérialisation de données, ce qui signifie simplement transformer des données structurées (objets, listes, paires clé-valeur) en un format texte qui peut être sauvegardé dans un fichier ou envoyé sur un réseau. Ils se chevauchent beaucoup en termes de capacités, mais ils proviennent de philosophies de conception différentes.
- JSON (JavaScript Object Notation) a été défini au début des années 2000 et est maintenant spécifié dans la RFC 8259 . Il est issu de la syntaxe JavaScript et est devenu le format de données par défaut pour les API REST.
- YAML (YAML Ain't Markup Language) a été conçu spécifiquement pour être lisible par les humains. C'est un sur-ensemble de JSON, ce qui signifie que tout JSON valide est aussi du YAML valide, mais YAML ajoute beaucoup plus de flexibilité par-dessus.
Syntaxe Côte à Côte
Le moyen le plus rapide de comprendre la différence est de regarder les mêmes données écrites dans les deux formats. Voici une configuration d'application simple exprimée en exemple YAML par rapport à JSON :
Version YAML :
server:
host: localhost
port: 8080
debug: true
database:
name: myapp_db
max_connections: 10
allowed_origins:
- https://example.com
- https://app.example.com
Version JSON :
{
"server": {
"host": "localhost",
"port": 8080,
"debug": true
},
"database": {
"name": "myapp_db",
"max_connections": 10
},
"allowed_origins": [
"https://example.com",
"https://app.example.com"
]
}
Les deux fichiers contiennent exactement les mêmes données. YAML utilise l'indentation pour montrer l'imbrication. JSON utilise des accolades, des crochets et des virgules. La version YAML est notablement plus courte et plus facile à scanner en un coup d'œil.
Différences Principales
| Fonctionnalité | YAML | JSON |
|---|---|---|
| Commentaires |
Supportés avec
#
|
Non supportés |
| Guillemets Autour des Chaînes | Optionnels dans la plupart des cas | Toujours requis |
| Virgules Finales | Non applicable | Non autorisées (causent des erreurs d'analyse) |
| Chaînes Multiligne |
Support natif (
|
et
>
opérateurs)
|
Nécessite des
\n
séquences d'échappement
|
| Types de Données | Déduit les types automatiquement | Explicites (nombres, chaînes, booléens) |
| Ancres et Alias | Supportés (réutiliser des blocs) | Non supportés |
| Disponibilité du Parseur | Bonne, mais varie selon la bibliothèque | Intégrée à chaque langage/runtime moderne |
| Taille du Fichier | Généralement plus petite | Légèrement plus grande en raison de la ponctuation |
yes
en YAML est analysée comme un booléen
true
dans de nombreux parseurs, et non comme la chaîne « yes ». Les codes de pays comme
NO
(Norvège) ou les numéros de version comme
1.0
peuvent aussi être mal interprétés. Mets toujours entre guillemets les chaînes qui pourraient être ambiguës.
Quand Utiliser YAML
YAML excelle dans les situations où les humains écrivent et maintiennent directement le fichier de configuration. Les utilisations courantes dans le monde réel incluent :
-
Pipelines CI/CD
comme GitHub Actions (
.github/workflows/*.yml), GitLab CI (.gitlab-ci.yml) et les configurations CircleCI - Manifestes Kubernetes , où chaque définition de ressource est un fichier YAML
-
Fichiers Docker Compose
(
docker-compose.yml) - Playbooks Ansible et fichiers d'inventaire
-
Fichiers de Configuration d'Application
pour des frameworks comme Ruby on Rails (
database.yml) et Spring Boot (application.yml)
Le support des commentaires seul est une raison majeure pour laquelle les développeurs préfèrent YAML pour les fichiers de configuration. Pouvoir écrire
# This port must match the nginx upstream
directement dans le fichier est inestimable dans les environnements d'équipe où le contexte compte.
Les ancres YAML sont une autre fonctionnalité sous-utilisée. Tu peux définir un bloc une fois et le réutiliser :
defaults: &defaults
timeout: 30
retries: 3
production:
<<: *defaults
host: prod.example.com
staging:
<<: *defaults
host: staging.example.com
Quand Utiliser JSON
JSON est le meilleur choix quand les machines sont les consommatrices principales des données. Reste avec JSON quand :
- Tu construis ou consommes une API. Les API REST utilisent presque universellement JSON. Il se mappe directement aux objets JavaScript et est analysé nativement par les navigateurs sans aucune bibliothèque supplémentaire.
- Tu as besoin d'une compatibilité maximale du parseur. Les parseurs JSON sont intégrés à Python, Node.js, Go, Java, Rust, Ruby et à chaque navigateur majeur. Les parseurs YAML sont des dépendances externes.
- Le fichier est généré par machine. Les outils qui écrivent des fichiers de configuration ou de données par programmation (comme les gestionnaires de paquets) ont tendance à générer du JSON car il est plus simple à sérialiser correctement.
-
Tu utilises
package.json,tsconfig.jsonou des fichiers d'écosystème similaires. Les écosystèmes Node.js et TypeScript sont JSON-first par convention. - Tu as besoin d'une validation stricte. JSON Schema est une norme mature et largement supportée pour valider la structure des documents JSON. Pour un guide complet sur la mise en œuvre de la validation dans tes projets, consulte notre article sur la validation JSON Schema.
Conversion Entre YAML et JSON
Les deux formats sont structurellement équivalents dans la plupart des cas, donc la conversion entre eux est simple. Tu devras généralement convertir YAML en JSON quand un outil ou une API attend du JSON mais ta configuration est écrite en YAML, ou quand tu veux valider plus facilement la structure de ton YAML.
Puisque YAML est un sur-ensemble de JSON, la conversion est sans perte pour tous les types de données standard. Les principales choses qui ne survivent pas à une conversion YAML-to-JSON sont les fonctionnalités spécifiques à YAML comme les commentaires, les ancres et les alias, car JSON n'a pas d'équivalents pour ceux-ci.
Pour une conversion rapide basée sur le navigateur sans que tes données ne quittent ta machine, tu peux utiliser un outil de conversion YAML en JSON dédié qui gère l'analyse et le formatage automatiquement. C'est particulièrement pratique quand tu passes entre des fichiers YAML d'infrastructure en tant que code et des payloads d'API qui doivent être en JSON.
Convertis YAML en JSON instantanément, directement dans ton navigateur
Tu travailles avec des fichiers de configuration YAML par rapport à JSON et tu dois changer de format rapidement ? Notre convertisseur YAML en JSON gratuit gère la transformation côté client, donc tes données de configuration ne quittent jamais ta machine.
Essaie le Convertisseur YAML en JSON →
Pas exactement. YAML est un sur-ensemble de JSON, donc il peut faire tout ce que JSON fait et plus. Mais JSON ne disparaîtra pas car c'est la norme pour les API et la communication machine à machine. Pense à eux comme des outils complémentaires : YAML pour les fichiers de configuration édités par des humains, JSON pour l'échange de données entre systèmes.
Non, le JSON standard ne supporte pas les commentaires. C'est l'une des frustrations les plus courantes des développeurs avec les fichiers de configuration JSON. Certains outils comme VS Code supportent JSONC (JSON with Comments) pour leurs propres fichiers de configuration, mais ce n'est pas une norme et cassera les parseurs JSON réguliers. Si tu as besoin de commentaires dans ta configuration, YAML est le meilleur choix.
JSON est généralement plus rapide à analyser car sa grammaire est plus simple et les parseurs sont hautement optimisés, souvent intégrés directement aux runtimes de langage. Les parseurs YAML doivent gérer plus de règles de syntaxe, l'inférence de type et des fonctionnalités comme les ancres. Pour les fichiers de configuration lus une fois au démarrage, la différence est négligeable. Pour le streaming de données à haut débit, JSON gagne clairement.
Les problèmes les plus courants sont l'indentation incohérente (mélanger les tabulations et les espaces cassera YAML), les valeurs spéciales non entre guillemets comme
yes
,
no
,
null
ou
on
étant interprétées comme des booléens, et les deux-points dans les chaînes non entre guillemets. Utilise toujours des espaces (pas des tabulations) pour l'indentation, et mets entre guillemets toute valeur de chaîne qui pourrait être ambiguë.
Pour les types de données standard, aucune donnée n'est perdue. Cependant, les fonctionnalités spécifiques à YAML comme les commentaires, les ancres et les alias n'ont pas d'équivalents JSON et seront supprimés lors de la conversion. Les ancres sont d'abord résolues (les valeurs référencées sont insérées), et les commentaires sont simplement supprimés. Les données réelles clé-valeur et sa structure sont complètement préservées.
YAML est la norme pour Kubernetes et Docker Compose. Les manifestes Kubernetes sont presque toujours écrits en YAML, et la documentation officielle utilise YAML dans tous les exemples. Les fichiers Docker Compose utilisent l'extension
.yml
par défaut. Bien que Kubernetes accepte techniquement aussi JSON, la convention de la communauté est fermement YAML pour la lisibilité et le support des commentaires.