En bref : JSON a une grammaire petite et stricte — les erreurs qui cassent un analyseur (virgules finales, clés non guillemetées, guillemets simples) sont invisibles dans les données minifiées mais évidentes une fois formatées. Connaître les vraies règles de syntaxe transforme "l'API a renvoyé une erreur" en une correction de deux secondes. Associez ce guide à Encoding Converter, Character Counter, Text Difference et AI Hidden Characters.

Formater du JSON consiste à ajouter des espaces et une indentation pour rendre sa structure lisible ; le valider consiste à vérifier que cette structure suit réellement la grammaire définie dans RFC 8259. Le JSON minifié — la forme compacte sans espaces que les API transmettent réellement — est correct mais illisible ; un formateur inverse cela sans changer les données.

Les règles de syntaxe qui comptent vraiment

Les clés JSON doivent être des chaînes entre guillemets doubles — {name: "valeur"} n'est pas valide, seul {"name": "valeur"} s'analyse correctement. Les guillemets simples ne sont jamais valides pour les chaînes ou les clés, contrairement aux littéraux objet JavaScript, que la syntaxe de JSON restreint délibérément. Une virgule finale après le dernier élément d'un tableau ou objet — ["a", "b",] — est du JSON invalide, même si c'est inoffensif (voire requis par convention) dans d'autres langages, et c'est l'une des raisons les plus fréquentes pour lesquelles du JSON édité à la main échoue à s'analyser.

Pourquoi "ça a l'air correct" n'est pas la même chose que valide

Un document JSON peut être visuellement indiscernable d'un valide et pourtant échouer à s'analyser — une accolade fermante manquante à la fin d'une grande structure imbriquée, un guillemet typographique () collé depuis un traitement de texte au lieu d'un guillemet droit ", ou un commentaire égaré (JSON n'a aucune syntaxe de commentaire, contrairement à JSON5 ou JSONC) casseront tous un analyseur strict tout en semblant corrects au premier coup d'œil. C'est exactement pourquoi formater avant de regarder aide : une indentation correcte rend une accolade non fermée visuellement évidente en brisant le motif d'imbrication attendu.

Formatage vs validation de schéma

Un formateur vérifie que le JSON est syntaxiquement valide — accolades équilibrées, chaînes correctement guillemetées, pas de virgule finale. Il ne vérifie pas si les données ont un sens : si un champ censé être un nombre est en fait une chaîne, ou si un champ requis est manquant. C'est une préoccupation distincte, gérée par la validation JSON Schema, qui vérifie structure et types par rapport à une définition de schéma plutôt que de simplement vérifier que le JSON lui-même est bien formé.

Un flux de travail pour du JSON désordonné ou cassé

  1. Collez d'abord le JSON brut — minifié, cassé, ou autre — dans un formateur.
  2. S'il s'analyse, examinez la structure indentée pour trouver le champ ou la valeur que vous cherchez réellement.
  3. S'il échoue à s'analyser, vérifiez d'abord l'emplacement de l'erreur : la plupart des analyseurs signalent une ligne/colonne, qui pointe généralement directement vers une virgule, accolade ou guillemet manquant.
  4. Surveillez particulièrement les virgules finales et les guillemets typographiques quand la source a été saisie à la main ou collée depuis un éditeur non-code.

Erreurs courantes à éviter

  • Supposer qu'une indentation qui semble valide signifie du JSON valide — formatage et analyse sont des étapes distinctes.
  • Ajouter une virgule finale par habitude venant de JavaScript ou Python, où elle est souvent tolérée.
  • Coller du JSON depuis un traitement de texte et obtenir des guillemets typographiques courbes au lieu de droits.
  • Confondre "se formate sans erreur" avec "correspond au schéma attendu par l'API" — ce sont des vérifications différentes.

La plupart des erreurs JSON tiennent à un caractère précis à un endroit précis — la vraie valeur d'un formateur est de rendre cet endroit visible plutôt que de vous laisser scruter une seule ligne ininterrompue pour le trouver.