Var, let et const en JavaScript : le trio infernal expliqué (avec une touche de TypeScript)
Disponible en :
Sébastien TIMONER
Expert en développement web et gestion d'équipes techniques, je me spécialise dans la création et l'optimisation de solutions numériques performantes. Grâce à une maîtrise approfondie de technologies modernes comme React.js, Node.js, TypeScript, Symfony, Docker et FrankenPHP, j'assure la réussite de projets SaaS complexes, de la conception à la mise en production, pour des entreprises de divers secteurs.
Salut, toi qui t'arraches les cheveux avec ces fameuses variables en JavaScript ! Tu te demandes quand utiliser var, let ou const sans te ridiculiser en réunion d'équipe ? Ne bouge pas, on va démêler tout ça ensemble, tranquillement et avec le sourire. Au programme : on explore chaque mot-clé, on compare leur portée (globale, fonction, bloc), on rigole un peu du hoisting (ce mécanisme un peu magique de JavaScript), on balance de petits exemples concrets, et on termine par un soupçon de TypeScript. Prêt ? C'est parti !
Commençons par var, le doyen des variables JavaScript. Si JavaScript était une série, var serait le personnage un peu old-school, imprévisible mais attachant. Jusqu'à ES5, on n'avait que lui pour déclarer nos variables. Tu peux toujours l'utiliser aujourd'hui, mais attention : il a quelques particularités qui peuvent surprendre.
var x = 1; var x = 2; ne déclenchera pas d'erreur – JavaScript va juste écraser la première valeur par la seconde. Pratique pour le vieux code, mais source de confusion à éviter dans le nouveau code.Pour illustrer la portée un peu trop large de var, voici un petit exemple :
javascript
Eh oui, même si ce fruit était déclaré à l'intérieur d'un if, le console.log en dehors du bloc l'affiche sans problème. var se moque des frontières de bloc : il est soit global, soit attaché à sa fonction englobante, un point c'est tout.
Et le meilleur (ou le pire) pour la fin : le hoisting. En français on parle de hissage, mais soyons honnêtes, on utilise surtout le terme hoisting. C'est la tendance qu'a var à se déclarer en douce en haut de la portée. JavaScript, lors de l'exécution, fait comme si toutes les déclarations var avaient été « remontées » tout en haut de la fonction. Du coup, tu peux utiliser ta variable avant même sa ligne de déclaration… avec une valeur par défaut un peu étrange. Regardons ça de plus près dans la section hoisting plus bas (spoiler : var adore te surprendre avec undefined).
En résumé, var a rendu de fiers services, mais il est un peu fourbe sur les bords : portée large, redéclaration silencieuse, hoisting imprévisible… On peut faire mieux, et ça tombe bien, ES6 a introduit de nouveaux keywords pour remettre de l'ordre !
En 2015, JavaScript a accueilli let (ainsi que const). Et là, on a eu droit à un petit lifting des variables. let est un peu le cool kid discipliné : il corrige la plupart des bizarreries de var tout en restant flexible.
let x = 1; let x = 2; dans le même bloc, tu auras droit à une jolie erreur SyntaxError: Identifier 'x' has already been declared. Ça évite bien des confusions, avoue.Pour bien voir la différence de portée par rapport à var, comparons avec l'exemple précédent en remplaçant var par let :
javascript
Avec let, une fois sorti des accolades du if, terminé, la variable legume n'est plus définie. Essaie de la loger et bam : ReferenceError. Ça, c'est let qui fait respecter les règles de bonne conduite en scoping.
Et le hoisting dans tout ça ? Les variables let (et const) sont également hoistées, mais différemment. Elles ne sont pas utilisables avant d'être déclarées. Techniquement, le moteur JS sait qu'elles existent dans le bloc (il réserve la mémoire), mais tant que la ligne de déclaration n'est pas exécutée, toute tentative d'accès déclenchera une erreur. On dit que ces variables sont dans la zone morte temporelle (oui, ça fait film d'horreur, mais c'est juste le nom chic pour dire "inaccessibles avant initialisation"). On détaille ce comportement un peu plus loin, mais retiens déjà que let ne te laissera pas faire le fou furieux en utilisant une variable trop tôt.
En pratique, let est devenu le choix par défaut pour les variables qui vont changer au cours du temps. Il apporte de la clarté (portée de bloc) et de la sécurité (pas de redéclaration hasardeuse, pas d'accès avant déclaration). Bref, let est ton nouveau copain pour déclarer des variables temporaires ou modifiables.
Au tour de const ! Introduit en même temps que let, ce mot-clé crée des constantes… ou presque. Disons qu'il crée des variables dont la référence ne changera pas. const a la même portée de bloc que let (fini les var qui se baladent partout) et les mêmes règles de hoisting (zone morte temporelle jusqu'à déclaration). La grande différence, c'est qu'une fois initialisée, la variable ne peut plus être réassignée.
const x; tout seul, ça ne passe pas (erreur SyntaxError directe). Il faut faire const x = 42; par exemple.Regarde ce petit exemple pour bien voir la différence avec une variable modifiable :
javascript
On définit PI comme constant, on peut l'utiliser sans souci tant qu'on ne cherche pas à la changer. Au moment où on essaye de faire PI = 3.15, JavaScript nous arrête net : interdiction de modifier une constante.
Note : Constante ne veut pas dire immuable à 100%. Si la valeur est un objet ou un tableau, tu pourras toujours modifier l'intérieur de l'objet/du tableau. Ce qui ne bouge pas, c'est la variable elle-même (la référence en mémoire). Par exemple :
javascript
Ici, on a pu changer name dans l'objet utilisateur malgré le const. En revanche, réaffecter carrément utilisateur vers un autre objet est interdit. Donc, const = constant, pas modifiable, mais uniquement au niveau de la variable elle-même. Il ne faut pas confondre constance de la variable et immutabilité de la valeur.
javascript
Avec un tableau, c'est la même logique : on peut modifier son contenu (ajouter, supprimer, modifier des éléments) car on ne change que l'intérieur du tableau. Mais on ne peut pas réassigner la variable fruits vers un nouveau tableau. C'est comme si le tableau était une boîte : on peut changer ce qu'il y a dedans, mais pas remplacer la boîte elle-même.
En pratique, const est idéal pour toutes les valeurs qui ne doivent pas changer : par exemple une configuration, une référence, etc. C'est très utilisé et ça rend le code plus robuste (on sait que cette variable ne bougera pas). D'ailleurs, les bonnes pratiques recommandent souvent d'utiliser const par défaut, et de passer à let uniquement quand on sait que la valeur devra changer. Quant à var… eh bien, à moins d'une raison particulière, on l'oublie 😉.
Parlons un peu plus de portée (scope). La portée détermine "où" une variable est accessible dans ton code. Il y a principalement trois niveaux de portée en JavaScript :
En résumé : var est limité à la fonction (ou global), alors que let et const sont limités au bloc courant. Cette différence règle pas mal de pièges classiques. Par exemple :
javascript
Ici, la boucle avec var laisse traîner i en dehors, avec sa valeur finale 3. La boucle avec let, elle, nettoie j en sortant : impossible d'y accéder après coup. En pratique, ça veut dire que tu peux avoir plusieurs variables let nommées pareil dans des blocs différents sans interférence, là où un var unique se serait partagé entre tous ces blocs.
Passons au hoisting, ce mécanisme de hissage des déclarations. C'est souvent source de confusion (et de blagues en réunion), alors clarifions. Le hoisting, c'est le fait que le moteur JavaScript "déplace" en quelque sorte les déclarations de variables et de fonctions en tête de leur scope au moment de l'exécution. En réalité, rien n'est vraiment déplacé dans ton code, c'est juste que JavaScript alloue la mémoire pour tes variables en amont, avant d'exécuter pas à pas.
Faisons un petit test de hoisting dans la pratique :
javascript
Au moment du premier console.log, la variable monVar a bien été créée en mémoire via hoisting, mais sa valeur par défaut est undefined (puisqu'on ne l'a pas encore assignée). Aucune erreur, juste undefined qui s'affiche. Ensuite on assigne "Bonjour", et la seconde fois on obtient la valeur attendue.
Voyons maintenant avec let :
javascript
Ici, le premier console.log provoque une ReferenceError. Pourquoi ? Parce que monLet est hoisté sans initialisation. Il est dans sa zone morte temporelle, inaccessible. JavaScript refuse de nous donner une valeur qui n'existe pas encore réellement. Une fois qu'on exécute let monLet = "Hello";, la variable sort de sa zone morte et obtient "Hello". Le second console.log marche alors parfaitement.
On le voit bien : var se comporte comme un ninja en remontant sa déclaration en haut et en se donnant la valeur undefined en douce, tandis que let/const jouent la sécurité et empêchent tout usage tant qu'ils ne sont pas initialisés. Moralité : évite de coder en comptant sur le hoisting, c'est un coup à se faire des nœuds au cerveau (et à sortir des undefined inattendus). Mieux vaut déclarer tes variables en haut de leurs scopes et garder ton code clair. Si tu oublies, le comportement de let/const te rappellera à l'ordre avec une erreur, là où var t'aurait laissé patauger avec un undefined.
Ah, et tant qu'on y est, note que les fonctions déclarées classiquement (function maFonction() \{ ... \}) sont aussi hoistées entièrement. Tu peux appeler une fonction déclarée plus bas dans ton code, JavaScript la connaîtra déjà. Mais attention, les fonctions fléchées ou expressions de fonction assignées à des variables, elles, suivent les règles de hoisting de var/let selon le mot-clé utilisé (sujet pour un autre jour 😉).
Avant de se quitter, parlons vite fait de TypeScript. Si tu commences à utiliser TypeScript (le super-set de JavaScript qui ajoute le typage statique), tu retrouveras nos trois compères var, let et const. Bonne nouvelle : leurs comportements en portée et hoisting restent exactement les mêmes qu'en JavaScript pur, puisque TypeScript se compile en JavaScript standard. Cependant, TypeScript apporte sa touche perso côté typage, et ça vaut le coup d'œil, surtout pour let et const.
let fruit = "pomme";, TypeScript va inférer que fruit est de type string. Si tu écris let age = 25;, il comprendra que age est un number, etc. Pour let, il reste assez large : la variable peut changer, donc le type est celui de base (string, number, etc.).typescript
La variable couleur est de type "rouge" et pas juste string. Intérêt ? Si plus loin ton code attend précisément la valeur "rouge" ou "bleu" (par exemple un paramètre qui ne peut être que l'une de ces couleurs), et que tu as const couleur = "rouge", tu pourras le passer sans souci. Avec un let couleur = "rouge" (type string large), TypeScript aurait râlé car "rouge" n'est qu'une possibilité parmi tous les string. En bref, const en TypeScript permet d'être ultra précis sur le type quand c'est utile. C'est comme un bonus qui renforce encore la notion de constante.
console.log(maVar); var maVar = 3;, il te signalera que tu as un problème de portée ou d'ordre. Idem pour un let utilisé trop tôt, TS connaît les règles de hoisting et te protégera (autant que possible) des bêtises.En résumé, TypeScript ne change pas les règles fondamentales de var/let/const, mais il les renforce avec le filet de sécurité du typage. Tu gagnes en clarté et en erreurs attrapées plus tôt. Retiens surtout que const en TypeScript, c'est doublement gagnant : une variable non réassignable et un type littéral précis – que demander de plus ?
On a fait le tour du propriétaire, alors qui est le gagnant du match var vs let vs const ? Sans grande surprise : en 2025, le duo let & const l'emporte haut la main pour écrire du code propre et maintenable. Voici un petit récap épicé de conseils pratiques :
Voilà, tu sais maintenant quand utiliser var, let ou const en JavaScript, et même un peu comment ça se passe côté TypeScript. Plus question de confondre nos trois compères ni de te faire chambrer en revue de code parce que tu as sorti un var de ton chapeau sans raison valable. Allez, file coder sereinement, et n'oublie pas : const autant que possible, let si nécessaire, et var… le moins possible ! Bon dev !