Convertir YAML en JSON

Que fait le convertisseur YAML vers JSON ?

Le convertisseur lit YAML 1.2-strict et émet JSON — bidirectionnel, avec support multi-document et indications spécifiques au profil pour les domaines d’usage YAML les plus importants en 2026 : Kubernetes, Docker Compose, GitHub Actions, Helm.

Pur-client. Chaque saisie reste dans votre navigateur. Pas d’inscription, pas d’upload serveur, pas de tracking — vous pouvez le vérifier vous-même avec les outils dev navigateur dans l’onglet Réseau.

Cinq propriétés le distinguent des convertisseurs standards :

• YAML-1.2-strict avec Norway-Lint. Le parseur tourne en mode 1.2-strict — NO, yes, off restent des chaînes. Le Norway-Lint avertit quand même, car beaucoup de parseurs aval tournent encore en mode 1.1.
• Visualiseur d’anchors et d’aliases. Liste d’arêtes avec ligne de définition et toutes les utilisations (*alias et merge << distingués) — avant la résolution.
• Profils de workflow. Validateurs Kubernetes, Compose, GHA et Helm vérifient les champs obligatoires de l’outil respectif sans rendre le convertisseur un linter strict.
• Préservation des commentaires au retour. JSON → YAML peut optionnellement préserver les commentaires d’un YAML d’origine à leur position.
• Tableau de fidélité de type. Datetime, binary, tags personnalisés sont affichés sous la sortie JSON comme liste, pour que la perte de type ne se passe pas cachée.

Le convertisseur n’est pas un éditeur live, mais un pont de format ciblé entre YAML et JSON. L’écriture du fichier YAML lui-même se fait dans votre éditeur — VS Code, Vim, Cursor — avec validation de schéma et auto-complétion. Ici, le fichier arrive quand il est structurellement prêt et n’a qu’à être traduit dans une autre représentation.

Qu’est-ce que le Norway-bug et comment l’outil le traite-t-il ?

Le Norway-bug est le piège YAML le plus cité : sous YAML 1.1, NO parse comme booléen false, car le token appartient à la famille booléenne 1.1 (yes/no/on/off, chaque variante de casse). Une liste naïve de pays comme allowed: [DE, FR, NO, ES] devient ['DE', 'FR', false, 'ES'] — la Norvège disparaît, sans que le parseur ne signale d’erreur.

YAML 1.2 a supprimé ce comportement ; seuls true et false y sont encore booléens. Mais : beaucoup de parseurs dans la nature tournent encore aujourd’hui par défaut sur 1.1, car la mise à jour avait un caractère de breaking-change. PyYAML de Python est par défaut 1.1 jusqu’à la version 6, Psych de Ruby aussi. Des outils comme Norway-Land documentent l’histoire en détail.

Le lint de ce convertisseur scanne la source pour ces tokens exacts : NO, Yes, off, entiers octaux à 0 initial (0755), valeurs sexagésimales (22:22). S’il trouve un hit, il affiche la ligne, le token et une proposition concrète ("NO" cité, 0o755 comme marqueur octal explicite). L’outil ne bloque pas la conversion — il montre seulement où la fracture 1.1/1.2 passe par votre code.

À quoi servent les profils de workflow ?

Les convertisseurs YAML vers JSON génériques sont des convertisseurs de format sans connaissance du domaine. Ils ne savent pas qu’un manifeste Kubernetes sans apiVersion et kind est rejeté par l’API-server, ou que GitHub Actions ne résout pas les anchors YAML.

Les profils dans ce convertisseur comblent exactement cette lacune :

• Kubernetes — vérifie les trois champs obligatoires API-server apiVersion, kind, metadata.name et émet une indication info-level si un kind namespaced (Deployment, Service, …) arrive sans metadata.namespace. Multi-document : chaque ressource est vérifiée individuellement.
• Docker Compose — vérifie l’existence de services: (obligatoire), marque le champ version: dépassé en Compose v2 comme info, accepte les extensions préfixées x- et flagge les clés top-level inconnues.
• GitHub Actions — vérifie on: et jobs: (obligatoires), émet une note info pour name: manquant, et avertit en cas d’anchors YAML détectés, car Actions ne les honore pas.
• Helm — vérifie la convention Chart.yaml : apiVersion: v2, name, version, type.

Toutes les indications sont non bloquantes. Elles complètent la sortie JSON de contexte, mais ne la bloquent jamais. Qui a besoin de validation stricte utilise kubeval, kustomize, docker compose config, helm lint en local.

Comment fonctionne le visualiseur d’anchors et aliases ?

Les anchors YAML (&name) et aliases (*name) sont le mécanisme DRY du langage. Vous définissez un morceau de configuration une fois et y faites référence plusieurs fois. << est le merge-key : il fusionne les champs de la map référencée dans la map actuelle, avec possibilité de surcharge.

Le problème en pratique : dès qu’un fichier a deux ou trois anchors, on perd vite la vue d’ensemble de qui est défini où et quelle surcharge prend effet. Le visualiseur résout cela avec une liste d’arêtes compacte :

• Chaque anchor apparaît une fois avec &name et ligne de définition.
• En dessous se trouve la liste de toutes les utilisations avec numéro de ligne et badge de type (merge pour <<, alias pour plain *name).
• Pour une entrée comme defaults: &d et <<: *d dans deux configurations, vous voyez d’un coup d’œil que d sert deux fois comme source de merge.

Le visualiseur scanne la source textuellement — rapide, pas d’analyse parseur complète nécessaire. Limite : les anchors dans des séquences flow-style ([a: &x 1]) sur plusieurs lignes ne sont pas saisis, mais c’est extrêmement rare dans les configurations DevOps.

Comment fonctionne la préservation des commentaires ?

JSON n’a pas de commentaires selon la spec. Qui fait YAML → JSON → YAML en sens inverse perd sur le premier trajet tous les commentaires — et ils ne reviennent pas, car le JSON n’en sait rien.

Le toggle Comment-Preservation (visible uniquement au retour JSON → YAML) résout cela avec une seconde entrée : le YAML d’origine. Activement allumé :

1. Le convertisseur parse le YAML d’origine en un AST avec propriétés de commentaire sur chaque nœud.
2. À partir du JSON, un YAML frais est émis.
3. Le convertisseur parcourt les deux arbres AST en parallèle et transfère les commentaires par match de chemin sur le YAML frais.

Les commentaires d’en-tête restent en-tête, les commentaires de tête restent de tête, les commentaires de queue se rattachent après la bonne valeur. Pour les mappings, le match se fait par clé, pour les séquences par index.

Limite : si vous renommez des clés dans le JSON, déplacez des champs ou changez des structures, le commentaire tombe à cet endroit — le match de chemin ne trouve rien. Qui veut absolument préserver les commentaires modifie les données de sorte que la structure d’origine reste reconnaissable.

Qu’est-ce qui n’est volontairement pas construit ?

• Pas d’éditeur YAML live. Le convertisseur parse en tapant, mais n’offre pas de complétion de syntaxe ni d’auto-complétion consciente du schéma. Qui en a besoin utilise VS Code avec l’extension YAML.
• Pas d’extension de tags personnalisés. !Ref, !GetAtt, !Sub de CloudFormation ou tags spécifiques à Ansible sont parsés avec tolérance, mais pas évalués. Des outils comme aws cloudformation validate-template sont l’adresse correcte.
• Pas de rendu de template Helm. Les Helm-Charts avec placeholders {{ .Values.x }} exigent le binaire Helm. Nous rendons Chart.yaml directement ; values.yaml est traité comme YAML générique.
• Pas de validation de schéma K8s complète. Les indications K8s sont heuristiques. Qui a besoin de validation complète contre le schéma actuel utilise kubeval ou kustomize build | kubectl --dry-run=server apply.

Où trouver plus de détails ?

• YAML 1.2 Spec — la spécification officielle
• YAML sur Wikipedia — histoire et propriétés
• Explication du Norway-Problem — pourquoi 1.2 a supprimé les types implicites
• Convention Workflow Kubernetes — apiVersion, kind, metadata
• Docker Compose Reference — schéma Compose
• GitHub Actions Workflow Syntax — référence workflow