JSON vs YAML vs TOML : Quel format de config choisir ?

JSON, YAML et TOML sont les trois formats de configuration les plus populaires en développement logiciel. Chacun a ses forces et ses compromis. Ce guide fournit une comparaison complète pour vous aider à choisir le bon format.

Convertissez entre JSON et YAML instantanément →

Aperçu de chaque format

JSON (JavaScript Object Notation)

JSON a été introduit au début des années 2000 par Douglas Crockford. Conçu pour la simplicité, c'est aujourd'hui le standard de facto pour les API web, les fichiers comme package.json et l'échange de données.

YAML (YAML Ain't Markup Language)

YAML a été proposé en 2001, conçu pour la lisibilité humaine. Il est utilisé dans Docker Compose, Kubernetes, Ansible et les pipelines CI/CD (GitHub Actions, GitLab CI).

TOML (Tom's Obvious Minimal Language)

TOML a été créé en 2013 par Tom Preston-Werner pour être un format minimal et non ambigu. C'est le standard pour Rust (Cargo.toml), Python (pyproject.toml) et Hugo.

Comparaison de syntaxe

Voici la même configuration dans les trois formats :

JSON

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true
  },
  "database": {
    "host": "db.example.com",
    "port": 5432,
    "name": "myapp",
    "credentials": {
      "username": "admin",
      "password": "secret"
    }
  },
  "features": ["auth", "logging", "cache"],
  "max_connections": 100
}

YAML

# Server configuration
server:
  host: localhost
  port: 8080
  debug: true

# Database settings
database:
  host: db.example.com
  port: 5432
  name: myapp
  credentials:
    username: admin
    password: secret

features:
  - auth
  - logging
  - cache

max_connections: 100

TOML

# Server configuration
max_connections = 100
features = ["auth", "logging", "cache"]

[server]
host = "localhost"
port = 8080
debug = true

[database]
host = "db.example.com"
port = 5432
name = "myapp"

[database.credentials]
username = "admin"
password = "secret"

Comparaison des fonctionnalités

Quand utiliser chaque format

Utilisez JSON quand...

// Typical JSON use cases
// package.json
{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "dev": "next dev",
    "build": "next build"
  }
}

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "strict": true
  }
}

Utilisez YAML quand...

# Docker Compose
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html

# GitHub Actions
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Utilisez TOML quand...

# Cargo.toml (Rust)
[package]
name = "my-app"
version = "0.1.0"
edition = "2021"

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

# pyproject.toml (Python)
[project]
name = "my-package"
version = "1.0.0"
requires-python = ">=3.9"

[tool.ruff]
line-length = 88
target-version = "py39"

Pièges courants

YAML : Problèmes d'indentation

YAML utilise l'indentation pour définir la structure. Mélanger tabs et espaces cause des erreurs fréquentes.

# BAD: mixing tabs and spaces (invisible but breaks YAML)
services:
	web:          # tab character - YAML error!
    image: nginx

# BAD: inconsistent indentation
services:
  web:
      image: nginx   # 4 spaces here
    ports:            # 2 spaces here - error!
      - "80:80"

# GOOD: consistent 2-space indentation
services:
  web:
    image: nginx
    ports:
      - "80:80"

YAML : Le "problème de la Norvège"

En YAML 1.1, NO, yes, on, off non quotés sont interprétés comme booléens. Le code pays "NO" (Norvège) devient false.

# The "Norway Problem" - YAML 1.1
countries:
  - name: Norway
    code: NO          # Parsed as boolean false!
  - name: Sweden
    code: SE          # Parsed as string "SE"
  - name: Finland
    code: FI          # Parsed as string "FI"

# Other surprising boolean values in YAML 1.1:
truthy:  yes          # boolean true
falsy:   no           # boolean false
enabled: on           # boolean true
disabled: off         # boolean false
positive: TRUE        # boolean true
negative: False       # boolean false

# FIX: Always quote values that could be misinterpreted
countries:
  - name: Norway
    code: "NO"        # Now correctly a string
  - name: Sweden
    code: "SE"
settings:
  enabled: "yes"      # Now correctly a string

JSON : Virgules finales

JSON n'autorise pas les virgules finales. Ajouter une virgule après le dernier élément cause une erreur de parse.

// BAD: trailing comma after last element
{
  "name": "my-app",
  "version": "1.0.0",
  "private": true,    // <-- trailing comma = PARSE ERROR
}

// BAD: trailing comma in array
{
  "colors": [
    "red",
    "green",
    "blue",            // <-- trailing comma = PARSE ERROR
  ]
}

// GOOD: no trailing commas
{
  "name": "my-app",
  "version": "1.0.0",
  "private": true
}

TOML : Syntaxe des tables imbriquées

Les structures profondément imbriquées en TOML peuvent devenir verbeuses. Chaque niveau nécessite son propre en-tête [section.subsection].

# TOML: deeply nested config can be verbose
[server]
host = "localhost"

[server.ssl]
enabled = true

[server.ssl.certificates]
cert = "/path/to/cert.pem"
key = "/path/to/key.pem"

[server.ssl.certificates.ca]
bundle = "/path/to/ca-bundle.pem"

# The same in YAML is more compact:
# server:
#   host: localhost
#   ssl:
#     enabled: true
#     certificates:
#       cert: /path/to/cert.pem
#       key: /path/to/key.pem
#       ca:
#         bundle: /path/to/ca-bundle.pem

# TOML inline tables can help for shallow nesting:
[server]
host = "localhost"
ssl = { enabled = true, cert = "/path/to/cert.pem" }

Outils de conversion

Besoin de passer d'un format à l'autre ? Utilisez nos convertisseurs gratuits :

Convertisseur JSON ↔ YAML — conversion bidirectionnelle

Convertisseur TOML ↔ YAML — conversion instantanée

Convertissez entre JSON et YAML instantanément →

Convertissez entre TOML et YAML avec notre outil gratuit →