Aller au contenu
Toova
Tous les outils

JSON vs YAML — Quand utiliser chacun

Toova

JSON et YAML sont tous deux des moyens de représenter des données structurées sous forme de texte. Ils prennent tous deux en charge les chaînes, les nombres, les booléens, les tableaux et les objets imbriqués. Ils sont largement supportés dans tous les langages de programmation et plateformes. Pourtant, ils font des compromis très différents : JSON optimise la lisibilité par les machines et la vitesse d'analyse ; YAML optimise la lisibilité humaine et la configuration expressive. Savoir quand utiliser lequel évite les frictions qui découlent de l'utilisation d'un format de configuration conçu pour les API pour écrire des fichiers de configuration rédigés à la main, ou l'inverse.

Ce guide couvre les différences de syntaxe, les forces et faiblesses pratiques de chaque format, les choix d'outils concrets qui dépendent du format, les considérations de performances et un cadre de décision clair pour 2026.

JSON : présentation

JSON (JavaScript Object Notation) a été formalisé par Douglas Crockford au début des années 2000 et standardisé dans la RFC 8259 et ECMA-404. Son objectif de conception était un format minimal et non ambigu pouvant être analysé et sérialisé par n'importe quel langage de programmation sans nécessiter un analyseur complexe.

JSON prend en charge exactement six types de données : les chaînes (toujours entre guillemets doubles), les nombres, les booléens (true/false), null, les objets (maps clé-valeur avec des clés chaînes) et les tableaux (listes ordonnées). Il n'y a pas de commentaires, pas de types date, pas de types binaires, pas de références. Ce minimalisme est intentionnel : les règles strictes éliminent l'ambiguïté et rendent les analyseurs simples et rapides. 

{
  "name": "deploy-service",
  "version": "2.1.0",
  "environment": "production",
  "replicas": 3,
  "enabled": true,
  "tags": ["backend", "critical"],
  "resources": {
    "cpu": "500m",
    "memory": "512Mi"
  }
}

Chaque clé doit être entre guillemets doubles. Les virgules de fin ne sont pas autorisées. Il est impossible d'écrire un commentaire. Les chaînes ne peuvent pas s'étendre sur plusieurs lignes sans échapper le caractère de saut de ligne. Ces contraintes rendent JSON plus difficile à écrire à la main mais trivialement facile à générer depuis du code et à analyser côté récepteur.

YAML : présentation

YAML (YAML Ain't Markup Language) a été conçu par Clark Evans, Ingy dot Net et Oren Ben-Kiki à partir de 2001. La version 1.2, qui atteint la compatibilité JSON, a été finalisée en 2009. L'objectif de conception de YAML est un format de données lisible par l'homme que les développeurs peuvent écrire directement dans des éditeurs de texte sans apprendre une nouvelle syntaxe. La spécification complète est disponible sur yaml.org.

YAML utilise l'indentation pour exprimer la structure plutôt que des crochets. Les listes utilisent des tirets. Les clés ne sont pas entre guillemets par défaut. Les commentaires commencent par #. Les chaînes ne nécessitent pas de guillemets sauf si elles contiennent des caractères spéciaux. Les chaînes multilignes disposent d'une syntaxe de scalaire bloc dédiée. 

# Configuration de déploiement pour la production
name: deploy-service
version: 2.1.0
environment: production
replicas: 3
enabled: true

tags:
  - backend
  - critical

resources:
  cpu: 500m
  memory: 512Mi

La même structure de données exprimée en YAML est significativement plus courte et plus lisible — surtout lorsqu'elle inclut des commentaires ou des listes imbriquées. Le compromis est que l'analyseur YAML doit gérer beaucoup plus de complexité : la sensibilité à l'indentation, de multiples façons d'exprimer le même type, les ancres, les alias, les clés de fusion et un héritage historique d'interprétation booléenne ambiguë.

Comparaison syntaxique côte à côte

Chaînes multilignes

Les chaînes multilignes sont l'un des avantages les plus clairs de YAML pour les fichiers de configuration. YAML propose deux styles de scalaire bloc : le littéral (|) préserve les sauts de ligne exactement, et le plié (>) joint les lignes avec des espaces pour les longs textes en prose. 

# YAML : plusieurs façons d'écrire des chaînes multilignes
# Bloc littéral (préserve les sauts de ligne)
description: |
  Voici la première ligne.
  Voici la deuxième ligne.
  Dernière ligne avec saut de ligne final.

# Bloc plié (les sauts de ligne deviennent des espaces, idéal pour les longs textes)
summary: >
  Ce long paragraphe est écrit sur
  plusieurs lignes mais sera joint en
  une seule chaîne séparée par des espaces.

# En JSON, vous devez échapper les sauts de ligne
# "description": "Voici la première ligne.
Voici la deuxième ligne.
Dernière ligne."

Ancres et alias

Les ancres YAML (&) et les alias (*) vous permettent de définir une valeur une fois et de la référencer dans plusieurs endroits, à la manière d'une variable. La clé de fusion (<<) fusionne le contenu d'un mapping dans un autre, fournissant une forme d'héritage. 

# Les ancres et alias YAML réduisent la duplication
defaults: &defaults
  timeout: 30
  retries: 3
  log_level: info

development:
  <<: *defaults   # fusionner les valeurs par défaut
  log_level: debug

staging:
  <<: *defaults
  timeout: 60

production:
  <<: *defaults

JSON n'a pas d'équivalent. En JSON, la configuration répétée doit être dupliquée, gérée par une couche de templating ou traitée par la logique de l'application consommatrice. Les ancres YAML sont puissantes pour les configurations maintenues manuellement mais peuvent rendre les fichiers plus difficiles à comprendre pour les lecteurs non familiarisés avec la convention.

Forces et faiblesses

Points forts de JSON

  • Analyse non ambiguë — la grammaire est assez simple pour tenir sur une seule page. Chaque analyseur produit le même résultat pour une entrée donnée.
  • Vitesse — les analyseurs JSON font partie des analyseurs de texte les plus rapides qui existent. V8 analyse le JSON significativement plus vite qu'il n'exécute du JavaScript lui-même.
  • Support JavaScript natif — JSON.parse() et JSON.stringify() sont intégrés à chaque environnement d'exécution JavaScript. Aucune dépendance n'est nécessaire.
  • Outillage universel — chaque client d'API, base de données et pipeline de données parle JSON nativement. C'est le format d'API de facto.
  • Pas de sensibilité à l'indentation — les espaces blancs n'ont pas d'importance pour le sens, rendant JSON robuste aux différences de formatage entre éditeurs, systèmes d'exploitation et outils.

Points faibles de JSON

  • Pas de commentaires — vous ne pouvez pas expliquer une valeur de configuration en ligne. C'est un point de friction significatif pour les fichiers rédigés à la main.
  • Verbeux pour les humains — toutes les clés doivent être entre guillemets, des virgules séparent chaque élément, et des accolades entourent chaque objet et tableau.
  • Erreurs de virgule de fin — les virgules de fin après le dernier élément de tableau ou d'objet sont invalides et provoquent des erreurs d'analyse faciles à introduire lors d'une édition manuelle.
  • Pas de chaînes multilignes — représenter une chaîne avec des sauts de ligne intégrés nécessite un échappement \n, rendant difficile l'intégration de requêtes SQL ou de scripts shell.
  • Pas de type date — les dates sont des chaînes. Les conventions varient (ISO 8601, timestamps Unix, formats personnalisés) et doivent être gérées par l'application.

Points forts de YAML

  • Commentaires — la syntaxe de commentaire # fait de YAML le choix évident pour les fichiers de configuration nécessitant une documentation en ligne.
  • Lisibilité — moins de bruit syntaxique. Clés sans guillemets, pas de virgules, structure basée sur l'indentation qui imite la façon dont les humains écrivent des plans.
  • Chaînes multilignes — les scalaires bloc littéral et plié gèrent gracieusement les longues chaînes sans échappement.
  • Ancres et clés de fusion — réduisent la duplication dans les grands fichiers de configuration.
  • Système de types riche — les analyseurs YAML déduisent les types à partir du format de la valeur (chaînes, entiers, flottants, booléens, null, timestamps) sans annotations de type explicites.

Points faibles de YAML

  • Complexité — la spécification YAML complète est énorme. Les cas limites abondent : le problème de la Norvège, les surprises de coercition de type implicite, la sensibilité tabulation-espace.
  • Analyse lente — les analyseurs YAML sont substantiellement plus lents que les analyseurs JSON en raison de la complexité de la grammaire.
  • Erreurs d'indentation — une seule ligne mal alignée change le sens du document sans produire d'erreur d'analyse, créant des bugs subtils difficiles à repérer.
  • Le problème de la Norvège — dans YAML 1.1, le NO brut est analysé comme le booléen false. Les codes pays, les abréviations et de nombreux mots anglais ont des interprétations booléennes inattendues dans les analyseurs YAML 1.1 (encore courants).
  • Comportement d'analyseur incohérent — les analyseurs YAML de différents langages implémentent différents sous-ensembles de la spécification ou différentes versions, entraînant des problèmes de portabilité.

Quand utiliser JSON

Réponses et requêtes d'API

JSON est le format universel pour les API REST. Chaque bibliothèque client HTTP peut le sérialiser et désérialiser nativement. La vitesse d'analyse compte à l'échelle des API, et la grammaire non ambiguë de JSON signifie que chaque client et serveur analyse les mêmes données de manière identique. Les réponses GraphQL sont en JSON. Les définitions OpenAPI/Swagger sont en JSON (bien que YAML soit également accepté). Si vous concevez une API, adoptez JSON par défaut. 

{
  "user": {
    "id": 42,
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "createdAt": "2026-01-15T10:30:00Z"
  }
}

Configuration générée par du code

Lorsqu'un programme génère de la configuration — un outil de build produisant des fichiers de verrouillage de dépendances, un framework générant un manifeste de projet, un outil de déploiement enregistrant des sommes de contrôle — JSON est le bon format. La sortie n'a jamais besoin d'être écrite à la main, les commentaires ne sont pas nécessaires, et la grammaire non ambiguë de JSON garantit que le code consommateur analyse exactement ce qui a été généré. package.json, tsconfig.json, package-lock.json et composer.json sont tous des exemples de ce schéma.

Échange de données entre services

Lorsque deux services doivent échanger des données — files de messages, webhooks, flux d'événements — la vitesse, l'universalité et l'absence d'ambiguïté de JSON en font le bon choix. Les avantages de YAML (commentaires, chaînes multilignes) sont sans intérêt dans les pipelines de données automatisés. Utilisez le Formateur JSON pour inspecter les charges utiles lors du débogage, et le convertisseur JSON vers YAML si vous devez rendre une charge utile lisible par l'homme à des fins de documentation.

Stockage en bases de données

PostgreSQL, MongoDB, MySQL et la plupart des bases de données qui stockent des données structurées le font en JSON ou dans des formats compatibles JSON. YAML n'est pas un format de stockage pris en charge dans aucune base de données majeure. Si vous stockez de la configuration ou des données structurées dans une base de données, utilisez JSON.

Quand utiliser YAML

Configuration d'infrastructure et de déploiement

Les manifestes Kubernetes, les charts Helm, les fichiers Docker Compose et les playbooks Ansible utilisent tous YAML. Ces fichiers sont écrits et examinés par des humains, contiennent souvent des commentaires explicatifs et bénéficient de la syntaxe de liste lisible de YAML pour décrire des ensembles de ressources. Un Déploiement Kubernetes avec plusieurs conteneurs, des montages de volumes et des variables d'environnement est substantiellement plus facile à lire en YAML qu'en JSON.

Définitions de pipeline CI/CD

GitHub Actions, GitLab CI, CircleCI et Bitbucket Pipelines utilisent tous YAML pour les définitions de pipeline. Les configurations de pipeline sont rédigées par des humains, fréquemment commentées et contiennent une logique multi-étapes qui bénéficie de la syntaxe lisible de YAML. 

# Workflow GitHub Actions — YAML est un choix naturel
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lancer les tests
        run: npm test

Fichiers de configuration d'application

Les paramètres Django (via django-configurations), le database.yml de Ruby on Rails, la configuration Gatsby et de nombreux autres frameworks utilisent YAML pour leur configuration. Quand les développeurs doivent lire et comprendre un fichier de configuration aux côtés du code, la capacité de YAML à inclure des commentaires et des explications multilignes réduit la charge cognitive.

Données de documentation

Les générateurs de sites statiques comme Jekyll, Hugo et Eleventy utilisent le frontmatter YAML dans les fichiers de contenu. La combinaison de métadonnées YAML et de corps Markdown est répandue car la syntaxe clé-valeur lisible de YAML s'intègre naturellement en haut d'un document texte. Le frontmatter JSON existe mais est rarement préféré.

Performances

Pour les pipelines de traitement de données, les benchmarks de sérialisation montrent systématiquement que JSON est 5 à 10 fois plus rapide à analyser que YAML pour des données équivalentes. Un appel JSON.parse() V8 sur un fichier de 1 Mo se termine en quelques millisecondes. L'analyse YAML équivalente prend des dizaines de millisecondes. Pour un serveur web gérant des milliers de requêtes par seconde, cette différence compte. Pour un outil CLI lisant un fichier de configuration une seule fois au démarrage, elle ne compte pas.

Si la performance est votre préoccupation principale et que vous choisissez entre JSON et YAML pour un format de données à haut débit, JSON gagne sans aucun doute. Si vous avez besoin d'une analyse encore plus rapide, envisagez des formats binaires comme MessagePack ou Protocol Buffers pour la communication inter-services.

Considérations de sécurité

Les analyseurs YAML sont plus complexes et ont une surface d'attaque plus grande que les analyseurs JSON. Le risque le plus significatif est l'exécution de code arbitraire via la désérialisation YAML. Dans le PyYAML de Python (avant que safe_load ne soit appliqué par défaut), le chargement de YAML non fiable avec la fonction yaml.load() par défaut pouvait exécuter du code Python arbitraire intégré dans le YAML. Les analyseurs YAML PHP et Ruby ont eu des vulnérabilités similaires.

La règle : utilisez toujours le chargement sûr lors de l'analyse de YAML non fiable. En Python, utilisez yaml.safe_load(), jamais yaml.load() sans l'argument Loader. En Java, configurez le constructeur pour restreindre les types autorisés. En Ruby, utilisez YAML.safe_load() plutôt que YAML.load().

Les analyseurs JSON n'ont pas cette vulnérabilité car le système de types de JSON n'a pas de concept de valeurs exécutables. Un analyseur JSON ne peut produire que des chaînes, des nombres, des booléens, null, des tableaux et des objets — jamais du code. Pour traiter des données utilisateur non fiables, JSON est intrinsèquement plus sûr à analyser.

Conversion entre JSON et YAML

Les formats sont sémantiquement compatibles pour les types de données les plus courants. La conversion entre eux est simple lorsque les données n'utilisent pas de fonctionnalités spécifiques à YAML (ancres, types personnalisés, scalaires bloc). Utilisez le convertisseur JSON vers YAML pour transformer les réponses d'API ou les fichiers de verrouillage en YAML lisible pour la documentation ou le débogage. Utilisez le convertisseur YAML vers JSON pour alimenter la configuration YAML dans des outils ou API natifs JSON. Les deux outils fonctionnent dans le navigateur — vos données ne quittent jamais votre appareil.

Le Formateur JSON est utile pour inspecter et valider la structure JSON avant la conversion. Si vous travaillez avec une configuration qui passe fréquemment d'un format à l'autre — par exemple, des manifestes Kubernetes qui doivent être sérialisés pour un appel d'API — avoir les deux convertisseurs en favoris fait gagner du temps.

Cadre de décision

  • Vous rédigez une réponse ou une requête d'API REST ? JSON.
  • Vous configurez Kubernetes, Docker Compose ou Ansible ? YAML.
  • Vous rédigez un pipeline CI/CD ? YAML.
  • Vous stockez des données dans une base de données ? JSON.
  • Vous rédigez un fichier de configuration modifiable par l'homme avec des commentaires ? YAML.
  • Vous générez de la configuration par programmation depuis du code ? JSON.
  • Vous traitez des entrées utilisateur non fiables ? JSON (analyseur plus sûr).
  • Pipeline de données à haut débit ? JSON (ou format binaire).
  • Projet qui utilise déjà un format de manière cohérente ? Suivez la convention existante.

En cas de doute, le facteur le plus important est les humains qui liront et écriront le fichier. Si le fichier est principalement généré par des machines et consommé par des machines, la simplicité de JSON gagne. Si des humains le liront, le modifieront et se soucieront de sa clarté, l'expressivité de YAML vaut la complexité supplémentaire de l'analyseur.