En bref : Le JSON est le choix le plus sûr pour les échanges de données entre machines, tandis que le YAML est préférable pour les configurations modifiées manuellement. Tout repose sur un choix de conception : la manière dont chaque format structure ses données. Le JSON affiche sa structure au grand jour, à l'aide d'accolades et de crochets visibles. Le YAML, lui, la dissimule dans les espaces invisibles. Ces deux formats de sérialisation remplissent la même fonction, ce qui explique pourquoi le choix se fait souvent par habitude plutôt que par réflexion, et pourquoi tant d'équipes finissent par gérer les deux. Voici comment trancher.
JSON signifie JavaScript Object Notation et, comme son nom l'indique, il est dérivé des formats de données JavaScript. Il s'agit d'un standard ouvert : léger, textuel et doté d'un ensemble de types de données volontairement limité. Sa syntaxe est courte, sa structure simple et il est très facile à lire.
Il est utilisé pour envoyer des données vers un serveur et les renvoyer au client, tel une enveloppe contenant les informations échangées entre correspondants. Les développeurs l'utilisent dans les applications mobiles, dans les bases de données orientées documents comme MongoDB (qui stocke un format binaire similaire au JSON appelé BSON), dans les files d'attente de messages et les pipelines de logs, ainsi que dans les API REST destinées aux utilisateurs, en tant qu'alternative plus conviviale au XML. C'est le format de charge utile par défaut pour les API REST, et tous les navigateurs l'analysent nativement.
Selon Douglas Crockford, le créateur du JSON, un langage utilisant les mêmes principes était déjà utilisé chez Netscape en 1996, mais le JSON ne s'est imposé comme syntaxe courante qu'aux alentours de 2001. Indépendant du langage, il fonctionne avec n'importe quel langage de programmation, et cette portabilité est la raison principale de sa popularité.
Un .json fichier est un fichier texte brut contenant un document JSON unique, enregistré avec l'extension .json et lisible dans n'importe quel éditeur. Il utilise une liste restreinte de types de données : chaînes de caractères, nombres, objets, tableaux, booléens et null. La syntaxe emprunte des conventions familières aux programmeurs des langages de la famille C, comme C, C++, C#, Java, JavaScript, Perl, Python et les autres. Comme l'indique le site officiel du JSON, un objet est un ensemble non ordonné de paires nom/valeur qui s'ouvre par une accolade ouvrante et se ferme par une accolade fermante, chaque nom étant suivi de deux-points et les paires étant séparées par des virgules.
La grammaire de travail tient sur une seule page sur json.org : ce n'est pas un résumé de la spécification, c'est la spécification elle-même. Le format est également formellement normalisé sous les noms ECMA-404 (2e édition, 2017) et IETF RFC 8259 (2017), mais la grammaire définie par ces documents reste la même, tout aussi compacte. Gardez cela à l'esprit lorsque vous découvrirez la spécification YAML plus tard.
Les mêmes données, d'abord en JSON, utilisant des informations sur le groupe de heavy metal Metallica :
{
"band": "Metallica",
"formed": 1981,
"origin": "Los Angeles, California",
"genres": ["thrash metal", "heavy metal"],
"active": true,
"members": [
{ "name": "James Hetfield", "role": "vocals, rhythm guitar", "joined": 1981 },
{ "name": "Lars Ulrich", "role": "drums", "joined": 1981 },
{ "name": "Kirk Hammett", "role": "lead guitar", "joined": 1983 },
{ "name": "Robert Trujillo", "role": "bass", "joined": 2003 }
],
"disbanded": null
}Les accolades délimitent l'objet et les tableaux ; chaque élément est entre guillemets ; deux-points séparent chaque nom de sa valeur, et une virgule sépare chaque paire de la suivante. Toute la structure est apparente, juste là, à l'extérieur, prête à être comptée.
Il fonctionne parce que sa syntaxe est compacte et lisible par l'humain, le balisage est minimal, l'analyse est rapide dans tous les langages et sa prise en charge est quasi universelle.
Il présente trois lacunes. Les types de données se limitent aux chaînes, nombres, objets, tableaux, booléens et null, donc tout ce qui est plus complexe doit être encodé sous forme de chaîne puis décodé manuellement à l'arrivée. Il n'y a pas de prise en charge des espaces de noms, des commentaires ou des attributs, et l'absence de commentaires se fait cruellement sentir dans un fichier de configuration. Enfin, la structure est volontairement simple, ce qui fait que les configurations complexes finissent souvent par développer leurs propres conventions.
YAML signifiait à l'origine « Yet Another Markup Language », avant que le sens ne devienne « YAML Ain't Markup Language » pour mettre l'accent sur les données plutôt que sur les documents. C'est un format léger et très lisible par l'humain, principalement utilisé pour stocker la configuration d'outils DevOps tels qu'Elasticsearch, Docker, Kubernetes, Prometheus et Ansible.
Comme l'indique le site officiel, lui-même écrit en YAML, YAML est un langage de sérialisation de données convivial pour tous les langages de programmation. Bien qu'il s'agisse d'un langage de sérialisation de données, il est tout aussi souvent utilisé pour les fichiers de configuration. Nous allons l'aborder sous l'angle de la sérialisation de données.
YAML a été rendu public en 2001. Ses membres fondateurs sont Ingy dot Net, Clark Evans et Oren Ben-Kiki, qui ont uni leurs forces pour créer quelque chose de plus simple que XML. Depuis, il est devenu le format de configuration par défaut de la majeure partie de la chaîne d'outils DevOps, ce qui signifie que le choix a souvent été fait pour vous avant même votre arrivée.
Un fichier YAML est un fichier texte brut, enregistré avec l'extension .yaml ou .yml, contenant un ou plusieurs documents YAML. Un seul fichier peut regrouper plusieurs documents séparés par une ligne de trois tirets, ce qui permet par exemple à un manifeste Kubernetes de combiner un déploiement et un service. Il prend en charge les commentaires, ce qui rend son édition particulièrement agréable.
YAML est un sur-ensemble de JSON : tout document JSON valide est également un YAML valide ; un fichier YAML peut donc contenir des objets JSON et un analyseur YAML lira un fichier .json sans aucune modification. Il gère aisément les types de données complexes, en imbriquant les objets aussi profondément que nécessaire. C'est précisément cette flexibilité qui pousse certains systèmes à restreindre les fonctionnalités YAML qu'ils acceptent.
#).|) conserve les sauts de ligne, le signe supérieur à (>) les fusionne en une seule ligne.Voici les mêmes données, cette fois en YAML :
band: Metallica
formed: 1981
origin: Los Angeles, California
genres:
- thrash metal
- heavy metal
active: true
members:
- name: James Hetfield
role: vocals, rhythm guitar
joined: 1981
- name: Lars Ulrich
role: drums
joined: 1981
- name: Kirk Hammett
role: lead guitar
joined: 1983
- name: Robert Trujillo
role: bass
joined: 2003
disbanded: nullTrois différences sautent aux yeux. Les accolades et les crochets ont disparu, l'indentation se chargeant de marquer la hiérarchie. Les guillemets ont également disparu, car YAML déduit le type à partir de la valeur. Enfin, les membres sont présentés sous forme d'une liste de tirets plutôt que comme un tableau séparé par des virgules, ce qui permet d'ajouter un cinquième élément en créant un nouveau bloc plutôt qu'en modifiant la ponctuation existante.
Plus propre, certes. Mais observez bien où se situe l'ossature. Dans la version JSON, elle est explicite. Dans la version YAML, elle est déduite des espaces, ce qui constitue une approche très différente.
Il fonctionne bien car sa syntaxe est facile à lire, l'indentation indique la structure sans nécessiter de ponctuation, les commentaires sont pris en charge, les structures complexes sont exprimables et les ancres permettent de réutiliser un bloc plutôt que de le copier. Cette réutilisation est l'une des raisons pour lesquelles YAML est utilisé pour décrire l'infrastructure, comme les piles Kubernetes, où les mêmes paramètres se retrouvent dans des dizaines d'objets.
C'est précisément là que réside sa flexibilité qu'il échoue. Une indentation ou un espacement incorrect génère des erreurs de validation, ou pire, un fichier qui s'analyse correctement mais produit un résultat non souhaité. Sa nature déclarative rend le débogage plus complexe : il n'y a rien à parcourir pas à pas, l'erreur n'apparaît donc qu'au moment de l'analyse ou de l'application du fichier. L'inférence de type comporte également ses pièges, le plus célèbre étant le code pays alpha-2 de la Norvège, NO, interprété comme le booléen faux à moins de le mettre entre guillemets. À proprement parler, ce comportement appartient à YAML 1.1: la spécification actuelle, YAML 1.2, révision 1.2.2 (octobre 2021), restreint les booléens aux seules valeurs true et false. Ce piège persiste car un grand nombre d'analyseurs utilisent encore par défaut la sémantique 1.1 ; en pratique, il suffit donc de mettre NO entre guillemets et de passer à autre chose.
YAML et JSON sont deux formats populaires, similaires en termes de structure et de facilité d'utilisation. Leurs différences de conception, de syntaxe et de fonctionnalités font que le choix entre les deux dépend de l'usage prévu.
| Fonctionnalité | JSON | YAML |
|---|---|---|
| Syntaxe | Accolades, crochets, guillemets et virgules | Indentation, deux-points et tirets |
| Commentaires | Non pris en charge | Pris en charge avec # |
| Types de données | Chaînes, nombres, objets, tableaux, booléens, null | Les mêmes, plus les dates et horodatages |
| Vitesse d'analyse | Plus rapide : grammaire restreinte et non ambiguë | Plus lente : spécification beaucoup plus vaste |
| Lisibilité humaine | Bonne, une fois la ponctuation dépassée | Meilleure pour l'édition manuelle, moins évidente pour repérer la structure |
| Réutilisation | Aucune | Ancres et alias |
| Support d'outillage | Natif dans les navigateurs et presque toutes les bibliothèques standards | Nécessite une bibliothèque externe dans la plupart des langages |
| Usage typique | API, échange de données, fichiers générés par machine | Fichiers de configuration, pipelines CI, infrastructure |
Une distinction fondamentale sous-tend tout cela. JSON a été conçu pour être écrit et lu par des machines ; il impose donc sa structure et ne laisse aucune place à l'interprétation pour un analyseur. YAML a été conçu pour les humains ; il déplace cette structure vers les espaces blancs, ce qui donne au fichier l'apparence d'un plan plutôt que celle d'un code.
La différence d'analyse provient des spécifications, et non d'un quelconque benchmark. La grammaire JSON tient sur une seule page sur json.org. La spécification YAML 1.2 s'étend sur des dizaines de pages couvrant les ancres, les balises, les scalaires de bloc, les documents multiples et le typage implicite : davantage de travail pour l'analyseur, et plus de risques d'erreurs. Considérez l'écart de vitesse comme une différence de nature plutôt que comme un chiffre : négligeable pour un fichier lu une seule fois au démarrage, mais mesurable pour un service qui désérialise en continu.
C'est aussi la raison pour laquelle ils échouent différemment. Un fichier JSON mal formé provoque généralement une erreur immédiate et explicite lors de l'étape d'analyse. Un fichier YAML mal formé est souvent analysé sans encombre, mais avec un sens totalement différent, car une indentation a déplacé une clé sous le mauvais parent, ou une valeur non citée a été interprétée avec le mauvais type. Les erreurs silencieuses sont les plus coûteuses.
Aucun des deux dans l'absolu. La question ne se résout qu'une fois le besoin défini : que doit accomplir le format ?
JSON est le plus adapté aux échanges de données. Rapide à analyser, pris en charge partout sans dépendance, et chaque élément est explicitement délimité, ce qui évite au parseur d'interpréter incorrectement la structure. Le revers de la médaille est la limitation des types de données : les valeurs complexes sont encodées sous forme de chaînes de caractères puis décodées à la sortie. Si vous concevez ces échanges, notre comparaison entre GraphQL et REST pèse le pour et le contre des deux styles d'API dominants.
YAML est le plus adapté aux fichiers de configuration maintenus par un humain. Il permet l'ajout de commentaires, autorise des imbrications profondes sans accumulation de ponctuation, et les ancres permettent de définir des paramètres partagés en une seule fois. Le revers de la médaille est que la structure repose sur l'indentation : un fichier peut être syntaxiquement valide tout en étant erroné, et le parseur a une charge de travail plus importante.
En résumé : si c'est un programme qui écrit le fichier, utilisez JSON. Si c'est une personne qui l'écrit, utilisez YAML, et ajoutez un validateur en amont.
Cette distinction n'est pas abstraite pour nous. Lorsque nous avons fait passer FlippedNormals, une place de marché dédiée à l'infographie qui était devenue trop grande pour WordPress, de Heroku vers AWS, le déclencheur a été exactement le compromis mentionné plus haut : les dynos gérés par Heroku nous offraient peu de contrôle sur la mise à l'échelle à mesure que le catalogue s'étoffait. Nous avons donc migré la plateforme vers AWS et terminé la première étape en deux mois, parallèlement à une migration de base de données de MySQL vers PostgreSQL. Une migration d'infrastructure de ce type est le moment où la partie YAML de cet article cesse d'être théorique : le déploiement est décrit, révisé et versionné dans des fichiers de configuration modifiés manuellement.
La partie JSON est apparue dans le même environnement, au sein des charges utiles que les services de la place de marché s'échangeaient : écrites par la machine, lues des milliers de fois, et jamais modifiées à la main. Un même système, deux formats, chacun remplissant la fonction pour laquelle il est le plus adapté.
Pour la plupart des équipes, il ne s'agit pas d'une décision esthétique. La facture se règle à cinq niveaux.
Erreurs de configuration en production. La sensibilité aux espaces et l'inférence de type de YAML signifient qu'un fichier peut être valide tout en étant erroné. Aucun analyseur ne détecte ce type d'erreur : seule une vérification de schéma le permet, ou bien un échec de déploiement en plein milieu de l'après-midi. Tout dépôt où YAML pilote l'infrastructure nécessite une validation de schéma et un formateur en intégration continue, ce qui représente un temps d'ingénierie à consacrer à la mise en place et à la maintenance.
Sécurité au niveau de l'analyseur. Le chargeur complet de YAML peut construire des objets arbitraires à partir d'un document, transformant discrètement une demande d'analyse de fichier en une autorisation d'exécuter tout ce que le fichier décrit, dès lors que l'entrée n'est pas fiable. C'est pourquoi les bibliothèques proposent un chargement sécurisé, le safe_load de PyYAML étant le plus connu, et pourquoi il doit être utilisé par défaut dans toute base de code lisant du YAML qu'elle n'a pas elle-même généré. JSON ne présente pas cette vulnérabilité, car le format ne permet pas de décrire un type à instancier.
Temps d'intégration. JSON est familier à quiconque a déjà utilisé une API. YAML possède des ancres, des alias, des scalaires de bloc et plusieurs documents par fichier, et tout nouvel arrivant y est confronté dès sa première semaine sur une infrastructure Kubernetes. Prévoyez le temps nécessaire à la montée en compétences, ou standardisez sur un sous-ensemble documenté et formalisez-le par écrit.
Coût de l'analyse à grande échelle. Pour un fichier de configuration lu une seule fois au démarrage, le coût d'analyse est négligeable. Pour un service désérialisant des milliers de charges utiles par seconde, ce n'est pas le cas, et la grammaire plus restreinte de JSON est moins coûteuse à traiter.
Environnements mixtes. Le résultat le plus coûteux n'est ni l'un ni l'autre des formats. C'est le mélange des deux : de la configuration en YAML, des fixtures en JSON, une couche de conversion intercalée entre les deux, et deux ensembles de règles de validation qui divergent au fil des dix-huit mois. Choisissez un format par usage, documentez cette décision et validez chacun d'eux avec un schéma : JSON Schema pour le côté JSON, et l'un des outils de schéma YAML pour l'autre.
Quatre questions à se poser avant de choisir un format de sérialisation pour un projet.
Le plus souvent, les réponses ne pointent pas vers un format unique pour l'ensemble du système. Sur la plupart des plateformes que nous développons, la distinction est toujours la même : YAML pour ce que les humains maintiennent, les pipelines, les manifestes et la configuration d'environnement, et JSON pour ce que les services s'échangent entre eux. L'erreur que nous constatons le plus souvent n'est pas de choisir le mauvais format, mais de laisser les deux se mélanger dans la même tâche sans que personne ne décide lequel va où.
Non. Le JSON est plus rapide à analyser car sa grammaire tient sur une seule page et ne souffre d'aucune ambiguïté, tandis que la spécification YAML est beaucoup plus vaste et nécessite une inférence de type. Cet écart est négligeable pour un fichier de configuration lu une seule fois au démarrage, mais il devient significatif pour un service qui analyse des charges utiles en continu.
Oui. Le YAML est un sur-ensemble du JSON ; tout document JSON valide est donc également un YAML valide, et un analyseur YAML lit un .json fichier sans modification. L'inverse n'est pas vrai : un analyseur JSON ne peut pas lire du YAML.
.json fichier ?Un fichier texte brut contenant un document JSON unique, enregistré avec l'extension .json . Il contient un objet ou un tableau à la racine, utilise des clés et des valeurs entre guillemets, et s'ouvre avec n'importe quel éditeur de texte.
Un fichier texte brut enregistré sous .yaml ou .yml qui contient un ou plusieurs documents YAML. Il utilise l'indentation plutôt que des accolades, prend en charge les commentaires et constitue le format de configuration standard pour des outils tels que Kubernetes, Docker Compose et Ansible.
Le YAML, car c'est le langage dans lequel l'écosystème est écrit, et les manifestes sont modifiés et relus par des humains. Kubernetes accepte l'équivalent en JSON, mais tous les exemples, tutoriels et manifestes générés que vous rencontrerez seront en YAML.
Sur tout dépôt où plusieurs personnes modifient du YAML, oui. Un formateur associé à un linter dans votre CI permet de détecter les erreurs d'indentation et d'inférence de type qu'un analyseur accepte sans broncher, mais qu'un cluster rejettera plus tard.
Uniquement avec un chargeur sécurisé. Le chargeur complet peut instancier des objets arbitraires décrits dans le document ; l'analyse d'un fichier non fiable peut donc exécuter du code. Utilisez la variante sécurisée fournie par votre bibliothèque, comme celle de PyYAML : safe_load, dès lors que le fichier ne provient pas de votre propre dépôt.
Dès qu'un programme écrit ou lit le fichier plutôt qu'un humain : charges utiles d'API, files d'attente de messages, lignes de logs, jeux de données de test, stockage navigateur. Optez pour le YAML lorsqu'un humain gère le fichier et a besoin de commentaires et d'une structure facile à parcourir.
Oui, et la plupart des bibliothèques YAML le font en une ligne de code. La conversion du YAML vers le JSON fait perdre les commentaires et les ancres ; considérez donc le YAML comme la source et le JSON comme l'artefact généré, jamais l'inverse.
Le choix d'un format de sérialisation est une décision mineure aux conséquences durables, et généralement l'aspect le moins intéressant d'une question d'architecture bien plus vaste. Si vous réfléchissez à la manière dont vos services doivent échanger et stocker des données, notre équipe d'ingénierie sera ravie d'en discuter avec vous.
Rédacteur de contenu et producteur de médias numériques qui s'intéresse à la relation symbiotique entre la technologie et la société. Les livres, la musique et les guitares sont une constante.
Alexandra Mendes est spécialiste senior de la croissance chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction de textes sur le développement de logiciels, l'IA et la transformation numérique. Après avoir suivi un cours de développement frontend, Alexandra a acquis des compétences pratiques en matière de codage et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la façon dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
People who read this post, also found these interesting:
.webp)
