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

Voici la version courte de TOML vs JSON vs YAML : JSON est le format d’échange machine par défaut que tous les langages savent analyser, YAML est le format lisible qui fait tourner Kubernetes et les pipelines CI, et TOML est le format explicite et typé conçu pour la configuration d’outils et d’applications comme Cargo.toml et pyproject.toml. Aucun format ne gagne partout. Le bon format de fichier de configuration dépend de trois choses : qui l’édite, si vous avez besoin de commentaires, et à quel point les types doivent être stricts.

Une règle empirique rapide. Si une machine l’écrit et une machine le lit, optez pour JSON. Si une personne édite à la main une infrastructure profondément imbriquée tous les jours, YAML mérite sa complexité. Si vous voulez une configuration explicite et typée, difficile à rater, TOML est le choix le plus sûr. Ces formats ne sont pas vraiment des concurrents. Ils occupent des voies différentes : JSON pour les machines, YAML pour le DevOps, TOML pour la configuration d’outils. La suite de ce guide le confirme avec des exemples côte à côte, les différences qui causent réellement des bugs, et une matrice de décision.

La réponse en 30 secondes

Si vous n’avez qu’une demi-minute, ce tableau est la comparaison des formats de fichiers de configuration que vous cherchez.

	JSON	YAML	TOML
Commentaires	Non	Oui (#)	Oui (#)
Types de données	Explicites, minimaux	Implicites (déduits de la forme)	Explicites, riches
Dates natives	Non	Dépend de la version	Oui (quatre types)
Style d’imbrication	Accolades {}	Indentation	En-têtes [section]
Sensible à l’indentation	Non	Oui (tabulations interdites)	Non
Chaînes multilignes	Non (seulement \n)	Oui (| et >)	Oui (""")
Virgules finales	Interdites	S/O	Autorisées dans les tableaux
Sur-ensemble de JSON	—	Oui (1.2)	Non
Idéal pour	API, échange de données	K8s, CI, Ansible	Config d’outils Rust/Python

Trois verdicts en une ligne découlent de ce tableau :

• Choisissez JSON quand le fichier est produit et consommé par des programmes : charges utiles d’API, package.json, tsconfig.json, tout ce qui franchit une frontière de système.
• Choisissez YAML quand des humains éditent à la main une configuration profonde et imbriquée et que l’écosystème l’attend déjà : manifestes Kubernetes, GitHub Actions, Docker Compose, playbooks Ansible.
• Choisissez TOML quand vous voulez une configuration claire et typée pour un outil ou une application, essentiellement plate avec quelques sections, éditée par des contributeurs de niveaux variés : Cargo.toml, pyproject.toml, Hugo, Netlify.

Reste à comprendre pourquoi ces verdicts tiennent, car c’est dans les raisons que se cachent les vrais bugs.

La même config, de trois façons

Rien n’explique la différence plus vite qu’une même configuration écrite trois fois. Voici une petite config de service : un nom et une version, quelques indicateurs de premier niveau, une liste de fonctionnalités, et un bloc de base de données imbriqué.

JSON :

{
  "name": "acme-api",
  "version": "2.4.0",
  "debug": false,
  "released": "2026-07-02",
  "features": ["auth", "metrics", "tracing"],
  "database": {
    "host": "db.internal",
    "port": 5432,
    "max_connections": 100
  }
}

YAML :

name: acme-api
version: "2.4.0"
debug: false
released: "2026-07-02"
features:
  - auth
  - metrics
  - tracing
database:
  host: db.internal
  port: 5432
  max_connections: 100

TOML :

name = "acme-api"
version = "2.4.0"
debug = false
released = "2026-07-02"
features = ["auth", "metrics", "tracing"]

[database]
host = "db.internal"
port = 5432
max_connections = 100

Les trois décrivent des données identiques. Leur apparence, en revanche, diffère nettement. JSON porte le plus de ponctuation : chaque clé est entre guillemets doubles, chaque niveau ajoute des accolades, et une seule virgule finale égarée est une erreur de syntaxe. YAML en supprime presque tout, si bien que la structure vient de la seule indentation, ce qui se lit à merveille jusqu’à ce qu’une tabulation s’y glisse. TOML se situe entre les deux : des guillemets uniquement sur les chaînes, des paires key = value, et un en-tête [database] qui nomme le bloc imbriqué à la manière d’un vieux fichier INI. Le champ released est une chaîne entre guillemets dans les trois cas, pour que les données restent identiques ici. C’est délibéré, car les dates sont précisément là où ces formats cessent de s’accorder.

JSON — le format d’échange machine par défaut

JSON est le format vers lequel vous vous tournez sans réfléchir, et cet instinct est généralement le bon. Tous les langages courants embarquent un analyseur, toutes les API HTTP le parlent, et sa grammaire est assez réduite pour tenir en tête. Il est strict et sans ambiguïté : une chaîne est une chaîne, 5432 est un nombre, true est un booléen, et il n’existe qu’une seule façon d’écrire chacun. Cette rigueur est ce qui rend JSON sûr à envoyer entre des systèmes qui ne se sont jamais rencontrés. Quand un service Node envoie du JSON à un service Go, les deux s’accordent sur le sens octet pour octet.

Cette même rigidité explique pourquoi JSON domine son terrain de prédilection. package.json, tsconfig.json et composer.json sont en JSON parce que les outils les génèrent et les réécrivent constamment, et une configuration écrite par la machine réclame un format strict pour la machine. Pour les charges utiles d’API et les files de messages, il n’y a tout simplement aucune raison de choisir autre chose.

Les faiblesses de JSON apparaissent toutes dès qu’un humain doit l’éditer à la main. Pas de commentaires. Pas de virgules finales, donc réordonner une liste implique de corriger les virgules. Pas de chaînes multilignes, seulement des échappements \n. Chaque clé exige des guillemets doubles. Et il n’y a pas de type date, donc 2026-07-02 doit exister sous forme de chaîne entre guillemets et être analysé par convention. Pour un fichier de configuration qu’une personne maintient, ces manques finissent par créer des frictions.

Le problème du « JSON sans commentaires »

La fonctionnalité JSON la plus demandée est précisément celle que Douglas Crockford a délibérément écartée : les commentaires. Son raisonnement était que les commentaires incitaient les gens à faire passer en douce des directives d’analyse dans les fichiers de configuration, brisant l’interopérabilité. Quoi que vous pensiez de ce choix, vous ne pouvez pas annoter une configuration JSON pure, ce qui est pénible pour tout ce que des humains maintiennent. La solution pratique est un sur-ensemble. JSON5 ajoute les commentaires, les virgules finales, les clés sans guillemets et les guillemets simples ; JSONC (JSON with Comments) est la variante plus légère que VS Code utilise pour ses paramètres. Les deux conservent la forme de JSON tout en le rendant éditable. Si vous avez besoin de commentaires mais souhaitez rester dans la famille JSON, lisez notre guide de formatage JSON5 et JSONC pour savoir quand utiliser l’un ou l’autre et garder vos outils satisfaits.

YAML — le standard DevOps lisible par l’humain

YAML est optimisé pour l’humain au clavier. Il prend en charge les commentaires, sa mise en page fondée sur l’indentation garde les structures profondément imbriquées lisibles, et les ancres vous permettent de définir un bloc une seule fois et de le réutiliser via un alias au lieu de copier-coller :

defaults: &defaults
  timeout: 30
  retries: 3

staging:
  <<: *defaults
  host: staging.internal

production:
  <<: *defaults
  host: prod.internal

L’ancre &defaults nomme un bloc, et <<: *defaults la fusionne dans les deux environnements, si bien qu’une modification du délai d’attente partagé se fait à un seul endroit. Ni JSON ni TOML n’ont d’équivalent. Cette lisibilité est la raison pour laquelle YAML est devenu la lingua franca de l’exploitation : les manifestes Kubernetes, les workflows GitHub Actions, les fichiers Docker Compose et les playbooks Ansible sont tous en YAML. Quand votre config compte cinq niveaux de profondeur et qu’un humain la retouche quotidiennement, la faible ponctuation de YAML est un vrai soulagement.

Le prix, c’est la complexité et les surprises. La spécification YAML 1.2 est vaste, et la conformité totale est rare, si bien que différents analyseurs divergent dans les cas limites. L’indentation est significative, les tabulations sont purement et simplement interdites, et une espace mal alignée peut changer le sens ou empêcher l’analyse. Le piège le plus tranchant est le typage implicite : YAML devine le type d’un scalaire sans guillemets d’après sa forme, et il se trompe assez souvent pour avoir gagné un surnom.

Le problème norvégien en un paragraphe

Écrivez country: NO en YAML et de nombreux analyseurs vous renvoient le booléen false, et non la chaîne "NO", car YAML 1.1, que la plupart des outils Kubernetes suivent encore, traite NO, YES, ON, OFF, Y et N comme des booléens. Le code pays de la Norvège devient false, silencieusement, sans aucune erreur. Ce même typage implicite transforme 0755 en nombre octal et 1.20 en 1.2. La correction est ennuyeuse mais fiable : mettez entre guillemets les chaînes qui pourraient être confondues avec autre chose. Ce piège est assez célèbre pour mériter son propre approfondissement, avec de véritables pannes et l’historique de YAML 1.1 face à 1.2, dans notre guide du problème norvégien de YAML. Pour cet article, la leçon est simple : la commodité de YAML et son danger proviennent de la même fonctionnalité.

YAML l’emporte quand des personnes éditent chaque jour une configuration profondément imbriquée et que l’écosystème environnant l’exige déjà. Si vous écrivez un chart Helm, vous écrivez du YAML, et c’est très bien ainsi.

TOML — une configuration explicite conçue pour l’outillage

TOML (Tom’s Obvious, Minimal Language, créé par Tom Preston-Werner) a été conçu pour être le format de configuration que les utilisateurs de YAML auraient aimé avoir : lisible, mais sans les devinettes. Son trait caractéristique est l’explicitation. Les types sont sans ambiguïté, donc port = 5432 est toujours un entier et name = "acme" est toujours une chaîne, sans inférence fondée sur la forme sur laquelle trébucher. La syntaxe TOML emprunte l’en-tête [section] aux fichiers INI, ce qui rend le premier niveau d’une configuration facile à parcourir du regard, et elle n’est pas sensible à l’indentation, si bien que les espaces ne changent jamais le sens. La spécification TOML 1.0.0 est petite et stable, ce qui est un atout : il y a moins de choses à mémoriser de travers.

La capacité phare de TOML, ce sont les types natifs de date et d’heure, que ni JSON ni le YAML pur ne gèrent proprement. Il en compte quatre : date-heure avec décalage et fuseau horaire (1979-05-27T07:32:00Z), date-heure locale sans fuseau, date locale (1979-05-27, juste un jour du calendrier) et heure locale (07:32:00). Cela signifie qu’une date de déploiement reste une vraie date au lieu d’une chaîne que vous devez réanalyser.

Trois éléments de la syntaxe TOML font l’essentiel du travail. Un en-tête [section] ouvre une table ; un en-tête pointé comme [tool.ruff] imbrique une table dans une autre sans indentation supplémentaire ; et une table en ligne { version = "1.0", features = ["derive"] } condense un petit objet sur une seule ligne. Les sections répétées utilisent un en-tête doublé, le tableau de tables :

[[servers]]
name = "alpha"
ip = "10.0.0.1"

[[servers]]
name = "beta"
ip = "10.0.0.2"

Ce bloc devient un tableau JSON de deux objets sous la clé servers. Il se lit bien pour une liste plate, ce qui est exactement ce dont la plupart des configurations d’outils ont besoin.

Les faiblesses sont réelles mais limitées. TOML n’a pas de type null, donc une valeur absente est simplement une clé omise. L’imbrication profonde devient verbeuse, car chaque niveau d’une structure imbriquée répétée reprend l’en-tête [[path]] complet, ce qui devient plus bruyant que l’équivalent YAML. Et TOML est plus jeune et moins universel que JSON ou YAML, si bien que tous les outils ne le parlent pas. TOML brille pour une configuration essentiellement plate avec une poignée de sections étiquetées, ce qui décrit l’écrasante majorité des configurations d’outils.

Pourquoi TOML pour Rust et Python ?

L’essor de TOML suit deux écosystèmes qui l’ont adopté comme standard. Le gestionnaire de paquets de Rust, Cargo, utilise Cargo.toml pour chaque crate, si bien que tout développeur Rust lit et écrit du TOML dès le premier jour. Python a suivi : la PEP 518 a introduit pyproject.toml pour déclarer les exigences de build, et la PEP 621 a standardisé les métadonnées de projet (nom, version, dépendances et sections [tool.*]) dans ce même fichier, remplaçant un éparpillement de setup.py, setup.cfg et de configurations propres à chaque outil. Au-delà de ces deux-là, Hugo, Netlify, Poetry et Foundry adoptent tous TOML par défaut. Le fil conducteur, c’est une configuration d’outillage que les contributeurs éditent à la main et qui gagne à être évidente plutôt qu’astucieuse.

Face à face — les différences qui mordent vraiment

Les tableaux de fonctionnalités sont bien rangés. Les bugs, non. Voici les différences précises qui causent de vrais problèmes, chacune accompagnée d’un petit exemple que vous pouvez passer dans n’importe quel analyseur.

Commentaires

JSON n’a aucune syntaxe de commentaire. TOML et YAML utilisent tous deux # jusqu’à la fin de la ligne.

# TOML : un commentaire en début de ligne
port = 5432  # et un en fin de ligne

# YAML : style de commentaire identique
port: 5432   # commentaire en fin de ligne

Dès l’instant où vous collez un // ou un # dans du JSON strict, l’analyse échoue. Ce n’est pas cosmétique. Une configuration qu’un humain maintient sans commentaires accumule un savoir tribal qui ne vit que dans la tête de quelqu’un.

Types de données et dates

Les types de JSON sont explicites mais rares, sans type date. Les types de TOML sont explicites et riches. Ceux de YAML sont implicites et, comme vu plus haut, parfois erronés. Les dates sont la ligne de partage la plus nette. TOML exprime les quatre variantes nativement :

odt = 1979-05-27T07:32:00Z   # date-heure avec décalage (a un fuseau horaire)
ldt = 1979-05-27T07:32:00    # date-heure locale (sans fuseau horaire)
ld  = 1979-05-27             # date locale (un jour du calendrier)
lt  = 07:32:00               # heure locale

Convertissez ce TOML en JSON et chaque valeur devient une chaîne qui conserve son sens : une date locale reste "1979-05-27" au lieu d’être gonflée en un faux horodatage à minuit. Notre convertisseur TOML vers JSON préserve exactement ce type de date, ce que beaucoup de convertisseurs naïfs ratent. YAML, de son côté, peut ou non traiter 1979-05-27 comme une date selon l’analyseur et la version du schéma, ce qui est précisément l’ambiguïté que vous ne voulez pas dans une configuration de production.

Profondeur d’imbrication

Plus votre configuration s’imbrique profondément, plus les formats divergent. Prenez une petite arborescence de style Docker Compose :

services:
  web:
    build:
      context: .
      args:
        NODE_ENV: production
    ports:
      - "8080:8080"

YAML exprime la profondeur par la seule indentation, et reste compact. La même structure en TOML vous oblige à écrire le chemin complet dans chaque en-tête, et à placer les valeurs scalaires avant les tables enfants :

[services.web]
ports = ["8080:8080"]

[services.web.build]
context = "."

[services.web.build.args]
NODE_ENV = "production"

JSON porte l’arborescence dans des accolades imbriquées, ce qui est sans ambiguïté mais lourd en ponctuation. Pour une configuration peu profonde, les trois se ressemblent ; passé trois ou quatre niveaux, YAML est visiblement plus léger et TOML visiblement plus répétitif. Cette seule différence explique pourquoi Kubernetes a choisi YAML et Cargo a choisi TOML.

Sensibilité à l’indentation

Seul YAML se soucie des espaces. En JSON et en TOML, vous pouvez indenter comme bon vous semble, ou pas du tout, et le sens reste identique. En YAML, l’indentation est la structure, et les tabulations sont interdites, si bien qu’un éditeur qui insère une tabulation, ou un bloc collé à la mauvaise profondeur, modifie silencieusement le document ou refuse de le charger. Un élément de liste indenté d’une espace de trop peut se rattacher à la mauvaise clé parente sans la moindre erreur, un bug exaspérant à repérer à l’œil car le fichier a toujours l’air correct. Si vos contributeurs utilisent des éditeurs et des réglages hétérogènes, c’est une taxe permanente que YAML prélève et que les deux autres non, et c’est une bonne raison de faire tourner un linter en CI sur toute grande configuration YAML.

Chaînes multilignes

JSON ne peut pas contenir un retour à la ligne littéral dans une chaîne ; vous l’échappez avec \n. YAML et TOML ont tous deux de vraies chaînes multilignes.

{ "note": "line one\nline two" }

note: |
  line one
  line two

note = """
line one
line two
"""

Le | de YAML conserve les retours à la ligne (un bloc > les replie en espaces à la place), et le """ de TOML se comporte de façon similaire, en supprimant le retour à la ligne qui suit immédiatement les guillemets d’ouverture. Pour des scripts embarqués, du SQL ou du texte d’aide, cela seul peut décider du format.

Virgules finales et rigueur

JSON est le plus strict des trois. Une virgule finale après le dernier élément d’un tableau est une erreur de syntaxe :

# TOML valide — la virgule finale est autorisée
ports = [
  8001,
  8002,
]

La même virgule finale après 8002 en JSON échoue à l’analyse, ce qui explique pourquoi ajouter une ligne à un tableau JSON implique si souvent de corriger aussi la virgule de la ligne précédente. TOML autorise la virgule finale, et la syntaxe de liste à tiret par ligne de YAML élude entièrement la question. La rigueur est une vertu pour l’échange machine et une nuisance pour l’édition à la main, soit le même compromis vu de l’autre côté. C’est aussi la friction que JSON5 et JSONC ont entrepris d’éliminer spécifiquement pour JSON.

Grands entiers et le plafond de 2^53

Les trois formats peuvent écrire un entier 64 bits sous forme de texte. Les ennuis commencent quand cette valeur passe par JavaScript, car les nombres JSON du navigateur sont des doubles IEEE-754 et ne peuvent représenter exactement que les entiers jusqu’à 2^53 − 1 (9007199254740991). Un identifiant Snowflake ou un horodatage en nanosecondes est plus grand que cela, si bien qu’un aller-retour par un outil basé sur JS l’arrondit et corrompt la valeur :

snowflake = 1420070400000000000   # exact dans le texte TOML

{ "snowflake": "1420070400000000000" }

La solution fiable dans tous les formats consiste à stocker ces valeurs sous forme de chaînes entre guillemets, pour qu’aucun analyseur numérique ne les touche jamais. Ce n’est pas un défaut d’un format en particulier ; c’est une limite de l’environnement d’exécution qui réalise la conversion. Nos convertisseurs vous avertissent quand un entier franchit cette limite au lieu de le corrompre en silence.

Comment choisir — matrice de décision et logigramme

Quand vous décidez concrètement quel format de configuration utiliser, parcourez les questions dans l’ordre et arrêtez-vous au premier oui franc.

1. Le fichier est-il écrit et lu principalement par des programmes, ou l’écosystème impose-t-il déjà un format ? Si oui, utilisez JSON. Une charge utile d’API, c’est du JSON. Un fichier à côté de package.json, c’est du JSON. Ne luttez pas contre l’outillage.
2. Des humains éditent-ils à la main, chaque jour, une configuration profonde et imbriquée, dans une stack qui l’attend (Kubernetes, CI, Ansible) ? Si oui, utilisez YAML, et adoptez une convention de guillemets pour esquiver le problème norvégien.
3. S’agit-il d’une configuration d’outil ou d’application, essentiellement plate avec quelques sections, éditée par des contributeurs de niveaux variés, où le typé et l’évident l’emportent sur le concis ? Si oui, utilisez TOML.

Si deux réponses sont à égalité, départagez-les avec cette grille :

Besoin	Meilleur choix	Pourquoi
Commentaires dans le fichier	TOML ou YAML	JSON n’en a pas
Valeurs date/heure natives	TOML	Quatre types de date explicites
Imbrication très profonde	YAML	L’indentation reste compacte
Zéro surprise d’espaces	JSON ou TOML	Non sensible à l’indentation
Fichier imposé par l’écosystème	JSON	package.json, tsconfig.json
Édition humaine, peu de sections	TOML	Types explicites, en-têtes de style INI
Échange de machine à machine	JSON	Universel, strict, rapide
L’inférence de type ne doit jamais deviner	JSON ou TOML	YAML infère implicitement

La plupart des projets finissent par en utiliser plusieurs. Un dépôt peut avoir un package.json en JSON qu’il ne touche jamais à la main, un pyproject.toml en TOML pour son outillage Python, des workflows YAML dans .github, et un fichier .env pour les secrets locaux qui ne suit aucune de ces grammaires. Ce mélange est normal, et c’est bien là l’idée : chaque fichier vit dans le format qui convient à celui qui l’édite. Si la couche .env fait partie de votre installation, notre guide du format de fichier .env explique où elle s’insère aux côtés de la configuration JSON et comment convertir de l’une à l’autre.

Convertir entre TOML, JSON et YAML

Vous finissez par convertir entre ces formats plus souvent que vous ne le penseriez. Un job de CI lit un pyproject.toml écrit à la main et en a besoin en JSON pour alimenter un tableau de bord de dépendances. Une migration fait passer une application d’une config YAML à TOML pour un typage plus strict. Une revue de code est plus facile quand vous comparez la forme JSON de deux fichiers plutôt que leurs originaux sensibles aux espaces. Chaque direction a un piège qu’il vaut mieux connaître avant de coller.

TOML vers JSON. Le principal risque, ce sont les dates. Une date locale comme 1979-05-27 doit rester une date de calendrier, et non devenir un horodatage UTC à minuit qui invente une heure et un fuseau horaire. Les commentaires sont eux aussi perdus, puisque JSON ne peut pas les contenir. Le convertisseur TOML vers JSON préserve fidèlement chaque type de date, si bien que les allers-retours restent sans perte.

JSON vers TOML. TOML est plus strict sur la structure, si bien que deux choses peuvent bloquer une conversion. Le premier niveau doit être un objet, car un document TOML est toujours une table à sa racine ; un tableau ou un scalaire nu n’a nulle part où aller. Et TOML n’a pas de null, donc une valeur d’objet nulle est supprimée (avec un avertissement listant les clés concernées), tandis qu’un null à l’intérieur d’un tableau n’a tout simplement aucune représentation TOML valide. Le convertisseur JSON vers TOML fait remonter ces deux cas explicitement au lieu de produire une sortie cassée.

JSON et YAML, dans les deux sens. Ici, le problème norvégien est ce qu’il faut surveiller : un NO ou un 0755 sans guillemets peut changer de type en franchissant la frontière. Le convertisseur JSON vers YAML et le convertisseur YAML vers JSON gèrent la mise entre guillemets pour qu’une chaîne reste une chaîne.

Après toute conversion, il vaut la peine de valider le résultat. Passer la sortie dans le formateur JSON confirme que le JSON est bien formé et indenté de façon cohérente avant que vous ne le validiez ou l’envoyiez en aval. Et parce que les fichiers de configuration transportent des secrets (jetons de registre, identifiants de base de données, clés de déploiement), tous ces outils s’exécutent entièrement dans votre navigateur : rien n’est téléversé, si bien qu’un Cargo.toml avec un jeton de registre privé ou un fichier de valeurs avec des identifiants ne quitte jamais votre machine.

FAQ

TOML est-il meilleur que YAML ?

Aucun n’est universellement meilleur ; le choix entre TOML et YAML dépend de la forme. TOML est plus difficile à rater grâce aux types explicites et à l’absence de pièges d’indentation, il l’emporte donc pour une configuration d’outillage essentiellement plate. YAML exprime l’imbrication profonde de façon plus compacte, il l’emporte donc pour de grandes infrastructures en couches comme Kubernetes.

Dois-je utiliser JSON ou YAML pour les fichiers de configuration ?

Pour une configuration qu’un humain édite, préférez YAML : il autorise les commentaires et se lit clairement, ce que JSON ne fait pas. Pour une configuration que des programmes génèrent et consomment, préférez JSON : il est strict, rapide et universel. La ligne de partage, c’est qui réalise l’édition, l’humain ou la machine.

Pourquoi JSON n’autorise-t-il pas les commentaires ?

Le créateur de JSON, Douglas Crockford, a supprimé les commentaires à dessein. Il craignait que les gens y intègrent des directives d’analyse et brisent l’interopérabilité entre analyseurs. Si vous avez besoin de commentaires dans un fichier de forme JSON, utilisez JSON5 ou JSONC, qui les rétablissent sans changer la structure fondamentale.

Qu’est-ce que le problème norvégien en YAML ?

C’est YAML 1.1 qui traite certains mots sans guillemets comme des booléens, si bien que country: NO devient false au lieu de la chaîne "NO". YES, ON et OFF se comportent de la même manière. Mettre la valeur entre guillemets l’évite ; voyez le guide dédié lié plus haut pour l’histoire complète.

TOML prend-il en charge les commentaires ?

Oui. TOML utilise # pour les commentaires, aussi bien sur leur propre ligne qu’à la suite d’une valeur, exactement comme YAML. Notez que les commentaires sont perdus quand vous convertissez TOML en JSON, puisque JSON n’a aucune syntaxe de commentaire pour les contenir.

TOML peut-il représenter tout ce que JSON peut ?

Presque. L’écart entre JSON et TOML est petit mais réel : TOML n’a pas de type null, donc les null de JSON sont supprimés ou rejetés à la conversion, et un document TOML doit être une table au premier niveau, si bien qu’un tableau ou un scalaire JSON nu ne peut pas être converti sans être d’abord enveloppé sous une clé.

YAML est-il un sur-ensemble de JSON ?

Depuis YAML 1.2, oui : tout document JSON valide est aussi un YAML valide, donc un analyseur YAML peut lire directement du JSON. C’est un fait utile, mais ne vous y appuyez pas comme sur une frontière de sécurité, car les analyseurs YAML ajoutent des fonctionnalités (comme les ancres) que JSON n’a pas.

Quel format de configuration est le plus rapide à analyser ?

JSON est généralement le plus rapide, avec les analyseurs les plus matures et les plus optimisés dans tous les langages. YAML est le plus lent et le plus complexe à analyser en raison de sa vaste spécification et de son typage implicite. TOML se situe au milieu, plus proche de JSON que de YAML en vitesse.