La conversion est-elle sans perte ?
Non, et aucune conversion YAML vers JSON ne l'est. Les commentaires, les anchor, les merge key, les tag et le style en bloc n'ont pas d'équivalent JSON : ils sont résolus ou supprimés. Ce qui change ici, c'est que chacun est compté et localisé au lieu de disparaître discrètement.
Le résultat redonne-t-il le même fichier ?
Le JSON, oui : convertir du JSON en YAML puis revenir a produit un JSON identique octet pour octet sur les trois fichiers réels testés, littéraux numériques et ordre des clés compris. Le YAML, non : les commentaires ont disparu, les anchor et les merge key sont développés, et les guillemets changent. Les valeurs survivent à l'aller-retour ; le fichier tel que vous l'aviez écrit, non.
Pourquoi mon yes est-il devenu une chaîne ?
Parce que cet outil lit le YAML 1.2, où yes est du texte. PyYAML, Ruby et le yaml.v2 de Go lisent le YAML 1.1, où le même mot vaut true. Ce sont exactement les lignes que signale la liste des écarts : vous les voyez ici plutôt que dans un déploiement cassé.
Mes nombres sont-ils arrondis ?
Non. Le JSON est écrit à partir de votre texte source et non d'un nombre JavaScript : 9007199254740993 et 1.10 sont imprimés exactement comme vous les avez tapés. L'ordre des clés survit aussi, y compris les clés qui ressemblent à des nombres comme 10, 2 et 1, qu'un objet JavaScript ordinaire réordonnerait silencieusement en 1, 2, 10.
Peut-il ouvrir des fichiers CloudFormation ou Ansible ?
Il les ouvre sans échouer : !Ref et !GetAtt sont acceptés et leurs valeurs conservées, mais le tag lui-même est supprimé. Ce que vous récupérez, ce sont des données, pas un template déployable.
Mon fichier est-il téléversé ?
Non. La conversion s'exécute dans votre onglet. Ici, cela compte plus que sur la plupart des pages : les manifestes Kubernetes et les workflows CI transportent couramment des noms d'hôtes internes, des adresses de registry, des noms de secrets et parfois les secrets eux-mêmes.
