Formateur YAML

Formatez du YAML avec une indentation cohérente, ou convertissez-le en JSON. Détecte les tabulations mélangées et les incohérences d'indentation.

Dernière mise à jour : 2026-09-12

Qu'est-ce qu'un formateur YAML ?

Un formateur YAML prend un document dont l'indentation est irrégulière et le réécrit avec une indentation uniforme de 2 ou 4 espaces, tout en validant la syntaxe au passage. Les fichiers de configuration ont tendance à accumuler des incohérences d'indentation après des copier-coller et des modifications manuelles répétés, et le premier signe du problème n'apparaît souvent que bien plus tard, sous la forme d'une erreur cryptique du pipeline CI/CD ou de l'outil de gestion de configuration. Comme cet outil fonctionne entièrement dans votre navigateur, vous pouvez vérifier des fichiers de configuration sensibles sans envoyer leur contenu à un serveur externe.

Cet outil s'appuie sur un analyseur léger développé sur mesure, ciblant le "sous-ensemble courant" largement utilisé dans Docker Compose, GitHub Actions et les manifestes Kubernetes : mappings, listes, collections en ligne et types scalaires de base. Il ne prend pas en charge les fonctionnalités avancées comme les ancres (&), les alias (*), les documents multiples ou les scalaires de bloc (|/>). Si vous travaillez avec du YAML qui repose sur ces fonctionnalités, mieux vaut combiner cet outil avec un analyseur complet.

Comment utiliser le formateur YAML

Collez votre YAML Collez le YAML à formater dans le champ de saisie à gauche. Si vous n'avez pas d'exemple sous la main, cliquez sur "Exemple" pour insérer un YAML à tester.
Choisissez un mode Sélectionnez "Formater et valider" pour vérifier la syntaxe et normaliser l'indentation, ou "Convertir en JSON" pour restituer le contenu YAML au format JSON.
Choisissez la largeur d'indentation Uniquement en mode "Formater et valider", choisissez 2 ou 4 espaces pour la sortie, selon la convention déjà en vigueur dans votre projet.
Vérifiez le résultat Si le YAML est valide, le résultat formaté (ou la conversion JSON) s'affiche à droite. Sinon, un message d'erreur et le numéro de ligne s'affichent pour vous permettre d'aller directement au problème.
Copiez le résultat Cliquez sur "Copier" pour copier le résultat dans le presse-papiers et le recoller directement dans votre fichier de configuration.

Astuces pour en tirer le meilleur parti

Cet outil utilise un analyseur léger développé en interne, prenant en charge les paires clé: valeur, l'imbrication, les listes et la syntaxe en ligne [a, b, c] / {a: 1}.
Même si vous collez du YAML avec une indentation incohérente (3 ou 5 espaces, par exemple), il sera réécrit avec une indentation uniforme de 2 ou 4 espaces, tant que l'analyse réussit.
En mode "Convertir en JSON", vous pouvez prévisualiser votre YAML converti directement en JSON — pratique pour le comparer à une configuration CI ou à une réponse d'API.
En cas d'erreur, le numéro de ligne s'affiche : vérifiez cette ligne pour un problème d'indentation ou un espace manquant après les deux-points.
YAML interdit l'indentation par tabulations. Activer "convertir les tabulations en espaces" dans les réglages de votre éditeur permet d'éviter complètement ce piège.

Quand utiliser cet outil

Vérification préalable des configurations CI

Passez vos fichiers .yml GitHub Actions ou GitLab CI dans cet outil avant de valider, afin de détecter une indentation cassée ou des tabulations égarées avant que le pipeline n'échoue sur une erreur de syntaxe.

Nettoyage des manifestes Kubernetes

Les manifestes Deployment et Service modifiés par plusieurs personnes finissent souvent avec une indentation incohérente. Normalisez-les selon la convention de votre équipe (2 espaces, par exemple) avant de les envoyer en relecture.

Validation des fichiers Docker Compose

Les erreurs d'indentation dans docker-compose.yml passent souvent inaperçues jusqu'à ce que le conteneur échoue au démarrage. Vérifier ici au préalable la syntaxe et la cohérence de l'indentation vous apporte plus de sérénité.

Comparer YAML et JSON côte à côte

Lorsque vous devez utiliser la même configuration ou les mêmes données d'API à la fois en YAML et en JSON, le mode "Convertir en JSON" vous permet de vérifier le résultat de la conversion avant de l'utiliser avec d'autres outils basés sur JSON ou des validateurs de schéma.

Glossaire

YAML: Acronyme récursif de "YAML Ain't Markup Language", un format de sérialisation de données qui exprime une structure hiérarchique par l'indentation. Très utilisé pour les fichiers de configuration.
Indentation: Les espaces en début de ligne, que YAML utilise pour exprimer les relations parent-enfant. Selon la spécification, les tabulations ne peuvent jamais être utilisées pour l'indentation.
Mapping: Une structure qui représente des données sous forme de paires "clé: valeur", équivalente à un tableau associatif ou un objet dans d'autres langages.
Liste (séquence): Une structure qui énumère des valeurs dans l'ordre, chaque élément commençant par un tiret suivi d'un espace ("- ").
Style de flux: Une façon d'écrire mappings et listes en ligne sur une seule ligne, comme {a: 1} ou [a, b, c], sans dépendre de l'indentation.
Ancres et alias: Un mécanisme où un contenu défini avec &nom peut être réutilisé ailleurs avec *nom, évitant de répéter les mêmes valeurs. Cet outil ne le prend pas en charge.
Scalaire de bloc: Une façon d'écrire des chaînes multilignes avec | (qui conserve les sauts de ligne) ou > (qui les transforme en espaces). Cet outil ne le prend pas en charge.
Problème norvégien: Un piège bien connu de YAML où des valeurs sans guillemets comme no ou yes sont interprétées comme des booléens plutôt que comme de simples chaînes de caractères.

Questions fréquentes

YAML convient bien aux fichiers de configuration édités et relus à la main par des humains (configurations CI, manifestes Kubernetes, etc.), car il permet les commentaires et se lit plus naturellement. JSON convient mieux à la communication entre programmes, comme les réponses d'API, car il est moins ambigu et s'analyse plus rapidement.

La spécification YAML interdit l'utilisation de tabulations pour l'indentation. La plupart des analyseurs traiteront cela comme une erreur de syntaxe et arrêteront le traitement. Le plus sûr est de configurer votre éditeur pour convertir automatiquement les tabulations en espaces.

Non. Cet outil cible le "sous-ensemble courant" habituellement utilisé dans Docker Compose, GitHub Actions et fichiers similaires (mappings, listes, collections en ligne et types scalaires de base), et ne prend pas en charge les fonctionnalités avancées comme les ancres, les alias, les documents multiples ou les scalaires de bloc (|/>).

C'est un piège bien connu : écrire no, yes, on ou off sans guillemets est interprété comme un booléen par de nombreuses implémentations YAML, plutôt que comme une simple chaîne de caractères (comme le code pays de la Norvège). Pour que ce soit traité comme une chaîne, entourez-le de guillemets, par exemple "no".

Anecdote — Pourquoi YAML est devenu le format de configuration de référence

YAML (YAML Ain't Markup Language) est un format de sérialisation de données apparu en 2001. Comme il ne nécessite pas de balises de fermeture et paraît bien plus simple que XML, il est devenu le choix standard pour les fichiers de configuration d'infrastructure depuis les années 2010 : Docker Compose, GitHub Actions et les manifestes Kubernetes l'utilisent tous.

Cela dit, le principe de YAML consistant à "structurer par l'indentation" est facile à lire pour un humain, mais aussi fragile : l'indentation se casse facilement lors d'un copier-coller. En particulier, mélanger tabulations et espaces peut amener de nombreux analyseurs à produire silencieusement une structure incorrecte sans générer d'erreur, ce qui en fait une source fréquente d'erreurs de configuration involontaires.

Il existe aussi un piège bien connu appelé le "problème norvégien". Écrire le code pays no sans guillemets est interprété comme le booléen false par de nombreuses implémentations YAML. Les différences entre YAML 1.1 et 1.2 quant aux chaînes considérées comme des booléens sont également une source fréquente de problèmes de compatibilité entre implémentations.

Voir toutes les anecdotes