Convertir JSON en YAML en Ligne
Convertis du JSON en YAML lisible. Ideal pour creer des configs Docker Compose, Kubernetes ou GitHub Actions.
name: John Doe age: 30 active: true tags: - developer - javascript address: city: Madrid zip: 28001
Cas d'usage
Du JSON d'API a une configuration YAML lisible
Creer des configs DevOps
Transforme les reponses JSON des API Kubernetes, Docker ou d'outils cloud en fichiers de configuration YAML editables.
Workflow DevOps
Convertis les templates JSON CloudFormation ou Azure ARM en YAML equivalent pour une meilleure lisibilite et maintenabilite.
100 % prive
Ton JSON est traite dans ton navigateur. Jamais envoye a un serveur. Aucune inscription, aucune limite d'usage.
YAML propre
Indentation de 2 espaces, types correctement representes, pret a coller dans docker-compose.yml ou un manifeste Kubernetes.
Comment ça marche
Trois étapes, sans complications
Colle ton JSON
Colle n'importe quel JSON valide : reponse d'API, configuration, donnees structurees. Le JSON formate et minifie sont tous les deux acceptes.
Conversion en YAML propre
Le JSON est converti en YAML avec une indentation de 2 espaces, suivant les conventions des projets DevOps les plus populaires.
Copie et utilise le YAML
Copie le YAML resultant pour l'utiliser comme base de ton docker-compose.yml, d'un manifeste Kubernetes ou de n'importe quelle config YAML.
FAQ
Des questions ?
Le YAML surpasse le JSON en lisibilite pour les configurations longues et hierarchiques. Ses principaux avantages sont : le support des commentaires (indispensable dans les fichiers de config documentes), une syntaxe plus concise (sans accolades ni guillemets dans la plupart des cas), une meilleure representation des chaines multiligne (scripts, commandes, texte), et une lecture plus naturelle des listes. Le JSON est superieur quand la destination est une API ou un programme qui le traite automatiquement : l'analyse est plus rapide, la spec est plus simple et stricte, et il y a moins d'ambiguïte. La regle pratique en DevOps : YAML pour les fichiers que les humains editent directement, JSON pour les donnees echangees entre systemes.
Le convertisseur genere un YAML structurellement equivalent au JSON d'entree, sans commentaires (le JSON n'ayant pas de commentaires, il n'y a pas d'information a transferer). Cependant, le YAML genere est un excellent point de depart : ouvre-le dans n'importe quel editeur et ajoute des commentaires manuellement avec # avant ou apres n'importe quelle ligne. Dans des outils comme docker-compose.yml et les manifestes Kubernetes, les commentaires sont fondamentaux pour documenter la raison d'etre de chaque valeur de configuration.
Le JSON est considerablement plus rapide a analyser que le YAML. L'analyse JSON est en O(n) avec des constantes tres faibles : des parseurs comme simdjson (utilise dans Node.js depuis la version 17) traitent jusqu'a 3 Go/s sur du materiel moderne. Le YAML necessite un parseur plus complexe (gestion des ancres, aliases, types explicites, differents styles de chaines) et est typiquement 10 a 50 fois plus lent que le JSON pour le meme volume de donnees. Pour les petits fichiers de config (un docker-compose.yml de quelques Ko), la difference est imperceptible. Pour les API qui echangent des millions de messages par seconde, le JSON est le bon choix. L'utilisation du YAML dans les outils DevOps est une decision d'ergonomie pour les humains qui editent ces fichiers.
Le convertisseur utilise une indentation de 2 espaces, qui est la convention adoptee par pratiquement tout l'ecosysteme DevOps : Kubernetes (kubectl genere du YAML avec 2 espaces), Helm, GitHub Actions, GitLab CI, Ansible et Docker Compose. Certains projets utilisent 4 espaces (courant dans les projets Python ou la convention PEP 8 a 4 espaces influence les developpeurs), mais 2 espaces est le standard de facto dans la communaute DevOps.
La conversion de types est directe : les nombres JSON (entiers et flottants) sont representes comme des scalaires YAML sans guillemets ; les booleens JSON (true/false) deviennent true/false en YAML ; null en JSON devient null ou ~ en YAML ; les chaines sont representees sans guillemets quand c'est sans ambiguïte, ou entre guillemets simples ou doubles quand la valeur pourrait etre interpretee comme un autre type (par exemple, la chaine 42 necessite des guillemets pour ne pas devenir un nombre, et true necessite des guillemets pour ne pas devenir un booleen).
Convertir JSON en YAML : des reponses d'API aux configurations DevOps lisibles
La conversion de JSON en YAML est une operation courante dans les workflows DevOps modernes. Les API Kubernetes (l'API REST Kubernetes retourne les ressources en JSON par defaut), AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager et la plupart des outils d'infrastructure-as-code ont des interfaces JSON natives, mais leurs utilisateurs preferent travailler avec des fichiers de configuration YAML pour une meilleure lisibilite. kubectl, l'outil en ligne de commande de Kubernetes, convertit automatiquement entre YAML et JSON : quand tu executes kubectl get deployment mon-app -o yaml, Kubernetes retourne l'objet JSON de l'API et kubectl le convertit en YAML pour l'affichage. La conversion inverse (JSON vers YAML) est utile lors de la creation d'un manifeste YAML a partir d'une reponse d'API, lors de la migration de configurations entre outils, ou lors de la documentation d'une configuration existante en ajoutant des commentaires YAML.
Le YAML (specification 1.2, publiee sur yaml.org en juillet 2009) est un sur-ensemble de JSON, garantissant que la conversion JSON vers YAML est toujours possible sans perte d'information. La conversion inverse (YAML vers JSON) ne perd que les commentaires, que le JSON ne peut pas representer. Les avantages du YAML pour les configurations humaines sont bien documentes : l'absence d'accolades et de crochets reduit le bruit visuel de 30 a 40 % pour les configurations typiques ; les commentaires permettent de documenter la raison d'etre de chaque parametre directement dans le fichier ; les chaines multiligne (surtout avec le bloc litteral |) permettent d'inclure des scripts shell, des requetes SQL ou du contenu de fichiers directement dans la configuration sans echapper les caracteres speciaux.
Dans l'ecosysteme Kubernetes, le choix entre YAML et JSON est bien etabli : les fichiers que les developpeurs creent et maintiennent dans les depots git sont du YAML ; les donnees que kubectl envoie au serveur API sont du JSON (kubectl convertit le YAML en JSON en interne avant d'effectuer l'appel HTTP) ; les reponses du serveur API sont du JSON ; et les outils d'automatisation (Helm, Kustomize, Argo CD, Flux) travaillent avec le YAML comme entree et le JSON comme protocole interne. Cette separation entre le format humain (YAML) et le format protocole (JSON) est un schema aussi suivi par GitHub Actions (les workflows sont en YAML, l'API GitHub est en JSON), GitLab CI, Ansible (playbooks en YAML, donnees d'inventaire dynamique en JSON), et Terraform (HCL est l'alternative de HashiCorp, mais il accepte aussi le JSON natif dans des fichiers .tf.json).