Fin du support d’Angular 20 le 28 novembre 2026 : vers quelle version migrer

Angular 20 reçoit des correctifs de sécurité jusqu’au 28 novembre 2026. Après cette date, l’équipe Angular de Google ne publie plus rien pour cette version. Ce guide donne les dates exactes, ce que la fin du support change, la version vers laquelle migrer, l’ordre des mises à jour et les changements à vérifier entre Angular 20 et Angular 22.

Il s’adresse aux dirigeants techniques, aux DSI et aux responsables d’applications dont le front-end tourne encore en Angular 20. La mise à jour des applications web fait partie de notre offre de développement web et de la maintenance applicative.

Quand le support d’Angular 20 s’arrête-t-il ?

Le support d’Angular 20 s’arrête le 28 novembre 2026, à la fin de sa période de support long terme. La règle est publiée par l’équipe Angular : une version majeure est en général supportée 24 mois, soit 12 mois de support actif, avec des mises à jour régulières, puis 12 mois de support long terme, limité aux correctifs critiques et de sécurité.

Angular 20 est sortie le 28 mai 2025. Son support actif s’est terminé le 19 novembre 2025, à la sortie d’Angular 21 ; depuis, elle ne reçoit plus que des correctifs de sécurité et de régression. Sa dernière version publiée à ce jour est la 20.3.35, du 2 novembre 2026.

Les versions 2 à 19 d’Angular ne sont plus supportées : une application encore en Angular 19, ou plus ancienne, est déjà dans la situation qui attend Angular 20.

Que se passe-t-il après le 28 novembre 2026 ?

Après le 28 novembre 2026, une application Angular 20 continue de fonctionner normalement, mais aucune faille découverte ensuite dans le framework ne sera plus corrigée pour elle. Rien ne casse le 29 novembre : c’est le risque qui grandit, à mesure que les correctifs ne sont publiés que pour Angular 21 et 22.

• La sécurité. Le support long terme couvre précisément les failles nouvellement identifiées. Après le 28 novembre, une faille qui touche aussi Angular 20 reste ouverte.
• Les navigateurs. Pendant le support long terme, l’équipe Angular corrige aussi les régressions causées par un changement extérieur, comme une nouvelle version de navigateur. Cette protection s’arrête en même temps.
• Les dépendances. Les bibliothèques de composants et les outils suivent les versions récentes : une application restée en Angular 20 se retrouve peu à peu bloquée sur d’anciennes versions de ses dépendances.
• Les exigences de vos clients et de vos audits. Si un contrat, un client ou un audit de sécurité exige des composants maintenus, Angular 20 devient un écart à justifier.

Des sociétés tierces vendent un support payant pour les versions d’Angular sorties du support officiel. Il achète du temps, pas une solution : la migration reste à faire. La démarche est la même que pour un langage serveur en fin de vie, décrite dans notre article sur la fin du support de PHP 8.2.

Angular 21 ou Angular 22 : vers quelle version migrer ?

Pour quitter Angular 20, la version cible à privilégier est Angular 22 : c’est la version active, sortie le 3 juin 2026, et elle sera supportée jusqu’en juin 2028.

• Angular 22, le choix par défaut. Supportée jusqu’en juin 2028. Les nouveautés introduites en Angular 21 y sont devenues stables, notamment les formulaires à base de signaux et les API resource : les nouveaux écrans ne reposent plus sur des API expérimentales.
• Angular 21, une étape et pas une cible. Elle est déjà en support long terme et s’arrête en juin 2027 : s’y arrêter, c’est refaire la même opération dans sept mois.
• Angular 21 comme cible provisoire, seulement si un composant l’impose. Quand une bibliothèque indispensable n’est pas encore compatible avec Angular 22, ou quand l’environnement ne peut pas encore passer à TypeScript 6 ni quitter Node.js 20.

Peut-on passer directement d’Angular 20 à Angular 22 ?

Non : la commande ng update ne fait passer qu’une version majeure à la fois. Pour aller d’Angular 20 à Angular 22, on passe d’abord en Angular 21, puis en Angular 22.

Si l’on demande un saut de plusieurs versions majeures, l’outil s’arrête avec le message « Updating multiple major versions … at once is not supported » et indique la commande à lancer pour la version suivante. Chaque étape applique les migrations automatiques de sa version, qui réécrivent le code là où un comportement change : les sauter reviendrait à les faire à la main.

Les deux commandes, dans l’ordre : ng update @angular/cli@21 @angular/core@21, puis, une fois la version 21 testée, ng update @angular/cli@22 @angular/core@22. Le guide de mise à jour interactif de l’équipe Angular liste, pour chaque étape, les points à vérifier selon la complexité de l’application.

Comment migrer d’Angular 20 vers Angular 22 ?

Une migration d’Angular 20 vers Angular 22 se fait en deux mises à jour successives, chacune testée avant la suivante, après une mise à niveau de l’environnement. Les étapes, dans l’ordre :

• Faire l’inventaire. Version exacte d’Angular, versions de Node.js et de TypeScript, bibliothèques de composants et leur compatibilité avec Angular 21 et 22, outil de tests, chaîne de construction. Un audit rapide de l’existant répond à ces questions.
• Mettre l’environnement à niveau. Angular 22 accepte Node.js 22.22.3, 24.15 ou 26, et plus Node.js 20 ; TypeScript 5.9 pour Angular 21, puis TypeScript 6 pour Angular 22. Les serveurs d’intégration continue et les images de déploiement sont concernés aussi.
• Passer en Angular 21. Lancer ng update, relire les migrations appliquées, construire l’application et lancer les tests.
• Passer en Angular 22. Même chose, puis traiter à la main ce que les migrations ne couvrent pas, à commencer par le routeur (voir la section suivante).
• Tester l’application. Les parcours critiques, les formulaires, la navigation, les appels au serveur, et le rendu côté serveur s’il est utilisé. Une campagne de tests préparée avant la migration sert de référence.
• Livrer et surveiller. Une mise en production annoncée, avec un retour arrière prêt, puis le suivi des erreurs remontées par les navigateurs.

Qu’est-ce qui change entre Angular 20 et Angular 22 ?

Entre Angular 20 et Angular 22, la plupart des changements de comportement sont couverts par des migrations automatiques qui conservent le fonctionnement existant. Quelques points demandent pourtant une vérification, ou une intervention à la main.

En passant à Angular 21 :

• Sans Zone.js par défaut. Les nouvelles applications n’utilisent plus Zone.js pour détecter les changements. Pour une application existante qui en dépend, la migration ajoute provideZoneChangeDetection() : son comportement ne change pas. Se passer réellement de Zone.js est un chantier à part, à planifier.
• Vitest pour les tests. Les nouveaux projets utilisent Vitest ; Karma reste utilisable mais il est déprécié, et une migration optionnelle convertit les tests Jasmine. Les tests qui utilisent fakeAsync se réécrivent à la main.
• HttpClient fourni par défaut. provideHttpClient() ne sert plus qu’à personnaliser le client, par exemple pour ajouter des intercepteurs.
• TypeScript 5.9. Angular 21 demande TypeScript 5.9 au moins.

En passant à Angular 22 :

• TypeScript 6 et Node.js. Angular 22 exige TypeScript 6 et abandonne Node.js 20. Node.js 22 n’étant lui-même supporté que jusqu’au 30 avril 2027, mieux vaut viser Node.js 24 ou 26.
• OnPush par défaut. La stratégie de détection des changements par défaut devient OnPush. La migration ajoute la stratégie Eager, l’ancien « Default », aux composants qui n’en déclaraient pas, pour garder leur comportement.
• HttpClient sur l’API Fetch. Le client HTTP utilise désormais Fetch ; la migration ajoute withXhr() là où il faut garder l’ancienne implémentation. Le suivi de progression des envois de fichiers n’est pas pris en charge avec Fetch.
• Contrôle strict des templates. strictTemplates est activé par défaut ; la migration le désactive explicitement là où il ne l’était pas. L’activer ensuite fait apparaître des erreurs de types utiles.
• Le routeur. paramsInheritanceStrategy vaut désormais « always » : les routes enfants héritent des paramètres de leurs parents. Aucune migration n’est fournie : pour garder l’ancien comportement, il faut indiquer « emptyOnly » à la main.
• Le chaînage optionnel dans les templates. Une expression comme project?.author renvoie désormais undefined au lieu de null, comme en TypeScript ; une migration encadre les expressions concernées.
• Webpack. Le constructeur basé sur webpack (@angular-devkit/build-angular) est déprécié : une application qui l’utilise encore a intérêt à passer au constructeur « application » d’Angular.

Une application qui a pris du retard sur ses versions cache souvent d’autres retards, dans le code comme dans l’infrastructure : c’est une part de la dette technique, et son rattrapage relève de la maintenance évolutive.

Questions fréquentes

Angular 20 : fixez maintenant la date de la migration

Le 28 novembre 2026 ne casse rien, mais il ouvre une période où chaque faille découverte dans le framework reste ouverte sur Angular 20. La décision tient en trois points : la version cible (Angular 22), l’ordre des étapes (21, puis 22), et une date de livraison pour chacune, fixée après l’inventaire des dépendances.

L’équipe iones met à jour des applications Angular, de l’inventaire à la mise en production, dans le cadre de son offre de développement web, et les tient à jour dans la durée avec la maintenance applicative. Pour faire le point sur vos applications, écrivez-nous.