Les échanges de données sont partout : une API transmet une commande, une application mobile synchronise un profil, un service appelle un autre service. XML, JSON et Protocol Buffers — ou Protobuf — répondent à ce besoin, avec des compromis différents. Le SDK gratuit Codec de SynapxLab les convertit directement dans le navigateur, en distinguant ce qui relève de la structure de ce qui dépend d’un schéma.
Tester les formats en pratique — Collez un schéma
.proto, convertissez vos données dans les deux sens et observez le poids obtenu ainsi que le wire format généré. Essayer le convertisseur XML, JSON et Protobuf
Trois manières de décrire la même information
Un même objet métier peut être exprimé de plusieurs façons : XML avec des balises, JSON avec des clés et valeurs, Protobuf avec des champs définis dans un schéma. Le bon choix dépend du contexte : document durable, API publique ou appel fréquent entre microservices.
XML : une structure balisée, riche et explicite
XML repose sur des balises ouvrantes et fermantes. Cette syntaxe le rend très lisible pour une personne qui examine le flux, tout en donnant une structure auto-descriptive : les noms des éléments voyagent avec les valeurs. XML gère naturellement les attributs et les namespaces, utiles lorsque plusieurs vocabulaires doivent cohabiter dans un même document.
XML a longtemps dominé les échanges applicatifs, notamment avec SOAP, et reste présent dès qu’un standard métier ou documentaire l’impose. Sa contrepartie est son coût : les balises répétées augmentent la taille des messages et leur analyse demande plus de travail qu’une structure compacte.
JSON : le format texte des API web
JSON est un format texte composé d’objets, de tableaux, de clés et de valeurs. Sa syntaxe est plus légère que celle de XML et très familière des développeurs web. Dans un navigateur, JSON.parse permet de transformer directement un document JSON en structure exploitable par JavaScript.
Sa simplicité explique sa place centrale dans les API REST, les configurations, les interfaces web et le diagnostic. Il ne nécessite pas de schéma obligatoire. Cette souplesse a des limites : JSON n’offre pas de type binaire natif, ne prévoit pas de commentaires, et l’absence de schéma ne remplace pas un contrat d’API clair.
Protobuf : un contrat et un encodage binaire
Protocol Buffers est une technologie de sérialisation binaire créée par Google. Avant de produire ou de lire les octets, vous définissez les messages dans un fichier .proto. Ce schéma décrit les champs, leurs types et leurs numéros. L’outil protoc sert ensuite à compiler ce contrat et à générer le code nécessaire dans le langage visé.
Le point essentiel est souvent mal compris : dans une déclaration comme string email = 2;, le 2 n’est pas une valeur et n’est pas une position décorative. C’est l’identifiant du champ qui sera inscrit dans le binaire à la place de son nom. Le flux Protobuf ne contient pas les noms de champs tels que email ou customer_id ; il contient leurs numéros, encodés dans un tag calculé ainsi : (field_number << 3) | wire_type.
Les entiers utilisent notamment des varints, un encodage à taille variable. Les petites valeurs occupent peu d’octets, ce qui contribue à la compacité générale. Avec des noms absents du flux et un encodage binaire adapté, Protobuf est généralement plus compact et plus rapide à sérialiser ou à analyser que les formats texte. En contrepartie, il est illisible sans son fichier .proto et demande une étape de compilation ou de génération de code.
Protobuf constitue le socle de gRPC. Il permet d’ajouter un champ sans casser les anciens lecteurs, à condition de ne jamais réutiliser un numéro ayant déjà existé.
Comparaison rapide des formats
| Critère | XML | JSON | Protobuf |
|---|---|---|---|
| Taille | Élevée, à cause des balises | Modérée et légère pour du texte | Faible en général, encodage binaire compact |
| Vitesse de parsing | Souvent plus coûteuse | Rapide dans les environnements web | Rapide avec le schéma et le code généré |
| Lisibilité humaine | Très bonne, structure balisée | Très bonne, syntaxe concise | Faible sans le fichier .proto |
| Schéma requis | Non pour lire la structure, possible via XSD | Non obligatoire | Oui, fichier .proto et message cible |
| Types binaires | Possibles selon les conventions employées | Pas de type binaire natif | Nativement pris en charge par le schéma |
| Écosystème et usage typique | SOAP, documents, configurations, legacy | API REST, web, configuration, debug | gRPC, microservices, mobile, flux à fort volume |
Quand utiliser XML, JSON ou Protobuf ?
Il n’existe pas de gagnant universel. XML reste un choix cohérent pour les documents structurés, les intégrations legacy et les services SOAP. Ses attributs, ses namespaces et son écosystème documentaire répondent à des besoins que la seule concision ne remplace pas.
JSON est souvent le meilleur point de départ pour une API publique, une configuration, une interface web ou une phase de débogage. Il est immédiatement observable, largement supporté et particulièrement naturel dans le navigateur. C’est aussi le format qui réduit la friction lorsqu’un partenaire doit essayer un endpoint sans installer d’outillage particulier.
Protobuf convient particulièrement aux communications internes entre microservices, aux appels gRPC, aux applications mobiles et aux flux où la taille et la vitesse comptent réellement. Son adoption suppose toutefois une discipline de schéma : versionner les .proto, préserver les numéros de champs et intégrer la génération de code au cycle de développement.
Les autres formats d'échange
XML, JSON et Protobuf ne résument pas à eux seuls les formats d'échange de données. Ils constituent toutefois trois repères pédagogiques utiles : XML représente les formats texte verbeux et balisés, JSON les formats texte légers, et Protobuf les formats binaires fondés sur un schéma. Autour de ces trois familles, d'autres solutions répondent à des besoins plus ciblés de configuration, de données tabulaires, d'interopérabilité ou de performance.
Les formats texte : configuration et données simples
YAML privilégie la lisibilité humaine grâce à une syntaxe fondée sur l'indentation. Quasi surensemble de JSON, il est particulièrement présent dans les fichiers de configuration de CI/CD, Docker Compose et Kubernetes. Cette souplesse a une contrepartie : l'indentation compte et son analyse est plus subtile que celle de JSON.
TOML vise également la configuration, avec une organisation en sections et des types lisibles. Il est notamment adopté par l'écosystème Rust avec Cargo, ainsi que par Python avec pyproject.toml. Pour les données plates, CSV reste une option minimale, structurée en lignes et colonnes, adaptée aux tableurs ; il ne porte en revanche ni hiérarchie ni types. INI, basé sur des paires clé=valeur regroupées en sections, convient à une configuration basique.
Les formats binaires : compacité, schéma ou accès direct
MessagePack peut être vu comme un JSON binaire compact, sans schéma : il est réversible tel quel et sert à alléger des échanges JSON existants. CBOR est une alternative standardisée sans schéma, définie par la RFC 8949, proche de MessagePack et présente dans l'IoT, COSE et WebAuthn. BSON étend JSON sous forme binaire avec des types riches, notamment les dates et les données binaires ; MongoDB l'utilise.
Avro est un format binaire à schéma, dont le schéma est décrit en JSON. Il est courant dans les environnements data tels que Hadoop et Kafka, où le schéma accompagne ou précède les données. Enfin, FlatBuffers et Cap'n Proto sont des formats binaires à schéma conçus pour un accès « zéro copie » : un champ peut être lu sans désérialiser l'ensemble du message. Cette propriété est utile dans les jeux vidéo et les cas très sensibles à la performance.
| Format | Famille (texte/binaire) | Schéma | Usage typique |
|---|---|---|---|
| YAML | Texte | Non | Configuration CI/CD, Docker Compose, Kubernetes |
| TOML | Texte | Non | Configuration Rust et Python |
| CSV | Texte | Non | Données plates et tableurs |
| MessagePack | Binaire | Non | Alléger des échanges JSON existants |
| CBOR | Binaire | Non | IoT, COSE et WebAuthn |
| Avro | Binaire | Oui | Écosystèmes data Hadoop et Kafka |
| FlatBuffers | Binaire | Oui | Jeux vidéo et accès performant aux données |
Le SDK Codec de SynapxLab se concentre volontairement sur XML, JSON et Protobuf, les formats les plus courants en usage réel.
Convertir plusieurs formats grâce à un pivot
Pour relier plusieurs formats, un format pivot simplifie l’architecture : chaque format rejoint une représentation centrale, puis le format demandé. Cela évite de multiplier les chemins spécifiques.
flowchart LR
XML["XML"] <-->|"conversion structurelle"| JSON["JSON — format pivot"]
JSON <-->|"schema .proto requis"| PB["Protobuf"]Dans ce modèle, XML vers JSON et JSON vers XML sont des conversions principalement structurelles. Elles ne demandent pas de schéma : l’outil traduit éléments, attributs, objets, tableaux et valeurs. Les nuances d’un XML complexe — namespaces, attributs ou ordre des éléments — doivent néanmoins être traitées avec attention.
Le passage entre JSON et Protobuf est différent. Pour encoder du JSON en Protobuf, il faut connaître le schéma .proto et le nom précis du message à utiliser. Pour décoder les octets Protobuf, il faut les mêmes informations. Sans elles, des numéros de champs et des types de fil ne suffisent pas à reconstituer de façon fiable les noms, les types métier ou l’imbrication attendue.
Pourquoi un convertisseur Protobuf universel n’existe pas
Un convertisseur JSON vers Protobuf prétendument universel, sans schéma, ne peut pas être exact. Le binaire Protobuf a été conçu pour ne pas embarquer les noms de champs. Il transporte des identifiants numériques et des valeurs encodées ; le fichier .proto apporte la signification de ces identifiants.
Cette dépendance n’est pas un défaut accidentel : c’est précisément le compromis qui rend le format compact et efficace. Elle impose simplement un contrat explicite. Si un champ porte le numéro 2, seul le schéma indique qu’il correspond, par exemple, à une chaîne email, à un entier ou à une structure imbriquée selon le message concerné.
Le SDK Codec vous demande donc de coller votre schéma .proto ainsi que le nom du message lorsque vous travaillez avec Protobuf. Cette étape garantit que la conversion s’appuie sur le vrai contrat de vos données, au lieu de produire une interprétation approximative.
Essayer Codec dans votre navigateur
Codec a été conçu pour rendre ces passages plus accessibles lors d’un développement, d’une migration ou d’une vérification d’intégration. Vous pouvez convertir XML ⇄ JSON ⇄ Protobuf depuis votre navigateur, en fournissant le schéma nécessaire dès que Protobuf entre en jeu.
Le SDK est gratuit, souverain et hébergé en France. La conversion s’effectue à 100 % côté navigateur : aucune donnée n’est envoyée à un serveur. Vous pouvez l’essayer sur synapx.fr/sdk/Codec/ avec un jeu de données de test, puis avec vos propres structures et vos fichiers .proto.