Validateur et Linter YAML

Un validateur YAML devrait t'éviter les mauvaises surprises au déploiement

Le YAML se lit bien, et c'est exactement le piège. Cette lisibilité cache une arête coupante : l'indentation, c'est de la donnée. Décale un item de liste de deux espaces et soudain c'est un autre service qui récupère cette variable d'environnement. Répète une key et certains parsers jettent silencieusement la première valeur. Une tabulation égarée passe sous le radar de ton éditeur et fait sauter un pipeline trois étapes plus loin. Glisse un deux-points dans une valeur non quotée et il se fait lire comme quelque chose que tu n'avais pas prévu. Aucune de ces erreurs ne paie de mine. Et ce sont précisément le genre de bugs que personne n'attrape en code review, parce que le fichier a toujours l'air correct.

Du coup ce validateur vise les fichiers que tu colles vraiment toute la journée. Workflows GitHub Actions, services Compose, manifests Kubernetes, front matter de site statique, le bout de config bizarre copié depuis une réponse Stack Overflow. Il fait tourner les vérifications de syntaxe et de structure les plus courantes dans ton navigateur, signale les problèmes ligne par ligne, construit un aperçu façon JSON pour les maps et listes ordinaires, te montre les paths des scalaires, et glisse des rappels propres à chaque profil. Honnêtement, je ne le présenterais jamais comme un substitut au vrai parser Kubernetes ou Docker, et je me trompe peut-être sur jusqu'où on peut le pousser, mais comme première passe rapide il t'évite la honte de voir la CI rejeter une évidence.

Comment lire le rapport YAML

Regarde le score puis le premier problème, dans cet ordre. Un score propre veut juste dire que le fichier a passé les vérifications pratiques de cette page, rien de plus grandiose. Et un warning n'est pas un verdict disant que le fichier est cassé. Parfois c'est juste l'aperçu qui admet qu'il ne peut pas développer en toute sécurité un truc comme un anchor ou un custom tag. L'aperçu JSON gagne sa place quand les listes et maps imbriquées deviennent trop emmêlées pour se lire à l'œil. Le path explorer, c'est celui que tu veux quand la vraie question est de savoir si une valeur a bien atterri sous le parent que tu croyais.

• Les vérifications d'indentation traquent les tabulations, les espacements bizarres, et ces sauts de profondeur soudains qui trahissent en général un dérapage de nesting.
• Les vérifications de duplicate keys guettent la même key qui apparaît deux fois dans un même scope de map simple.
• La détection des scalaires lit les booléens, les nombres, null, les chaînes quotées, et les tableaux inline simples aussi.
• Les vérifications de profil te rappellent les champs qu'on s'attend à voir pour GitHub Actions, Compose, Kubernetes, le front matter.
• Le path explorer aplatit le YAML imbriqué en paths concrets, ce qui est tout simplement plus facile quand tu essaies de décrire un problème dans un ticket.

Workflow pratique avant de commiter du YAML

Colle-le, choisis le profil le plus proche, dégage les warnings structurels avant toute autre chose. Traite l'aperçu JSON comme une simple aide à la lecture. Ce n'est pas une promesse que ton YAML se convertit proprement, et s'il te plaît ne le déploie pas comme si ça l'était. Une fois la page bien calme, lance ce à quoi ton environnement fait réellement confiance : docker compose config, kubectl apply --dry-run, ton linter de CI, le build du site statique, selon le cas. Deux étapes. Le navigateur attrape les bêtises en amont, le parser de prod garde le dernier mot, et c'est cette part-là que je ne suis pas prêt à confier à un onglet de navigateur.

Questions fréquentes

Est-ce un parser YAML 1.2 complet ?

Non. C'est un validateur pratique côté navigateur pour le YAML de config que les gens écrivent la plupart du temps. La spec complète traîne avec elle les anchors, aliases, tags, le comportement des merge, tout un tas de cas limites, et ça appartient vraiment à un parser dédié, pas à ça.

Pourquoi la détection des duplicate keys est-elle importante ?

Voilà le côté sournois. Certains parsers gardent juste la dernière valeur et jettent la première. Du coup le fichier te paraît correct, et pendant ce temps l'appli tourne tranquillement sur un réglage que tu n'avais jamais voulu. C'est dans cet écart que vivent les sessions de debug à deux heures du matin.

Est-ce que je peux coller des secrets ici ?

Ne prends pas l'habitude de coller des secrets de prod dans un outil en ligne, celui-ci compris. Oui, le parsing se fait dans ton navigateur et rien n'est envoyé nulle part. Quand même, masque tes tokens, tes keys, tes mots de passe avant de faire une capture d'écran ou de partager une session de debug. Le toi du futur te remerciera.

Pourquoi le YAML est-il aussi sensible à l'indentation ?

Parce que les espaces sont la structure. Pas d'accolades, pas de crochets, et les tabulations sont carrément interdites. Du coup un espace mal placé soit réécrit le sens du fichier, soit refuse simplement de parser. C'est l'erreur YAML numéro un, et elle pique tout le monde au moins une fois.

Quelle est la différence entre YAML et JSON ?

Le YAML est en gros un superset de JSON pensé pour être lu par des humains : tu as les commentaires, les anchors, un rendu plus propre. Le JSON est le plus strict des deux, et il est meilleur quand ce sont des machines qui se parlent entre elles. À retenir : tout fichier JSON est déjà du YAML valide.