Skip to content

Convertisseur JSON vers YAML

Collez du JSON, obtenez du YAML instantanément. En direct dans le navigateur. K8s/Compose, 2/4 espaces, guillemets sécurisés Norway. 100 % privé, sans envoi.

Sans pistage Fonctionne dans le navigateur Gratuit
Options · 2 espaces · auto · bloc
Indentation
Style
0 car.
YAML Sortie
0 lignes
Vérifié pour la conformité RFC 8259, la sortie conforme à la spécification YAML 1.2 et la correction de la gestion du problème Norway — Go Tools Engineering Team · 4 mai 2026

Qu'est-ce que YAML et pourquoi convertir depuis JSON ?

YAML (YAML Ain't Markup Language) est un format de sérialisation de données lisible par un humain, conçu pour les fichiers de configuration, l'infrastructure-as-code et partout où un humain écrit des données qu'une machine lira. Sa syntaxe basée sur l'indentation ne nécessite ni accolades ni crochets, ce qui le rend bien plus lisible que JSON pour les structures imbriquées complexes. Kubernetes, Helm, Ansible, Docker Compose, GitHub Actions, CircleCI et pratiquement tous les outils cloud-natifs utilisent YAML comme format de configuration principal. Convertir du JSON en YAML est donc l'une des tâches les plus courantes en DevOps et développement backend — vous recevez une définition de ressource depuis une API en JSON, et vous avez besoin d'un manifeste YAML pour le valider dans le contrôle de version.

Cet outil présente quatre différenciateurs importants par rapport aux convertisseurs en ligne typiques :

**1. Problème Norway — Guillemets automatiques sécurisés.** Le piège le plus fréquent dans la conversion JSON vers YAML est le problème Norway de YAML. Dans YAML 1.1 (utilisé par des millions d'analyseurs en production, notamment les anciennes versions de Kubernetes, PyYAML, Ansible et Psych de Ruby), les chaînes brutes yes, no, on, off, y et n sont interprétées comme des valeurs booléennes true/false. Cela a notablement touché le code ISO du pays Norvège (« NO » → false) et a causé de véritables pannes en production dans des configurations Kubernetes. YAML 1.2 a corrigé ce problème, mais vos analyseurs ne sont peut-être pas encore sur la version 1.2. Le mode Auto par défaut de cet outil utilise la bibliothèque eemeli/yaml avec le schéma YAML 1.1, encadrant automatiquement de guillemets toute chaîne problématique Norway pour garantir des conversions aller-retour sûres dans les analyseurs YAML 1.1 et 1.2. En savoir plus dans notre article compagnon sur le problème Norway de YAML et les différences JSON-YAML.

**2. Préservation de l'ordre des clés.** Contrairement à certains convertisseurs qui trient les clés alphabétiquement, cet outil préserve l'ordre d'insertion des clés d'origine de votre JSON — correspondant au comportement de JSON.parse() dans tous les moteurs JavaScript modernes. Cela est important pour les manifestes Kubernetes (où apiVersion et kind sont attendus en premier par convention), les spécifications OpenAPI (où info apparaît avant paths) et toute configuration où l'ordre des champs est significatif pour la lisibilité ou les diffs.

**3. Mise en garde sur la précision des grands nombres.** Les nombres JSON supérieurs à 2^53 - 1 (9007199254740991) ne peuvent pas être représentés exactement dans le type float double précision IEEE 754 de JavaScript. Lorsque JSON.parse() lit un grand entier comme un champ resourceVersion de Kubernetes (qui est un entier 64 bits côté serveur), il le tronque silencieusement. Il s'agit d'une limitation fondamentale de JavaScript dans le navigateur qui affecte tous les outils JSON en navigateur, y compris celui-ci. La solution sûre est de s'assurer que les grands entiers sont stockés sous forme de chaînes dans votre JSON avant de convertir. Cet outil documente honnêtement ce comportement dans l'erreur courante Perte de précision des nombres ci-dessous.

**4. Confidentialité 100 % basée sur le navigateur.** Vos données JSON — qui contiennent souvent des clés API, des identifiants de base de données, des configurations de services internes et des secrets de production — ne quittent jamais votre navigateur. Aucune donnée n'est envoyée à un serveur. Vous pouvez le vérifier dans l'onglet Réseau de votre navigateur. C'est la seule façon sûre de traiter des données de configuration sensibles dans un outil en ligne. Consultez notre outil compagnon pour la direction inverse sur Convertisseur YAML vers JSON, et notre Formateur JSON si vous devez valider et formater le JSON avant de convertir.

La nature lisible de YAML s'accompagne d'un compromis : il présente plus de cas limites d'analyse que JSON. Au-delà du problème Norway, YAML a des particularités sur les nombres octaux (0777 est interprété comme 511 en YAML 1.1), la syntaxe des chaînes multilignes (| pour littéral, > pour replié), les références d'ancre et d'alias (&anchor et *alias) et la prise en charge de plusieurs documents (séparateur ---). JSON n'a aucune de ces complexités — c'est un format strict et minimal avec seulement six types de données. Pour les échanges de données entre machines, JSON est presque toujours le meilleur choix. Pour les fichiers de configuration édités par des humains où la lisibilité et les commentaires importent, YAML l'emporte. Ce convertisseur vous offre le meilleur des deux mondes : utilisez JSON de manière programmatique, convertissez en YAML pour votre infrastructure.

// Convert JSON to YAML in Node.js using the eemeli/yaml library
import { Document } from 'yaml';

const data = JSON.parse('{"apiVersion":"apps/v1","kind":"Deployment"}');

// version: '1.1' ensures Norway-problem strings (yes/no/on/off/y/n)
// are automatically quoted in the output for YAML 1.1 parser safety
const doc = new Document(data, { version: '1.1' });

const yamlString = doc.toString({
  indent: 2,
  lineWidth: 0,         // disable line wrapping
  defaultStringType: 'PLAIN',   // Auto mode: only quote when needed
});

console.log(yamlString);
// apiVersion: apps/v1
// kind: Deployment

Fonctionnalités clés

Conversion en direct

La sortie YAML se met à jour instantanément au fil de la saisie ou du collage de JSON — sans bouton Convertir. Les grandes entrées (>200 Ko) passent automatiquement en mode manuel pour maintenir la réactivité du navigateur.

Indentation 2 ou 4 espaces

Basculez entre 2 espaces (standard pour Kubernetes, Docker Compose et GitHub Actions) et 4 espaces (convention Ansible). Les tabulations YAML sont interdites — cet outil utilise toujours des espaces.

Guillemets automatiques sécurisés (sécurisé Norway)

Le mode Auto par défaut utilise le schéma YAML 1.1 pour mettre automatiquement entre guillemets les chaînes comme « no », « yes », « on », « off », « y » et « n » qui seraient mal interprétées comme des booléens par les analyseurs YAML 1.1, prévenant ainsi les erreurs de configuration en production.

Styles Bloc et Flux

Le style Bloc produit un YAML indenté et lisible par un humain, idéal pour les manifestes et fichiers de config. Le style Flux produit un YAML compact en ligne, similaire à JSON — utile pour les extraits de documentation ou les outils préférant une sortie minimale.

Confidentialité 100 % basée sur le navigateur

Toute la conversion s'exécute localement dans votre navigateur en JavaScript. Vos données JSON — y compris les clés API, les identifiants et les configs de production — ne sont jamais envoyées à un serveur, jamais journalisées et jamais stockées.

Gère K8s, Compose et Terraform

Optimisé pour les cas d'usage DevOps réels : manifestes Kubernetes, piles Docker Compose, valeurs de charts Helm, workflows GitHub Actions, spécifications OpenAPI et sorties de plans Terraform JSON — avec des exemples pour chacun.

Exemples

Déploiement Kubernetes

{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"my-app","namespace":"production","labels":{"app":"my-app","version":"1.0.0"}},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"my-app"}},"template":{"metadata":{"labels":{"app":"my-app"}},"spec":{"containers":[{"name":"my-app","image":"my-app:1.0.0","ports":[{"containerPort":8080}],"resources":{"requests":{"memory":"64Mi","cpu":"250m"},"limits":{"memory":"128Mi","cpu":"500m"}}}]}}}}

Convertir un manifeste de déploiement Kubernetes depuis le format JSON de réponse API vers YAML pour l'appliquer avec kubectl apply -f

Docker Compose

{"version":"3.9","services":{"web":{"image":"nginx:1.25-alpine","ports":["80:80","443:443"],"environment":{"NGINX_HOST":"example.com","NGINX_PORT":"80"},"depends_on":["db"],"restart":"unless-stopped"},"db":{"image":"postgres:16-alpine","environment":{"POSTGRES_DB":"mydb","POSTGRES_USER":"admin","POSTGRES_PASSWORD":"secret"},"volumes":["pgdata:/var/lib/postgresql/data"]}},"volumes":{"pgdata":{}}}

Convertir une définition de services Docker Compose du format JSON vers le format YAML requis par docker compose up

Workflow GitHub Actions

{"name":"CI","on":{"push":{"branches":["main"]},"pull_request":{"branches":["main"]}},"jobs":{"build":{"runs-on":"ubuntu-latest","steps":[{"uses":"actions/checkout@v4"},{"name":"Set up Node.js","uses":"actions/setup-node@v4","with":{"node-version":"20","cache":"pnpm"}},{"name":"Install dependencies","run":"pnpm install --frozen-lockfile"},{"name":"Run tests","run":"pnpm test"}]}}}

Convertir une définition de workflow CI GitHub Actions depuis JSON vers YAML pour la valider dans .github/workflows/

Spécification OpenAPI

{"openapi":"3.0.3","info":{"title":"User API","version":"1.0.0","description":"Manage application users"},"paths":{"/users":{"get":{"summary":"List users","operationId":"listUsers","parameters":[{"name":"limit","in":"query","schema":{"type":"integer","default":20}}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/User"}}}}}}}},"/users/{id}":{"get":{"summary":"Get user","operationId":"getUser","parameters":[{"name":"id","in":"path","required":true,"schema":{"type":"string"}}],"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"User":{"type":"object","properties":{"id":{"type":"string"},"name":{"type":"string"},"email":{"type":"string","format":"email"}}}}}}

Convertir une spécification OpenAPI 3.0 de JSON vers YAML — le format privilégié par Swagger UI, Redoc et la plupart des outils API

package.json

{"name":"my-app","version":"1.0.0","description":"A sample Node.js application","private":true,"scripts":{"dev":"vite","build":"tsc && vite build","preview":"vite preview","test":"vitest","lint":"eslint . --ext .ts,.tsx"},"dependencies":{"react":"^18.3.0","react-dom":"^18.3.0"},"devDependencies":{"typescript":"^5.4.0","vite":"^5.2.0","vitest":"^1.5.0","eslint":"^8.57.0","@types/react":"^18.3.0"},"engines":{"node":">=20.0.0","pnpm":">=9.0.0"}}

Convertir un package.json Node.js typique vers YAML — utile pour migrer la configuration vers des outils préférant YAML

Plan Terraform JSON

{"format_version":"1.0","terraform_version":"1.7.4","variables":{"region":{"value":"us-east-1"}},"planned_values":{"root_module":{"resources":[{"address":"aws_s3_bucket.main","mode":"managed","type":"aws_s3_bucket","name":"main","values":{"bucket":"my-app-assets","force_destroy":false,"tags":{"Environment":"production","ManagedBy":"terraform"}}}]}},"resource_changes":[{"address":"aws_s3_bucket.main","mode":"managed","type":"aws_s3_bucket","name":"main","change":{"actions":["create"],"before":null,"after":{"bucket":"my-app-assets","force_destroy":false}}}]}

Convertir une sortie de plan Terraform JSON vers YAML pour une revue humaine, des pistes d'audit GitOps et des pipelines CI/CD — une fonctionnalité différenciatrice absente de la plupart des convertisseurs

Comment utiliser

  1. 1

    Collez votre JSON

    Entrez ou collez vos données JSON dans le champ de saisie ci-dessus. Vous pouvez aussi cliquer sur « Charger un exemple » pour essayer un exemple comme un déploiement Kubernetes, un fichier Docker Compose ou un plan Terraform.

  2. 2

    Consultez la sortie YAML en direct

    Le YAML apparaît instantanément dans le panneau de sortie. Ajustez les Options (indentation 2/4, guillemets Auto/Double/Simple, style Bloc/Flux) pour correspondre aux exigences de votre outil cible.

  3. 3

    Copiez ou téléchargez

    Cliquez sur Copier pour récupérer le YAML dans votre presse-papiers, ou sur Télécharger pour le sauvegarder en fichier .yaml prêt pour kubectl apply, docker compose up ou tout autre outil.

Pièges courants de conversion

Virgules de fin

JSON n'autorise pas de virgule après le dernier élément d'un objet ou d'un tableau. C'est extrêmement courant lors d'une copie depuis du code JavaScript, qui autorise les virgules de fin. Supprimez la virgule finale avant de convertir.

✗ Incorrect
{"name": "Alice", "role": "admin",}
✓ Correct
{"name": "Alice", "role": "admin"}

Guillemets simples

JSON exige des guillemets doubles pour toutes les valeurs de chaîne et les clés d'objet. Les guillemets simples sont valides en JavaScript et Python, mais constituent une erreur de syntaxe en JSON.

✗ Incorrect
{'name': 'Alice', 'active': true}
✓ Correct
{"name": "Alice", "active": true}

Clés sans guillemets

Toutes les clés d'objet JSON doivent être encadrées de guillemets doubles. Les clés sans guillemets sont valides dans les littéraux d'objets JavaScript mais causeront une erreur d'analyse en JSON strict.

✗ Incorrect
{name: "Alice", role: "admin"}
✓ Correct
{"name": "Alice", "role": "admin"}

Commentaires non autorisés

Le JSON standard ne supporte aucun type de commentaire — ni //, ni /* */, ni #. Si vous avez besoin de commentaires dans une configuration, utilisez YAML (qui supporte les commentaires #) ou JSONC (JSON avec commentaires, utilisé par VS Code). Supprimez tous les commentaires avant d'utiliser des données comme JSON.

✗ Incorrect
{"port": 8080 // HTTP port}
✓ Correct
{"port": 8080}

Problème Norway de YAML (géré automatiquement en mode Auto)

Dans les analyseurs YAML 1.1 (utilisés par Kubernetes, Ansible, PyYAML, Ruby Psych), les chaînes brutes yes, no, on, off, y et n sont interprétées comme des booléens true/false plutôt que comme des chaînes. Le mode Auto de cet outil met automatiquement ces valeurs entre guillemets dans la sortie YAML pour garantir des conversions aller-retour sûres dans tout analyseur YAML 1.1 ou 1.2. Si vous sélectionnez le mode Double ou Simple, toutes les chaînes sont explicitement entre guillemets, ce qui évite également le problème — mais le mode Auto produit la sortie la plus naturelle.

✗ Incorrect
# JSON input: {"country": "no", "enabled": "yes"}
# YAML without quoting (dangerous):
country: no
enabled: yes
# YAML 1.1 parser reads: country=false, enabled=true
✓ Correct
# YAML with Auto quoting (safe):
country: 'no'
enabled: 'yes'
# YAML 1.1 parser reads: country="no", enabled="yes"

Perte de précision pour les grands entiers

JavaScript ne peut représenter exactement les entiers que jusqu'à 2^53 - 1 (9007199254740991). Les entiers JSON supérieurs à cette valeur — comme les champs resourceVersion de Kubernetes (qui sont des int64 côté serveur) — sont silencieusement arrondis lors de l'analyse par JSON.parse(). Ce nombre tronqué apparaît ensuite dans la sortie YAML. Il s'agit d'une limitation fondamentale de JavaScript dans le navigateur affectant tous les outils JSON basés sur navigateur. La solution sûre est de stocker les grands entiers sous forme de chaînes dans votre JSON avant de convertir.

✗ Incorrect
// JSON input (resourceVersion is int64 on K8s server)
{"resourceVersion": 9007199254740993}
// JavaScript reads it as: 9007199254740992 (precision lost)
// YAML output will contain the wrong number
✓ Correct
// Store large integers as strings to preserve precision
{"resourceVersion": "9007199254740993"}
// YAML output: resourceVersion: '9007199254740993' (exact)

Cas d'utilisation courants

Manifestes Kubernetes
Convertissez les réponses JSON de l'API kubectl get -o json ou de l'API Kubernetes en manifestes YAML pour les workflows GitOps, les overlays Kustomize et les déploiements kubectl apply -f.
Fichiers Docker Compose
Transformez la sortie JSON de docker inspect ou les configurations de services générées programmatiquement en fichiers docker-compose.yaml compatibles avec docker compose up et les déploiements Docker Stack.
Valeurs de Charts Helm
Convertissez des exports de configuration JSON en fichiers YAML de valeurs pour les déploiements de charts Helm, permettant une configuration d'infrastructure versionnée avec une syntaxe YAML épurée.
Workflows GitHub Actions
Construisez programmatiquement des définitions de workflows GitHub Actions en JSON et convertissez-les au format .github/workflows/*.yaml requis par le runner GitHub Actions.
Spécifications OpenAPI
Convertissez les spécifications OpenAPI/Swagger du format JSON retourné par de nombreux frameworks (FastAPI, SpringDoc) au format YAML préféré par Swagger UI, Redoc et les outils de passerelle API.
Migration de configuration
Migrez la configuration d'application stockée en JSON (appsettings.json, config.json) vers le format YAML pour les outils qui nécessitent ou préfèrent YAML, en ajoutant la possibilité d'utiliser des commentaires pour la documentation.

Détails techniques

Analyse JSON conforme à RFC 8259
L'entrée JSON est analysée avec le JSON.parse() natif du navigateur, entièrement conforme à RFC 8259. Cela fournit des messages d'erreur de syntaxe précis incluant des informations de position (numéros de ligne et de colonne au mieux) et gère tous les types de données JSON : chaînes, nombres, booléens, null, tableaux et objets.
Sortie YAML 1.2 via l'API Document eemeli/yaml avec schéma YAML 1.1
Le YAML est généré avec la bibliothèque eemeli/yaml (v2.8+, sécurisée CVE) via son API Document avec version: '1.1'. Cette combinaison produit une sortie conforme à YAML 1.2 tout en appliquant les règles de guillemets YAML 1.1 — ce qui signifie que les chaînes problématiques Norway (yes/no/on/off/y/n) sont automatiquement mises entre guillemets dans la sortie, la rendant sûre pour les analyseurs YAML 1.1 et 1.2. Le retour à la ligne est désactivé (lineWidth: 0) pour préserver les longues chaînes intactes.
100 % basé sur le navigateur — Pas de téléchargement, pas de serveur
Tout le traitement se passe entièrement dans le moteur JavaScript de votre navigateur. Aucune donnée n'est transmise sur le réseau à aucun moment. Les entrées supérieures à 200 Ko passent automatiquement du mode en direct au mode manuel (nécessitant un clic explicite sur Convertir) pour maintenir la réactivité du navigateur et éviter le blocage du thread principal lors d'une sérialisation intensive.

Bonnes pratiques

Utilisez toujours le mode Auto pour les configurations DevOps
Lors de la conversion de JSON pour Kubernetes, Helm, Ansible, Docker Compose ou GitHub Actions, utilisez toujours le mode Auto (sécurisé Norway) par défaut. Les analyseurs YAML 1.1 de ces outils interpréteront silencieusement les chaînes brutes yes, no, on, off, y et n comme des booléens — le mode Auto évite cela de manière transparente.
Utilisez 2 espaces pour les outils cloud-natifs
Kubernetes, Docker Compose, GitHub Actions et Helm utilisent tous 2 espaces d'indentation par convention. Utiliser 4 espaces dans ces fichiers est du YAML valide, mais créera des incohérences avec les exemples de la communauté, les configs générées automatiquement et les manifestes existants de votre équipe.
Stockez les grands entiers sous forme de chaînes avant de convertir
Les champs resourceVersion, uid et autres champs int64 de Kubernetes provenant du serveur API peuvent dépasser la plage des entiers sûrs de JavaScript (2^53 - 1). Si vous avez besoin d'une précision numérique exacte, stockez ces valeurs sous forme de chaînes JSON avant de convertir. C'est particulièrement important pour les sorties kubectl get -o json incluant des champs générés côté serveur.
Validez le JSON d'abord
Si votre source JSON est écrite à la main ou provient d'un système qui produit parfois des sorties invalides (virgules de fin, clés sans guillemets, commentaires), validez-la avec un formateur JSON avant de convertir. Utilisez notre Formateur JSON pour détecter et corriger les erreurs de syntaxe d'abord, puis convertissez le JSON propre en YAML.
Préférez le style Bloc pour les fichiers versionnés
Le YAML en style Bloc produit des diffs propres et lisibles dans Git car chaque champ apparaît sur sa propre ligne. Le style Flux (compact, en ligne) rend les diffs plus difficiles à lire et à réviser. Réservez le style Flux pour intégrer de courts extraits YAML dans de la documentation ou pour les outils nécessitant une sortie compacte.

Questions fréquentes

Comment convertir du JSON en YAML en ligne ?
Collez votre JSON dans le champ de saisie ci-dessus. L'outil le convertit instantanément en YAML dans votre navigateur — sans clic nécessaire. Vous pouvez ajuster l'indentation (2 ou 4 espaces), le style de guillemets (Auto, Double ou Simple) et le style de sortie (Bloc ou Flux) depuis le panneau Options. Une fois le YAML affiché dans la zone de sortie, cliquez sur Copier pour le récupérer dans votre presse-papiers ou sur Télécharger pour le sauvegarder en fichier .yaml. Tout s'exécute localement — vos données ne quittent jamais votre appareil.
Qu'est-ce que le problème Norway de YAML et comment cet outil le gère-t-il ?
Le problème Norway de YAML désigne une particularité de la spécification YAML 1.1 dans laquelle des chaînes brutes comme « no », « yes », « on », « off », « y » et « n » sont interprétées comme des booléens (false/true) plutôt que comme des chaînes de caractères. Cela a causé un incident réel célèbre où le code ISO du pays Norvège (« NO ») était lu comme le booléen false dans les playbooks Ansible et les configurations Kubernetes. YAML 1.2 a corrigé ce problème, mais des millions d'analyseurs en production (anciennes versions de Kubernetes, PyYAML, Ansible, Psych de Ruby) utilisent encore YAML 1.1. Le mode Auto (par défaut) de cet outil encadre automatiquement les chaînes problématiques entre guillemets pour qu'elles circulent en toute sécurité dans les analyseurs YAML 1.1 et 1.2. Lorsque des chaînes problématiques sont détectées dans votre entrée, une bannière d'avertissement liste exactement les valeurs qui ont été automatiquement mises entre guillemets.
Pourquoi le problème Norway est-il important pour Kubernetes et le DevOps ?
Les manifestes YAML Kubernetes, les valeurs Helm, les playbooks Ansible et les workflows GitHub Actions sont tous analysés par des outils qui utilisaient historiquement YAML 1.1. Si vous avez une clé de configuration dont la valeur est « no » (par exemple un code de pays, un indicateur activé sous forme de chaîne ou un champ booléen personnalisé), un analyseur YAML 1.1 le convertira silencieusement en booléen false. Cela peut provoquer des erreurs de configuration de service extrêmement difficiles à déboguer car le YAML semble correct en texte mais se comporte différemment une fois analysé. Utilisez toujours le mode Auto lors de la conversion de JSON pour Kubernetes ou toute chaîne d'outils DevOps.
Dois-je utiliser une indentation de 2 ou 4 espaces pour YAML ?
Utilisez 2 espaces pour les manifestes Kubernetes, les valeurs Helm, les fichiers Docker Compose et les workflows GitHub Actions — ces outils sont conçus autour du YAML à 2 espaces, la convention de la communauté. Utilisez 4 espaces pour les playbooks Ansible (qui suivent une convention à 4 espaces) et lorsque votre équipe ou organisation impose un guide de style spécifique. YAML interdit entièrement les tabulations — toute l'indentation doit être des espaces. Cet outil est réglé par défaut sur 2 espaces, ce qui est le bon choix pour la grande majorité des cas d'usage cloud-natif.
Comment utiliser cet outil pour créer un manifeste Kubernetes ?
Si vous avez une définition de ressource Kubernetes en JSON (depuis kubectl get deployment my-app -o json, une réponse API ou un bloc de ressource Terraform), collez-la dans le champ de saisie. Sélectionnez 2 espaces d'indentation (valeur par défaut) et Auto pour les guillemets (valeur par défaut, qui gère le problème Norway). La sortie YAML est immédiatement prête pour kubectl apply -f. Vous pouvez aussi cliquer sur Télécharger pour sauvegarder le fichier avec l'extension .yaml et le transmettre directement à kubectl apply -f -. L'exemple Déploiement K8s ci-dessus présente un manifeste de déploiement complet que vous pouvez charger et modifier.
Comment convertir un JSON Docker Compose en YAML ?
Collez votre JSON Docker Compose dans le champ de saisie. Utilisez 2 espaces d'indentation (convention Docker Compose) et le style Bloc. Le YAML de sortie est compatible avec docker compose up, docker compose config et Docker Stack. Un scénario courant est d'exporter la configuration d'une pile en cours d'exécution avec docker inspect puis de la reconvertir en fichier compose.yaml. L'exemple Docker Compose ci-dessus inclut des définitions de services avec ports, variables d'environnement, volumes et depends_on.
Les nombres JSON supérieurs à 2^53 perdent-ils en précision lors de la conversion en YAML ?
Oui. Il s'agit d'une limitation fondamentale de JavaScript : le type IEEE 754 double précision utilisé par le type Number de JavaScript ne peut représenter exactement les entiers que jusqu'à 2^53 - 1 (9007199254740991). Tout entier au-delà — comme les champs resourceVersion de Kubernetes (qui sont des int64 côté serveur) — sera silencieusement arrondi lors du passage par JSON.parse(). Par exemple, la valeur 9007199254740993 devient 9007199254740992 en JavaScript, et ce nombre tronqué apparaîtra dans votre sortie YAML. Ce problème affecte tous les outils JSON basés sur navigateur, pas seulement celui-ci. La solution sûre est de stocker les grands entiers sous forme de chaînes dans votre JSON ("resourceVersion": "9007199254740993") — ils apparaîtront comme des chaînes YAML sans perte de précision.
Le convertisseur préserve-t-il l'ordre d'origine des clés de mon JSON ?
Oui. La bibliothèque eemeli/yaml utilisée par cet outil préserve l'ordre d'insertion, ce qui correspond au comportement de JSON.parse() dans tous les moteurs JavaScript modernes (V8, SpiderMonkey, JavaScriptCore). Les clés apparaissent dans la sortie YAML dans le même ordre qu'elles apparaissaient dans l'entrée JSON. Ceci est important pour les manifestes Kubernetes et les spécifications OpenAPI où l'ordre des champs est souvent significatif pour la lisibilité et les diffs.
Quand utiliser JSON plutôt que YAML ?
Utilisez JSON quand : vous construisez des API et des services web (JSON est le format d'échange universel), quand la vitesse d'analyse machine est importante, quand vous avez besoin d'une sécurité de type stricte, ou quand le consommateur est une application JavaScript/TypeScript. Utilisez YAML quand : vous écrivez des fichiers de configuration destinés à l'édition humaine (manifestes Kubernetes, pipelines CI/CD, playbooks Ansible, valeurs Helm), quand vous souhaitez des commentaires dans votre config, ou quand la lisibilité est plus importante que la rigueur. Règle pratique : si une machine écrit ou lit en premier, utilisez JSON ; si un humain écrit et qu'une machine lit, utilisez YAML.
Comment convertir du JSON en YAML en ligne de commande ?
L'approche la plus populaire est de combiner yq et jq. Installez yq (version Mike Farah, pas la version Python) : brew install yq sur macOS ou wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/local/bin/yq pour Linux. Puis exécutez : cat input.json | yq -P pour afficher au format YAML. Alternativement : yq -o yaml input.json ou cat input.json | python3 -c "import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False)". Pour Kubernetes spécifiquement : kubectl get deployment my-app -o yaml convertit directement depuis l'API du cluster.
Comment convertir du JSON en YAML en Python, Node.js ou Go ?
En Python : import json, yaml; yaml.dump(json.load(open('input.json')), open('output.yaml', 'w'), default_flow_style=False) en utilisant PyYAML, ou ruamel.yaml pour une fidélité de conversion aller-retour. En Node.js : import { Document } from 'yaml'; const doc = new Document(JSON.parse(input), { version: '1.1' }); const result = doc.toString({ indent: 2, lineWidth: 0 }) — c'est la même bibliothèque et approche utilisée par cet outil. En Go : import gopkg.in/yaml.v3; json.Unmarshal(jsonBytes, &data); yaml.Marshal(data) — notez que Go YAML v3 utilise YAML 1.1 par défaut, donc les chaînes problématiques Norway seront automatiquement mises entre guillemets.
Mes données JSON sont-elles envoyées à un serveur lorsque j'utilise cet outil ?
Non. Toute la conversion se passe entièrement dans votre navigateur en JavaScript. Vos données JSON ne sont jamais transmises sur le réseau, jamais stockées sur un serveur, et jamais journalisées ou analysées. L'outil est donc sûr à utiliser avec des clés API, des identifiants de base de données, des fichiers de configuration internes, des manifestes Kubernetes de production et toute autre donnée sensible. L'outil n'utilise aucun cookie pour vos données d'entrée et aucune analyse tierce ne capture ce que vous collez. Vous pouvez vérifier cela en ouvrant l'onglet Réseau de votre navigateur — vous verrez zéro requête déclenchée par le collage de JSON.
Y a-t-il une limite de taille pour l'entrée JSON ?
Il n'y a pas de limite stricte, mais les grandes entrées (supérieures à 200 Ko) passent automatiquement du mode en direct au mode manuel. En mode manuel, un bouton Convertir apparaît et la conversion ne s'exécute que lorsque vous cliquez dessus — cela empêche le thread principal du navigateur de se bloquer pendant 200-500 ms à chaque frappe. Pour les très grands fichiers JSON (plusieurs mégaoctets), envisagez des outils en ligne de commande comme yq ou jq pour de meilleures performances. L'outil gère efficacement les charges utiles réelles typiques : exports complets de namespaces Kubernetes, grandes spécifications OpenAPI et fichiers Docker Compose multi-services.