JSON vs YAML vs XML : quand utiliser vraiment chacun

JSON, YAML et XML sont tous les trois capables de représenter essentiellement les mêmes données sous-jacentes — objets imbriqués, listes, paires clé-valeur, valeurs simples — ce qui explique justement pourquoi le choix entre eux se résume si souvent à une habitude ou au réglage par défaut d'un framework, plutôt qu'à une décision réfléchie. Mais les trois ont été conçus à des époques différentes pour des cas d'usage principaux différents, et ces objectifs de conception initiaux se traduisent encore aujourd'hui par de vraies différences pratiques : lequel est agréable à modifier à la main, lequel une machine peut valider strictement, lequel s'imbrique en profondeur sans devenir illisible, et lequel dispose déjà d'un écosystème d'outils qui l'attend. Choisir en fonction de ces différences, plutôt que par habitude, est ce qui fait qu'un choix de format est réellement bon plutôt que simplement conventionnel.

Le JSON a été directement extrait de la syntaxe des objets littéraux de JavaScript, et cette origine explique précisément pourquoi il est devenu le format d'échange de données par défaut pour les API web : tout environnement JavaScript peut l'analyser nativement sans la moindre bibliothèque, sa grammaire est assez réduite pour être implémentée correctement en une après-midi dans à peu près n'importe quel autre langage, et ses règles strictes — pas de commentaires, pas de virgule finale, des clés obligatoirement entre guillemets doubles — signifient qu'un analyseur JSON a très peu d'ambiguïté à résoudre, ce qui rend le JSON à la fois rapide à analyser et facile à générer correctement. Cette même rigueur est aussi la principale faiblesse du JSON pour tout ce qu'un humain est censé modifier directement à la main : l'absence de commentaires signifie qu'il n'y a aucun moyen de laisser une note explicative dans un fichier de configuration, et la syntaxe d'accolades imbriquées, chargée de ponctuation, devient réellement difficile à suivre visuellement dès qu'une structure s'imbrique sur plus de trois ou quatre niveaux.

C'est pourquoi le JSON domine la communication de machine à machine — réponses d'API, échange de données entre services, tout ce qui est principalement généré et consommé par du code plutôt que lu et modifié par une personne — tout en restant un choix un peu maladroit pour les fichiers de configuration qu'un humain est censé entretenir à la main.

Le YAML a été conçu avec la priorité inverse : la lisibilité humaine et la facilité de modification manuelle, au prix d'une spécification d'analyse considérablement plus complexe que celle du JSON. Il utilise l'indentation plutôt que des accolades pour représenter l'imbrication, prend en charge de véritables commentaires avec `#`, et autorise les chaînes sans guillemets dans le cas courant — autant d'éléments qui font qu'un fichier YAML bien formaté se lit presque comme des notes structurées en texte simple plutôt que comme du code. C'est précisément pour cela que le YAML est devenu la norme pour les fichiers de configuration dans une immense partie de l'outillage de développement : définitions de pipelines CI/CD, manifestes d'orchestration de conteneurs, configuration d'application qu'un humain doit vraiment lire et modifier directement. Le compromis est que la dépendance du YAML aux espaces blancs pour représenter la structure le rend réellement fragile à modifier correctement à la main — une indentation mal placée change silencieusement à quel bloc appartient un élément, plutôt que de déclencher une erreur évidente — et sa spécification plus permissive et riche en fonctionnalités a produit, au fil des années, de réelles incohérences d'analyse, documentées, entre différentes bibliothèques YAML, une ambiguïté que la grammaire bien plus stricte du JSON ne laisse tout simplement pas exister.

Le XML est antérieur au JSON comme au YAML et a été conçu, lui aussi, pour une priorité différente : une structure de document stricte et vérifiable, entourée d'un écosystème de normes mature — des langages de schéma capables de valider la structure d'un document avant même que le code applicatif n'y touche, XPath pour interroger l'intérieur d'un document, des espaces de noms pour combiner des vocabulaires issus de sources différentes sans collision de noms. Cette profondeur d'outillage reste réellement inégalée par le JSON ou le YAML dans les contextes d'entreprise et centrés sur les documents : des secteurs avec des exigences strictes d'échange de données, des formats de document normalisés et des systèmes hérités de longue durée bâtis autour du XML continuent d'en dépendre précisément pour cette maturité de validation et d'outillage, et non par pure inertie. Le compromis bien connu est la verbosité — représenter les mêmes données imbriquées en XML nécessite généralement sensiblement plus de caractères que le JSON équivalent, puisque chaque valeur a besoin d'une balise ouvrante et fermante plutôt que d'un simple caractère de ponctuation — ce qui explique en grande partie pourquoi le XML a perdu son rôle de format par défaut pour les API au profit du JSON, à mesure que les services web ont mûri et que la taille des charges utiles et la simplicité d'analyse sont devenues des priorités plus importantes que la validation façon document.

Pour le corps d'une requête ou d'une réponse d'API, le JSON est aujourd'hui presque toujours le bon choix par défaut — c'est ce qu'attendront sans la moindre friction la plupart des bibliothèques clientes, la plupart des outils de documentation, et la plupart des développeurs de l'autre côté d'une intégration. Pour un fichier de configuration qu'une personne doit lire et modifier régulièrement à la main — pipelines CI, configuration d'application, définitions d'infrastructure as code — les commentaires et l'imbrication plus propre du YAML se justifient réellement, à condition que l'outillage environnant valide soigneusement la syntaxe, car c'est précisément là que la fragilité du YAML face aux espaces blancs se fait le plus sentir. Pour un format centré sur les documents avec un réel besoin de validation stricte de schéma, d'espaces de noms pour combiner des vocabulaires, ou d'intégration à un système d'entreprise existant basé sur XML, la verbosité du XML est un prix raisonnable pour une maturité d'outillage qu'aucun des deux autres ne reproduit entièrement. Le choix de format qui sert vraiment bien un projet est celui qui correspond à qui — ou à quoi — va le plus souvent lire et écrire le fichier, pas celui qui se trouve être le standard le plus à la mode du moment.