Ouvrir une application météo, un tableau de bord IoT ou un terminal de paiement en ligne. Derrière l’écran, presque tout circule dans le même format texte, avec ses accolades et ses paires clé/valeur.
Né de JavaScript, ce format se lit aujourd’hui dans la quasi-totalité des langages de programmation. Encore faut-il maîtriser sa syntaxe stricte et éviter le piège des données imbriquées ou encodées deux fois, qui font dérailler tant de parseurs.
En bref
Ce format texte est normalisé par ECMA-404 et la RFC 8259.
Sa syntaxe repose sur des paires clé/valeur et six types de valeurs.
Un objet peut en contenir un autre, ou une chaîne déjà encodée.
Depuis ES2025, JavaScript importe ces fichiers nativement.
Le format texte qui fait parler les applications entre elles
JSON signifie JavaScript Object Notation. C’est un format texte léger, lisible par un humain et trivial à analyser pour une machine.
Sa syntaxe vient de JavaScript, mais sa grammaire n’appartient à aucun langage. Python, Java, Go, PHP ou C# le lisent sans effort.
Sur le terrain, cette notation sert surtout de langue commune aux échanges client-serveur. Presque chaque appel à une API REST renvoie sa réponse sous cette forme. Les capteurs des objets connectés s’en servent aussi pour remonter leurs mesures vers le cloud.
Les bases de données ont suivi le mouvement. PostgreSQL stocke ces documents en binaire dans ses colonnes jsonb, et MongoDB les enregistre au format BSON.
Une syntaxe simple en apparence, intransigeante dans les faits
Pour écrire un fichier valide, il faut respecter la syntaxe à la lettre. Chaque objet repose sur deux briques, les clés et les valeurs. Ensemble, elles forment une paire clé/valeur.
Les clés sont toujours des chaînes de caractères entourées de guillemets doubles. Les guillemets simples sont refusés.
Les valeurs appartiennent à l’un des six types autorisés. Ce sont des chaînes, des nombres, des booléens, des tableaux, des objets ou la valeur null.
Un objet s’ouvre et se ferme par des accolades {}. Il contient zéro, une ou plusieurs paires clé/valeur, séparées par des virgules. Chaque clé est suivie de deux-points, qui la séparent de sa valeur.
Et la moindre virgule après le dernier élément suffit à rendre tout le fichier invalide. Le format ne pardonne pas ce que JavaScript tolère.
Voici un exemple complet, tel qu’un thermostat connecté pourrait l’envoyer à son serveur.
Chaîne : une suite de zéro ou plusieurs caractères Unicode entre guillemets doubles. Les caractères spéciaux s’échappent avec une barre oblique inverse.
Nombre : un entier ou un décimal, avec un exposant éventuel. Les valeurs NaN et Infinity n’existent pas dans ce format.
Booléen : true ou false, sans guillemets et en minuscules.
Null : la valeur null signale l’absence d’information.
Tableau : une collection ordonnée de valeurs entre crochets [], séparées par des virgules. Un tableau accepte des objets, d’autres tableaux ou des types mélangés.
Objet : un ensemble non ordonné de paires clé/valeur entre accolades. Seules les clés exigent des guillemets, car chaque valeur suit les règles de son propre type.
Ces deux derniers types ouvrent la porte à l’imbrication des données. Un objet peut en contenir un autre, qui en contient lui-même un troisième. Et c’est là que les ennuis commencent.
JSON of JSON : imbriquer des objets sans tomber dans le double encodage
Derrière cette expression se cachent deux réalités très différentes. L’une est saine. L’autre fait perdre des après-midi entières au débogage.
La première, c’est l’objet imbriqué. Une valeur contient un autre objet, comme « position » dans l’exemple du thermostat. Le parseur lit tout en une passe, et data.position.etage donne directement l’étage.
La seconde, c’est l’objet stringifié, glissé dans un autre sous forme de texte. Le contenu interne n’a plus rien d’un objet. C’est une simple chaîne, truffée de guillemets échappés.
Ce cas surgit souvent dans les files de messages, les journaux applicatifs ou certains événements cloud. Un premier appel à la méthode parse() rend l’enveloppe. Mais payload n’est encore que du texte, et il faudra un second appel pour atteindre la température.
Pour éviter ce double emballage accidentel, trois réflexes suffisent :
Sérialisez l’objet complet une seule fois, au moment de l’envoi.
Ne repassez jamais le résultat de stringify() dans un second stringify().
Si un service tiers impose une chaîne encodée, décodez-la dès la réception et validez-la aussitôt.
Charger et manipuler ces données, du navigateur au serveur
Oubliez $.ajax() et jQuery. En JavaScript moderne, deux méthodes natives font l’essentiel du travail. parse() transforme un texte en objet, et stringify() fait le chemin inverse.
Exemple pratique : interroger une API avec fetch()
Prenons le cas le plus courant, l’appel à une API. La fonction fetch(), disponible dans tous les navigateurs récents comme dans les versions actuelles de Node.js, suffit largement.
La requête part vers l’API, puis le code vérifie le statut HTTP avant toute lecture. Ce contrôle évite d’analyser une page d’erreur HTML comme s’il s’agissait de données. Une méthode dédiée de l’objet Response décode alors le corps et livre un objet prêt à l’emploi.
Depuis ES2025, un fichier de configuration local s’importe même comme un module, sans fetch() ni bundler. Il suffit d’ajouter l’attribut d’import type au bout de l’instruction import.
Les bibliothèques à connaître selon votre langage
Côté serveur, chaque écosystème a ses outils pour sérialiser et désérialiser les données JSON. Le choix dépend surtout des performances visées et de la plateforme cible.
Python : un module natif fait partie de la bibliothèque standard. Quand la vitesse devient critique, orjson prend le relais.
Java : Jackson domine les projets d’entreprise. Gson, la bibliothèque de Google, fonctionne toujours, mais elle est passée en mode maintenance et n’accueillera plus de grosses nouveautés.
Go : le paquet de sérialisation est intégré à la bibliothèque standard. Go 1.25 en a ajouté en août 2025 une version 2 expérimentale.
C++ : la bibliothèque de Niels Lohmann séduit par sa simplicité, RapidJSON par sa rapidité.
JavaScript et TypeScript : parse() et stringify() sont natifs. Aucune dépendance n’est nécessaire.
Pourquoi ce format a supplanté XML dans les échanges web
Son succès se comprend mieux quand on remonte le fil de l’interactivité sur le Web. Tout commence avec des pages qui se rechargeaient à chaque clic.
Des pages rechargées à chaque clic aux échanges asynchrones
Au début des années 2000, le navigateur se contentait d’afficher ce que le serveur préparait. Chaque clic sur un lien ou un bouton déclenchait une requête. Le serveur renvoyait alors une page HTML complète.
Cette méthode était lente et gourmande. Le navigateur redessinait toute la page, même pour une seule ligne modifiée.
AJAX, JSONP puis CORS : comment la notation de Crockford a pris la main
Avec l’essor d’AJAX, les pages ont appris à charger des données en arrière-plan, de manière asynchrone. XML devait d’abord jouer ce rôle, d’où le X d’AJAX. Mais son concurrent, plus léger et lisible directement en JavaScript, l’a vite remplacé.
Pour contourner la politique de même origine des navigateurs, les développeurs ont longtemps bricolé JSONP. Cette astuce passait par une balise script et une fonction de rappel. Elle est aujourd’hui obsolète et déconseillée, car elle exécute du code tiers sans aucun contrôle.
Le standard CORS l’a remplacée. Le serveur déclare lui-même quels domaines ont le droit de lire ses réponses. Le navigateur, lui, fait respecter cette règle.
Les atouts qui ont fait gagner ce format
Moins verbeux : pas de balise fermante, pas d’attributs. Le même jeu de données pèse en général nettement moins lourd qu’en XML.
Rapide à analyser : sa grammaire se limite à quelques règles, et chaque langage dispose de parseurs très optimisés.
Lisible : un humain comprend la structure d’un coup d’œil, sans documentation.
Fidèle aux structures de données : objets et tableaux correspondent directement aux dictionnaires, listes et classes des langages modernes. Le modèle de données gagne en prévisibilité, même si les paires clé/valeur limitent certaines représentations.
Pratique en langage dynamique : en JavaScript ou en Python, une réponse d’API devient un objet manipulable en une seule instruction.
Face à XML, une ligne de code contre des dizaines
La principale alternative s’appelle XML. Il garde sa place dans les documents complexes, les flux RSS ou certains échanges bancaires. Pourtant, les nouveaux projets lui préfèrent la notation objet dans leur immense majorité.
La différence saute aux yeux au moment de l’analyse. Convertir du XML en objet JavaScript demande souvent un parseur dédié, puis une logique adaptée à chaque structure.
Ici, un seul appel à parse() suffit. Aucune connaissance préalable de l’objet analysé n’est nécessaire.
Les dates clés qui en ont fait un standard
Douglas Crockford a spécifié le format au début des années 2000, et son site officiel a été lancé en 2002. En décembre 2005, Yahoo! commence à proposer certains de ses services Web dans cette notation.
La normalisation suit. Le format devient la norme ECMA-404 en 2013. En 2017, la RFC 8259 de l’IETF, la deuxième édition d’ECMA-404 et la norme ISO/IEC 21778 consolident le tout, et ces textes font toujours foi en 2026.
Sa portée dépasse aujourd’hui le seul Web. Le protocole de messagerie JMAP, normalisé en 2019, s’appuie par exemple sur lui pour synchroniser les e-mails.
Concis et flexible, le format a pourtant quelques angles morts. Voici les quatre qui coûtent le plus cher en production :
Pas de schéma imposé : la liberté est totale, mais rien n’empêche d’envoyer des données mal formées. Un validateur de schéma sert justement à verrouiller la structure.
Aucun type date : les dates voyagent sous forme de chaînes. Sans convention commune, de préférence l’ISO 8601, les écarts de format s’accumulent.
Pas de commentaires : impossible d’annoter un champ dans le fichier. Des variantes comme JSONC ou JSON5 les acceptent, mais elles sortent de la norme.
Un seul type de nombre : la norme ne distingue ni entier, ni flottant, ni décimal. Beaucoup de parseurs, dont celui de JavaScript, convertissent tout en flottant 64 bits et perdent la précision des très grands entiers.
Typage strict : valider avant de faire confiance
En TypeScript, parse() renvoie le type any. Autrement dit, le compilateur ferme les yeux sur tout ce qui arrive d’une API ou d’un fichier externe.
La bonne pratique consiste à typer le résultat en unknown. Le code doit alors vérifier chaque champ avant de l’utiliser, sinon la compilation échoue.
Cette rigueur évite les bugs silencieux, ceux qu’un champ manquant ou un type inattendu déclenche des semaines plus tard. Pour automatiser la vérification, les équipes s’appuient sur Zod côté TypeScript, ou sur un schéma standardisé pour un contrat indépendant du langage.
Ce type de fichier s’ouvre avec n’importe quel éditeur de texte. Pour le lire confortablement ou traquer une erreur de syntaxe, mieux vaut toutefois un outil dédié.
JSONLint : un validateur open source qui signale la ligne fautive et reformate le code.
JSONEditorOnline : un outil web pour éditer, visualiser et formater ses données. Il les affiche côte à côte, en arbre et en code.
Minifier : un module qui supprime les espaces inutiles pour obtenir le fichier le plus léger possible.
JSONFormatter : il visualise, formate et valide un fichier, avec une détection des erreurs en temps réel.
Code Beautify : en plus du formatage, il convertit les données vers d’autres formats comme XML ou CSV.
BeautifyTools : une suite d’outils en ligne, dont un formateur pratique pour restructurer un fichier illisible.
jq : l’outil en ligne de commande de référence pour filtrer et transformer ces données depuis un terminal Linux, macOS ou Windows.
Les éditeurs de code comme VS Code formatent et valident aussi ce format nativement. Firefox intègre de son côté un visualiseur qui affiche les réponses d’API sous forme d’arbre. Sur mobile, plusieurs applications gratuites font l’affaire, avec une qualité très variable.
Sachez toutefois qu’en novembre 2025, la société watchTowr a exhumé des milliers d’identifiants et de clés d’API. Ils dormaient dans plus de 80 000 fichiers sauvegardés sur JSONFormatter et CodeBeautify. Ne collez jamais de données sensibles dans un formateur en ligne.
Cinq évolutions de 2025-2026 qui changent la pratique
La norme n’a pas bougé depuis 2017. Son écosystème, lui, avance vite, et cinq évolutions récentes modifient la façon de la manipuler au quotidien.
Évolution
Date
Ce que ça change
Import natif des fichiers de données (import attributes)
ES2025, juin 2025
Un fichier de configuration se charge comme un module JavaScript, sans fetch() ni bundler.
Nouveau paquet de sérialisation en Go
Go 1.25, août 2025
Une API expérimentale, plus stricte et plus performante au décodage.
Sorties structurées des modèles d’IA
OpenAI en 2024, Anthropic fin 2025
L’API génère une réponse conforme au schéma fourni, sans objet malformé.
Spécification de schéma v1
En développement en 2026
Première version stable avec garanties de compatibilité. La version 2020-12 fait toujours référence.
Gson en mode maintenance
Situation actuelle
Les projets Java et Android migrent vers Jackson, Moshi ou Kotlin Serialization.
La troisième ligne mérite qu’on s’y arrête. Les agents IA déployés en production échangent leurs appels d’outils dans ce format. Un schéma imposé dès la génération évite donc qu’une virgule manquante bloque toute une chaîne d’automatisation.
Côté infrastructure, Amazon Web Services comme Google Cloud Platform exposent leurs API et leurs journaux de cette façon. Savoir lire ces structures, y compris un objet encodé niché dans un événement, fait partie du minimum vital pour qui déploie dans le cloud.
Traitez chaque donnée reçue comme une donnée étrangère
Ce format a gagné parce qu’il est simple. Cette simplicité trompe pourtant. Sans schéma, sans type date et sans commentaires, il délègue toute la rigueur au développeur.
Validez donc chaque entrée, sérialisez une seule fois pour éviter le double encodage, et choisissez un parseur adapté à votre langage. Ces trois habitudes coûtent quelques lignes de code. Elles en économisent des centaines au débogage.
FAQ
Que signifie JavaScript Object Notation ?
JavaScript Object Notation est un format texte léger et indépendant du langage, normalisé par ECMA-404 et la RFC 8259. Il sert à échanger des données structurées entre applications, notamment via les API REST, les applications web et mobiles et les bases de données modernes.
Quelle différence avec XML ?
Les deux formats échangent des données structurées. La notation objet est plus compacte, sans balises fermantes, et se transforme en objet JavaScript en un seul appel. XML garde l’avantage pour les documents complexes, les attributs et certains échanges réglementés.
Ce format est-il sécurisé ?
Non, pas en lui-même, car il ne fait que transporter des données. Validez et nettoyez chaque entrée, utilisez parse() plutôt que eval() et choisissez des bibliothèques maintenues. Évitez aussi de coller des données sensibles dans un formateur en ligne.
Qu’est-ce qu’un JSON of JSON ?
L’expression désigne un objet contenu dans un autre. Il peut s’agir d’objets imbriqués, lus en une seule analyse, ou d’un objet encodé sous forme de chaîne de caractères. Dans ce second cas, il faut appeler parse() deux fois pour accéder aux données.
Comment ouvrir un fichier JSON ?
N’importe quel éditeur de texte suffit, comme le Bloc-notes ou VS Code. Pour une lecture plus confortable, Firefox l’affiche sous forme d’arbre. Des outils comme JSONLint ou JSONEditorOnline le formatent et le valident en quelques secondes.
