Douglas Crockford et JSON : pourquoi toutes les applications le parlent

JSON en clair : ce que c'est et pourquoi ça compte

JSON (JavaScript Object Notation) est une manière légère de représenter des données sous forme de texte brut en utilisant des paires clé–valeur et des listes.

Si vous développez des applications web — même si vous ne pensez pas beaucoup aux « formats de données » — JSON est probablement déjà la colle qui tient votre produit ensemble. C'est la façon dont un frontend demande des données, dont un backend répond, dont les applications mobiles synchronisent l'état, et dont les services tiers envoient des événements. Quand le JSON est clair et cohérent, les équipes livrent plus vite ; quand il est désordonné, chaque fonctionnalité prend plus de temps parce que tout le monde se dispute sur ce que les données « signifient ».

Un petit exemple

Voici un petit objet JSON que vous pouvez lire en un coup d'œil :

{
  "userId": 42,
  "name": "Sam",
  "isPro": true,
  "tags": ["beta", "newsletter"]
}

Même sans contexte technique, on peut généralement deviner : un utilisateur a un identifiant, un nom, un drapeau d'état et une liste de labels.

Ce que vous tirerez de cet article

Vous apprendrez :

• D'où vient JSON et comment il est devenu grand public (y compris le rôle de Douglas Crockford)
• Pourquoi son design « minimal » est en grande partie la raison de son succès
• Pourquoi JSON s'intègre si naturellement aux API et à HTTP
• Des conseils pratiques pour bien utiliser JSON — afin que les payloads restent compréhensibles à mesure que votre application grandit

L'objectif est simple : vous aider à comprendre non seulement ce qu'est JSON, mais pourquoi presque toutes les applications « le parlent » — et comment éviter les erreurs courantes que les équipes répètent encore.

Le rôle de Douglas Crockford dans la démocratisation de JSON

Douglas Crockford n'a pas « inventé » toutes les idées derrière JSON, mais il a fait quelque chose d'aussi important : il a rendu un modèle simple et fonctionnel visible, lui a donné un nom et l'a poussé dans le grand public.

Le problème du web naissant : l'échange de données était chaotique

Aux débuts des applications web, les équipes jonglaient avec des options maladroites pour transférer des données entre le navigateur et le serveur. XML était courant mais verbeux. Des formats personnalisés basés sur des délimiteurs étaient compacts mais fragiles. JavaScript pouvait techniquement évaluer des données comme du code, mais cela brouillait la frontière entre « données » et « script exécutable », ce qui ouvrait la porte aux bugs et aux problèmes de sécurité.

Crockford a vu une voie plus propre : utiliser un petit sous-ensemble de la syntaxe littérale JavaScript capable de représenter des données simples de manière fiable — objets, tableaux, chaînes, nombres, booléens et null — sans fonctionnalités superflues.

Nommer, documenter et offrir « une page à pointer »

Une des plus grandes contributions de Crockford fut sociale, pas seulement technique : il l'a appelé JSON (JavaScript Object Notation) et a publié une documentation claire sur json.org. Cela a donné aux équipes un vocabulaire partagé (« on envoie du JSON ») et une référence suffisamment courte pour être lue et assez stricte pour être implémentée.

Il a aussi promu JSON comme format de données indépendant de JavaScript en tant que langage : de nombreux langages pouvaient le parser et le générer, et il se mappait naturellement aux structures de données courantes.

Des jalons de standardisation auxquels on pouvait faire confiance

L'adoption s'accélère quand les équipes se sentent en sécurité à parier sur un format sur le long terme. JSON a progressivement gagné ce statut de « pari sûr » grâce à des jalons largement connus :

• RFC 4627 (2006) : description formelle initiale pour des implémentations interopérables
• ECMA-404 : une norme concise définissant la syntaxe JSON
• RFC 7159 puis RFC 8259 (2017) : clarifications sur l'interopérabilité et confirmation de la place de JSON sur Internet

Le plaidoyer de Crockford, combiné à ces standards et à un écosystème croissant de parseurs, a aidé JSON à passer d'une convention pratique au moyen par défaut de communication entre applications — en particulier via des API HTTP (développé plus loin dans /blog/json-and-apis).

Avant JSON : les formats de données que le web essayait de supporter

Avant que JSON devienne le moyen par défaut de déplacer des données, le web s'appuyait sur un mélange de formats soit trop lourds, soit trop incohérents, soit trop personnalisés pour être adoptés à grande échelle.

Ce qu'on utilisait avant JSON

XML était le grand choix « standard ». Il fonctionnait entre les langages, disposait d'outils et pouvait représenter des structures imbriquées. Il apportait cependant beaucoup de cérémonial.

En même temps, de nombreuses applications passaient des données sous forme de chaînes de requête personnalisées (surtout dans les premières requêtes AJAX) : paires clé/valeur dans les URL ou le corps POST. D'autres inventaient des formats texte ad‑hoc — listes séparées par des virgules ici, blobs délimités par des pipes là — souvent avec des règles d'échappement faites à la main qu'un seul développeur comprenait.

Les points douloureux récurrents

Les problèmes communs n'étaient pas théoriques :

• Verbosité : XML faisait paraître les petits payloads gros, et les gros payloads énormes.
• Complexité du parsing : le XML en conditions réelles nécessitait souvent des parseurs plus lourds et une gestion fine des espaces de noms, attributs vs éléments, et espaces blancs.
• Conventions inconsistantes : avec des formats ad‑hoc, chaque endpoint devenait son propre mini‑protocole. Les clients devaient deviner les types, l'encodage et les cas limites.

Pourquoi « assez bon et simple » gagne

La plupart des applications n'ont pas besoin d'un format capable d'exprimer toutes les structures possibles. Elles ont besoin d'un moyen prévisible d'envoyer des objets, des tableaux, des chaînes, des nombres et des booléens — rapidement, de manière cohérente et avec peu d'ambiguïté. Les formats plus simples réduisent le nombre de décisions (et d'erreurs) que les équipes doivent prendre pour chaque endpoint.

Une comparaison rapide : XML vs JSON

\u003cuser\u003e
  \u003cid\u003e42\u003c/id\u003e
  \u003cname\u003eAda\u003c/name\u003e
  \u003cisActive\u003etrue\u003c/isActive\u003e
\u003c/user\u003e

{
  "id": 42,
  "name": "Ada",
  "isActive": true
}

Les deux expriment la même idée, mais JSON est plus facile à parcourir visuellement, plus simple à générer et plus proche de la manière dont la plupart des applications modélisent déjà les données en mémoire.

Pourquoi JSON est minimal : les choix de conception qui ont marché

La longévité de JSON n'est pas un accident. Il réussit parce qu'il est volontairement petit : juste assez de structure pour représenter des données applicatives réelles sans inviter une variation infinie.

L'ensemble d'éléments utiles le plus petit

JSON vous donne une boîte à outils minimale qui se mappent proprement à la manière dont la plupart des applications pensent les données :

• Objets : champs nommés (comme un contact avec name, email)
• Tableaux : listes ordonnées (comme des articles dans un panier)
• Chaînes : texte
• Nombres : valeurs numériques (avec quelques réserves)
• Booléens : true/false
• null : une « absence de valeur » explicite

C'est tout. Pas de dates natives, pas de commentaires, pas de types numériques personnalisés, pas de références. Cette simplicité rend JSON facile à implémenter dans tous les langages et plateformes.

Lisible par l'humain, efficace pour la machine — par conception

JSON est suffisamment lisible pour que les humains puissent l'inspecter rapidement dans les logs et les réponses d'API, tout en restant facile à parser rapidement pour les machines. Il évite le cérémonial inutile mais garde des délimiteurs clairs ({}, [], :) pour que les parseurs soient rapides et fiables.

Le compromis : parce que JSON est si minimal, les équipes doivent se mettre d'accord sur des conventions pour des éléments comme les timestamps, l'argent et les identifiants (par exemple, utiliser des chaînes ISO‑8601 pour les dates).

La stricteur est une fonctionnalité, pas une limitation

Les règles strictes de JSON (chaînes entre guillemets doubles, pas de virgules finales, un petit ensemble de types) réduisent l'ambiguïté. Moins d'ambiguïté veut dire moins d'échecs « ça marche sur ma machine » quand différents systèmes échangent des données.

Une idée fausse à lever

JSON ressemble à la syntaxe d'objet JavaScript, mais JSON n'est pas JavaScript. C'est un format de données agnostique au langage, utilisable depuis Python, Java, Go, Ruby et partout ailleurs où l'on a besoin de sérialisation cohérente et d'interopérabilité.

Comment JSON est devenu le choix par défaut entre frontends et backends

JSON n'a pas gagné parce que c'était le format le plus riche en fonctionnalités. Il a gagné parce qu'il correspondait à la manière dont les applications web étaient déjà construites : un navigateur lourdement JavaScript parlant à un serveur via des requêtes HTTP simples.

JavaScript était déjà présent sur chaque page

Dès que les navigateurs se sont standardisés autour de JavaScript, le côté client disposait d'un moyen natif de représenter des données structurées : objets, tableaux, chaînes, nombres, booléens et null. JSON reflétait étroitement ces primitives, donc transférer des données entre « ce que comprend le navigateur » et « ce que renvoie le serveur » semblait naturel.

Les premières applications de type Ajax ont accéléré cela. Plutôt que de renvoyer des pages HTML complètes, les serveurs pouvaient retourner un petit payload que l'UI rendrait. Une réponse comme celle‑ci était immédiatement utile :

{
  "user": {"id": 42, "name": "Sam"},
  "unreadCount": 3
}

Parsing facile partout, pas seulement dans les navigateurs

Même si la syntaxe JSON ressemble à JavaScript, elle est neutre vis‑à‑vis du langage. Dès que des serveurs et clients dans d'autres langages ont dû interopérer avec des frontends web, des bibliothèques JSON sont apparues — et sont rapidement devenues « équipement standard ». Parser une chaîne JSON en structures natives est généralement un appel de fonction, et générer du JSON est tout aussi simple.

L'effet boule de neige des outils

Une fois que frameworks, clients d'API, débogueurs, proxies et outils de documentation ont supposé JSON, choisir autre chose créait de la friction. Les développeurs pouvaient inspecter les payloads dans les outils devtools du navigateur, coller des exemples dans des tests et compter sur des bibliothèques matures pour l'encodage, le décodage et la gestion des erreurs.

Un payload, plusieurs consommateurs

Une seule réponse JSON peut servir une interface web, une application mobile, un service interne et une intégration tierce avec peu ou pas de modifications. Cette interopérabilité a fait de JSON un pari sûr pour les équipes qui construisent « un backend, plusieurs frontends » — et a contribué à en faire le contrat par défaut entre client et serveur.

JSON et les API : l'ajustement pratique avec HTTP

JSON n'a pas gagné parce qu'il était sophistiqué — il s'insérait proprement dans le fonctionnement actuel du web. HTTP est fondé sur l'envoi d'une requête et la réception d'une réponse, et JSON est un moyen simple et prévisible de représenter le « corps » de cette réponse (ou requête) comme des données structurées.

HTTP + JSON en une minute

Une requête d'API inclut généralement une méthode et une URL (par exemple, GET /users?limit=20). Le serveur répond par un code de statut (comme 200 ou 404), des en‑têtes et un corps optionnel.

Quand le corps est du JSON, un en‑tête clé est :

• Content-Type: application/json

Cet en‑tête indique aux clients comment interpréter les octets reçus. À l'aller (client → serveur), envoyer Content-Type: application/json signifie « je poste du JSON », et les serveurs peuvent le parser de manière cohérente.

Schémas de réponse API courants

JSON fonctionne particulièrement bien pour les motifs récurrents dans les API.

Pagination enveloppe souvent une liste avec des métadonnées :

{
  "data": [{"id": 1, "name": "A"}],
  "pagination": {"limit": 20, "offset": 0, "total": 153}
}

Filtrage et tri se font généralement dans la chaîne de requête URL, tandis que les résultats restent un tableau JSON (ou un champ data). Par exemple : GET /orders?status=paid&sort=-created_at.

Les réponses d'erreur bénéficient d'une forme standard pour que les clients puissent afficher des messages et gérer les retrys :

{
  "error": {
    "code": "invalid_request",
    "message": "limit must be between 1 and 100",
    "details": {"field": "limit"}
  }
}

La correspondance pratique est simple : HTTP fournit la livraison et le sens (verbes, codes de statut, cache), tandis que JSON offre une structure légère et lisible pour les données elles‑mêmes.

JSON vs XML : pourquoi JSON l'emporte généralement pour les données applicatives

Quand on compare JSON et XML, on compare souvent « données pour applications » versus « documents ». Les deux formats peuvent représenter des informations structurées, mais JSON tend à correspondre à ce que la plupart des applications manipulent réellement : objets simples, listes, chaînes, nombres, booléens et null.

Lisibilité et taille : moins de balises, moins de bruit

XML est verbeux par conception. La répétition des balises d'ouverture et de fermeture rend les payloads plus volumineux et plus difficiles à scanner dans les logs ou les inspecteurs réseau. JSON transmet généralement la même signification avec moins de caractères et moins d'encombrement visuel, ce qui aide lors du débogage et peut réduire les coûts de bande passante à grande échelle.

Ce n'est pas qu'une question d'esthétique : des payloads plus petits signifient souvent des transferts plus rapides et moins de travail pour les parseurs et les proxies.

Alignement du modèle de données : maps et listes correspondent aux données applicatives

La plupart des données applicatives ressemblent naturellement à des dictionnaires (maps clé/valeur) et des tableaux (listes) : un utilisateur avec des attributs, une commande avec des lignes, une page avec des composants. JSON se mappe directement sur ce modèle mental et sur les structures natives en JavaScript et dans la plupart des langages modernes.

XML peut représenter les mêmes structures, mais demande souvent des conventions : attributs vs éléments, éléments enfants répétés pour les listes et des règles supplémentaires pour déterminer « ce qui compte comme un nombre » (puisque tout est du texte à moins d'ajouter du typage).

Où XML peut encore briller (sans le ridiculiser)

XML reste fort pour les cas d'usage centrés sur les documents : contenu mixte (texte entrecoupé de balisage), workflows de publication et écosystèmes avec des outils XML matures (par exemple, certaines intégrations d'entreprise). Si votre payload ressemble davantage à un document qu'à un graphe d'objets, XML peut être un meilleur choix.

Conseils : choisissez selon les besoins, pas la mode

Si votre objectif principal est d'échanger des données applicatives entre frontend, backend et API, JSON est généralement le choix le plus simple et le plus direct. Si vous avez besoin de balisage documentaire, de contenu mixte ou si vous êtes intégré dans un domaine fortement orienté XML, XML peut rester l'outil adapté.

Règles JSON qui surprennent encore les équipes

JSON ressemble à des « objets JavaScript », donc les équipes supposent souvent qu'elles peuvent le traiter comme du JavaScript. C'est là que les bugs s'infiltrent : JSON est plus strict, plus petit et moins permissif.

Les règles syntaxiques strictes

Quelques problèmes « ça marche chez moi » reviennent sans cesse :

• Les guillemets doubles sont obligatoires pour les clés et les valeurs de type chaîne. {name: "Ada"} n'est pas du JSON ; { "name": "Ada" } l'est.
• Pas de virgules finales. { "a": 1, } échouera dans de nombreux parseurs.
• Pas de commentaires. // et /* ... */ sont invalides. Si vous avez besoin de notes, gardez‑les dans la documentation ou utilisez un champ séparé (avec prudence) pendant le développement.

Ces contraintes sont intentionnelles : elles gardent les parseurs simples et cohérents entre les langages.

Nombres, dates et décimales : choisissez les types délibérément

JSON n'a qu'un seul type numérique : number. Il n'y a pas d'entier natif, ni de décimal de précision, ni de date.

• Argent et décimales haute précision (prix, taux de change) sont souvent plus sûrs en chaînes (par ex. "19.99") pour éviter des différences d'arrondi entre systèmes.
• Dates et heures devraient généralement être des chaînes dans un format standard, le plus courant étant ISO 8601 (ex. "2025-12-26T10:15:30Z"). Évitez les formats de date personnalisés qui demandent des suppositions.
• Faites attention aux entiers très grands : certains environnements ne peuvent pas les représenter précisément. En cas de doute, envoyez‑les sous forme de chaînes.

Unicode et échappement dans les systèmes réels

JSON est Unicode, mais les systèmes réels trébuchent encore sur l'encodage et l'échappement :

• Assurez‑vous que tout est systématiquement en UTF-8 sur le réseau.
• Rappelez‑vous que certains caractères doivent être échappés dans les chaînes (comme les guillemets " et les barres obliques inverses \\).
• Méfiez‑vous des caractères invisibles copiés depuis des documents (espaces insécables, guillemets typographiques) qui peuvent casser le parsing.

Sécurité : parsez JSON en toute sécurité

Parsez toujours JSON avec un vrai parseur JSON (JSON.parse ou l'équivalent dans votre langage). Évitez toute approche de type eval, même si elle « semble plus rapide ». Et validez les entrées aux frontières — surtout pour les API publiques — afin que des champs ou types inattendus n'atteignent pas la logique métier.

Concevoir des payloads JSON qui vieillissent bien

Un payload JSON n'est pas juste des « données en transit » — c'est une interface à long terme entre des équipes, des systèmes et le futur vous. La différence entre un payload qui tient et un payload qui est réécrit chaque trimestre tient généralement à une discipline ennuyeuse : cohérence, gestion du changement et cas limites prévisibles.

La cohérence vaut mieux que l'ingéniosité

Choisissez des règles de nommage et tenez‑vous y partout :

• Utilisez un seul style de casse (généralement camelCase ou snake_case) et ne mélangez pas.
• Gardez les clés stables. Renommer userId en id est une rupture même si le sens semble « évident ».
• Préférez des champs explicites plutôt que la « polymorphie magique ». Une clé qui change de type ("count": 3 vs "count": "3") provoquera des bugs difficiles à tracer.

Versionner sans drame

Vous pouvez éviter la plupart des guerres de versions en faisant des changements additifs :

• Ajoutez de nouveaux champs optionnels plutôt que de modifier ou supprimer les existants.
• Traitez les suppressions comme des dépréciations : conservez l'ancien champ, arrêtez de le documenter pour les nouveaux clients et annoncez une date de retrait.
• Si vous devez vraiment faire un changement cassant, versionnez l'endpoint (/v2/...) ou incluez un signal de version clair dans un en‑tête — ne changez pas silencieusement la sémantique.

Les erreurs devraient être ennuyeusement prévisibles

Les clients gèrent mieux les échecs quand les erreurs partagent une forme unique :

{
  "error": {
    "code": "INVALID_ARGUMENT",
    "message": "email must be a valid address",
    "details": { "field": "email" }
  }
}

Documentation qui reflète la réalité

Une bonne documentation JSON inclut des exemples réels — réponses réussies et en échec — avec tous les champs. Gardez les exemples synchronisés avec le comportement en production et précisez quels champs sont optionnels, nullable ou dépréciés. Quand les exemples correspondent aux réponses réelles, les intégrations vont plus vite et cassent moins.

Où Koder.ai s'insère (si vous développez des API rapidement)

Si vous utilisez un workflow de type vibe‑coding pour lancer rapidement de nouvelles fonctionnalités, les contrats JSON deviennent encore plus importants : l'itération rapide est excellente jusqu'à ce que clients et services dérivent.

Sur Koder.ai, les équipes génèrent souvent un frontend React plus un backend Go + PostgreSQL puis itèrent sur les formes d'API en planning mode avant de les verrouiller. Des fonctionnalités comme les snapshots et rollback aident quand un petit changement JSON se révèle cassant, et l'export du code source facilite le maintien du contrat dans votre dépôt et son application via des tests.

Validation et contrats : JSON Schema et au‑delà

JSON est facile à générer, ce qui est à la fois une force et un piège. Si un service envoie "age": "27" (chaîne) et qu'un autre attend 27 (nombre), rien dans JSON lui‑même ne l'empêchera. Le résultat est souvent le pire type de bug : un plantage client en production, ou un dysfonctionnement subtil qui n'arrive qu'avec certaines données.

Pourquoi la validation compte (même pour un JSON « simple »)

La validation consiste à attraper des données mauvaises ou inattendues avant qu'elles n'atteignent les consommateurs — votre frontend, les intégrations partenaires, le pipeline analytique ou les applications mobiles.

Les points d'échec courants incluent des champs requis manquants, des clés renommées, des types erronés et des valeurs « presque correctes » (comme des dates dans des formats incohérents). Une petite étape de validation à la frontière de l'API peut transformer ces problèmes en messages d'erreur clairs plutôt qu'en pannes.

JSON Schema : ce que c'est et quand l'utiliser

JSON Schema est une manière standard de décrire à quoi votre JSON doit ressembler : propriétés requises, types autorisés, enums, patterns, etc. Il est surtout utile quand :

• Vous avez plusieurs clients (web + mobile + partenaires) consommant la même API
• Vous avez besoin de changements rétrocompatibles dans le temps
• Vous voulez des vérifications automatisées dans CI/CD, pas seulement une revue humaine

Avec un schéma, vous pouvez valider les requêtes côté serveur, valider les réponses dans les tests et générer de la documentation. Beaucoup d'équipes le couplent à leurs docs API (souvent via OpenAPI), de sorte que le contrat est explicite plutôt que « savoir tribale ». Si vous publiez déjà de la documentation développeur, lier des exemples de schéma depuis /docs permet de garder les choses cohérentes.

Alternatives légères (et complémentaires)

Toutes les équipes n'ont pas besoin d'outillage complet de schéma dès le jour 1. Options pratiques :

• Exemples de payloads partagés dans le repo (fichiers golden)
• Tests de contrat qui vérifient que les réponses réelles correspondent aux attentes
• Contrats pilotés par le consommateur (les clients définissent ce dont ils ont besoin)

Règle utile : commencez par des exemples et des tests de contrat, puis ajoutez JSON Schema quand les changements et les intégrations commencent à se multiplier.

Performance et fiabilité avec JSON à l'échelle

JSON semble « léger » quand vous envoyez quelques champs. À l'échelle — clients mobiles sur réseaux instables, API à fort trafic, pages analytiques lourdes — JSON peut devenir un problème de performance ou de fiabilité si vous ne le façonnez pas et ne l'envoyez pas avec soin.

Gardez les payloads petits : paginez, filtrez et évitez l'overfetching

Le problème d'échelle le plus courant n'est pas le parsing JSON, mais l'envoi de trop de données.

La pagination est la victoire simple : retournez des morceaux prévisibles (par exemple limit + cursor) pour que les clients ne téléchargent pas des milliers d'enregistrements d'un coup. Pour les endpoints qui retournent des objets imbriqués, envisagez des réponses partielles : laissez le client demander uniquement ce dont il a besoin (champs sélectionnés ou expansions « include »). Cela évite l'« overfetching », où un écran n'a besoin que de name et status mais reçoit tout l'historique et toutes les configurations.

Règle pratique : concevez les réponses autour des actions utilisateur (ce dont un écran a besoin maintenant), pas autour de ce que votre base de données peut joindre.

Compression et cache : moins d'octets, moins de requêtes

Si votre API sert de grandes réponses JSON, la compression réduit fortement la taille des transferts. De nombreux serveurs gèrent gzip ou brotli automatiquement, et la plupart des clients le supportent sans code supplémentaire.

Le cache est l'autre levier. En gros, visez :

• Réponses cacheables pour les données qui ne changent pas chaque seconde
• Règles de cache claires (par ex. ETag ou patterns « last modified »)

Cela réduit les téléchargements répétés et lisse les pics de trafic.

Streaming et parsing incrémental (quand JSON devient énorme)

Pour des sorties très volumineuses — exports, flux d'événements, synchronisations en masse — envisagez des réponses en streaming ou un parsing incrémental pour que les clients n'aient pas à charger tout un document en mémoire avant de pouvoir faire quelque chose d'utile. Ce n'est pas nécessaire pour la plupart des applis, mais c'est une option précieuse quand « un gros blob JSON » commence à expirer.

Observabilité : journalisez en toute sécurité sans exposer de données

JSON est facile à logger, ce qui est à la fois utile et dangereux. Traitez les logs comme une interface produit :

• Évitez de logger les corps de requête/réponse entiers par défaut
• Redactez les champs sensibles (tokens, mots de passe, identifiants personnels)
• Préférez des logs structurés qui capturent IDs, durées et codes d'erreur plutôt que des payloads bruts

Bien fait, vous déboguerez plus vite tout en réduisant le risque d'exposition accidentelle de données.

Et après pour JSON — et une checklist simple de bonnes pratiques

JSON n'est pas « fini » — il est stable. Ce qui évolue maintenant, c'est l'écosystème autour : éditeurs plus puissants, meilleure validation, contrats d'API plus sûrs et des outils qui aident les équipes à éviter des changements cassants accidentels.

Où va JSON

JSON restera probablement le format par défaut pour la plupart des applications web et mobiles parce qu'il est largement supporté, facile à déboguer et s'aligne bien sur les structures de données courantes.

Le plus grand changement est la montée des API typées : les équipes continuent d'envoyer du JSON, mais le définissent plus précisément via des outils comme JSON Schema, OpenAPI et des générateurs de code. Cela signifie moins de moments « devine la forme », une meilleure autocomplétion et une détection d'erreurs plus précoce — sans abandonner JSON.

Formats apparentés : JSON Lines / NDJSON

Quand vous devez envoyer ou stocker beaucoup d'enregistrements efficacement (logs, événements analytiques, exports), un grand tableau JSON peut être peu pratique. JSON Lines (aussi appelé NDJSON) résout cela en mettant un objet JSON par ligne. Il se stream bien, peut être traité ligne par ligne et fonctionne bien avec les outils en ligne de commande.

Une checklist simple de bonnes pratiques

Utilisez ceci comme contrôle rapide avant de déployer des payloads qui vivront plus longtemps qu'un sprint :

• Gardez les clés cohérentes et prévisibles (choisissez un style de nommage et tenez‑vous y).
• Préférez des identifiants stables (ne faites pas dépendre les clients de positions dans un tableau).
• Utilisez des timestamps ISO 8601 (ex. 2025-12-26T10:15:00Z).
• Distinguez « manquant » vs « vide » vs null et documentez votre choix.
• Versionnez avec soin (ajoutez des champs librement ; supprimez/renommez seulement avec un plan).
• Validez aux frontières (validation côté serveur ; vérifications basiques côté client).
• Retournez des erreurs utiles (codes machine + texte lisible par l'humain).

Continuez d'apprendre

Si vous voulez aller plus loin, parcourez les guides connexes sur /blog — en particulier des sujets comme la validation de schémas, le versionnage d'API et la conception de payloads pour la compatibilité à long terme.