YAML vs TOML
Choisissez YAML pour les écosystèmes qui le parlent déjà — Kubernetes, pipelines CI, Ansible — et pour les documents profondément imbriqués que des humains doivent lire. Choisissez TOML quand un fichier doit être sans ambiguïté, résistant au collage et strictement typé : chaînes entre guillemets, dates natives, structure explicite. Les deux prennent en charge les commentaires, les deux sont des langages de configuration, et convertir entre eux est de la routine.
YAML vs TOML en clair
YAML et TOML existent pour la même raison : JSON fait une configuration misérable — pas de commentaires, guillemets obligatoires sur chaque clé, accolades à compter. À partir de ce point de départ commun, les deux ont parié à l’opposé. YAML a parié sur la brièveté par l’inférence : guillemets généralement facultatifs, imbrication exprimée par l’indentation, structure implicite. TOML a parié sur l’explicite : les chaînes doivent être entre guillemets, les sections doivent être déclarées par des [headers], et rien n’est deviné. Aucun pari n’est mauvais ; ils optimisent des modes de défaillance différents.
Le pari de YAML achète des fichiers compacts et très lisibles — et toute une classe d’erreurs que TOML n’a pas. Des erreurs d’indentation remodèlent des documents en silence, et les scalaires nus sont typés par inférence, si bien qu’un code de pays comme NO devient le booléen false (le problème de la Norvège). Le pari de TOML achète des fichiers plus longs en profondeur mais presque impossibles à mal lire : la grammaire est petite, versionnée stable au sens semver à la 1.0 depuis 2021, et le type d’une valeur est toujours déclaré par sa syntaxe.
Cette page compare les deux là où les choix se font : syntaxe et structure, typage et surprises classiques, commentaires et ancres, et les écosystèmes — Kubernetes et CI pour YAML, Cargo et le packaging Python pour TOML — qui, d’ordinaire, tranchent avant vous.
La façon la plus rapide de sentir la différence de typage est de convertir le même fichier dans les deux sens — le convertisseur YAML vers JSON montre exactement ce que chaque scalaire nu est devenu, dans votre navigateur.
Curieux de voir à quoi se réduit le style explicite de TOML ? Le convertisseur TOML vers JSON exécute l’analyse en local et n’étiquette rien, parce que rien n’a besoin d’être inféré.
Deux philosophies : inféré contre déclaré
La différence la plus profonde tient à l’endroit où vit la structure. Dans YAML, la structure est l’espace blanc : les niveaux d’indentation définissent l’imbrication, et les tabulations sont interdites sans exception. Dans TOML, la structure est la ponctuation : une ligne comme [database.pool] déclare une table, et l’indentation est purement cosmétique. Tout le reste de cette page — résistance au collage, verbosité en profondeur, messages d’erreur — découle de cette seule décision.
| Aspect | YAML 1.2 | TOML 1.0 |
|---|---|---|
| Structure | Indentation (espaces seulement ; tabulations interdites) | En-têtes [table] et clés pointées |
| Chaînes | Guillemets généralement facultatifs | Toujours entre guillemets — "..." ou '...' |
| Typage | Inféré selon le parseur ; NO devient false | Déclaré par la syntaxe ; rien n’est inféré |
| Dates et heures | Type timestamp, selon le parseur | Date-times RFC 3339 natifs |
| Ancres | Ancres & et alias * | Aucune — les valeurs se répètent ou sont générées |
| Multi-documents | Oui — flux séparés par --- | Un document par fichier |
| Commentaires | # jusqu’à la fin de la ligne | # jusqu’à la fin de la ligne |
| Stabilité de la spécification | 1.2 (2009), stratifiée et touffue | 1.0 (2021), petite et stable au sens semver |
Syntaxe : indentation contre en-têtes de table
La configuration peu profonde flatte les deux formats ; l’imbrication profonde les sépare. YAML se fait plus discret à mesure que la structure grandit — deux espaces et un tiret — tandis que TOML écrit un en-tête par niveau : [database.pool.limits], puis [database.pool.limits.read]. À trois niveaux, TOML n’est que verbeux ; à huit, YAML est le seul choix raisonnable écrit à la main. Les tableaux de tables renversent le verdict : les blocs [[products]] de TOML sont nets et greppables, tandis que les longues listes de maps YAML sont exactement là où les colonnes dérivent.
La résistance au collage découle directement. Déposer un bloc dans YAML une colonne trop à gauche ou trop à droite casse l’analyse ou — pire — change silencieusement ce qu’il signifie ; le fichier s’analyse encore et rien ne vous alerte. Dans TOML, un bloc collé porte son propre [header], donc il atterrit là où son en-tête l’indique, quel que soit l’espace blanc alentour.
Types et le problème de la Norvège
YAML infère les types scalaires, et l’inférence a des dents : yes, no, on et off deviennent des booléens sous les règles YAML 1.1 que beaucoup de parseurs livrent encore, NO devient false, et une version écrite 1.20 peut arriver comme le nombre 1.2. YAML 1.2 a taillé les règles mais n’a pas unifié les parseurs, si bien qu’un même fichier peut être typé différemment selon les outils. La défense consiste à mettre entre guillemets tout ce qui doit rester une chaîne.
TOML n’a aucune étape d’inférence à rater : les guillemets font une chaîne, les chiffres nus font un entier (underscores admis pour la lisibilité), et les horodatages RFC 3339 sont un type de première classe — un véritable avantage sur JSON comme YAML pour une configuration qui porte des dates. Les chaînes multilignes existent dans les deux : les blocs """ à triple guillemets de TOML et les scalaires | et > de YAML.
Écosystèmes, et quand choisir l’un ou l’autre
Les écosystèmes ont déjà partagé le territoire. YAML possède le cloud-native et la CI : manifestes Kubernetes, GitHub Actions et GitLab CI, Ansible, docker-compose, descriptions OpenAPI. TOML possède le packaging et les métadonnées d’outillage : le Cargo de Rust, le pyproject.toml de Python, et une longue liste d’outils CLI qui veulent une configuration sans ambiguïté et accueillante aux commentaires. Choisir contre un écosystème revient à se battre contre son outillage pour toujours, donc c’est rarement un choix libre.
Là où vous choisissez vraiment : YAML pour les documents profondément imbriqués et relus par des humains, TOML quand les valeurs doivent être sans ambiguïté, les diffs exacts et les fichiers édités à la fois par des humains et des générateurs. La recommandation s’inverse couramment — la plupart des dépôts hébergent les deux — et les convertisseurs reliés ici font le pont dans les deux sens, en local.
Questions fréquentes
TOML remplace-t-il YAML ?
Non — les deux se sont partagé le territoire plutôt que de s’y battre. YAML est retranché là où l’outillage cloud-native l’impose : Kubernetes, GitHub Actions, Ansible, docker-compose. TOML est retranché dans le packaging : Cargo.toml, pyproject.toml et la configuration de la plupart des outils CLI modernes. Les nouveaux outils choisissent de plus en plus TOML pour des réglages simples, mais aucune migration sérieuse hors de YAML n’est en cours à grande échelle.
TOML a-t-il le problème de la Norvège ?
Non. YAML infère les types des scalaires nus, donc NO s’analyse comme le booléen false et on ou off deviennent aussi des booléens. TOML exige que chaque chaîne soit entre guillemets, donc "NO" est sans ambiguïté une chaîne et rien n’est jamais inféré. La défense de YAML est la même discipline que TOML impose : mettre entre guillemets toute valeur qui doit rester du texte.
Les convertisseurs YAML et TOML envoient-ils ma configuration ?
Non. L’analyse et la production s’exécutent dans votre onglet de navigateur — il n’existe aucun point d’envoi, et la Content-Security-Policy du site n’autorise les requêtes réseau que vers elle-même. Ouvrez le panneau Network de DevTools pendant une conversion : vous ne verrez aucune requête sortante ; les fichiers que vous collez restent dans l’onglet.
Pourquoi TOML devient-il si verbeux pour une configuration imbriquée ?
Chaque niveau d’imbrication exige son propre en-tête entre crochets : [database.pool.limits.read] déclare trois lignes de portée avant la première valeur. Cette verbosité est aussi la fonctionnalité — les sections sont greppables, la portée est sans ambiguïté, et les diffs montrent exactement ce qui a bougé. Si votre configuration s’imbrique huit niveaux de profondeur, l’indentation de YAML est vraiment le meilleur choix.
YAML et TOML prennent-ils tous les deux en charge les commentaires ?
Oui — les deux utilisent # jusqu’à la fin de la ligne, et c’est précisément pourquoi les deux ont délogé JSON pour la configuration. Ils diffèrent dans presque tout le reste : ancres et flux multi-documents n’existent que dans YAML, tandis que TOML offre des dates RFC 3339 natives et une grammaire 1.0 stable au sens semver que YAML n’a jamais égalée.
Quel format est le plus sûr à copier-coller ?
TOML. Un bloc collé dans YAML doit atterrir exactement à la bonne colonne d’indentation, sans quoi le sens du document change en silence ; même quand le fichier s’analyse, rien ne vous alerte. Les blocs TOML sont délimités par leurs propres [headers], donc l’indentation est cosmétique et une section collée signifie ce que son en-tête dit, où qu’elle atterrisse.
Où puis-je lire les normes citées ici ?
Quels outils liés devriez-vous utiliser ensuite ?
- JSON vs YAMLComparatif point par pointOuvrir
- Les bases de YAMLGuide en langage clairOuvrir
- Convertir YAML en JSONConvertit sans que « NO » devienne falseOuvrir
- Convertir JSON en YAMLConvertit avec des guillemets qui résistent à l’aller-retourOuvrir
- TOML vers JSONConvertisseur qui fonctionne dans votre navigateurOuvrir
- JSON vers TOMLConvertisseur qui fonctionne dans votre navigateurOuvrir