Convertisseur JSON ↔ YAML — Convertissez entre JSON et YAML en ligne _

Qu'est-ce que la conversion JSON ↔ YAML ?

JSON (JavaScript Object Notation, RFC 8259) est un format texte strict délimité par accolades pour les données structurées ; YAML (YAML Ain't Markup Language, version 1.2) est un surensemble de JSON qui utilise indentation, sauts de ligne et syntaxe lisible pour le même modèle de valeur. Convertir entre les deux permet de pivoter la même configuration entre une forme adaptée aux machines (JSON pour les API, la validation de schéma, les transformations programmatiques) et une forme adaptée aux humains (YAML pour la revue de code, les manifestes Kubernetes, les workflows GitHub Actions) sans retaper la moindre clé.

Comment fonctionne la conversion JSON ↔ YAML ?

Chaque conversion s'exécute localement dans votre navigateur grâce à la bibliothèque js-yaml embarquée (MIT, version 4.1.0). Les étapes principales sont :

1. Le sélecteur de mode (Détection automatique / JSON → YAML / YAML → JSON) décide quel pipeline tourne. En mode Détection automatique, le premier caractère non blanc de l'entrée choisit la direction — { ou [ signifie JSON ; toute autre chose signifie YAML.
2. JSON → YAML : JSON.parse valide l'entrée et produit une valeur JavaScript ; jsyaml.dump(value, { indent, lineWidth: -1, sortKeys: false }) écrit la forme YAML 1.2. Avec Multi-document activé, un tableau d'entrée est dumpé un élément par document et joint avec des séparateurs ---.
3. YAML → JSON : jsyaml.loadAll analyse chaque document de l'entrée (gérant les séparateurs --- automatiquement) dans un tableau ; les entrées à un seul document sont déballées de sorte que la sortie JSON soit le document lui-même, pas un tableau d'un élément.
4. L'indentation (2 ou 4 espaces) et l'impression joliment sont configurables. Impression joliment désactivée émet du JSON minifié via JSON.stringify(value) sans espaces blancs.
5. La sortie est écrite dans la zone de texte en lecture seule. En cas d'échec d'analyse YAML, le message d'erreur inclut la ligne et la colonne (indexées à 1) rapportées par le e.mark de js-yaml afin que vous sautiez droit au bug.

Pourquoi convertir JSON et YAML avec cet outil ?

• Confidentialité : chaque passe d'analyse, de transformation et d'émission se produit dans votre navigateur. Les données — y compris les secrets Kubernetes, les JWT signés et les configurations propriétaires — n'atteignent jamais nos serveurs.
• YAML multi-document : jsyaml.loadAll reconnaît les séparateurs --- et renvoie un tableau de documents, que le convertisseur déballe pour les cas mono-document ou conserve comme tableau JSON pour les cas multi-document.
• Ancres et alias résolus : le mécanisme &anchor / *alias de YAML est géré par le schéma par défaut de js-yaml. Une valeur définie une fois et référencée deux fois fait l'aller-retour vers un objet JSON où toutes les références portent des valeurs égales.
• Pas de CDN, pas de télémétrie : la bibliothèque js-yaml.min.js est servie depuis la même origine que la page, donc l'outil fonctionne hors ligne, derrière des proxys d'entreprise et dans des environnements air-gappés.

Quelles sont les applications courantes de la conversion JSON ↔ YAML ?

Pivoter entre JSON et YAML revient dans le DevOps, l'ingénierie plateforme et l'outillage d'API :

• Manifestes Kubernetes : convertir un YAML Deployment, ConfigMap ou HelmRelease en JSON afin qu'un validateur interne de politique (Joi, Ajv, OPA Rego) puisse le linter programmatiquement, puis revenir au YAML pour l'apply sur le cluster.
• Workflows CI/CD : faire passer un workflow.yml GitHub Actions par du JSON afin qu'un générateur de code réécrive la matrice ou les dépendances entre jobs, puis émettre le YAML nettoyé pour la PR.
• Spécifications OpenAPI : coller un openapi.json issu de la documentation auto-générée d'un backend et le convertir en openapi.yaml pour la référence éditée par humains versionnée dans le dépôt.

À quoi ressemble un exemple d'aller-retour JSON ↔ YAML ?

Coller {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"web"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"web"}}}} et appuyer sur CONVERTIR en mode JSON → YAML produit huit lignes de YAML indenté avec apiVersion: apps/v1 sur la première ligne. Réinjecter ce YAML en mode YAML → JSON avec Impression joliment activée renvoie l'objet d'origine octet pour octet après un JSON.stringify(value, null, 2) stable, l'ordre des clés étant préservé car le schéma par défaut de js-yaml honore l'ordre d'insertion dans les deux directions.

Ce convertisseur JSON ↔ YAML s'exécute-t-il entièrement dans mon navigateur ?

Oui. Chaque passe d'analyse, de transformation et d'émission s'exécute localement en JavaScript dans votre onglet. La bibliothèque js-yaml embarquée est servie depuis la même origine que la page — pas de CDN, pas de fetch, pas de XMLHttpRequest, pas de navigator.sendBeacon sur l'entrée. L'outil fonctionne aussi hors ligne une fois la page chargée, car c'est un bundle statique HTML/CSS/JS avec la bibliothèque vendor copiée à côté. Les secrets Kubernetes, les charges utiles JWT, les YAML CloudFormation signés et les configurations propriétaires restent sur votre appareil.

Comment le convertisseur gère-t-il le YAML multi-document ?

YAML prend en charge plusieurs documents dans un même flux, séparés par des lignes ne contenant que ---. En YAML → JSON le convertisseur appelle jsyaml.loadAll, qui renvoie chaque document comme une valeur JavaScript. Si exactement un document est trouvé, la sortie JSON est ce document directement ; si deux ou plus sont trouvés, la sortie JSON est un tableau. En JSON → YAML, lorsque l'entrée est un tableau JSON ET que le commutateur Multi-document est activé, chaque élément du tableau est émis comme son propre document avec des séparateurs --- entre eux — utile pour générer un bundle compatible kubectl apply à partir d'un tableau JSON de ressources.

Les ancres et alias YAML sont-ils pris en charge ?

Oui — les définitions &anchor et les références *alias sont résolues par le schéma par défaut de js-yaml lors du chargement. Une entrée YAML telle que defaults: &d\n retries: 3\n timeout: 30\njob_a:\n <<: *d\njob_b:\n <<: *d est analysée en un objet JSON où job_a et job_b contiennent tous deux retries: 3, timeout: 30. La clé de fusion << (une extension YAML 1.1 que js-yaml honore encore) est également prise en charge sur le schéma par défaut.

Les commentaires YAML sont-ils préservés lors de la conversion vers JSON puis retour ?

Non — js-yaml supprime les commentaires lors de l'analyse, donc un aller-retour YAML → JSON → YAML perd toute ligne préfixée par #. C'est une limitation connue du modèle load/dump ; si la préservation des commentaires est critique, utilisez une bibliothèque qui en tient compte, comme le paquet npm yaml (qui fournit une API CST + AST conçue pour préserver les trivia), plutôt que js-yaml. Pour la plupart des flux de conversion de configuration, le compromis est acceptable : le YAML après aller-retour conserve toutes les clés, valeurs, ancres et alias, simplement sans les commentaires écrits par humains.

Que deviennent les tags YAML personnalisés ?

Le convertisseur utilise le DEFAULT_SCHEMA de js-yaml, qui comprend !!str, !!int, !!float, !!bool, !!null, !!seq, !!map, !!binary et !!timestamp — chaque tag des schémas core et JSON de YAML 1.2. Les tags personnalisés ou spécifiques à une application (p. ex. !Ref dans CloudFormation, !vault dans Ansible) ne sont pas reconnus et apparaissent sous forme d'erreur claire citant le tag non pris en charge. Pour CloudFormation en particulier, utilisez le flux aws cloudformation package + --output-template-file pour étendre les tags personnalisés avant de coller dans ce convertisseur.

Ce convertisseur JSON ↔ YAML embarque js-yaml@4.1.0 servi depuis la même origine, prend en charge les flux multi-document et les ancres/alias d'origine, et signale les erreurs d'analyse YAML avec ligne et colonne pour que vous corrigiez la source. Pas d'envoi, pas de CDN, pas de télémétrie — chaque octet reste dans votre navigateur.