Le rythme des versions et la durée de support
Angular annonce désormais une version majeure tous les 12 mois, avec quatre à six mineures par majeure. Jusqu'à Angular 22, le cycle était de six mois. Chaque majeure est en principe soutenue 24 mois : 12 mois de support actif, puis 12 mois de support à long terme (LTS), limité aux correctifs critiques et de sécurité.
Les versions encore soutenues au 27 octobre 2026, selon angular.dev :
| Version | Sortie | Fin du support actif | Fin du LTS |
|---|---|---|---|
| Angular 22 | 3 juin 2026 | juin 2027 | juin 2028 |
| Angular 21 | 19 novembre 2025 | 3 juin 2026 | juin 2027 |
| Angular 20 | 28 mai 2025 | 19 novembre 2025 | 28 novembre 2026 |
Les versions 2 à 19 ne sont plus soutenues. Angular 23 est annoncé vers juin 2027. Les versions sorties sous l'ancien cycle avaient un support plus court : Angular 20 aura été soutenu 18 mois.
La règle : une majeure à la fois
angular.dev pose deux conditions pour ng update : la version visée doit être soutenue, et la version de départ doit être à une majeure au plus de la version visée. Pour passer de 19 à 21, on passe donc par 20.
Ce n'est pas une formalité : ng update exécute des migrations automatiques (schematics) qui réécrivent votre code pour la version suivante. Elles ne s'enchaînent que d'une majeure à la suivante, d'où la règle. Si vous changez les numéros de version dans package.json puis lancez npm install, aucune migration ne tourne.
Avant de lancer ng update
- Un arbre Git propre.
ng updaterefuse par défaut de travailler sur un dépôt qui a des fichiers modifiés ou non suivis (l'option--allow-dirtylève ce garde-fou ; évitez-la). Créez une branche dédiée. - Des vérifications au vert : lint, tests unitaires, build de production, tests de bout en bout s'il y en a. Sans cela, vous ne saurez pas si une erreur vient de la mise à jour.
- Node.js et TypeScript à la version demandée par la cible, d'après le tableau de compatibilité d'angular.dev :
| Angular | Node.js | TypeScript |
|---|---|---|
| 20.2 et 20.3 | ^20.19.0, ^22.12.0 ou ^24.0.0 | 5.8 à 5.9 |
| 21 | ^20.19.0, ^22.12.0 ou ^24.0.0 | 5.9 |
| 22 | ^22.22.3, ^24.15.0 ou ^26.0.0 | 6.0 |
Angular 22 abandonne Node.js 20 : pensez à l'image de vos agents d'intégration continue, à vos conteneurs de build et aux postes des développeurs.
- Le guide officiel pour votre saut de version : l'Update Guide d'angular.dev génère la liste des changements à faire selon la version de départ, la version d'arrivée et la complexité de l'application.
Les étapes, pour un saut d'une majeure
Exemple pour passer d'Angular 20 à 21 :
git switch -c maj/angular-21
npx ng update @angular/core@21 @angular/cli@21 --create-commits--create-commits produit un commit par mise à jour et par migration : la relecture est plus facile, et vous pouvez annuler une migration précise.
Ensuite, dans l'ordre :
- Les paquets qui suivent Angular :
ng update @angular/material@21si vous utilisez Material et le CDK, puis l'outillage, par exempleng update angular-eslint. - Les bibliothèques tierces : chacune doit avoir une version compatible avec la nouvelle majeure (voir plus bas).
- Les vérifications : types, lint, tests, build, tests de bout en bout. Corrigez dans cet ordre : une erreur de typage provoque souvent des échecs en cascade plus loin.
- Les dépendances : relisez
npm auditet la sectionoverridesdepackage.json. Une surcharge ajoutée pour une ancienne faille peut être devenue inutile, voire bloquante. - La fusion, puis le saut suivant si vous visez plus loin. Ne cumulez pas deux majeures dans une même demande de fusion.
Les mises à jour mineures et correctives se font à tout moment, entre deux majeures, avec les mêmes vérifications.
Les pièges les plus fréquents
Les bibliothèques tierces qui bloquent
C'est la cause la plus courante d'un ng update qui échoue sur des dépendances de pair : une bibliothèque de composants exige le CDK de la même majeure, une bibliothèque d'état exige la même version d'Angular. Avant de commencer, vérifiez pour chaque bibliothèque qu'une version compatible avec la cible existe. Si c'est le cas, passez-les dans la même commande que le framework pour que les dépendances de pair se résolvent ensemble :
npx ng update @angular/core@21 @angular/cli@21 @ngrx/storeSi une bibliothèque n'a pas encore de version compatible, attendez-la ou remplacez-la : forcer ne fait que déplacer l'erreur à l'exécution.
L'option --force
--force ignore les incompatibilités de dépendances de pair. Elle fait passer la commande, pas l'application : une bibliothèque compilée pour la majeure précédente peut casser à la compilation ou, pire, à l'exécution. Réservez-la au cas où vous savez pourquoi le conflit est sans effet.
Les migrations qui n'ont pas tourné
Si quelqu'un a déjà monté les paquets à la main, les migrations peuvent être relancées seules :
npx ng update @angular/core --migrate-only --from=20 --to=21--from et --to ne fonctionnent qu'avec --migrate-only et pour un seul paquet.
Node.js, npm et l'intégration continue
Une mise à jour qui passe en local et échoue en CI vient presque toujours d'une version de Node.js différente. Fixez la version (fichier .nvmrc, champ engines, image de CI) dans la même branche que la mise à jour. Côté npm, l'outil ngm documente une erreur Cannot read properties of null (reading 'edgesOut') pendant la montée vers Angular 21, due à npm 10 ; passer à npm 11 la résout.
Les dépréciations accumulées
Une API dépréciée reste disponible au moins pendant la majeure suivante, soit au moins 12 mois, et n'est retirée qu'à une version majeure. Traitez les avertissements de dépréciation à chaque saut : ce sont les erreurs de compilation du saut suivant.
Organiser la maintenance dans le temps
Avec une majeure par an et 24 mois de support, une application tenue à jour une fois par an reste toujours sur une version soutenue. Le risque vient du retard : plus il y a de majeures à rattraper, plus les bibliothèques tierces divergent et plus chaque saut coûte. Inscrivez la montée de version au calendrier dès la sortie d'une majeure, et faites les mineures au fil de l'eau.
Se faire aider
Deux produits du studio couvrent ce sujet. Maintenance Angular est un abonnement : un développeur Angular établit chaque mois un diagnostic (support, failles, dépendances), livre les mises à jour seulement si votre lint, vos tests et votre build passent, et fait les montées de majeure selon le palier, dans votre dépôt et à distance. Il ne couvre ni le back-end, ni le déploiement en production, ni les migrations depuis AngularJS. Socle est un starter Angular 22 pour un nouveau projet, livré avec ses contrôles qualité en une commande et un guide de mise à jour ; il ne met pas à jour une application existante.
Sources
- angular.dev, Angular versioning and releases
- angular.dev, Version compatibility
- angular.dev, ng update
- angular.dev, Update Guide
- Socle, guide de mise à jour (docs/mise-a-jour.md)
- ngm, maintenance d'une application Angular (README, src/support.mjs)
- Pages relues le 2026-10-27