Si vous avez travaillé avec des fichiers de configuration, des APIs ou de la sérialisation de données, vous avez rencontré au moins deux de ces formats. Ils représentent tous des données structurées, mais font des compromis très différents. Voici un guide pratique pour vous aider à choisir.

Vue d’ensemble

Caractéristique	JSON	YAML	TOML
Lisibilité	Moyenne	Haute	Haute
Commentaires	Non	Oui	Oui
Complexité du spec	Faible	Haute	Faible
Virgules finales	Non	N/A	Non
Chaînes multi-lignes	Non (utiliser `\n`)	Oui	Oui
Usage courant	APIs, échange de données	Config, CI/CD	Config (Rust, Go)

JSON : le format universel

JSON (JavaScript Object Notation) est la lingua franca de l’échange de données. Chaque langage de programmation sait le parser, chaque API le parle.

Forces :

Universellement supporté
Parsing sans ambiguïté — pas de surprises
Rapide à parser programmatiquement
Spec stricte = comportement cohérent

Faiblesses :

Pas de commentaires (une frustration constante pour les fichiers de config)
Verbeux — beaucoup de guillemets et d’accolades
Pas de virgules finales (source facile d’erreurs de syntaxe)
Pas de chaînes multi-lignes

Idéal pour : réponses API, stockage de données, communication inter-services.

YAML : le format human-friendly

YAML (YAML Ain’t Markup Language) privilégie la lisibilité humaine avec une indentation significative et une syntaxe minimale.

Forces :

Très lisible pour les structures simples
Supporte les commentaires
Chaînes multi-lignes avec plusieurs styles
Ancres et alias pour des configs DRY

Faiblesses :

Sensible à l’indentation (problèmes tabs vs espaces)
Le typage implicite peut causer des bugs (yes/no → booléens, 3.10 → float 3.1)
Spec complexe avec beaucoup de cas limites
Le “problème de la Norvège” (NO parsé comme false)

Idéal pour : pipelines CI/CD (GitHub Actions, GitLab CI), manifestes Kubernetes, Docker Compose, Ansible.

TOML : le format de configuration

TOML (Tom’s Obvious Minimal Language) a été conçu explicitement pour les fichiers de configuration. C’est le format par défaut pour Rust (Cargo.toml), les modules Go et le packaging Python (pyproject.toml).

Forces :

Typage explicite (pas de conversions implicites)
Supporte les commentaires
Syntaxe claire de tables/sections
Support natif des dates/heures
Spec simple et concise

Faiblesses :

Les données très imbriquées deviennent fastidieuses
Moins d’outillage que JSON/YAML
Pas adapté à l’échange de données entre services

Idéal pour : configuration applicative, fichiers de métadonnées de projets.

Pièges courants

Le typage implicite de YAML

# Ceci est un booléen, pas une chaîne !
country: NO

# Ceci est le float 3.1, pas la chaîne "3.10"
version: 3.10

Corrigez avec des guillemets explicites : country: "NO", version: "3.10".

La rigueur de JSON

{
  "name": "example",
  "version": "1.0",  // ← Ce commentaire est du JSON invalide
}

JSON n’autorise ni les commentaires ni les virgules finales. Utilisez JSONC (JSON with Comments) ou supprimez-les avant le parsing.

L’imbrication en TOML

[servers.alpha]
ip = "10.0.0.1"

[servers.alpha.dc]
name = "eqdc10"

Pour des données très imbriquées, TOML devient vite verbeux. Si votre config dépasse 3 niveaux de profondeur, envisagez JSON ou YAML.

Convertir entre les formats

Au lieu de réécrire manuellement les données d’un format à l’autre, vous pouvez déposer n’importe lequel de ces formats dans JSON Lens. L’outil détecte automatiquement le format et le parse dans le même arbre visuel — que votre entrée soit du JSON, YAML, TOML, XML ou même du HTML.

Cela facilite :

Valider que votre config YAML est structurellement correcte
Explorer un fichier TOML comme si c’était du JSON
Comparer les mêmes données dans différents formats

En résumé

Utilisez JSON pour les APIs et l’échange de données — c’est le choix sûr par défaut
Utilisez YAML pour les configs CI/CD et DevOps — mais attention au typage implicite
Utilisez TOML pour la configuration applicative — surtout dans les écosystèmes Rust/Go/Python
En cas de doute, choisissez le format attendu par votre écosystème