🚦 Angular 22 : signals, zoneless et cycle annuel, ce qui a vraiment changé

📚 Introduction

Le reproche le plus fréquent qu’on fait à Angular, c’est d’être lourd et daté. Zone.js qui patche la moitié des API du navigateur, la change detection qui repasse partout pour rien, RxJS obligatoire dès qu’on veut afficher une liste. Ce reproche a été justifié. Il ne l’est plus vraiment.

Entre la v20 et la v22, le framework a changé de fondations réactives, s’est débarrassé de zone.js par défaut, et a modifié sa stratégie de détection de changements. Et il a fait autre chose, dont on parle beaucoup moins mais qui pèse sans doute plus lourd sur un projet client : il a doublé la durée entre deux versions majeures.

Dernier article de la série, après la thèse framework contre bibliothèque et le tour du tooling.

🔍 Zoneless : c’est quoi, et depuis quand ?

Zone.js, c’est la bibliothèque qui patchait setTimeout, les événements DOM et les promesses pour prévenir Angular qu’il s’était peut-être passé quelque chose. Le mot important est peut-être : zone.js n’a aucune idée de si l’état a réellement changé, il signale juste qu’une tâche asynchrone s’est terminée. Résultat : beaucoup de synchronisations inutiles, du poids en plus dans le bundle, et des stack traces difficiles à lire.

Le mode zoneless supprime cette couche. Angular se fie à des notifications explicites : mise à jour d’un signal lu dans un template, callback d’un listener, ComponentRef.setInput, markForCheck.

La chronologie exacte, parce qu’elle traîne souvent fausse dans les articles de blog :

• v20.2.0 (août 2025) : zoneless passe stable.
• v21 (novembre 2025) : zoneless devient le défaut, avec une migration fournie.
• v20 et antérieures : il faut l’activer explicitement.

// Sur un projet en v20 uniquement — en v21+ c'est le comportement par défaut
bootstrapApplication(MyApp, {
	providers: [provideZonelessChangeDetection()]
});

Sur un projet déjà migré, il reste à retirer zone.js des polyfills dans angular.json (cibles build et test), puis à désinstaller le paquet. C’est le genre de détail qu’on oublie, et qui laisse une dépendance entière dans le bundle alors qu’elle ne sert plus à rien.

🧩 Signals, la nouvelle base réactive

La v20 a stabilisé les primitives : linkedSignal, toSignal, toObservable. La suite logique est arrivée avec les API asynchrones, resource() et httpResource(), qui exposent l’état d’un chargement sous forme de signaux plutôt que d’observables à souscrire.

readonly filtre = signal('');
readonly factures = httpResource(() => `/api/factures?q=${this.filtre()}`);

Quand filtre change, la requête repart et l’ancienne est annulée. Aucune souscription à gérer, aucun takeUntilDestroyed à ne pas oublier. RxJS reste disponible et pertinent pour les flux vraiment complexes — mais il n’est plus le ticket d’entrée obligatoire.

🧱 Ce que la v22 change concrètement

Angular 22 est sorti le 3 juin 2026 (@angular/core est en 22.1.0 à l’heure où j’écris). Les changements qui se voient :

• OnPush devient la stratégie de détection par défaut. Un composant qui ne précise rien est désormais en OnPush. L’ancien comportement s’appelle maintenant ChangeDetectionStrategy.Eager — Default a été renommé — et une migration ajoute automatiquement Eager là où c’est nécessaire.
• L’hydratation incrémentale devient le comportement par défaut côté rendu serveur.
• Signal Forms passent en API publique, dans @angular/forms/signals.
• @angular/aria est stabilisé : des primitives accessibles à styler soi-même.
• Nouveau décorateur @Service, qui remplace le @Injectable({ providedIn: 'root' }) écrit machinalement.
• TypeScript 6.0 minimum : le support de TS 5.9 est abandonné.
• Dépréciations côté HTTP : HttpClient.jsonp et HttpClientJsonpModule, withFetch (qu’on peut simplement supprimer), et reportProgress remplacé par reportUploadProgress et reportDownloadProgress.

Le renommage Default → Eager est mon préféré, parce qu’il est honnête : appeler « défaut » la stratégie la plus coûteuse était trompeur depuis longtemps.

💸 Le cycle annuel change le calcul de maintenance

C’est le changement dont personne ne parle et qui, sur une mission client, compte autant que le reste.

Jusqu’à la v22, Angular sortait une majeure tous les six mois. Depuis la v22, c’est une majeure tous les douze mois, avec quatre à six mineures entre les deux et un patch quasi hebdomadaire. La v23 est attendue autour de juin 2027.

La fenêtre de support annoncée est de vingt-quatre mois : douze mois de support actif, puis douze mois de LTS limité aux correctifs critiques et de sécurité. Concrètement, la v22 est en support actif jusque juin 2027 et en LTS jusque juin 2028. Les versions sorties sous l’ancien rythme sont plus courtes : le support actif de la v21 s’est arrêté à la sortie de la v22, en juin 2026, et son LTS court jusque juin 2027.

Traduit en budget : un projet qui reste sur une majeure supportée doit désormais planifier une montée de version par an au lieu de deux, et il dispose de deux ans avant qu’une version ne sorte complètement du support. À cela s’ajoute la politique de dépréciation — une API dépréciée reste présente au moins une majeure, soit environ douze mois, et n’est supprimée qu’en majeure.

Sur un projet client de cinq ans, ça donne un plan de maintenance qu’on peut réellement chiffrer à l’avance. Compare ça à une pile assemblée où chaque dépendance a son propre calendrier, sa propre définition d’un breaking change, et parfois personne pour la maintenir.

⚠️ Quelques précautions

• Les migrations ng update sont bonnes, pas infaillibles. Sur la migration Eager, relis le diff : un composant qui dépendait implicitement de la détection systématique peut cesser de se rafraîchir sans erreur visible.
• TypeScript 6 est un prérequis dur en v22. Si une dépendance de ton projet plafonne à TS 5.x, règle ça avant de lancer la montée.
• Le code zone-dépendant existant — celui qui fait des mutations d’état hors des mécanismes de notification d’Angular — casse silencieusement en zoneless. C’est le vrai point dur des vieilles bases de code, pas le framework lui-même.
• Une majeure par an, ce n’est pas une majeure optionnelle. Le rythme plus lent est un confort, pas une permission de rester quatre ans sur la même version.

🎉 Conclusion

L’Angular de 2026 est un framework sans zone.js, réactif par signaux, OnPush par défaut, avec des formulaires typés adossés à ces mêmes signaux et un cycle de releases annuel. Si ton dernier contact avec lui remonte aux NgModules et aux Subject partout, l’écart est considérable.

Ce qui ne change pas, et qui reste pour moi l’argument principal, c’est ce que je défendais au début de cette série : toutes ces briques avancent ensemble, sous le même numéro de version, avec un chemin de migration outillé. C’est ce qui rend un projet frontend chiffrable sur cinq ans plutôt que gérable au coup par coup.

🔗 Liens utiles

• Angular sans ZoneJS (zoneless)
• Versioning, cadence et politique de support
• Guide des signals
• CHANGELOG.md du dépôt angular/angular
• Guide de mise à jour Angular