FlowingDev

YAML, expliqué : comment l'indentation est devenue un super-pouvoir

YAML est un format de données lisible par l'homme qui utilise une simple indentation pour structurer les données, ce qui le rend populaire pour les fichiers de configuration et l'échange de données.

Essayer l'outil: Visionneuse YAML

En une phrase

YAML est un langage de sérialisation de données lisible par l'homme qui utilise l'indentation et une ponctuation minimale pour exprimer des structures de données, ce qui en fait un favori pour les fichiers de configuration que des humains doivent réellement écrire et lire.

Le problème qu'il résout

Au commencement, il y avait le chaos. Ou, plus précisément, il y avait des formats comme le XML. Si vous vouliez stocker des données structurées — disons, les paramètres d'un utilisateur — vous les enveloppiez dans une forêt de chevrons. C'était puissant, lisible par une machine, et un cauchemar total pour un humain à modifier sans faire d'erreur.

<user>
  <name>Alex</name>
  <roles>
    <role>editor</role>
    <role>admin</role>
  </roles>
  <active>true</active>
</user>

Puis est arrivé le JSON (JavaScript Object Notation). Ce fut une bouffée d'air frais ! Inspiré de la syntaxe des objets JavaScript, il a abandonné les chevrons au profit d'accolades, de crochets et de deux-points. C'était plus léger, plus propre, et c'est devenu le standard de facto pour les API du monde entier.

{
  "name": "Alex",
  "roles": [
    "editor",
    "admin"
  ],
  "active": true
}

Mais même le JSON a ses défauts quand ce sont des humains qui sont aux commandes. Toutes ces virgules, guillemets et accolades sont des pièges syntaxiques. Vous oubliez une virgule ? Tout le fichier est invalide. Vous voulez ajouter un commentaire pour expliquer pourquoi un paramètre a une certaine valeur ? Dommage, le JSON ne supporte pas les commentaires.

C'est la niche que YAML est venu combler au début des années 2000. Son nom, un acronyme récursif, dit tout : YAML Ain't Markup Language (YAML n'est pas un langage de balisage). Il se concentre exclusivement sur le fait d'être un format de données, pas un système de marquage de documents. L'objectif principal de ses créateurs était d'optimiser la lisibilité et la facilité d'écriture par les humains. Ils ont regardé la structure propre et indentée de Python et se sont dit : « Et si on pouvait utiliser ça pour les données ? » Le résultat est un format qui ressemble moins à du code qu'à un plan bien organisé.

Comment ça marche sous le capot

La magie de YAML réside dans sa simplicité et sa relation avec le JSON. Fondamentalement, un parser YAML lit un fichier texte et construit une structure de données abstraite en mémoire — un processus assez similaire au fonctionnement d'un parser JSON. C'est pourquoi la conversion entre YAML et JSON est si fluide ; ils représentent les mêmes concepts fondamentaux, mais avec des habits différents.

Le jeu de l'indentation

C'est la caractéristique principale de YAML. Là où JSON utilise {} et [] pour montrer l'imbrication, YAML utilise les espaces. La règle est simple : si une ligne est plus indentée que la ligne précédente, elle est un enfant de cette ligne.

  • Règle n°1 : Utilisez des espaces, pas des tabulations. Le monde s'est collectivement mis d'accord là-dessus pour éviter le chaos de l'alignement.
  • Règle n°2 : Soyez cohérent. Si vous utilisez 2 espaces pour votre premier niveau d'indentation, utilisez 2 espaces pour tous les premiers niveaux.

Regardez la différence. La structure est identique, mais la version YAML ressemble à une série de notes claires.

JSON :

{
  "server": {
    "port": 8080,
    "security": {
      "enable_https": true
    }
  }
}

YAML :

server:
  port: 8080
  security:
    enable_https: true

Les briques de base : scalaires, séquences et mappings

Les données YAML sont composées de trois choses de base :

  • Mappings (Objets/Dictionnaires) : Ce sont des paires clé-valeur. En YAML, vous les écrivez sous la forme clé: valeur. L'espace après les deux-points est obligatoire !
    # Un mapping simple
name: "Alex"
email: alex@example.com
  • Séquences (Listes/Tableaux) : Ce sont des listes ordonnées d'éléments. Vous indiquez chaque élément avec un tiret et un espace (- ).
    # Une séquence simple de rôles
- editor
- admin
- contributor
  • Scalaires (Valeurs) : Ce sont les données réelles : chaînes de caractères, nombres, booléens. L'une des fonctionnalités les plus sympathiques de YAML est que vous n'avez souvent pas besoin de mettre vos chaînes entre guillemets. name: Alex fonctionne très bien. Vous n'avez besoin de guillemets que si votre chaîne contient des caractères spéciaux ou pourrait être mal interprétée comme un autre type (comme true ou 5.0).

La combinaison de ces éléments vous donne le pouvoir de représenter presque n'importe quelle structure de données.

# Une liste d'objets utilisateur
- name: Alex
  email: alex@example.com
  roles:
    - editor
    - admin
- name: Bailey
  email: bailey@example.com
  roles:
    - contributor

Sorcellerie avancée : ancres, alias et tags

YAML a quelques tours dans son sac que JSON n'a pas, principalement pour garder vos fichiers DRY (Don't Repeat Yourself - Ne vous répétez pas).

  • Ancres (&) et Alias (*) : Une ancre vous permet de nommer un bloc de données. Un alias vous permet de référencer ce bloc ailleurs. C'est une aubaine pour les configurations complexes où vous avez des blocs répétés.

    # Définir un ensemble de configurations par défaut avec une ancre
default_db_config: &db_defaults
  adapter: postgres
  pool: 5
  timeout: 5000

# Utiliser les valeurs par défaut dans différents environnements avec un alias
development:
  <<: *db_defaults # Le << fusionne l'alias
  database: myapp_dev

production:
  <<: *db_defaults
  database: myapp_prod

    Ici, &db_defaults crée un modèle réutilisable. *db_defaults le copie. Si vous devez changer le timeout pour tous les environnements, vous n'avez qu'à le changer à un seul endroit.

  • Tags (!) : Les tags sont un moyen de dire explicitement au parser de quel type de données il s'agit. Vous les écrirez rarement vous-même, mais ils font partie de la spécification. !!str "123" force le parser à traiter "123" comme une chaîne de caractères, pas comme un nombre.

Histoires vécues

L'ingénieur DevOps dépassé

Une équipe gérait son infrastructure applicative sur Kubernetes. Chaque service, déploiement et carte de configuration était un fichier .json distinct. Au fur et à mesure que le système grandissait, l'« aveuglement aux accolades » s'est installé. Les diffs sur les pull requests étaient un cauchemar d'accolades mal assorties et de changements de virgules finales. Un ingénieur a finalement craqué et a mené une migration vers YAML. Soudain, les fichiers deployment.yaml sont devenus lisibles d'un coup d'œil. Des commentaires ont été ajoutés pour expliquer pourquoi un service avait une limite de mémoire spécifique. Trouver une faute de frappe dans une variable d'environnement est devenu un balayage visuel au lieu d'un casse-tête syntaxique.

Leçon : Pour une configuration complexe et hiérarchique qui est fréquemment lue et modifiée par des humains, la lisibilité de YAML est une énorme amélioration de la qualité de vie.

Le fanatique des générateurs de sites statiques

Une équipe de contenu utilisait un générateur de site statique (comme Hugo ou Jekyll) pour gérer le blog d'une entreprise. Chaque article commençait par du « frontmatter », un bloc de métadonnées pour le titre, l'auteur, la date et les tags. La configuration initiale utilisait du frontmatter en JSON. Les rédacteurs non techniques étaient constamment bloqués par des virgules manquantes ou des guillemets mal échappés. Un développeur a changé le format du frontmatter en YAML. La syntaxe était si intuitive (title: Mon Article, author: Dale) que les tickets de support des rédacteurs sont tombés à zéro. Ils pouvaient désormais se concentrer sur l'écriture, pas sur la syntaxe.

Leçon : Le faible bruit syntaxique de YAML en fait une excellente « interface » pour les non-développeurs qui ont besoin d'interagir avec des données structurées.

Le piège du code pays

Un développeur construisait un système pour traiter les commandes internationales et stockait les codes pays à deux lettres dans un fichier de configuration YAML. Tout fonctionnait à merveille pour les US, DE et JP. Mais lorsqu'une commande de Norvège (Norway) est arrivée, le système a planté. Après des heures de débogage, il a trouvé le coupable. Le fichier YAML contenait country: NO. Le parser YAML, dans son infinie bienveillance, a interprété NO comme la valeur booléenne false, et non comme la chaîne de caractères "NO". La correction était simple mais frustrante : country: "NO".

Leçon : L'inférence de type automatique de YAML est pratique mais peut conduire à des bugs surprenants. En cas de doute, ou lorsque vous traitez des données qui ressemblent à un booléen ou à un nombre, mettez vos chaînes entre guillemets.

Erreurs et pièges courants

  • Tabulations vs Espaces. C'est le péché originel de YAML. Vous devez utiliser des espaces pour l'indentation. La plupart des éditeurs peuvent être configurés pour convertir automatiquement les tabulations en espaces, ce qui vous évitera cette plaie particulière.
  • Le problème de la Norvège. Comme vu ci-dessus, des chaînes de caractères non guillemetées comme NO, YES, ON, OFF, et même certains nombres peuvent être automatiquement convertis en booléens ou en types numériques. La règle d'or : si c'est une chaîne qui pourrait être autre chose, mettez-la entre guillemets.
  • Oublier l'espace après les deux-points. Écrire clé:valeur provoquera une erreur d'analyse. Il doit y avoir un espace après les deux-points : clé: valeur. C'est un petit détail qui piège tout le monde au moins une fois.
  • Indentation incohérente. Utiliser deux espaces pour un niveau d'imbrication puis quatre pour un autre embrouillera le parser. Choisissez une largeur d'indentation (2 espaces est la convention la plus courante) et tenez-vous-y.
  • Confusion sur les chaînes multilignes. YAML a des caractères spéciaux (| et >) pour gérer les chaînes multilignes. | préserve les sauts de ligne (idéal pour les extraits de code), tandis que > les replie en une seule ligne (idéal pour les longs paragraphes). Utiliser le mauvais peut massacrer votre texte.

Pourquoi vous devriez vous y intéresser

Vous ne pouvez pas échapper à YAML si vous travaillez dans le développement logiciel moderne, en particulier dans le domaine du DevOps et de l'infrastructure.

  • La configuration est reine : Des outils comme Docker Compose, Kubernetes, Ansible et presque toutes les plateformes de CI/CD (GitHub Actions, GitLab CI) utilisent YAML comme leur langage de configuration principal. Le connaître n'est pas une option ; c'est une compétence de base.
  • Données centrées sur l'humain : Chaque fois que vous créez un système où des humains doivent rédiger ou modifier directement des données structurées — des paramètres d'application aux métadonnées d'un article de blog — YAML devrait être un candidat de premier choix.
  • Le sur-ensemble de JSON : Parce que YAML est (principalement) un sur-ensemble de JSON, vous avez une voie de migration claire et une excellente interopérabilité. Vous pouvez prendre un fichier JSON compliqué, le convertir en YAML pour le rendre plus lisible, ajouter des commentaires, puis le reconvertir si un autre système nécessite du JSON pur.

Pensez à YAML comme au bibliothécaire amical et organisé face au flux de données brut et efficace de JSON. Vous avez besoin des deux dans votre boîte à outils.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Visionneuse YAML