Qu'est-ce que YAML ? Le langage de données convivial pour les humains
YAML en termes simples
Le nom complet de YAML est 'YAML Ain't Markup Language' (YAML n'est pas un langage de balisage) — une boutade récursive qui te dit ce qu'il n'est *pas*. Il ne sert pas à baliser des documents comme le HTML. Au lieu de cela, YAML est un format de sérialisation de données conçu pour être lisible et modifiable par une personne sans avoir un manuel ouvert dans l'onglet suivant. Il est apparu pour la première fois en 2001, une création de Clark Evans, Ingy döt Net et Oren Ben-Kiki. Depuis, il est devenu le langage de configuration par défaut pour des outils essentiels comme Kubernetes, Ansible, GitHub Actions, Docker Compose et Ruby on Rails. En son cœur, YAML utilise l'indentation pour représenter des structures de données comme les paires clé-valeur et les listes. Tu ne trouveras pas de chevrons ou d'accolades ici. Un simple fichier Docker Compose le montre clairement : version: '3.9' services: web: image: nginx:latest ports: - '80:80' Compare cela avec le JSON équivalent et l'attrait est évident. Pas de virgules, pas de guillemets sur les clés, et pas d'accolades de fermeture à mal assortir. L'inconvénient est que l'indentation devient significative. Fais une erreur d'un seul espace, et le fichier pourrait ne pas être parsé ou, pire, signifier silencieusement quelque chose de complètement différent. Cette tension entre lecture facile et structure stricte définit l'expérience YAML. Te familiariser avec lui est la clé pour bien utiliser le format.
Comment YAML structure les données : les trois blocs de construction
Chaque document YAML est composé des mêmes éléments de base : les scalaires, les séquences et les mappings. Un scalaire est simplement une valeur unique, comme une chaîne de caractères, un nombre, un booléen ou null. YAML est astucieux pour inférer le type, ce qui est généralement utile mais peut parfois se retourner contre toi. La chaîne 'yes' est parsée comme un booléen `true` dans l'ancienne norme YAML 1.1, qui est toujours utilisée par PyYAML et d'autres outils hérités. YAML 1.2, cependant, la traite correctement comme une simple chaîne de caractères. Cet écart de version a causé de véritables bugs en production, tu dois donc absolument savoir quel parseur tes outils utilisent. Une séquence est simplement une liste ordonnée. Tu l'écris avec un tiret et un espace devant : fruits: - apple - banana - mango Un mapping est un ensemble de paires clé-valeur, ce que tu verras le plus souvent dans les fichiers de configuration. Tu peux imbriquer des mappings à n'importe quelle profondeur, et la structure est définie purement par une indentation cohérente. La spécification YAML est claire à ce sujet : tu dois utiliser des espaces, jamais des tabulations. YAML offre également des fonctionnalités puissantes pour réduire la répétition. Les ancres (&) et les alias (*) te permettent de définir un bloc de données une fois et de le réutiliser ailleurs. C'est un véritable sauveur dans les pipelines CI/CD où plusieurs tâches peuvent partager exactement le même bloc de variables d'environnement. Pour les chaînes longues, YAML propose deux styles de blocs : le scalaire de bloc littéral (|) préserve exactement les sauts de ligne, tandis que le scalaire de bloc plié (>) les regroupe en espaces. C'est parfait pour les longues commandes shell que tu veux garder lisibles dans le fichier sans ajouter de véritables sauts de ligne à la commande elle-même.
Où YAML est réellement utilisé
YAML prospère dans le monde de l'infrastructure et des outils de développement. Les chiffres ne mentent pas. En 2024, GitHub Actions traite plus de 100 millions d'exécutions de workflows par jour, chacune étant pilotée par un fichier .yml dans le répertoire .github/workflows d'un projet. Kubernetes, le moteur derrière la plupart des applications cloud-natives, s'appuie sur YAML pour définir chaque ressource : Deployments, Services, ConfigMaps, tu n'as qu'à nommer. Une application de microservices typique peut facilement accumuler des centaines de fichiers YAML. Ansible, l'outil d'automatisation informatique utilisé par plus de 25 000 organisations (selon Red Hat), utilise YAML pour tous ses playbooks. Une tâche standard dans un playbook Ansible ressemble à ceci : - name: Install nginx ansible.builtin.package: name: nginx state: present Au-delà de la sphère DevOps, tu trouveras YAML dans les générateurs de sites statiques comme Jekyll, qui utilise le front matter YAML pour stocker des métadonnées dans les fichiers Markdown. Des outils de test d'API comme Hoppscotch et Insomnia l'utilisent pour la configuration de l'environnement. Même les pipelines de science des données l'utilisent ; des outils tels que DVC (Data Version Control) suivent les paramètres d'expérience dans les fichiers YAML. Un endroit où tu ne verras pas beaucoup de YAML est l'échange de données entre services web. Les API REST utilisent presque universellement JSON pour les corps de requêtes et de réponses. Pourquoi ? Parce que les analyseurs JSON sont intégrés à chaque navigateur et que la rigueur du format ne laisse aucune place à l'ambiguïté. C'est la distinction clé : YAML est pour les humains qui éditent des fichiers sur disque ; JSON est pour les machines qui transmettent des données sur un réseau. Te souvenir de cette règle simple t'évitera beaucoup de confusion quant au format à choisir.
YAML vs JSON vs TOML : Choisir le bon format
Lorsque tu choisis un format de configuration, tu as généralement le choix entre YAML, JSON et TOML. Chacun a une personnalité distincte. JSON (JavaScript Object Notation) est le plus strict. Chaque chaîne de caractères doit être entre guillemets, chaque liste et objet explicitement fermé, et il ne prend pas en charge les commentaires. Ce dernier point est une source majeure de frustration pour les développeurs qui souhaitent annoter la configuration. Mais la force de JSON est son analyse rigide et sans ambiguïté ; deux analyseurs conformes produiront des structures de données identiques à partir de la même entrée. Sa taille de fichier est généralement comparable à celle de YAML pour des configurations typiques. TOML (Tom's Obvious, Minimal Language) a été créé pour corriger le manque de commentaires de JSON et les règles d'espacement délicates de YAML. Il utilise une syntaxe de style INI et a été adopté par le gestionnaire de paquets Cargo de Rust et la norme pyproject.toml de Python. TOML est fantastique pour les configurations plates ou peu imbriquées, mais il devient maladroit et verbeux lorsque tu dois représenter des données profondément imbriquées. Alors, où se situe YAML ? YAML est le grand gagnant lorsque ta configuration a une profondeur d'imbrication significative, lorsque tu peux utiliser des ancres et des alias pour éliminer la répétition, ou lorsque des personnes non techniques doivent éditer le fichier. C'est le mauvais choix lorsque ton équipe se bat constamment avec des erreurs d'indentation ou lorsque l'inférence de type crée des surprises (comme le célèbre problème de la Norvège, où le code pays 'NO' était parsé comme un booléen `false`). Si tu as besoin de convertir entre les formats, CocoConvert propose des conversions fiables de YAML vers JSON et de JSON vers YAML. Il ne prend pas en charge TOML comme format de sortie, cependant. Si tu dois passer de YAML à TOML, tu devras te tourner vers un outil en ligne de commande comme `yq`. Il vaut mieux le savoir à l'avance.
Erreurs YAML courantes et comment les éviter
La source d'erreurs YAML la plus courante est une indentation incohérente. Quiconque a passé une heure à déboguer un pipeline CI pour ne trouver qu'un seul espace mal placé connaît cette douleur. Contrairement à Python, qui accepte n'importe quelle largeur d'indentation cohérente, YAML exige que les clés de même niveau aient exactement la même indentation. Mélanger des indentations de deux et quatre espaces dans un même fichier entraînera une erreur d'analyse ou, bien pire, re-structurera silencieusement tes données. La seule façon sûre de travailler est de configurer ton éditeur pour qu'il utilise des espaces à la place des tabulations et impose une taille d'indentation cohérente. Deux espaces est la norme de facto pour Kubernetes et GitHub Actions. Les caractères spéciaux non guillemetés sont un autre piège. Un deux-points suivi d'un espace est un séparateur clé-valeur, donc une chaîne comme 'http://example.com:8080' doit être mise entre guillemets. Oublie les guillemets, et tu obtiendras une erreur d'analyse. De même, les valeurs commençant par `{`, `[`, ou `%` doivent être mises entre guillemets car elles ont une signification spéciale dans la syntaxe YAML. Ensuite, il y a les surprises de coercition de type. Nous avons déjà mentionné comment 'no' peut devenir `false`. Mais savais-tu que les nombres avec des zéros en tête peuvent être parsés comme des entiers octaux ? La valeur 0755, une permission de fichier Unix courante, devient décimal 493 à moins que tu ne la mettes entre guillemets. Les dates sont un autre piège ; 2024-01-01 sans guillemets devient un objet date, pas une chaîne, ce qui peut casser les outils qui attendent une chaîne. La meilleure défense est de 'linter' ton YAML avant de le committer. `yamllint` est un outil en ligne de commande essentiel qui détecte les erreurs d'indentation, les espaces de fin de ligne et d'autres problèmes courants. Ton pipeline CI devrait absolument inclure une étape `yamllint`. Pour une vérification rapide et ponctuelle, coller ton fichier dans le convertisseur YAML-vers-JSON de CocoConvert est un excellent test de bon sens. Si la structure JSON résultante ne ressemble pas à ce que tu avais l'intention de faire, ton YAML a un problème.
Convertir des fichiers YAML : ce que CocoConvert peut faire
CocoConvert fournit des outils pour les deux besoins de conversion les plus courants : YAML vers JSON et JSON vers YAML. Le processus est simple : colle ton contenu ou télécharge un fichier .yaml, choisis ton format cible et télécharge le résultat. Le convertisseur préserve avec précision la structure imbriquée de tes données. Il gère également correctement les fichiers YAML multi-documents (où les documents sont séparés par ---), convertissant chacun en un objet JSON distinct au sein d'un tableau plus grand. Lors de la conversion de YAML en JSON, la sortie est formatée avec une indentation standard de deux espaces, ce qui la rend lisible et compatible avec presque tous les outils JSON. Si tu as besoin d'une chaîne JSON compacte, sur une seule ligne — peut-être pour une variable d'environnement ou pour réduire la taille de la charge utile — une option de minification est disponible sur la page des résultats. Passant de JSON à YAML, le convertisseur utilise une indentation de deux espaces et omet le marqueur de début de document (---) pour les documents uniques. Si l'entrée contient plusieurs objets JSON, chacun devient un document YAML distinct séparé par le marqueur `---`. Surtout, il met automatiquement entre guillemets les valeurs de chaîne qui pourraient être mal interprétées comme des booléens, des nulls ou des nombres, tu n'as donc pas à t'inquiéter qu'une chaîne comme 'true' ou '1.0' cause des problèmes. Soyons directs sur les limitations. CocoConvert ne préserve pas les commentaires YAML pendant la conversion. Ce n'est pas une lacune de l'outil ; les commentaires ne font pas partie du modèle de données formel de YAML, ils sont donc supprimés par l'analyseur. Les ancres et les alias sont également résolus, ce qui signifie que la sortie finale contiendra des valeurs répétées plutôt que des références. Enfin, les fichiers très volumineux (plus de 10 Mo) peuvent expirer sur le niveau gratuit. Pour ces gros travaux, un outil en ligne de commande comme `yq` est le meilleur choix.
Quand utiliser YAML et quand s'en éloigner
YAML est le bon outil pour le travail lorsque quelques conditions sont remplies. Le fichier sera lu et édité par des humains, les données ont une structure imbriquée significative, et l'écosystème environnant utilise déjà YAML. Les manifestes Kubernetes, les pipelines CI/CD et les playbooks Ansible en sont les exemples emblématiques. Essayer d'utiliser JSON dans ces scénarios ne fait que te compliquer la vie sans réel bénéfice. Inversement, YAML est le mauvais choix lorsqu'un fichier n'est jamais touché que par des machines. Pour la communication de machine à machine, utilise JSON ou un format binaire plus efficace comme MessagePack ou Protocol Buffers. C'est aussi un mauvais choix si ton équipe a constamment des difficultés avec les erreurs d'indentation et manque de discipline pour utiliser un linter. Dans cette situation, la syntaxe plus simple de TOML, ou même un fichier JSON pré-traité, entraînera moins d'incidents de production. Si tu utilises YAML dans des projets Python, il y a un risque de sécurité critique que tu dois comprendre. La fonction par défaut `yaml.load()` de PyYAML peut exécuter du code arbitraire intégré dans un fichier YAML. Si tu analyses du YAML provenant d'une source non fiable, tu dois toujours utiliser `yaml.safe_load()`. Ce n'est pas une vulnérabilité théorique ; elle a été exploitée dans de véritables attaques de la chaîne d'approvisionnement. Le format est avec nous depuis plus de deux décennies et n'est pas près de disparaître. La spécification YAML 1.2, qui a corrigé la plupart des problèmes de coercition de type agaçants de la version 1.1, est désormais largement prise en charge par les analyseurs modernes comme PyYAML 6.0+, js-yaml 4.x et yaml.v3 de Go. Ma plus forte recommandation : si tu travailles sur un projet qui repose fortement sur YAML, migrer vers un analyseur conforme à la version 1.2 est la mise à niveau la plus impactante que tu puisses faire. Cela éliminera toute une catégorie de bugs subtils sans que tu aies à modifier une seule ligne de configuration.