← Tous les articles
Mis à jour le May 29, 20268 min read

Comment gérer du JSON cassé en JavaScript

Le JSON réel est souvent sale : virgules finales, guillemets simples, littéraux Python, fences markdown. Apprenez les patterns courants, comment écrire un helper de parsing sûr et quand passer à une bibliothèque de réparation dédiée.

Tout dev JavaScript l'a vu : JSON.parse() jette un SyntaxError et ton appli crashe. Le JSON vient d'une API, d'un fichier de config, ou du presse-papiers d'un utilisateur —— et il ne veut tout simplement pas se parser. Dans ce guide on parcourt précisément pourquoi ça arrive, à quoi ressemble du JSON cassé en conditions réelles, et comment le gérer avec élégance —— d'un simple try/catch à la réparation automatique.

1. Pourquoi JSON.parse() échoue

Le standard JSON (RFC 8259) est délibérément strict. JSON.parse() l'implémente exactement —— toute déviation, même mineure, jette un SyntaxError sans récupération partielle :

try {
  const data = JSON.parse('{ name: "Ada" }'); // clé sans guillemets
} catch (err) {
  console.error(err.message);
  // SyntaxError: Expected property name or '}' in JSON at position 2
}

Contrairement à un navigateur qui parse du HTML (avec un modèle de récupération d'erreur intégré), le parser JSON est une porte fermée. Le parsing strict est une feature : il force les producteurs à émettre des données propres. Mais quand tu ne contrôles pas la source des données —— sortie LLM, fichiers de config édités à la main, APIs tierces —— il te faut une stratégie pour quand cette porte claque.

2. Les motifs de JSON cassé les plus courants

Avant d'attraper une lib de réparation, ça aide de reconnaître ce à quoi tu as affaire. Presque tout JSON cassé en conditions réelles tombe dans l'une de ces catégories :

Apostrophes au lieu de guillemets doubles

// ❌ JSON invalide
{ 'name': 'Ada Lovelace' }

// ✅ Valide
{ "name": "Ada Lovelace" }

Les literals d'objet JavaScript acceptent les apostrophes ; JSON non. Les devs copient un literal d'objet directement dans un contexte JSON et tombent constamment sur cette erreur.

Virgules finales

// ❌ JSON invalide
{
  "name": "Ada",
  "active": true,   // virgule finale
}

// ✅ Valide
{
  "name": "Ada",
  "active": true
}

JavaScript moderne autorise les virgules finales dans les tableaux et objets. JSON non. C'est l'erreur la plus courante dans les fichiers JSON édités à la main.

Clés d'objet sans guillemets

// ❌ JSON invalide
{ name: "Ada", score: 98 }

// ✅ Valide
{ "name": "Ada", "score": 98 }

Les literals d'objet JavaScript ne requièrent pas de clés entre guillemets. JSON exige que toutes les clés soient des strings entre guillemets doubles, sans exception.

Commentaires JavaScript

// ❌ JSON invalide
{
  // ceci est l'enregistrement utilisateur
  "name": "Ada",
  /* ajouté en 2024 */
  "active": true
}

JSON n'a pas de syntaxe de commentaires. Des commentaires sont parfois ajoutés aux fichiers de config (JSONC —— JSON-with-Comments —— est une extension populaire), mais JSON.parse() les rejettera.

Strings multi-lignes

// ❌ JSON invalide
{
  "description": "line one
  line two"
}

// ✅ Valide —— échapper le saut de ligne
{
  "description": "line one\nline two"
}

Les valeurs string en JSON doivent tenir sur une seule ligne. Les sauts de ligne littéraux à l'intérieur d'une string ne sont pas autorisés ; utilise la séquence d'échappement \n à la place.

NaN, Infinity et undefined

// ❌ Pas du JSON valide
{ "ratio": NaN, "limit": Infinity, "value": undefined }

// ✅ Alternatives valides
{ "ratio": null, "limit": 1e308, "value": null }

Ce sont des valeurs JavaScript valides mais pas dans la spec JSON. JSON.stringify() les convertit silencieusement (NaN et Infinity deviennent null ; les propriétés undefined sont supprimées entièrement), ce qui peut causer des bugs round-trip subtils.

Literals Python

// ❌ Style Python —— JSON invalide
{ "active": True, "deleted": False, "value": None }

// ✅ JSON valide
{ "active": true, "deleted": false, "value": null }

JSON a été conçu pour interopérer entre plusieurs langages. Les True, False et None avec majuscule de Python sont une source fréquente de bugs de données cross-langage.

3. « Réparer » et « parser » ne sont pas la même chose

C'est important de distinguer deux opérations fondamentalement différentes :

  • Parsing strict —— valider que l'input est exactement du JSON correct, rapporter la position précise de toute erreur, rejeter tout ce qui dévie. À utiliser quand tu contrôles le producteur de données et veux imposer un contrat.
  • Parsing avec réparation —— tenter de récupérer une valeur JSON valide depuis un input syntaxiquement imparfait en utilisant un ensemble de règles heuristiques. À utiliser quand les données viennent d'une source non fiable ou imprécise (sortie LLM, presse-papiers utilisateur, service legacy).

Un parser de réparation fait des hypothèses. S'il rencontre True il suppose que tu voulais dire true. S'il rencontre une virgule finale il la retire. Ces hypothèses sont presque toujours correctes pour les motifs listés ci-dessus —— mais elles peuvent silencieusement masquer un document vraiment malformé où le « fix » change le sens prévu.

Le bon outil dépend du contexte. Dans un pipeline de réponses d'API validées par schéma, tu veux du parsing strict pour que les mauvaises données remontent à la surface immédiatement. Dans un outil dev où un humain colle du JSON copié d'un message Slack, le parsing avec réparation fait gagner du temps.

Librairies à connaître

Deux paquets npm font le gros du travail, avec des trade-offs complémentaires :

  • jsonrepair —— un parser de réparation tolérant. Tu lui donnes du JSON mauvais et tu récupères une string valide best-effort. Il gère les motifs ci-dessus (apostrophes, virgules finales, clés sans guillemets, commentaires, literals Python, fences markdown, crochets non fermés, input partiel). Synchrone, zéro dépendance, petit —— idéal quand tu as un document complet en mémoire.
  • clarinet —— un parser JSON streaming style SAX. À utiliser quand le JSON arrive en chunks (un stream, un gros fichier, une réponse LLM token par token) et que tu dois réagir au fur et à mesure que les clés/valeurs apparaissent plutôt que d'attendre le document complet. Il est strict sur la syntaxe, donc associe-le à jsonrepair si la source n'est pas fiable.

Règle empirique : répare quand tu as un petit blob non fiable ; stream quand le document est gros ou arrive progressivement.

4. Attraper les erreurs et donner un feedback amical aux utilisateurs

Le pattern minimum viable est un try/catch. Toujours faire ça —— ne laisse jamais JSON.parse() jeter sans être attrapé :

function safeParseJson(text) {
  try {
    return { ok: true, value: JSON.parse(text) };
  } catch (err) {
    return { ok: false, error: err.message };
  }
}

const result = safeParseJson(userInput);
if (!result.ok) {
  showError(`Could not parse JSON: ${result.error}`);
}

Le message d'erreur de JSON.parse() varie selon le moteur JavaScript. V8 (Node.js, Chrome) inclut un indice de position :

// Message d'erreur V8
"Expected ',' or '}' after property value in JSON at position 42"

// Firefox SpiderMonkey
"JSON.parse: expected ',' or '}' after property value in object
at line 3 column 5 of the JSON data"

L'information de position est utile mais spécifique au moteur. Si tu as besoin de reporting fiable ligne/colonne entre environnements, un parser descente-récursive custom peut émettre des erreurs structurées bien plus faciles à afficher aux utilisateurs.

5. Quand auto-réparer vs. demander confirmation

Toutes les réparations ne portent pas le même risque. Voici une heuristique pratique :

  • Sûr à réparer automatiquement —— virgules finales, normalisation des espaces, conversion du style de guillemets, clés sans guillemets, commentaires JavaScript, literals boolean/null Python. Ce sont des transformations mécaniques sans ambiguïté sémantique.
  • Envisager de demander à l'utilisateur —— réparations structurelles comme auto-fermer un objet ou tableau non fermé ({"name": "Ada" → {"name": "Ada"}), ou retirer du contenu (supprimer un commentaire qui semble intentionnel). La réparation est probablement juste, mais l'utilisateur voudra peut-être vérifier.
  • Toujours signaler, jamais corriger en silence —— les coercitions de type comme NaN → null changent la valeur des données. Montre à l'utilisateur ce qui a changé.

Une bonne UI de réparation affiche un diff : l'input original à gauche, l'output réparé à droite. L'utilisateur peut confirmer que le fix est correct avant de copier ou soumettre le résultat.

6. L'avantage de confidentialité du traitement JSON dans le navigateur

Quand tu traites du JSON localement dans le navigateur —— en utilisant le moteur JavaScript qui fait déjà tourner la page —— les données ne quittent jamais la machine de l'utilisateur. Ça compte plus que les devs ne le réalisent souvent :

  • Clés API et identifiants —— les devs collent régulièrement des payloads JSON qui contiennent des secrets. Un outil côté serveur logue chaque requête.
  • PII et données de santé —— la conformité GDPR et HIPAA devient bien plus simple quand il n'y a pas de transfert de données.
  • Données corporate —— beaucoup de politiques de sécurité interdisent de coller des données internes dans des services web tiers.

Le traitement dans le navigateur te donne une réparation JSON sans risque : pas de serveur, pas de logs, pas de rétention de données. Le calcul se passe dans un <textarea> et quelques kilo-octets de JavaScript.

Foire aux questions

Comment gérer une erreur JSON.parse en JavaScript ?

Enveloppe l'appel dans try/catch et retourne un résultat structuré au lieu de laisser le SyntaxError se propager (voir le helper safeParseJson ci-dessus). Ne jamais appeler JSON.parse() sur de l'input non fiable sans guard.

Y a-t-il un moyen de parser du JSON cassé automatiquement ?

Oui —— un parser de réparation récupère une valeur valide depuis un input imparfait en appliquant des heuristiques (retirer les virgules finales, convertir les apostrophes, mettre en minuscules True). Utilise-le pour les sources non fiables comme la sortie LLM ou du texte collé, pas pour des réponses d'API validées par contrat où tu veux que les mauvaises données remontent.

Quand devrais-je réparer du JSON vs. le rejeter ?

Répare quand un humain a collé du JSON approximatif ou qu'un LLM l'a produit ; rejette (parsing strict) quand tu contrôles le producteur et veux imposer un schéma. Les coercitions de type comme NaN → null devraient toujours être signalées, jamais appliquées silencieusement.

Quelle est la cause la plus fréquente du JSON cassé ?

Traiter un literal d'objet JavaScript comme du JSON —— apostrophes, clés sans guillemets et virgules finales. Voir JSON vs objets JavaScript et la référence des erreurs de syntaxe dans [object Object] et autres erreurs.

7. Essaye maintenant —— colle ton JSON cassé

Si tu as une chaîne JSON malformée à corriger maintenant, JSON Fix gère tous les motifs ci-dessus —— apostrophes, virgules finales, clés sans guillemets, literals Python, commentaires, fences de code markdown, et plus. Tout tourne dans ton navigateur ; rien n'est envoyé à un serveur.