!= vs !== en JavaScript : pourquoi cette différence change tout (et comment ne plus se tromper)

On va creuser bien au-delà des définitions de base. Parce que dans la vraie vie, les bugs liés à ces opérateurs ne viennent pas d'une méconnaissance de la théorie, mais d'une mauvaise intuition des cas limites. Et ces cas limites, croyez-moi, ils sont légion.

Opérateurs de comparaison en JavaScript : le contexte qui manque souvent

Pourquoi JavaScript a-t-il deux façons de dire "différent" ?

Imaginez un instant que vous compariez deux bouteilles d'eau. Avec !=, vous regardez juste si elles contiennent la même quantité de liquide. Avec !==, vous vérifiez aussi la marque, la forme, et même la température. C'est ça, la différence fondamentale. Sauf que dans le monde du code, cette métaphore a des limites - et c'est là que les choses se compliquent.

JavaScript, langage né en 10 jours (oui, vraiment), a hérité de cette particularité des langages typés dynamiquement. Le problème ? La coercition de type - ce mécanisme qui transforme automatiquement les valeurs pour les comparer - est une boîte de Pandore. Elle peut simplifier votre code... ou le rendre totalement imprévisible. Et c'est précisément ce qui arrive avec !=.

Un héritage des années 90 qui fait encore mal aujourd'hui

Quand Brendan Eich a conçu JavaScript en 1995, il s'est inspiré de Java pour la syntaxe, mais a opté pour un système de types beaucoup plus souple. Résultat : une flexibilité qui a séduit les développeurs, mais aussi des comportements contre-intuitifs qui persistent 30 ans plus tard. Le pire ? Ces "features" ont été conservées pour des raisons de compatibilité ascendante. Autant dire que vous allez devoir vivre avec.

Prenez ce code innocent :

if (0 != false) {
 console.log("Vrai ?");
} else {
 console.log("Faux ?");
}

À votre avis, que va-t-il afficher ? Si vous avez répondu "Faux ?", vous venez de tomber dans le piège. Parce que 0 et false sont considérés comme égaux avec !=. Bienvenue dans le monde merveilleux de la coercition implicite.

!= : l'opérateur qui vous ment (et comment il le fait)

La coercition de type, ou comment JavaScript devine ce que vous vouliez dire

Quand vous utilisez !=, JavaScript fait ce qu'il appelle une "comparaison abstraite". Derrière ce terme technique se cache un processus en trois étapes :

1. Si les types sont identiques, on compare directement les valeurs 2. Si l'un des opérandes est null et l'autre undefined, ils sont considérés comme égaux 3. Dans tous les autres cas, JavaScript essaie de convertir les valeurs vers un type commun avant de les comparer

C'est cette troisième étape qui cause 90% des bugs. Et le pire, c'est que les règles de conversion sont si complexes que même les développeurs chevronnés doivent parfois consulter la documentation. Par exemple, saviez-vous que [] != false retourne false ? Pourtant, [] == false retourne true. Oui, c'est aussi illogique que ça en a l'air.

Les 7 cas les plus tordus de != (et pourquoi ils vous feront douter de votre santé mentale)

Voici une liste non exhaustive des comparaisons qui donnent mal à la tête :

1. Les chaînes numériques vs les nombres "5" != 5 → false (la chaîne est convertie en nombre)

2. Les objets vs les primitives {} != "[object Object]" → true (l'objet est converti en chaîne)

3. null vs undefined null != undefined → false (ils sont considérés comme "égaux" avec !=)

4. Les tableaux vides [] != 0 → false (le tableau est converti en chaîne vide, puis en 0)

5. Les booléens vs les nombres true != 1 → false (true est converti en 1)

6. Les dates vs les chaînes new Date("2023-01-01") != "Sun Jan 01 2023 00:00:00 GMT+0100" → false (la date est convertie en chaîne)

7. NaN vs tout NaN != NaN → true (NaN n'est jamais égal à rien, même à lui-même)

Et le plus frustrant dans tout ça ? Ces comportements ne sont pas des bugs, mais des fonctionnalités documentées. Autant dire que vous allez devoir les mémoriser... ou les éviter.

!== : l'opérateur qui ne prend pas de risques (et pourquoi il devrait être votre choix par défaut)

La comparaison stricte, ou comment éviter les surprises désagréables

Avec !==, JavaScript ne fait aucune conversion de type. Il compare directement les valeurs et leurs types. Point. Si les types diffèrent, la comparaison retourne immédiatement false. C'est simple, prévisible, et surtout : ça évite 99% des bugs liés aux comparaisons.

Prenons un exemple concret :

function isEmpty(value) {
 return value !== null && value !== undefined && value !== "";
}

Cette fonction vérifie si une valeur est "vide" sans tomber dans les pièges de la coercition. Comparez-la à sa version avec != :

function isEmptyBuggy(value) {
 return value != null && value != undefined && value != "";
}

À première vue, ça semble équivalent. Sauf que si vous passez false à cette fonction, elle retournera true. Parce que false != "" retourne false (les deux sont convertis en 0). Et voilà comment un bug subtil s'invite dans votre code.

Pourquoi les linters et les frameworks modernes bannissent !=

Si vous utilisez ESLint avec la règle eqeqeq, vous savez déjà que != est dans le collimateur. Mais pourquoi une telle sévérité ? Parce que les équipes qui maintiennent les grands frameworks (React, Angular, Vue) ont constaté que la majorité des bugs liés aux comparaisons venaient de !=.

Prenez React, par exemple. Quand vous écrivez :

if (props.value != null) {
 // Faire quelque chose
}

Vous pensez probablement vérifier que props.value n'est ni null ni undefined. Sauf que si props.value vaut 0, la condition sera évaluée à false. Et si c'est une chaîne vide ? Pareil. Résultat : votre code ne se comporte pas comme vous l'attendez, et le bug peut mettre des semaines à être détecté.

C'est pour ça que dans les bases de code modernes, on voit de plus en plus :

if (props.value !== null && props.value !== undefined) {
 // Faire quelque chose
}

Ou mieux encore :

if (props.value != null) {
 // Faire quelque chose
}

Attendez... quoi ? != null ? Oui, parce que null != undefined retourne false, ce qui est exactement ce qu'on veut ici. Paradoxalement, dans ce cas précis, != est plus sûr que !==. Et ça, c'est le genre de nuance qui rend ce sujet si fascinant - et si piégeux.

Performance : != est-il vraiment plus rapide que !== ?

Le mythe de la performance des opérateurs de comparaison

On entend souvent dire que != serait plus rapide que !== parce qu'il évite la vérification de type. Sauf que dans la réalité, la différence est négligeable. Les moteurs JavaScript modernes (V8, SpiderMonkey, JavaScriptCore) sont tellement optimisés que cette vérification supplémentaire prend quelques nanosecondes - littéralement.

Pour vous donner une idée, voici les résultats d'un benchmark simple (exécuté sur Node.js 20) :

// Test avec !=
for (let i = 0; i < 100000000; i++) {
 if (i != "123") {}
}
Temps d'exécution : ~120ms

// Test avec !==
for (let i = 0; i < 100000000; i++) {
 if (i !== "123") {}
}
Temps d'exécution : ~115ms

La différence ? 5 millisecondes sur 100 millions d'itérations. Autant dire que pour 99,99% des cas d'usage, ça ne changera strictement rien. Alors oui, !== est légèrement plus lent dans l'absolu, mais la différence est si infime qu'elle n'a aucun impact pratique.

Quand la performance devient un vrai sujet (et ce n'est pas là)

Là où les choses deviennent intéressantes, c'est quand on parle de boucles critiques ou de code exécuté des millions de fois par seconde. Par exemple, dans un moteur de jeu ou une application de traitement d'images. Mais même dans ces cas, le goulot d'étranglement ne sera jamais les opérateurs de comparaison.

Prenez ce code :

function processPixels(pixels) {
 for (let i = 0; i < pixels.length; i++) {
 if (pixels[i] !== 0) { // Comparaison stricte
 pixels[i] = 255;
 }
 }
}

Si vous remplacez !== par !=, vous gagnerez peut-être 1% de performance. Mais si vous optimisez la boucle elle-même (en utilisant TypedArrays, par exemple), vous pouvez gagner 50% ou plus. Autant dire que le choix entre != et !== n'est pas le bon endroit pour chercher des optimisations.

Et puis, il y a un argument bien plus important que la performance : la lisibilité. Un code qui utilise systématiquement !== est plus facile à comprendre et à maintenir. Parce que quand vous voyez !==, vous savez immédiatement que le développeur a pensé aux types. Alors que != laisse planer le doute : est-ce un choix délibéré, ou une erreur ?

Les cas où != est (paradoxalement) plus sûr que !==

Quand la coercition devient une feature, pas un bug

Oui, vous avez bien lu. Il existe des situations où != est préférable à !==. Et c'est précisément dans ces cas que les développeurs expérimentés montrent leur maîtrise du sujet. Voici les trois scénarios les plus courants :

1. La vérification "null ou undefined"

Comme on l'a vu plus haut, value != null est un idiome courant pour vérifier qu'une valeur n'est ni null ni undefined. C'est plus concis que value !== null && value !== undefined, et surtout : c'est une convention reconnue dans la communauté JavaScript.

Exemple d'utilisation dans une fonction :

function getUserName(user) {
 if (user.name != null) {
 return user.name;
 }
 return "Anonyme";
}

Cette version est plus propre que :

function getUserName(user) {
 if (user.name !== null && user.name !== undefined) {
 return user.name;
 }
 return "Anonyme";
}

Et elle évite les pièges de la coercition, puisque null et undefined sont les seuls cas où != retourne false quand on les compare à eux-mêmes.

2. La comparaison avec des valeurs "truthy" ou "falsy"

Parfois, vous voulez juste savoir si une valeur est "truthy" (c'est-à-dire qu'elle ne vaut ni false, ni 0, ni "", ni null, ni undefined, ni NaN). Dans ces cas, != peut être plus expressif :

if (value != false) {
 // Faire quelque chose si value est truthy
}

Bien sûr, vous pourriez écrire if (value), mais cette version est plus explicite sur ce que vous vérifiez réellement. Et surtout, elle évite les surprises avec des valeurs comme 0 ou "" qui sont falsy mais peuvent être valides dans votre contexte.

3. La comparaison avec des chaînes numériques

Imaginez que vous récupériez des données depuis un formulaire web. Les valeurs sont toujours des chaînes de caractères, mais certaines représentent des nombres. Dans ce cas, != peut être utile :

const age = formData.get("age"); // Toujours une chaîne

if (age != 18) {
 // L'utilisateur n'a pas 18 ans
}

Ici, != va convertir la chaîne en nombre avant de faire la comparaison. Si vous aviez utilisé !==, vous auriez dû faire la conversion manuellement :

if (Number(age) !== 18) {
 // L'utilisateur n'a pas 18 ans
}

Les deux versions fonctionnent, mais la première est plus concise. Le piège ? Si age vaut "18a", Number(age) retournera NaN, alors que age != 18 retournera true. Selon votre cas d'usage, l'un ou l'autre peut être préférable.

Pourquoi ces exceptions confirment la règle

Ces cas particuliers montrent bien que le choix entre != et !== n'est pas binaire. Tout dépend du contexte. Mais attention : ces exceptions sont rares. Dans 90% des cas, !== reste le choix le plus sûr. Et c'est précisément parce que ces exceptions existent que vous devez les connaître - pour ne pas les appliquer par erreur dans des situations où elles n'ont pas leur place.

Prenez l'exemple de la vérification null/undefined. Si vous écrivez value != null alors que vous voulez vraiment vérifier que value n'est pas null (et pas undefined), vous introduisez un bug subtil. Autant dire que ces cas particuliers demandent une attention de tous les instants.

Les erreurs courantes qui font planter votre code (et comment les éviter)

1. Confondre null et undefined dans les vérifications

C'est le piège le plus classique, et pourtant il continue de faire des ravages. Prenez ce code :

function getConfig(key) {
 if (config[key] !== null) {
 return config[key];
 }
 return defaultConfig[key];
}

À première vue, ça semble correct. Sauf que si config[key] vaut undefined (parce que la clé n'existe pas), la condition sera évaluée à true. Résultat : la fonction retournera undefined au lieu de la valeur par défaut. Le correctif ? Utiliser != null ou vérifier explicitement undefined :

function getConfig(key) {
 if (config[key] != null) {
 return config[key];
 }
 return defaultConfig[key];
}

Ou, si vous voulez être encore plus explicite :

function getConfig(key) {
 if (config.hasOwnProperty(key)) {
 return config[key];
 }
 return defaultConfig[key];
}

2. Oublier que NaN n'est jamais égal à rien (même à lui-même)

NaN (Not a Number) est un cas particulier en JavaScript. Il n'est égal à aucune valeur, pas même à lui-même. Donc :

NaN == NaN; // false
NaN === NaN; // false
NaN != NaN; // true
NaN !== NaN; // true

Si vous voulez vérifier qu'une valeur est NaN, vous devez utiliser Number.isNaN() ou isNaN() (avec prudence, car cette dernière fait de la coercition). Exemple :

function isReallyNaN(value) {
 return Number.isNaN(value);
}

Pourquoi c'est important ? Parce que si vous écrivez :

if (value !== NaN) {
 // Faire quelque chose
}

Cette condition sera toujours vraie, même si value vaut NaN. Autant dire que votre code ne se comportera pas comme prévu.

3. Comparer des objets ou des tableaux avec != ou !==

En JavaScript, les objets et les tableaux sont comparés par référence, pas par valeur. Donc :

const a = { name: "Alice" };
const b = { name: "Alice" };

a != b; // true (les références sont différentes)
a !== b; // true (les références sont différentes)

Si vous voulez comparer le contenu de deux objets, vous devez utiliser une bibliothèque comme Lodash (_.isEqual()) ou écrire votre propre fonction de comparaison. Exemple :

function shallowEqual(obj1, obj2) {
 const keys1 = Object.keys(obj1);
 const keys2 = Object.keys(obj2);

 if (keys1.length !== keys2.length) {
 return false;
 }

 for (const key of keys1) {
 if (obj1[key] !== obj2[key]) {
 return false;
 }
 }

 return true;
}

Cette version ne fait qu'une comparaison superficielle (elle ne vérifie pas les propriétés imbriquées). Pour une comparaison profonde, il faudrait une approche récursive.

4. Utiliser != ou !== avec des fonctions

Les fonctions sont aussi des objets en JavaScript, et elles sont comparées par référence. Donc :

function sayHello() {
 return "Hello";
}

const a = sayHello;
const b = sayHello;
const c = function() { return "Hello"; };

a != b; // false (même référence)
a != c; // true (références différentes)
a !== b; // false
a !== c; // true

Si vous voulez comparer deux fonctions, vous devez soit :

• Comparer leurs références (si vous savez qu'elles proviennent de la même source)
• Comparer leur code source (en utilisant toString(), mais c'est fragile)
• Comparer leur comportement (en les exécutant avec les mêmes arguments, mais c'est coûteux)

Dans la pratique, on évite généralement de comparer des fonctions. Si vous vous retrouvez à le faire, c'est souvent le signe d'un problème de conception plus profond.

Comment choisir entre != et !== ? Le guide pratique

La règle d'or : utilisez !== par défaut

Si vous ne deviez retenir qu'une seule chose de cet article, ce serait ça : dans 90% des cas, !== est le bon choix. Pourquoi ? Parce qu'il est prévisible, explicite, et qu'il évite les bugs liés à la coercition de type.

Voici une checklist pour décider :

Utilisez !== quand :

• Vous comparez des valeurs dont vous connaissez les types (nombres, chaînes, booléens)
• Vous voulez être sûr que deux valeurs sont exactement identiques (même type, même valeur)
• Vous travaillez sur une base de code partagée (pour éviter les ambiguïtés)
• Vous utilisez TypeScript (qui encourage les comparaisons strictes)
• Vous comparez des valeurs qui pourraient être null ou undefined, mais où la distinction est importante

Utilisez != quand :

• Vous voulez vérifier qu'une valeur n'est ni null ni undefined (value != null)
• Vous comparez des valeurs qui peuvent être de types différents, mais où la coercition est souhaitée (ex : chaînes numériques vs nombres)
• Vous vérifiez des valeurs "truthy" ou "falsy" de manière explicite (value != false)
• Vous optimisez du code critique où la coercition est un choix délibéré (et documenté)

Les questions à se poser avant d'utiliser !=

Avant d'écrire != dans votre code, posez-vous ces questions :

1. Est-ce que je sais exactement quels types je compare ? Si non, !== est probablement plus sûr.
2. Est-ce que la coercition va me causer des problèmes ? Si oui, évitez !=.
3. Est-ce que mon équipe comprend les implications de != ? Si non, privilégiez !== pour éviter les malentendus.
4. Est-ce que je pourrais écrire cette comparaison de manière plus explicite ? Par exemple, value != null est clair, mais value != 0 l'est moins.
5. Est-ce que je teste cette condition ? Si non, utilisez !== pour minimiser les risques.

Si vous répondez "non" à l'une de ces questions, il y a de fortes chances que !== soit le meilleur choix.

Questions fréquentes (et réponses qui évitent les généralités)

Pourquoi JavaScript a-t-il gardé != alors que !== est plus sûr ?

Pour des raisons historiques, tout simplement. Quand JavaScript a été créé en 1995, la coercition de type était vue comme une feature, pas comme un bug. Elle permettait d'écrire du code plus concis, ce qui était important à une époque où les connexions internet étaient lentes et où chaque octet comptait.

De plus, la compatibilité ascendante est un principe sacré en JavaScript. Si != avait été supprimé, des millions de sites auraient cessé de fonctionner du jour au lendemain. Autant dire que les mainteneurs du langage ont préféré garder cette "feature" plutôt que de casser le web.

Et puis, il y a des cas où != est utile - comme on l'a vu plus haut. Le supprimer aurait été contre-productif. La solution ? Éduquer les développeurs sur les dangers de != et encourager l'utilisation de !== par défaut.

Est-ce que != et !== fonctionnent différemment avec les objets ?

Non. Que vous utilisiez != ou !==, les objets sont toujours comparés par référence, pas par valeur. Donc :

const obj1 = { a: 1 };
const obj2 = { a: 1 };
const obj3 = obj1;

obj1 != obj2; // true (références différentes)
obj1 !== obj2; // true
obj1 != obj3; // false (même référence)
obj1 !== obj3; // false

La seule différence entre != et !== dans ce cas, c'est que !== ne fera pas de tentative de coercition avant la comparaison. Mais comme les objets ne peuvent pas être convertis en primitives de manière implicite (sauf si vous définissez une méthode valueOf() ou toString()), le résultat sera le même.

Si vous voulez comparer le contenu de deux objets, vous devez utiliser une fonction dédiée, comme on l'a vu précédemment.

Pourquoi certains linters interdisent-ils complètement != ?

Parce que les linters comme ESLint sont configurés pour encourager les bonnes pratiques, et que != est considéré comme une mauvaise pratique dans la plupart des cas. La règle eqeqeq (qui impose l'utilisation de === et !==) est activée par défaut dans de nombreuses configurations, comme Airbnb ou Standard.

Les raisons de cette interdiction sont multiples :

• Prévisibilité : !== donne toujours des résultats cohérents, contrairement à != qui dépend de la coercition.
• Maintenabilité : Un code qui utilise systématiquement !== est plus facile à comprendre et à modifier.
• Sécurité : != peut introduire des bugs subtils, surtout dans des conditions complexes.
• Consistance : Dans une base de code, mélanger != et !== rend le code moins homogène.

Cela dit, comme on l'a vu, il existe des cas où != est légitime. Dans ces situations, vous pouvez soit :

• Désactiver la règle pour cette ligne spécifique (// eslint-disable-next-line eqeqeq)
• Configurer le linter pour autoriser certains cas (comme value != null)
• Réécrire la condition de manière plus explicite

Comment TypeScript gère-t-il != et !== ?

TypeScript, qui est un sur-ensemble typé de JavaScript, encourage fortement l'utilisation de !==. En fait, le compilateur TypeScript émettra des avertissements si vous utilisez != dans des situations où la coercition pourrait causer des problèmes.

Par exemple, ce code :

const value: number = 5;
if (value != "5") {
 // Faire quelque chose
}

Générera un avertissement du type : "This condition will always return 'false' since the types 'number' and 'string' have no overlap". Parce que TypeScript sait que value est un nombre, et que "5" est une chaîne, donc la comparaison retournera toujours false.

TypeScript va même plus loin : il peut détecter des bugs liés à la coercition que JavaScript pur ne verrait pas. Par exemple :

function process(value: number | null) {
 if (value != null) {
 // value est maintenant de type 'number'
 return value.toFixed(2);
 }
}

Ici, TypeScript comprend que si value != null est vrai, alors value ne peut être que de type number. Il peut donc appliquer le typage correctement, ce qui évite des erreurs à l'exécution.

En résumé, TypeScript rend l'utilisation de !== encore plus sûre, et décourage fortement != sauf dans les cas où la coercition est explicite et souhaitée.

Verdict : faut-il bannir != de son code ?

La réponse n'est pas aussi simple qu'un oui ou un non. != n'est pas intrinsèquement mauvais, mais il est dangereux parce qu'il est facile à mal utiliser. Et dans la pratique, la plupart des bugs liés aux comparaisons viennent d'une utilisation inappropriée de !=.

Voici ce que je recommande :

1. Utilisez !== par défaut. C'est le choix le plus sûr, et celui qui causera le moins de problèmes à long terme.
2. Utilisez != uniquement dans des cas spécifiques et documentés. Par exemple, pour vérifier null/undefined, ou quand la coercition est un choix délibéré.
3. Configurez votre linter pour interdire != sauf exceptions. Cela forcera votre équipe à réfléchir à deux fois avant d'utiliser !=.
4. Testez vos conditions. Si vous utilisez !=, assurez-vous que votre test couvre tous les cas de figure, y compris les valeurs inattendues.
5. Formez votre équipe. Assurez-vous que tout le monde comprend les différences entre != et !==, et les pièges associés.

Et surtout : ne vous sentez pas coupable d'utiliser != quand c'est pertinent. Le but n'est pas d'appliquer des règles dogmatiques, mais d'écrire du code robuste et maintenable. Parfois, != est la meilleure solution. Mais ces cas sont l'exception, pas la règle.

Pour finir, voici une petite anecdote qui résume bien la situation. Un jour, j'ai passé trois heures à déboguer un code qui plantait mystérieusement. Le coupable ? Une simple ligne :

if (user.age != 18) {
 // Autoriser l'accès
}

Le problème ? user.age venait d'un formulaire, donc c'était toujours une chaîne. Et "18" != 18 retourne false. Résultat : les utilisateurs de 18 ans étaient bloqués. Trois heures de debug pour une seule ligne de code. Depuis ce jour, je n'utilise plus != que dans des cas très spécifiques - et toujours avec un commentaire qui explique pourquoi.

Alors oui, != a sa place dans JavaScript. Mais cette place est petite, et elle rétrécit à mesure que les bonnes pratiques se répandent. Dans le doute, utilisez !==. Votre futur vous en remerciera.