Vous pensez que votre JSON est correct parce que JSON.parse n’a rien renvoyé ? En réalité, être analysable ne veut pas dire que les données sont correctes. Que faites-vous lorsque le backend renvoie {user_id: 123} (clé non entourée de guillemets) ? L’API attend un champ email, mais vous ne voyez que mail ? Ce sont les trois couches de la validation JSON, et la plupart des tutoriels en ligne ne couvrent que la première. Résultat : des bugs silencieux en production, des champs undefined dans l’interface et des heures perdues à chercher l’origine du problème. Cet article détaille ces 3 couches, explique comment chacune s’attaque à un problème différent, et montre comment le formateur JSON de Piick repère l’emplacement exact des erreurs pour vous faire gagner du temps.

Les trois niveaux de la validation JSON

La validation comporte trois couches, et chacune résout un problème différent :

  • Couche syntaxique : la chaîne est-elle du JSON légal ? Les guillemets, les virgules et les crochets doivent tous correspondre. C’est ce que fait JSON.parse par défaut.
  • Couche structurelle : les données correspondent-elles à un schéma prédéfini ? user est-il un objet, tags est-il un tableau, les champs obligatoires sont-ils présents ? JSON Schema est la norme de facto à ce niveau.
  • Couche sémantique : les valeurs ont-elles du sens ? status appartient-il à un enum valide, age est-il compris entre 0 et 150, email a-t-il le bon format ? Cette couche repose sur le code métier, ou sur des bibliothèques comme Zod et Ajv.

90 % des bugs se cachent dans les deux dernières couches. La couche syntaxique n’est que le ticket d’entrée.

Syntaxiquement correct ne veut pas dire correct côté données

Voici un scénario réel : l’API est censée renvoyer { "code": 0, "data": { "userId": 123 } }, mais elle renvoie en pratique { "data": { "userid": 123 } } — la casse est fausse. JSON.parse passe, mais le frontend lit userId, obtient undefined, et l’interface affiche du vide. Ce type de bug est particulièrement difficile à traquer en production.

La solution : utilisez JSON Schema pour générer les types TypeScript, ou effectuez la validation de schéma au niveau de la requête. Considérez le schéma comme le contrat de l’API et refusez immédiatement tout ce qui ne correspond pas, au lieu d’attendre des erreurs au moment de l’exécution.

5 erreurs JSON fréquentes et comment les corriger

  1. Virgules de fin {"a":1,} — supprimez la dernière virgule, ou utilisez le mode tolérant du formateur JSON de Piick pour les retirer automatiquement.
  2. Chaînes entre apostrophes {'a':1} — remplacez globalement par des guillemets, ou laissez le mode tolérant s’en charger.
  3. Clés non entourées de guillemets {a:1} — enveloppez les clés avec des guillemets.
  4. Commentaires résiduels // xxx — supprimez-les, ou laissez le mode tolérant les retirer.
  5. En-tête BOM {"a":1} — enregistrez en UTF-8 sans BOM.

Astuce de débogage : ne comptez pas les accolades à l’œil. Utilisez directement la fonctionnalité « afficher les numéros de ligne » de l’outil.

Comment localiser précisément les erreurs après analyse

Les erreurs de JSON.parse se contentent d’afficher Unexpected token sans préciser où. Chrome DevTools, Postman et les extensions VS Code peuvent afficher les numéros de ligne, mais ils imposent tous un copier-coller manuel.

Plus précis encore, le formateur JSON de Piick lit la position N issue de l’erreur V8, la convertit en numéro de ligne et de colonne, et l’affiche dans la bannière d’erreur. Collez un JSON cassé, et vous verrez exactement la ligne et la colonne en cause. Pour démarrer avec la validation de schéma, consultez la liste officielle des implémentations JSON Schema.

Ouvrez dès maintenant le formateur JSON de Piick, collez une chaîne JSON et essayez la localisation précise des erreurs qu’il propose.