Convertisseur JSON → YAML

Transformez vos données JSON en format YAML lisible et élégant.

JSON Entrée

YAML Sortie

Prêt -

Options YAML

Guide complet JSON vers YAML : de la lisibilité machine à la lisibilité humaine

Pourquoi je convertis mes configs JSON en YAML

YAML (Yet Another Markup Language, ou « YAML Ain't Markup Language ») est devenu le format de prédilection pour les fichiers de configuration dans l'écosystème DevOps et cloud-native. Quand je travaille avec Kubernetes, Docker Compose, GitHub Actions ou Ansible, je manipule quotidiennement du YAML. Sa force ? Une syntaxe épurée qui utilise l'indentation au lieu des accolades, élimine les guillemets superflus, et supporte les commentaires — tout ce que JSON ne fait pas. Cet outil me permet de transformer rapidement des structures JSON (souvent générées par des APIs ou des scripts) en YAML lisible et maintenable.

JSON vs YAML : comprendre les différences

📚 Lisibilité humaine

YAML utilise l'indentation significative au lieu des accolades et crochets. La structure hiérarchique est visible immédiatement, sans « bruit » syntaxique. Idéal pour les fichiers que les humains éditent fréquemment.

📝 Commentaires natifs

YAML supporte les commentaires avec #. JSON ne les supporte pas du tout. Pour documenter vos configurations, expliquer des valeurs ou désactiver temporairement des options, YAML est indispensable.

🎨 Types implicites

YAML détecte automatiquement les types : nombres, booléens (yes/no, true/false, on/off), dates, null. JSON requiert une syntaxe explicite pour chaque type.

📄 Multi-documents

Un fichier YAML peut contenir plusieurs documents séparés par ---. Très utile pour Kubernetes où un fichier peut définir plusieurs ressources. JSON : strictement un seul document par fichier.

Comment utiliser cet outil

  1. Collez votre JSON — Dans le panneau de gauche, formaté ou minifié
  2. La conversion est automatique — Le YAML apparaît en temps réel pendant la saisie
  3. Ajustez les options — Indentation (2-8 espaces), tri des clés, format des tableaux
  4. Exportez le résultat — Copiez ou téléchargez le fichier .yaml

Écosystème YAML : où ce format règne

  • Kubernetes — Deployments, Services, ConfigMaps, Secrets, Ingress... tout l'écosystème K8s est en YAML
  • Docker Compose — Définition de stacks multi-conteneurs, réseaux, volumes
  • CI/CD — GitHub Actions (.github/workflows), GitLab CI (.gitlab-ci.yml), CircleCI, Azure Pipelines
  • Infrastructure as Code — Ansible playbooks, CloudFormation templates, Terraform (HCL mais souvent converti)
  • Configuration applicative — Spring Boot (application.yml), Ruby on Rails, Hugo, Jekyll
  • OpenAPI/Swagger — Spécifications d'API souvent écrites en YAML pour la lisibilité

Options de conversion expliquées

Indentation : 2 espaces est la convention standard dans Kubernetes et la plupart des outils. 4 espaces améliore la lisibilité pour les structures très imbriquées. Trier les clés : utile pour les diffs Git et la cohérence. Tableaux compacts : affiche [a, b] sur une ligne au lieu de tirets sur plusieurs lignes. Forcer les guillemets : évite les pièges d'interprétation automatique (ex: « no » interprété comme false).

Questions fréquentes

JSON ou YAML : lequel choisir pour mon projet ?

Le choix dépend du cas d'usage :

  • JSON — Échange de données API, stockage en base, communication machine-to-machine, parsing rapide, écosystème JavaScript
  • YAML — Fichiers de configuration édités par des humains, documentation, besoin de commentaires, écosystème DevOps/Cloud

Règle simple : si des humains éditent souvent le fichier → YAML. Si c'est principalement lu/écrit par du code → JSON.

L'indentation YAML est-elle vraiment critique ? Espaces ou tabs ?

L'indentation est syntaxiquement significative en YAML — c'est ce qui définit la structure hiérarchique. Une erreur d'un seul espace peut :

  • Changer complètement la hiérarchie du document
  • Transformer un objet en élément de liste (ou l'inverse)
  • Rendre le fichier invalide

Règles absolues :

  • TOUJOURS des espaces — Les tabulations sont interdites en YAML
  • 2 espaces est la convention standard (Kubernetes, Docker, etc.)
  • Restez cohérent dans tout le fichier

Comment gérer les chaînes multilignes en YAML ?

YAML excelle pour les chaînes multilignes avec plusieurs syntaxes :

  • | (Literal Block) — Préserve tous les sauts de ligne. Idéal pour les scripts, clés SSH, certificats
  • > (Folded Block) — Joint les lignes avec des espaces, crée des paragraphes. Idéal pour les descriptions longues
  • |- ou >- — Supprime le saut de ligne final (trailing newline)
  • |+ ou >+ — Préserve tous les sauts de ligne finaux

Exemple pratique avec | pour un script shell inline dans un manifest Kubernetes.

Pourquoi « no » ou « yes » sont interprétés comme des booléens ?

C'est un piège classique de YAML 1.1 ! Les valeurs suivantes sont interprétées comme booléens :

  • True : yes, Yes, YES, true, True, TRUE, on, On, ON
  • False : no, No, NO, false, False, FALSE, off, Off, OFF

Problème classique : un code pays « NO » (Norvège) devient false ! Solutions :

  • Utilisez des guillemets : "no", 'NO'
  • Activez l'option « Forcer les guillemets » dans cet outil
  • YAML 1.2 est plus strict (seulement true/false), mais pas tous les parseurs l'implémentent

La conversion préserve-t-elle tous les types de données ?

Oui, tous les types JSON sont convertis en leurs équivalents YAML :

  • Objets → Mappings (clé: valeur sur lignes séparées)
  • Tableaux → Séquences (tirets - pour chaque élément)
  • Strings → Scalaires (guillemets uniquement si nécessaire)
  • Nombres → Nombres (sans guillemets)
  • Booléens → true/false
  • null → null ou ~ (tilde)

La conversion est bidirectionnelle sans perte de données.

Puis-je valider mon YAML généré pour Kubernetes ?

Cet outil garantit un YAML syntaxiquement valide, mais pas la conformité au schéma Kubernetes. Pour valider :

  • kubectl --dry-run — kubectl apply -f manifest.yaml --dry-run=client
  • kubeval — Outil CLI de validation contre les schémas K8s
  • IDE extensions — YAML Language Server avec schémas Kubernetes dans VS Code

Le YAML généré ici sera toujours parseable, mais vérifiez que les champs requis (apiVersion, kind, metadata) sont présents pour K8s.

Comment ajouter des commentaires après la conversion ?

Les commentaires ne peuvent pas venir du JSON (qui ne les supporte pas), mais vous pouvez les ajouter manuellement après conversion :

  • # Commentaire de ligne — Au début d'une ligne
  • clé: valeur # Commentaire inline — Après une valeur

YAML ne supporte pas les commentaires multi-lignes (/* */). Utilisez plusieurs # si nécessaire. Les commentaires sont essentiels pour documenter les configurations complexes !

Mes données sont-elles sécurisées pendant la conversion ?

Absolument — tout reste local :

  • La conversion utilise js-yaml, une bibliothèque JavaScript exécutée dans votre navigateur
  • Aucune donnée n'est transmise à un serveur
  • Vérifiable dans l'onglet Réseau des DevTools — zéro requête pendant la conversion
  • Fonctionne même hors ligne une fois la page chargée

Vous pouvez convertir en toute confiance vos configurations contenant des informations sensibles (variables d'environnement, configs internes).