YAML — qui se définit récursivement comme « YAML Ain't Markup Language » — représente les données via l'indentation plutôt que par des parenthèses ou des accolades. Tout est construit à partir de trois primitives : les valeurs scalaires (chaînes de caractères, nombres, booléens), les séquences (listes ordonnées, marquées avec -), et les mappings (paires clé-valeur, marquées avec :). Vous imbriquez des éléments en les indentant davantage. Un retrait de deux espaces sous une clé signifie « cela appartient à cette clé ». C'est ce qui rend YAML lisible à première vue, mais aussi ce qui le rend frustrant lorsque quelque chose casse. Au-delà des bases, YAML prend en charge les ancrages (&name) et les alias (*name) pour réutiliser des morceaux de configuration, les fichiers multi-documents séparés par ---, ainsi que des balises personnalisées pour les indices de type. La plupart des gens n'exploitent jamais les fonctionnalités avancées, mais les ancrages seuls peuvent vous éviter de maintenir le même bloc de configuration dans cinq endroits différents.
Si vous travaillez dans l'infrastructure de l'IA, YAML est incontournable. Les cartes de modèles Hugging Face sont des métadonnées YAML qui décrivent la licence d'un modèle, les ensembles de données, les métriques et l'utilisation prévue — c'est ainsi que le Hub sait ce que votre modèle est et comment l'afficher. Les fichiers Docker Compose qui démarrent votre serveur d'inférence, votre base de données vectorielle et votre stack de surveillance sont tous en YAML. Les manifestes Kubernetes qui déployent et échelonnent vos pods de serveur de modèles sont en YAML. Les configurations d'entraînement pour des cadres comme Hydra, MMEngine et Axolotl sont en YAML. Les pipelines CI/CD dans GitHub Actions, GitLab CI et CircleCI sont en YAML. Même les règles d'alerte Prometheus et les playbooks Ansible sont en YAML. Ce format a gagné la guerre des configurations non pas parce qu'il est parfait, mais parce qu'il est le moins douloureux à lire lorsque vous regardez un spécimen de déploiement de 200 lignes à 2h du matin.
La coercition de type implicite de YAML est son piège le plus célèbre. La valeur no est interprétée comme un booléen faux. La valeur 3.10 devient le flottant 3,1, ce qui pose un problème si c'est une version de Python. Le code pays NO pour la Norvège devient un booléen faux — c'est littéralement appelé « le problème de Norvège » et il a causé des bugs réels dans des ensembles de données en production. Puis il y a le problème tabulation-espaces : YAML interdit les tabulations pour l'indentation, point final. Une seule tabulation dans un fichier de 500 lignes rend l'ensemble impossible à analyser, souvent avec un message d'erreur qui pointe vers la ligne incorrecte. Les chaînes multilignes ajoutent encore un niveau de confusion avec | (bloc littéral, préserve les sauts de ligne), > (bloc plié, joint les lignes), ainsi que leurs variantes avec - et + pour contrôler les sauts de ligne en fin de ligne. La plupart des gens choisissent un style et le mémorisent plutôt que d'apprendre toutes les combinaisons.
JSON est strict, non ambigu et universellement pris en charge — mais il est pénible à écrire à la main en raison de tous les guillemets et accolades, et il ne prend pas en charge les commentaires. YAML est un surensemble de JSON (un JSON valide est un YAML valide) qui échange la rigueur pour la lisibilité : vous obtenez des commentaires, une syntaxe plus propre et des ancrages, mais vous avez aussi la coercition de type implicite et la sensibilité aux espaces blancs. TOML se situe entre les deux — typage explicite, commentaires, pas de sensibilité à l'indentation — et convient bien aux configurations plates ou peu profondes comme pyproject.toml et Cargo.toml de Rust. La règle pratique : utilisez JSON pour la communication machine-à-machine et les payloads API, TOML pour la configuration d'applications restant peu profonde, et YAML pour les configurations profondément imbriquées que les humains doivent lire et modifier régulièrement. Si votre configuration est plus profonde que trois niveaux, YAML est probablement votre meilleure option. Si elle est de deux niveaux ou moins, TOML vous évitera des maux de tête.
L'investissement le plus important que vous pouvez faire est un linter YAML. yamllint détecte non seulement les erreurs de syntaxe mais aussi les problèmes de style comme l'indentation incohérente et les espaces en fin de ligne. Exécutez-le dans votre pipeline CI afin que le YAML mal formé n'atteigne jamais la production. Les extensions d'IDE — le plugin YAML pour VS Code par Red Hat est le standard — vous donnent une validation en temps réel, une complétion automatique basée sur le schéma JSON, et des retours immédiats lorsque votre indentation s'écarte. Pour les configurations volumineuses avec des blocs répétés, apprenez à utiliser les ancrages et les alias : définissez une configuration par défaut une fois avec &defaults et fusionnez-la dans des entrées spécifiques avec <<: *defaults, en ne modifiant que ce qui change. Si vous travaillez avec Kubernetes ou Docker Compose, des outils comme kubeval et docker compose config valideront votre YAML contre le schéma réel, détectant des erreurs que ne repèrent pas les lintes généraux. Et lorsque tout échoue, souvenez-vous que vous pouvez toujours convertir YAML en JSON, le vérifier là-bas, puis le convertir à nouveau — car, à la fin de la journée, ils représentent les mêmes données.