BSON, CBOR, MessagePack : quel format de sérialisation binaire choisir

Ces trois formats encodent en binaire compact le même type de structures que le JSON (objets, tableaux, nombres, chaînes), mais aucun n’a été conçu pour le même contexte : le choix dépend de l’écosystème dans lequel le fichier circule plutôt que d’une hiérarchie de qualité.

Format	Origine / gouvernance	Signature fixe	Contexte typique
BSON	MongoDB Inc. (interne au produit)	Non	Stockage et échange internes MongoDB
CBOR	Norme IETF (RFC 8949)	Optionnelle (tag 55799, octets D9 D9 F7)	Objets connectés, protocoles normalisés (CoAP, WebAuthn)
MessagePack	Standard de facto, sans organisme officiel	Non	RPC interne, jeux multijoueurs, pipelines de logs

Le BSON (Binary JSON) étend le modèle JSON avec des types que ce dernier ne connaît pas nativement (dates, entiers 64 bits, identifiants binaires) et encode la longueur de chaque champ directement dans sa structure pour permettre à MongoDB de parcourir un document sans le réanalyser entièrement. Sa spécification reste maintenue par MongoDB Inc. plutôt que par un organisme extérieur : c’est un format pensé pour cette base de données précise (exports mongodump, protocole entre pilotes et serveur), pas une norme d’échange générale destinée à un usage indépendant.

Le CBOR, normalisé par l’IETF dans la RFC 8949, vise au contraire un encodage aussi compact que possible et rapide à décoder sans bibliothèque lourde, pensé dès l’origine pour les objets connectés aux ressources limitées. Son statut de norme IETF officielle en favorise l’adoption dans des protocoles normalisés comme CoAP (équivalent léger de HTTP pour l’IoT) ou WebAuthn/FIDO2, qui encode en CBOR les objets d’attestation échangés lors d’une authentification par clé de sécurité.

Le MessagePack partage la même philosophie de compacité, mais reste un standard de facto porté par sa communauté plutôt que normalisé par un organisme officiel. Il distingue nativement les entiers des nombres à virgule flottante et propose un type binaire dédié : deux limites du JSON, qui doit sinon encoder le binaire en base64, au prix d’un gonflement d’environ 33 %. Sa compacité et sa rapidité de décodage en ont fait un choix fréquent pour les protocoles RPC internes et les moteurs de jeux multijoueurs, où chaque octet et chaque microseconde de décodage comptent.

Ni BSON ni MessagePack n’ont de signature binaire fixe permettant d’identifier un fichier indépendamment de son contenu, contrairement à des formats dotés d’un en-tête réservé comme le Parquet ou l’Avro. CBOR définit un marqueur facultatif, le tag « Self-Described CBOR » (numéro 55799, sérialisé D9 D9 F7), que l’application peut placer en tête d’un fichier (RFC 8949, section 3.4.6) ; il n’est pas obligatoire, et beaucoup de fichiers CBOR n’en portent pas.

Le critère de choix reste donc l’écosystème : BSON pour tout ce qui touche à MongoDB spécifiquement, CBOR quand la conformité à une norme IETF officielle importe (objets connectés, protocoles normalisés), MessagePack pour un besoin générique de compacité entre systèmes qui contrôlent les deux extrémités de l’échange sans dépendre d’une norme externe.