Pourquoi les logiciels utilisent différents formats de données

Réponse rapide

Les programmes stockent et échangent des données sous forme d’octets. Que ces octets ressemblent à du texte lisible ou à du binaire opaque est un choix de design guidé par qui doit le lire (humains, scripts ou machines seules), combien la taille sur le fil compte, et à quel point la forme des données doit être imposée strictement. JSON convient aux API web et à la config ; CSV aux exports rectangulaires ; Protobuf au RPC haut débit ; PNG aux icônes sans perte ; SQLite aux requêtes relationnelles embarquées — aucun ne remplace totalement les autres.

Pourquoi le choix de format revient sans cesse

Les projets d’intégration échouent plus souvent sur des octets ambigus que sur des fonctionnalités manquantes. Un partenaire envoie du CSV avec des point-virgules ; votre importeur attend des virgules. Une API renvoie des nombres JSON en chaînes parce que les ID dépassent la plage d’entiers sûrs. Un client mobile attend Protobuf mais la passerelle émet du JSON pour le débogage et oublie de revenir en production.

Les formats encodent aussi des contrats sociaux : la finance vit dans des tableurs, le mobile veut du RPC compact, le juridique veut de l’XML archivable avec signatures, et les pipelines data science veulent Parquet ou des extraits SQLite. Imposer un format à chaque couche force des adaptateurs coûteux à chaque frontière.

Formats texte vs formats binaires

Les formats texte encodent l’information en caractères d’alphabets définis — surtout UTF-8 sur le fil aujourd’hui. Vous pouvez les ouvrir dans un éditeur, les envoyer par e-mail et les diff en contrôle de version. Les formats binaires packent types numériques, préfixes de longueur et bitmaps compressés sans garantir la lisibilité humaine. Analyser du binaire est en général plus rapide et plus compact parce qu’il n’y a pas de scan lexical d’accolades et de guillemets.

JSON

JSON mappe objets, tableaux, chaînes, nombres, booléens et null dans une syntaxe minimale. Les navigateurs exposent JSON.parse et JSON.stringify, ce qui a aidé JSON à déplacer XML pour beaucoup d’API. Le JSON strict n’a pas de commentaires et les clés dupliquées sont déconseillées — les validateurs attrapent les erreurs tôt.

• Force : bibliothèques universelles ; fit naturel pour REST et fichiers de config.
• Faiblesse : les nombres sont des doubles IEEE — les entiers au-delà de 2^53 ont besoin de chaînes en JS.
• Faiblesse : verbeux comparé au binaire ; les objets imbriqués répètent les noms de champs sur le fil.

{
  "query": "blue shirt",
  "page": 1,
  "filters": { "inStock": true }
}

Des objets imbriqués comme filters ci-dessus s’aplatissent mal en CSV sans conventions (colonne JSON, en-têtes répétés ou lignes dénormalisées). Ce mismatch d’impédance est un signal : restez en JSON quand les lignes ne sont pas plates.

{
  "id": 1042,
  "name": "Ana Rivera",
  "email": "ana@example.com",
  "active": true
}

id,name,email,active
1042,Ana Rivera,ana@example.com,true

CSV

Comma-separated values (parfois point-virgule selon les locales) représente des tables avec une ligne par rangée. Les tableurs importent le CSV sans cérémonie. Le format paraît trivial jusqu’à ce que des virgules apparaissent dans les cellules, que les locales utilisent des séparateurs décimaux différents, ou que des retours à la ligne se glissent dans des champs entre guillemets.

XML

XML balise les données avec éléments imbriqués et attributs, plus des namespaces pour mélanger des vocabulaires. Des langages de schéma (XSD) peuvent imposer la structure plus rigidement que le JSON typique. Le markup documentaire (fichiers Office, SVG, RSS) repose encore sur XML ; beaucoup d’API HTTP greenfield ont choisi JSON pour la brièveté et l’affinité JavaScript.

XML brille quand le contenu mixte compte — paragraphes avec gras inline — ou quand des industries ont standardisé des schémas particuliers il y a des décennies. JSON Schema et OpenAPI comblent partiellement le rôle de validation que les piles XML avaient, mais la maturité des outils diffère selon l’écosystème.

Échange binaire : Protobuf et MessagePack

Protocol Buffers compile un schéma .proto en structs typées dans de nombreux langages. Sur le fil, tags de champs et varints remplacent les chaînes de clés répétées. MessagePack est un encodage binaire schemaless proche de JSON — pratique quand vous voulez des payloads plus petits sans maintenir des fichiers .proto.

Les deux exigent un accord sur numéros de champs ou tags de type. Faire évoluer les schémas demande des règles : ajouter des champs optionnels, ne jamais réutiliser des numéros, réserver les tags dépréciés. Cette discipline achète la compatibilité à l’échelle dans les datacenters.

Images et médias

PNG préserve les pixels sans perte et supporte la transparence — bon pour les assets UI. JPEG échange compression avec perte pour les photos. WebP et AVIF visent des fichiers plus petits avec des codecs modernes. Ce ne sont pas des conteneurs de données génériques ; forcer des fichiers arbitraires via des formats image serait absurde, mais les équipes choisissent encore « PNG vs JPEG » quand la charge est visuelle par nature.

SQLite et bases mono-fichier

SQLite stocke des tables relationnelles dans un fichier binaire unique avec sémantique transactionnelle. Apps mobiles et navigateurs (via WebAssembly ou bindings natifs) l’utilisent pour recherche offline et caches structurés. Contrairement à des lignes JSON dans un dossier, SQLite offre des requêtes indexées sans monter un serveur — au prix de fichiers opaques et d’outils de backup qui comprennent le mode WAL.

Exporter un rapport en JSON donne un gros document ; exporter en .sqlite donne aux analystes des JOIN et des index. À l’inverse, envoyer un fichier SQLite par e-mail à quelqu’un qui n’a qu’Excel crée de la friction — rencontrez les destinataires là où leurs outils sont déjà.

Transport d’octets via des canaux texte

Pièces jointes e-mail, champs JSON qui doivent contenir un certificat et data URLs embarquent parfois des octets bruts en texte Base64. L’encodage grossit la taille d’environ quatre tiers et exige un décodage à réception. C’est un hack de transport, pas un remplacement du choix du format sous-jacent.

Comparaison en un coup d’œil

Choisir sans dogme

1. Identifiez le consommateur : personne dans Excel, script navigateur ou microservice en Go.
2. Décidez si un schéma formel et la compatibilité arrière comptent sur des années.
3. Mesurez taille de payload et temps d’analyse sur des données réalistes — pas des exemples hello-world.
4. Vérifiez la sécurité : n’exécutez jamais aveuglément des formules CSV ; assainissez les entités externes XML dans les parseurs legacy.
5. Préférez la conversion aux frontières : stockez du JSON canonique en interne, exportez CSV pour la finance, shippez Protobuf dans votre cluster.

Les formats d’échange gagnent sur l’ubiquité bien avant de gagner sur l’élégance.

— Sagesse pratique de l’intégration

Essayez par vous-même

Inspectez et transformez des données localement avant qu’elles ne franchissent une frontière de confiance. Formater et valider du JSON attrape virgules finales et erreurs de type. Convertir entre JSON et CSV révèle si votre table est vraiment rectangulaire ou cache des structures imbriquées. Encoder un petit fichier en Base64 montre la pénalité de taille d’embarquer du binaire dans du texte.

• JSON Formatter — structure lisible pour revue et diffs.
• JSON Validator — contrôle syntaxique strict avant déploiement.
• JSON to CSV / CSV to JSON — tester si votre modèle d’export correspond à la réalité.
• Base64 Encoder — voir la taille encodée versus octets bruts.

L’encodage n’est pas le chiffrement. Base64 et l’encodage d’URL transforment la représentation ; ils ne protègent pas les secrets de quiconque voit la chaîne.

Idées connexes

L’essor de JSON tient autant à l’ergonomie navigateur qu’à la syntaxe. Unicode et UTF-8 expliquent pourquoi les formats texte cassent quand les encodages se mélangent. Séparer encodage et chiffrement garde les revues sécurité honnêtes quand quelqu’un propose « juste le Base64 ».