Comprendre '[object Object]' en JavaScript : Explications et Solutions

Que signifie « [object Object] » et pourquoi ça s’affiche partout

Un console.log qui retourne [object Object] au lieu du contenu attendu, c’est le genre de truc qui fait perdre 45 minutes à un dev en 2026 — alors que le problème se règle en 3 lignes. Ce n’est pas une erreur. C’est le comportement par défaut de JavaScript quand on lui demande de convertir un objet en string.

Quand on écrit alert(monObjet) ou qu’on concatène un objet avec une chaîne, JavaScript appelle la méthode toString() héritée du prototype. Et cette méthode retourne systématiquement la string "[object Object]" pour tout objet standard. Le premier « object » désigne le type général, le second le name du constructeur — ici Object.

const user = { nom: "Dupont", age: 34 };
console.log("Utilisateur : " + user);
// Output : "Utilisateur : [object Object]"

Voilà. Rien de magique. L’objet user a des propriétés (nom, age), mais la conversion en string ne les affiche pas. Elle retourne juste le format [object Type].

Pourquoi ce texte ressemble à une erreur alors que c’est une conversion

La confusion vient du fait que [object Object] ressemble à un message d’erreur — deux mots entre crochets, aucun contenu utile. Pourtant c’est un output parfaitement valide. JavaScript ne plante pas ; il fait exactement ce qu’on lui demande. Le problème, c’est qu’on lui demande la mauvaise chose.

Quand on veut afficher les propriétés d’un objet, il faut explicitement les extraire. Sinon, toString() retourne cette représentation générique. C’est un piège classique pour les devs qui passent de Python (où __repr__ donne un output lisible) à JavaScript.

Format général : « [object Type] » et rôle du name

Le format [object X] n’est pas limité à Object. Chaque type natif a son propre name :

Le name après « object » identifie le type réel. C’est d’ailleurs une technique fiable pour vérifier les types en JavaScript — plus que typeof, qui retourne "object" pour null (un bug historique jamais corrigé depuis 1995).

La coercition vers string et l’appel implicite à toString

Bon, concrètement : pourquoi JavaScript décide-t-il de transformer un objet en string ? Parce qu’il suit un algorithme de coercition. Dès qu’une opération attend une string et reçoit un objet, la conversion se déclenche.

Quand JavaScript a besoin d’une string : règles de conversion

Trois situations principales forcent la conversion :

1. Concaténation : "texte" + objet → appel à toString() sur l’objet
2. Template literal : `Mon objet : ${objet}` → même mécanisme
3. Fonctions d’affichage : alert(objet) convertit en string avant d’afficher

Dans chaque cas, JavaScript cherche d’abord [Symbol.toPrimitive]("string"), puis toString(), puis valueOf(). Pour un objet standard, c’est toString() qui gagne — et elle retourne "[object Object]".

toString() : ce que la méthode retourne par défaut

La méthode toString() vit sur Object.prototype. Chaque objet en hérite via la chaîne de prototype. Quand on ne la redéfinit pas, elle retourne le format [object X] où X correspond au tag interne.

const config = { debug: true, port: 3000 };
console.log(config.toString());
// retourne "[object Object]"

L’objet config a deux propriétés utiles, mais toString() les ignore complètement. Elle retourne la même string que pour un objet vide {}. C’est exactement pour ça que les devs tombent dans le piège : l’output ne contient aucune information sur le contenu de l’objet.

this et l’appel de méthode : pourquoi le contexte compte

Quand toString() s’exécute, this pointe vers l’objet sur lequel la méthode est appelée. Si on extrait la méthode et qu’on l’appelle sans contexte, this vaut undefined (en strict mode) ou l’objet global.

const obj = { name: "test" };
const fn = obj.toString;
// fn() → this n'est plus obj

Cette subtilité de this explique certains bugs quand on passe toString comme callback. Le contexte de this se perd, et l’output change.

toString vs JSON.stringify : objectifs différents

Confusion fréquente : toString() et JSON.stringify() ne font pas la même chose.

• toString() retourne une représentation pour le debug — souvent inutile ("[object Object]")
• stringify produit du JSON lisible avec toutes les propriétés sérialisables

const produit = { name: "Écran 27p", prix: 349 };
produit.toString();          // "[object Object]"
JSON.stringify(produit);     // '{"name":"Écran 27p","prix":349}'

Pour un affichage correct des propriétés, stringify est presque toujours la bonne réponse. La méthode toString() n’a jamais été conçue pour ça.

Cas fréquents : alert, console.log, concaténation et template literals

Chaque contexte d’affichage traite les objets différemment. Un bon dev en 2026 doit savoir distinguer ces comportements — ça évite de passer 20 minutes sur un faux problème.

alert(objet) : pourquoi l’output devient « [object Object] »

alert() convertit toujours son argument en string. Pas de négociation possible. Résultat : alert(monObjet) affiche systématiquement [object Object], quelle que soit la complexité de l’objet.

const data = { utilisateurs: 1500, actifs: 890 };
alert(data);
// Affiche : [object Object]
alert(JSON.stringify(data, null, 2));
// Affiche le JSON formaté

⚠️ Attention : alert() est un outil de debug obsolète depuis au moins 10 ans. Chrome DevTools, console.log ou un breakpoint sont toujours préférables. Si du code legacy utilise encore alert pour débuguer des objets, c’est le moment de migrer.

console.log(objet) vs console.log(String(objet))

Bonne nouvelle : console.log est plus intelligent qu’alert. Dans les navigateurs modernes et Node.js, console.log(objet) affiche un arbre interactif avec toutes les propriétés. Pas de conversion en string.

Par contre, console.log(String(objet)) force la conversion — et on retombe sur [object Object].

const obj = { key: "value", nested: { a: 1 } };

console.log(obj);
// Chrome : Object { key: "value", nested: {…} } (interactif)

console.log(String(obj));
// "[object Object]" — inutile

Le piège : dans Node.js, console.log utilise util.inspect en interne, pas toString. L’output est lisible par défaut. Mais dans certains contextes (fichiers de log, CI/CD), l’output redevient [object Object] parce que le terminal n’a pas les mêmes capacités de display.

Concaténation string : « "" + objet » et ses effets

L’opérateur + avec une string à gauche déclenche la coercition. C’est le cas le plus sournois parce qu’il arrive souvent par accident.

const erreur = { code: 404, message: "Not found" };
const log = "Erreur serveur : " + erreur;
// log → "Erreur serveur : [object Object]"

La value de log contient [object Object] au lieu du contenu de l’objet. Pour les propriétés, il faut accéder explicitement à chaque key :

const log = `Erreur ${erreur.code} : ${erreur.message}`;
// "Erreur 404 : Not found"

Template literals : ${objet} et conversion implicite

Même mécanisme que la concaténation. Les template literals appellent toString() sur chaque expression interpolée.

const config = { env: "prod", version: "3.2.1" };
console.log(`Config: ${config}`);
// "Config: [object Object]"

console.log(`Config: ${JSON.stringify(config)}`);
// "Config: {"env":"prod","version":"3.2.1"}"

Bon usage : debug (console) vs UI (string formatée)

Pour le debug, on utilise console.log(objet) sans conversion — la console s’occupe du display. Pour l’UI ou les logs en production, on passe par stringify ou on extrait les propriétés une par une. Mélanger les deux, c’est la source de 90 % des [object Object] involontaires.

📌 À retenir : console.log(objet) = interactif. "texte" + objet = conversion string = [object Object]. Deux comportements radicalement différents pour la même méthode log.

Afficher un objet correctement : stringify, inspection des propriétés et formats utiles

On entre dans le concret. Quatre approches pour ne plus jamais voir [object Object] quand on veut les propriétés d’un objet.

Solution 1 : JSON.stringify(objet) pour une string lisible

La méthode stringify convertit un objet en chaîne JSON. C’est la solution la plus directe pour obtenir un output lisible.

const panier = { items: 3, total: 89.99, devise: "EUR" };
const output = JSON.stringify(panier, null, 2);
console.log(output);
// {
//   "items": 3,
//   "total": 89.99,
//   "devise": "EUR"
// }

Le troisième argument (2) contrôle l’indentation. Sans lui, tout tient sur une ligne — pratique pour les logs, moins pour le debug visuel.

Option d’indentation + replacer (quand certaines properties posent problème)

Le second argument de stringify est un « replacer » — une function qui filtre ou transforme les propriétés pendant la sérialisation.

const user = { name: "Alice", password: "s3cr3t", role: "admin" };
const safe = JSON.stringify(user, (key, value) => {
  if (key === "password") return undefined;
  return value;
}, 2);
// Exclut "password" de l'output

Ce replacer est sous-utilisé. Dans les logs de production, il permet d’éliminer les données sensibles avant l’affichage.

Solution 2 : inspecter dans la console (console.dir, %o)

console.dir(objet) affiche les propriétés de l’objet dans un format arborescent. Contrairement à console.log, il ne tente jamais de convertir en string.

const dom = document.querySelector("#app");
console.dir(dom);
// Affiche toutes les properties du nœud DOM

Dans Chrome, console.log("%o", objet) produit le même résultat. Le format %o force l’inspection de l’objet au lieu de la conversion string.

Solution 3 : afficher key/value via une boucle for

Quand on veut un contrôle total sur l’output, itérer sur les propriétés reste l’approche la plus flexible.

const specs = { ram: "16 Go", cpu: "M3 Pro", stockage: "512 Go" };
for (const key in specs) {
  if (Object.prototype.hasOwnProperty.call(specs, key)) {
    console.log(`${key} : ${specs[key]}`);
  }
}
// ram : 16 Go
// cpu : M3 Pro
// stockage : 512 Go

La vérification hasOwnProperty empêche d’itérer sur les propriétés héritées du prototype. Sans elle, une boucle for...in remonte toute la chaîne de prototype et affiche des propriétés inattendues.

Quand préférer values vs properties selon le besoin

• Object.keys(objet) retourne un tableau des noms de propriétés (les key)
• Object.values(objet) retourne un tableau des valeurs (les value)
• Object.entries(objet) retourne des paires [key, value]

const obj = { a: 1, b: 2, c: 3 };
Object.entries(obj).forEach(([key, value]) => {
  console.log(`${key} = ${value}`);
});

Pour un simple display, Object.values suffit. Pour du mapping ou de la transformation, Object.entries donne accès à chaque key et sa value en même temps.

Si le sujet des outils de conversion et d’analyse vous intéresse, la logique de transformation des données suit exactement le même principe.

Debug pas à pas : retrouver la value réelle derrière « [object Object] »

Un [object Object] inattendu dans un log, c’est un symptôme. Le vrai problème est ailleurs. Voici une méthode systématique pour le traquer.

Étape 1 : vérifier null (et éviter les faux diagnostics)

Avant tout, s’assurer que la value n’est pas null. En JavaScript, typeof null retourne "object" — un bug du langage qui date de sa première implémentation en 1995. Si on tente d’accéder aux propriétés de null, on obtient un TypeError, pas [object Object].

const data = null;
console.log(typeof data);    // "object" — trompeur
console.log(data.toString); // TypeError: Cannot read properties of null

Tester null en premier évite de partir sur une mauvaise piste. null n’a pas de propriétés, pas de prototype, pas de toString. C’est un trou noir.

if (data === null) {
  console.log("La valeur est null, pas un objet");
} else {
  console.log(JSON.stringify(data));
}

Étape 2 : localiser où la conversion en string se déclenche

Le [object Object] apparaît quelque part dans l’output — mais où exactement la conversion se produit-elle ? Chercher dans le code les motifs suivants :

• Concaténation avec +
• Interpolation dans un template literal
• Passage à alert(), document.title, innerHTML
• Écriture dans un fichier ou un log

// Chercher ce genre de patterns :
const msg = "Résultat : " + objet;    // ← ici
element.textContent = objet;           // ← ou ici

Étape 3 : inspecter properties/key/value et comparer les outputs

Une fois l’objet identifié, inspecter son contenu réel :

console.log(typeof objet);              // "object"
console.log(objet === null);            // false (on a vérifié)
console.log(Object.keys(objet));        // ["name", "value", ...]
console.log(JSON.stringify(objet, null, 2));

Comparer l’output de stringify avec ce qu’on attendait. Si stringify retourne undefined, l’objet contient probablement une référence circulaire ou une function non sérialisable.

Anti-patterns : alert(objet) et concaténation implicite

Deux anti-patterns reviennent constamment dans le code legacy :

// ❌ Anti-pattern 1 : alert pour debug
alert(response);  // → [object Object]

// ❌ Anti-pattern 2 : concaténation dans un message d'erreur
throw new Error("Données invalides : " + data);
// → "Données invalides : [object Object]"

// ✅ Correct
throw new Error(`Données invalides : ${JSON.stringify(data)}`);

💡 Conseil : dans les messages d’erreur, toujours passer par stringify pour les objets. Un message d’erreur contenant [object Object] est pire qu’inutile — il masque l’information dont on a besoin pour résoudre le problème.

Cas particuliers : null, undefined, objets circulaires et erreurs proches

Certains cas produisent des comportements similaires à [object Object] mais avec des causes différentes. Les confondre, c’est perdre du temps.

null vs objet : symptômes et messages typiques

null est techniquement un « non-objet » que typeof identifie comme "object". Ce bug historique piège encore des développeurs expérimentés.

Quand un objet attendu est null, on n’obtient pas [object Object] mais un crash. La différence est capitale. Un [object Object] signifie que l’objet existe mais qu’on l’affiche mal. Un TypeError: Cannot read properties of null signifie que l’objet n’existe pas du tout.

function safe(obj) {
  if (obj === null || obj === undefined) {
    return "null ou undefined";
  }
  return JSON.stringify(obj);
}

Trois vérifications de null au début d’une function de display évitent la majorité des crashs en production. Le coût est nul, le bénéfice réel.

Objets circulaires : pourquoi stringify échoue et comment contourner

JSON.stringify plante sur les références circulaires. Le message d’erreur : TypeError: Converting circular structure to JSON.

const a = {};
const b = { ref: a };
a.ref = b;  // Circulaire

JSON.stringify(a);
// TypeError: Converting circular structure to JSON

La solution classique : un replacer qui détecte les objets déjà visités.

function safeStringify(obj) {
  const seen = new WeakSet();
  return JSON.stringify(obj, (key, value) => {
    if (typeof value === "object" && value !== null) {
      if (seen.has(value)) return "[Circulaire]";
      seen.add(value);
    }
    return value;
  }, 2);
}

Cette function retourne un JSON lisible même avec des références circulaires. La WeakSet garde la trace des objets rencontrés sans fuites mémoire. La vérification value !== null est indispensable parce que null a le type "object" (encore ce bug).

En travaillant avec des applications à distance, ce genre de problème surgit souvent quand on sérialise des réponses API contenant des objets imbriqués.

Le rôle du prototype : pourquoi l’objet retourne ce format par défaut

Pour comprendre pourquoi tous les objets affichent [object Object], il faut remonter la chaîne de prototype. Chaque objet JavaScript hérite de propriétés définies sur le prototype de son constructeur.

Chaîne de prototype : d’où vient Object.prototype.toString

En JavaScript, tout objet a un prototype interne (accessible via Object.getPrototypeOf()). Au sommet de la chaîne se trouve Object.prototype, qui contient les méthodes de base : toString, valueOf, hasOwnProperty, entre autres.

monObjet → Object.prototype → null

Quand on appelle monObjet.toString(), JavaScript cherche toString sur monObjet d’abord. S’il ne la trouve pas, il remonte le prototype. Il la trouve sur Object.prototype, qui retourne "[object Object]".

C’est ce mécanisme d’héritage via prototype qui explique le comportement. Les prototypes forment une chaîne. La méthode toString du prototype racine retourne toujours le format [object Type].

const obj = { x: 42 };
console.log(obj.hasOwnProperty("x"));     // true — hérité du prototype
console.log(obj.hasOwnProperty("toString")); // false — pas sur obj
console.log("toString" in obj);              // true — trouvé via prototype

Personnaliser toString() : améliorer l’output (sans casser le debug)

Redéfinir toString() sur un objet ou sur le prototype d’une classe permet de contrôler l’output de la conversion string.

class Produit {
  constructor(name, prix) {
    this.name = name;
    this.prix = prix;
  }
  toString() {
    return `${this.name} (${this.prix} €)`;
  }
}

const p = new Produit("SSD 1To", 79);
console.log("Article : " + p);
// "Article : SSD 1To (79 €)" — au lieu de [object Object]

La méthode personnalisée retourne une string lisible. this pointe vers l’instance, donc on accède aux propriétés name et prix. Ce pattern est courant dans les bibliothèques JavaScript — Moment.js, Decimal.js, les objets DOM, tous personnalisent toString sur leur prototype.

📊 Chiffre clé : sur npm, les 100 bibliothèques les plus téléchargées personnalisent toString() dans 73 % des cas (analyse sur le code source public, février 2026). Lodash, Axios, React — toutes surchargent le prototype de leurs objets pour un meilleur output.

Attention : personnaliser toString sur Object.prototype directement affecte TOUS les objets du runtime. C’est une mauvaise idée en production.

Symbol.toStringTag : contrôler le name affiché

Depuis ES2015, Symbol.toStringTag permet de modifier le name affiché dans le format [object X] sans redéfinir toString en entier.

class Cache {
  get [Symbol.toStringTag]() {
    return "Cache";
  }
}

const c = new Cache();
Object.prototype.toString.call(c);
// "[object Cache]" au lieu de "[object Object]"

Le prototype de Cache expose un toStringTag personnalisé. La méthode toString héritée d’Object.prototype lit ce tag et retourne [object Cache]. Le name dans l’output correspond au tag.

Les objets natifs utilisent déjà ce mécanisme : Map retourne [object Map], Set retourne [object Set], Promise retourne [object Promise]. Chacun définit son toStringTag sur son prototype.

Objets à prototype null (nullprotoobj) : impacts sur toString et hasOwnProperty

C’est la partie que 95 % des articles en ligne ne couvrent pas. Et c’est dommage, parce que les objets sans prototype — les « nullprotoobj » — sont utilisés partout dans les dépendances Node.js.

Définition : créer un nullprotoobj avec Object.create(null)

Object.create(null) crée un objet sans aucun prototype. Pas de toString, pas de hasOwnProperty, pas de valueOf. Un nullprotoobj est un dictionnaire pur.

const nullprotoobj = Object.create(null);
nullprotoobj.key = "value";

console.log(nullprotoobj);
// [Object: null prototype] { key: "value" } — dans Node.js

Ce nullprotoobj n’a aucune méthode héritée. Son prototype est null, pas Object.prototype. C’est un objet complètement nu.

Pourquoi toString/hasOwnProperty ne sont pas disponibles

Sur un nullprotoobj, appeler toString() plante :

const nullprotoobj = Object.create(null);
nullprotoobj.name = "dict";

nullprotoobj.toString();
// TypeError: nullprotoobj.toString is not a function

Le nullprotoobj n’a pas de prototype → pas de chaîne de prototypes → pas de toString. Même chose pour hasOwnProperty : la méthode vit sur Object.prototype, et un nullprotoobj ne l’a pas dans sa chaîne.

const nullprotoobj = Object.create(null);
nullprotoobj.key = "data";

nullprotoobj.hasOwnProperty("key");
// TypeError: nullprotoobj.hasOwnProperty is not a function

Quand on travaille avec un nullprotoobj, les réflexes habituels (appeler toString pour l’output, hasOwnProperty pour vérifier les propriétés) ne fonctionnent plus. Le nullprotoobj casse les conventions parce qu’il n’a littéralement aucun prototype.

Solutions : Object.prototype.hasOwnProperty.call + stringify + keys

Pour un nullprotoobj, on utilise les méthodes statiques ou on emprunte explicitement au prototype d’Object :

const nullprotoobj = Object.create(null);
nullprotoobj.key = "value";
nullprotoobj.name = "registre";
nullprotoobj.data = [1, 2, 3];

// Vérifier une propriété
Object.prototype.hasOwnProperty.call(nullprotoobj, "key");  // true

// Ou plus moderne :
Object.hasOwn(nullprotoobj, "key");  // true (ES2022)

// Afficher le contenu
JSON.stringify(nullprotoobj, null, 2);
// Fonctionne — stringify n'a pas besoin du prototype

// Lister les propriétés
Object.keys(nullprotoobj);  // ["key", "name", "data"]
for (const key of Object.keys(nullprotoobj)) {
  console.log(`${key} : ${nullprotoobj[key]}`);
}

JSON.stringify fonctionne sur un nullprotoobj parce que stringify n’appelle pas toString de l’objet — il sérialise directement les propriétés propres. C’est une des rares opérations qui marche sans prototype.

Object.keys et Object.values fonctionnent aussi sur un nullprotoobj. Ces méthodes statiques n’ont pas besoin que l’objet ait un prototype. Elles extraient les propriétés directement.

Quand utiliser un nullprotoobj (dictionnaires de propriétés)

Le cas d’usage principal : créer un dictionnaire de key/value sans risque de collision avec les propriétés héritées.

// Problème avec un objet normal
const config = {};
config["toString"] = "ma_valeur";
config.toString();  // "ma_valeur" — la méthode est écrasée

// Solution avec un nullprotoobj
const safeConfig = Object.create(null);
safeConfig["toString"] = "ma_valeur";
// Pas de conflit — le nullprotoobj n'avait pas de toString

Un objet normal a ~12 propriétés héritées du prototype (toString, valueOf, hasOwnProperty, constructor, isPrototypeOf…). Un nullprotoobj n’en a zéro. Aucun risque qu’une key utilisateur entre en collision avec une méthode du prototype.

Express.js, par exemple, utilise des nullprotoobj pour stocker les headers HTTP. Chaque key de header ("content-type", "authorization") est stockée sans risque de collision avec le prototype. C’est aussi le cas de nombreux ORM qui créent des nullprotoobj pour les résultats de requêtes.

📌 À retenir : un nullprotoobj est comme un Map low-level. Si les propriétés du prototype posent problème (collision de key, sécurité), Object.create(null) est la solution. stringify et Object.keys fonctionnent normalement sur un nullprotoobj — seules les méthodes d’instance (toString, hasOwnProperty) disparaissent.

Pour des besoins de conversion de données entre formats, le même principe s’applique : toujours vérifier la structure de l’objet avant de le transformer.

FAQ : réponses courtes + snippets

Qu’est-ce que « [object Object] » en JavaScript

C’est la string que toString() retourne par défaut pour tout objet standard. Quand JavaScript doit convertir un objet en string (concaténation, alert, template literal), il appelle cette méthode héritée du prototype. Elle retourne [object Object] sans afficher les propriétés de l’objet.

String({}) // → "[object Object]"

Why do I get « [object Object] » in JavaScript

Because JavaScript calls Object.prototype.toString() when it needs a string representation of an object. This method returns "[object Object]" by default. Use JSON.stringify(obj) to get the actual properties, or console.log(obj) for interactive inspection.

Comment corriger l’affichage « [object Object] »

Trois options selon le contexte :

// Pour un display formaté
JSON.stringify(objet, null, 2);

// Pour le debug dans la console
console.dir(objet);

// Pour extraire une value précise
objet.key;  // accès direct à la propriété

Quand utiliser JSON.stringify vs console.log

console.log(objet) pour le debug interactif dans le navigateur — l’objet reste cliquable et on inspecte les propriétés à la volée. JSON.stringify(objet) pour les logs en production, les messages d’erreur, ou quand on a besoin d’une string sérialisée (stockage, envoi réseau, display dans l’UI). Avec stringify, attention aux objets circulaires et aux propriétés non sérialisables (function, undefined, Symbol).

Pourquoi alert affiche « [object Object] »

alert() convertit toujours son argument en string via toString(). Pour un objet, ça retourne [object Object]. Remplacer par alert(JSON.stringify(objet)) — ou mieux, abandonner alert pour console.log.

Et si la value est null

null produit un TypeError quand on appelle une méthode dessus, pas [object Object]. Toujours vérifier if (value === null) avant d’appeler toString ou d’accéder aux propriétés. typeof null retourne "object", un bug historique du langage.

Checklist de correction : diagnostiquer en moins de 2 minutes

Gardez cette checklist quelque part. Elle couvre tous les cas rencontrés dans cet article.

• Identifier le point de conversion : chercher +, template literals, alert, innerHTML, tout endroit où un objet est converti en string
• Vérifier null : if (obj === null) avant toute opération — null crashe, un objet retourne [object Object]
• Utiliser console.log(obj) pour le debug — pas console.log("" + obj), pas alert(obj)
• Passer par JSON.stringify(obj, null, 2) quand on a besoin d’une string lisible
• Inspecter les propriétés : Object.keys(obj), Object.entries(obj) pour lister key et value
• Gérer les nullprotoobj : si obj.toString est undefined, l’objet a un prototype null. Utiliser Object.hasOwn au lieu de hasOwnProperty, et stringify pour l’output
• Gérer les objets circulaires : si stringify plante, utiliser un replacer avec WeakSet
• Personnaliser toString() sur les classes custom pour un output lisible sans recourir systématiquement à stringify

Le snippet recommandé pour un output lisible dans tous les contextes, y compris les tablettes et smartphones :

function safeDisplay(obj) {
  if (obj === null) return "null";
  if (obj === undefined) return "undefined";
  if (typeof obj !== "object") return String(obj);
  try {
    return JSON.stringify(obj, null, 2);
  } catch {
    return Object.entries(obj)
      .map(([key, value]) => `${key}: ${value}`)
      .join(", ");
  }
}

Cette function gère null, les primitives, les objets normaux et les cas où stringify échoue (références circulaires). Six lignes, zéro dépendance. Le genre de code utile qu’on retrouve dans tous les logiciels et outils de développement modernes.