== vs === en JavaScript : quelle différence et comment ne pas casser le code

Introduction : pourquoi cette question tourmente des milliers de développeurs

Si vous avez déjà écrit en JavaScript, vous avez sûrement rencontré cette situation : votre code ne fonctionnait pas comme prévu, et la cause en était les opérateurs de comparaison == et ===. La question "Which equals operator (== vs ===) should be used in JavaScript comparisons?" fait partie des plus populaires sur Stack Overflow — elle a été consultée par des millions de développeurs. Et ce n'est pas un hasard.

La différence entre l'égalité non stricte (==) et stricte (===) est l'un des premiers pièges dans lequel tombent les débutants. Mais même les programmeurs expérimentés oublient parfois les nuances. Dans cet article, nous analyserons tous les pièges, montrerons avec des exemples concrets comment éviter les erreurs typiques, et donnerons des règles claires sur quand utiliser quoi.

Prêts ? C'est parti !

1. Les bases : que sont == et === en JavaScript

Les deux opérateurs sont utilisés pour comparer des valeurs. Mais il y a une différence clé :

\n
• == (égalité non stricte) — compare les valeurs avec conversion de type. Si les types sont différents, JavaScript essaie de convertir une valeur vers le type de l'autre, puis compare.
\n
• === (égalité stricte) — compare à la fois la valeur et le type de données sans aucune conversion. Si les types sont différents — directement false.
\n

Cela semble simple ? Mais le diable, comme toujours, se cache dans les détails.

Exemple pour s'échauffer

console.log(5 == "5");   // true (le nombre 5 est converti en chaîne "5")\nconsole.log(5 === "5");  // false (types différents : number vs string)

Le premier cas est un piège classique : vous attendez false, mais vous obtenez true. Et ce n'est que le début.

2. Comment JavaScript convertit les types : points non évidents

Lors de l'utilisation de ==, l'interpréteur exécute des algorithmes complexes de conversion. Voici quelques exemples qui peuvent surprendre :

Chaînes et nombres

console.log(0 == false);   // true (false → 0)\nconsole.log("" == false);  // true ("" → 0)\nconsole.log(null == undefined); // true (règle spéciale)\nconsole.log(null === undefined); // false

null et undefined sont particulièrement dangereux : avec ==, ils sont égaux entre eux, mais ne sont égaux à rien d'autre (même pas à false ou 0).

Tableaux et objets

console.log([] == false);   // true (tableau vide → "" → 0)\nconsole.log([1] == true);   // true ([1] → "1" → 1)\nconsole.log([1,2] == "1,2"); // true (tableau → chaîne)

Ici, on peut déjà perdre le fil de la logique. C'est à cause de telles "surprises" que de nombreux développeurs refusent catégoriquement d'utiliser ==.

3. Erreurs réelles issues de la pratique : quand == casse la logique

Analysons plusieurs situations qui peuvent entraîner des bugs en production.

Erreur 1 : Vérification de vacuité

function isEmpty(value) {\n    return value == false; // mauvais !\n}\n\nconsole.log(isEmpty(0));      // true\nconsole.log(isEmpty(""));     // true\nconsole.log(isEmpty(null));   // true ? Non, null == false → false\nconsole.log(isEmpty([]));     // true ? Oui, [] == false → true\nconsole.log(isEmpty("text")); // false\n

Cela semble fonctionner, mais en réalité null n'est pas égal à false avec == — c'est false. Et un tableau vide est considéré comme true ? Non, il est converti en 0. Confusion totale. La bonne solution est d'utiliser une vérification stricte ou des conditions explicites.

Erreur 2 : Comparaison avec undefined

let user = { name: "Alice" };\nif (user.age == undefined) { // ok, mais mieux avec ===\n    console.log("Âge non spécifié");\n}\n// Mais si age = null ?\nuser.age = null;\nconsole.log(user.age == undefined); // true ! Alors que ça devrait être false