const vs let en JavaScript : pourquoi const devrait être votre réflexe par défaut

Parmi les habitudes à acquérir tôt en JavaScript, celle-ci est l’une des plus simples et des plus impactantes : utiliser const par défaut. Ne passer à let que lorsqu’une variable doit être réaffectée. Pas avant.

Ça semble anodin. En pratique, ça change la façon dont on raisonne sur son code.

Ce que const garantit réellement

const ne rend pas une valeur immuable. Il interdit la réaffectation de la variable (c’est-à-dire qu’on ne peut pas y assigner une nouvelle valeur après sa déclaration).

const items = [1, 2, 3]
items.push(4)        // ✅ autorisé (on modifie le contenu du tableau)
items = [1, 2, 3, 4] // ❌ erreur (on tente de réaffecter la variable)

La question à se poser n’est donc pas “est-ce que la valeur peut changer”, mais “est-ce que cette variable va un jour pointer vers autre chose”.

L’erreur classique avec les éléments du DOM

C’est l’exemple qui revient le plus souvent chez les développeurs juniors :

// ❌ Mauvais réflexe
let button = document.getElementById('submit-btn')
let form = document.getElementById('contact-form')
let errorMessage = document.getElementById('error')

button.addEventListener('click', handleSubmit)

Le raisonnement derrière ce let : “le bouton peut être désactivé, le formulaire peut être modifié, les messages d’erreur peuvent apparaître et disparaître… donc ça change, donc let.”

C’est une confusion entre la variable et ce qu’elle contient. La variable button pointe toujours vers le même nœud du DOM. On ne la réaffecte jamais. Elle ne change pas. C’est const :

// ✅ Correct
const button = document.getElementById('submit-btn')
const form = document.getElementById('contact-form')
const errorMessage = document.getElementById('error')

button.addEventListener('click', handleSubmit)

Les propriétés de ces éléments (classList, textContent, disabled…) peuvent changer autant qu’on veut (ça n’a aucun rapport avec la constance de la variable).

Quand let est vraiment nécessaire

let est justifié dès qu’une variable est réaffectée après sa déclaration. Les cas concrets :

Un compteur qui s’incrémente :

let count = 0
for (const item of items) {
  if (item.active) count++
}

Note sur le const item : dans un for...of, une nouvelle liaison est créée à chaque itération. item n’est pas réaffecté, il est recréé. C’est pour ça que const est valide ici, contrairement au for classique où i++ réaffecte la même variable.

Un accumulateur :

let total = 0
for (const product of cart) {
  total += product.price
}

Une valeur qui change selon une condition :

let label = 'Inconnu'
if (score >= 90) label = 'Excellent'
else if (score >= 70) label = 'Bien'
else if (score >= 50) label = 'Passable'

L’indice d’une boucle for classique :

for (let i = 0; i < array.length; i++) {
  // i est réaffecté à chaque itération
}

Dans tous ces cas, la variable est réaffectée pendant l’exécution. let est le bon outil.

Pourquoi ce réflexe est utile

1. const documente l’intention. Quand un lecteur voit const, il sait immédiatement que cette variable ne sera pas réaffectée plus loin. Il n’a pas besoin de lire la suite pour le vérifier. let dit l’inverse : attention, cette valeur est susceptible de changer.

2. const prévient les bugs d’inattention. La réaffectation accidentelle d’une variable est une source d’erreur courante. Si le compilateur peut la détecter, autant le laisser faire.

3. const force à clarifier la structure. Si on se retrouve à contourner un const avec un let par habitude, c’est souvent le signal que le code pourrait être restructuré (extraction d’une fonction, renvoi direct d’une valeur, etc.).

Le test simple

À chaque déclaration de variable, posez-vous une seule question :

Cette variable va-t-elle être réaffectée après sa déclaration ?

Si la réponse est non (et c’est le cas de la grande majorité des variables dans un code bien structuré), c’est const. Si la réponse est oui, c’est let. var, on l’oublie.

C’est tout.

Bon dév, et bisou.

Keiro