Les closures restent l’un des concepts les plus puissants et les plus mal compris du langage. Beaucoup de développeurs croient encore qu’une closure n’est « qu’une fonction qui se souvient de variables extérieures ». En réalité, c’est bien plus subtil : une closure capture la référence vivante vers l’environnement lexical au moment de sa création, et non une copie des valeurs. Cela ouvre la porte à des comportements surprenants lorsque des variables mutables (objets, tableaux) sont capturées. En 2026, avec l’utilisation massive des hooks React, des stores Zustand/Jotai, des middlewares Redux Toolkit et des composants server-components, comprendre précisément quand et comment une closure « garde » une référence est devenu indispensable pour éviter des fuites mémoire et des bugs d’état très difficiles à débusquer.

// Cas classique piégeux en 2026
function createUserUpdater() {
  let user = { id: 42, name: "Léa" };

  return {
    updateName: function(newName) {
      user.name = newName;                // mutate la même référence !
    },
    getUser: function() {
      return user;
    }
  };
}

const manager = createUserUpdater();
manager.updateName("Sofia");
console.log(manager.getUser().name);      // "Sofia"

// Mais si on garde une référence externe...
const leaked = manager.getUser();
leaked.name = "Hacker";               // ← mutate aussi !
console.log(manager.getUser().name);      // "Hacker" 😱

En 2026, l’IIFE n’est plus utilisée pour masquer le scope global comme en 2012. Son rôle a radicalement changé : on s’en sert surtout pour créer des contextes d’exécution jetables, encapsuler des initialisations critiques ou isoler des variables très volatiles dans des fichiers de configuration ou des scripts d’entrée. À l’inverse, les modules ES (type="module") sont devenus la norme absolue pour tout code persistant et réutilisable. La grande différence réside dans le chargement statique des modules ES (hoisting + analyse statique des imports) contre le chargement dynamique et évalué à la volée des IIFE.

En JavaScript intermédiaire-avancé, la maîtrise de this reste un marqueur fort de compétence. En 2026, les flèches functions ont largement remplacé les .bind() manuels, mais il existe encore de nombreux contextes où this échappe au contrôle : les gestionnaires d’événements DOM natifs, les callbacks de bibliothèques tierces, les méthodes appelées via .call() / .apply() implicites, et surtout les décorateurs expérimentaux ou les proxies. La bonne pratique actuelle consiste à adopter systématiquement l’explicitation : soit via arrow function, soit via une variable const self = this; soit via .bind() très tôt dans la chaîne.

// Piège classique encore très fréquent en 2026
class AnalyticsTracker {
  count = 0;

  trackClick() {
    this.count++;
    console.log(`Tracked: ${this.count}`);
  }
}

const tracker = new AnalyticsTracker();

// Erreur classique
document.querySelector("button").addEventListener("click", tracker.trackClick);
// → this === button → this.count undefined

// Solutions 2026 (préférences décroissantes)
// 1. Arrow + propriété de classe (meilleure lisibilité)
trackClick = () => {
  this.count++;
  console.log(`Tracked → ${this.count}`);
};

// 2. .bind() au moment de l’attachement
button.addEventListener("click", tracker.trackClick.bind(tracker));