JSON expliqué : pourquoi il est devenu si populaire

Une courte histoire

JSON est né comme format d’échange pratique, pas comme projet académique de normalisation. Douglas Crockford l’a documenté sur json.org en arguant qu’une grammaire petite et prévisible battait les piles XML lourdes pour beaucoup de cas web. ECMA-404 et la RFC 8259 de l’IETF ont ensuite codifié les mêmes règles : texte UTF-8, objets et tableaux, et un ensemble fixe de types de valeurs. Cette standardisation comptait parce que les API sont des contrats — chaque client doit analyser les mêmes octets de la même façon.

JSON is a light-weight, text-based, language-independent data interchange format.

— RFC 8259

Ce que la syntaxe JSON autorise vraiment

Au niveau racine, JSON est soit un objet, soit un tableau. Les objets sont des cartes non ordonnées de chaînes vers des valeurs ; les tableaux sont des listes ordonnées. Les clés doivent être des chaînes entre guillemets doubles. Les chaînes utilisent des guillemets doubles et les séquences d’échappement usuelles (\", \\, \b, \f, \n, \r, \t, \uXXXX). Les nombres s’écrivent en décimal ; les booléens sont true et false ; null est une valeur à part entière. Voilà tout le système de types — pas de dates, pas de commentaires, pas d’undefined, pas de virgules finales en JSON strict.

{
  "title": "JSON Explained",
  "published": "2026-10-04",
  "featured": true,
  "tags": ["api", "data"],
  "metrics": { "views": 1204, "rating": 4.8 },
  "notes": null
}

La date et les métriques imbriquées sont des conventions que votre API documente — pas des types JSON natifs. JSON ne connaît que string, number, boolean, null, object et array.

Objets, tableaux et primitives en pratique

• Les objets regroupent des champs nommés — typique pour des enregistrements, des paramètres ou des ressources d’API.
• Les tableaux conservent l’ordre — listes d’éléments, lignes de journal ou coordonnées.
• Les chaînes portent du texte ; les nombres sont en binary64 IEEE 754 dans la plupart des analyseurs (attention aux entiers au-delà de 2^53 en JavaScript).
• Les booléens et null sont explicites pour que les analyseurs ne devinent pas.

Imbrication et forme de charge

Les vraies API imbriquent des objets dans des tableaux et des tableaux dans des objets : un résultat de recherche peut ressembler à { "items": [ { "id": 1, "name": "…" } ], "total": 42 }. Une imbrication profonde se lit bien en petites doses ; des structures plates avec des identifiants passent souvent mieux à l’échelle pour les clients qui patchent des champs isolés. JSON se moque du style que vous choisissez — le contrat est ce que promettent votre OpenAPI ou votre README.

JSON n’est pas JavaScript

Les littéraux d’objets JavaScript autorisent des clés entre simples quotes, des clés non quotées quand ce sont des identifiants valides, des virgules finales, undefined, des fonctions et des objets Date. JSON n’autorise rien de tout cela. Les navigateurs ont exposé JSON.parse et JSON.stringify pour que les applications franchissent la frontière en sécurité. Traiter les réponses d’API avec eval() était l’anti-modèle que JSON visait à remplacer.

Pourquoi JSON a déplacé XML pour beaucoup d’API

XML excelle quand il faut du contenu mixte, des espaces de noms, des schémas intégrés aux flux d’entreprise ou du balisage documentaire. JSON excelle quand il faut un format filaire mince pour des enregistrements structurés sur HTTP. Les charges JSON sont en général plus petites, les analyseurs plus simples, et chaque langage mainstream embarque une bibliothèque JSON. Le débat attributs contre éléments devient sans objet quand tout est des objets imbriqués.

JSON5, JSONC et la taxe de la rigueur

Les humains veulent des commentaires et des virgules finales dans les configs éditées à la main. JSON5 et JSONC (JSON avec commentaires) ajoutent ces facilités pour les fichiers sources. Les API de production, en revanche, restent massivement sur le JSON strict de la RFC 8259 pour que tous les consommateurs s’accordent sur les modes d’échec. Une virgule finale que votre éditeur tolère cassera l’analyseur strict d’une autre équipe — c’est pourquoi les collages dans les validateurs échouent encore en 2026.

Sérialisation et analyse

Les choix de sérialisation comptent : un stringify par défaut peut omettre les propriétés undefined en JavaScript, réordonner les clés d’objet de façon imprévisible ou sérialiser les dates en chaînes ISO seulement si vous ajoutez un replacer. Les concepteurs d’API documentent ces règles pour que les clients ne s’appuient pas sur l’ordre des clés ou une coercion implicite de types.

Validation et erreurs courantes

• Virgules finales après le dernier élément de tableau ou la dernière propriété d’objet
• Chaînes entre simples quotes au lieu de guillemets doubles
• Clés non quotées (habitude JavaScript collée dans du JSON)
• Littéraux JavaScript : undefined, NaN, Infinity
• Commentaires copiés depuis des modèles de config
• Crochets mal appariés ou virgules parasites entre valeurs
• Échappements Unicode invalides (\u doit être quatre chiffres hex)

Quand une intégration échoue, passez la charge dans un formateur et un validateur avant d’accuser le serveur. La moitié des signalements « l’API renvoie du mauvais JSON » viennent d’un copier-coller abîmé ou d’un double encodage JSON déjà en chaîne par un middleware.

JSON dans les API et l’échange

Les API HTTP envoient couramment du JSON avec Content-Type: application/json. Les clients envoient Accept: application/json pour préférer les réponses JSON. GraphQL et d’autres styles sérialisent encore souvent les résultats en JSON sur HTTP. Le CSV reste populaire pour les tableurs ; les outils json-to-csv et csv-to-json de SmartKitio existent pour la passerelle entre tableaux plats et formes d’API imbriquées — non parce qu’un format est supérieur, mais parce que les équipes vivent dans les deux mondes.

Limites réelles (pas des mythes)

• Pas de type date standard — utilisez des chaînes ISO 8601 et documentez les fuseaux horaires.
• Pas de type binaire — Base64 dans une chaîne (avec coût de taille) ou endpoints binaires séparés.
• Pas de schéma imposé par le format — JSON Schema, OpenAPI ou validateurs maison.
• Pas de commentaires ni métadonnées en JSON strict — champs adjacents comme "_comment" si besoin (et documentez la convention).
• Clés dupliquées dans les objets : la RFC 8259 dit que les noms devraient être uniques ; les analyseurs peuvent diverger sur la valeur gagnante — ne comptez pas sur les doublons.

JSON annoté : forme valide vs erreurs de collage courantes

Le bloc ci-dessous est du JSON strict valide — notez les clés entre guillemets doubles, pas de commentaires, pas de virgule finale après la dernière propriété. Beaucoup de fichiers « JSON » dans les dépôts sont en réalité du JSON5 ou des littéraux JavaScript ; les coller dans un validateur strict échoue pour des raisons prévisibles signalées ensuite.

{
  "data": {
    "id": "usr_8f2a",
    "email": "dev@example.com",
    "roles": ["reader", "editor"]
  },
  "meta": {
    "requestId": "req_91bc",
    "cached": false
  }
}

Envelopper les ressources dans data plus meta est un motif récurrent : data porte la ressource, meta porte la pagination, les identifiants de traçage ou les indices de rate-limit sans polluer l’objet métier.

{
  // TODO: remove before prod
  "data": {
    "id": "usr_8f2a",
    "email": "dev@example.com",
    "roles": ["reader", "editor",],
  },
  "meta": { "requestId": "req_91bc", "cached": false }
}

Le formateur et le validateur JSON de SmartKitio appliquent les mêmes règles strictes que les API de production — pour prettifier, minifier et attraper les erreurs de syntaxe en local avant qu’une charge n’atteigne un serveur de staging.