Appearance
Angular passe à une version majeure par an : ce que cela change (20 juillet 2026)
Depuis plusieurs années, Angular publie une version majeure tous les six mois. Ce rythme devrait bientôt être divisé par deux : l'équipe prépare désormais une version majeure tous les douze mois.
Le changement apparaît dans la pull request officielle angular/angular#69817, ouverte le 16 juillet 2026. Elle a déjà reçu l'approbation de plusieurs membres de l'équipe Angular, mais elle n'est pas encore fusionnée au moment où cet article est publié. La documentation Angular actuellement en ligne affiche donc toujours l'ancien calendrier.
La direction annoncée est néanmoins très claire : Angular 22, sorti le 3 juin 2026, ouvre un cycle plus long et Angular 23 est prévu autour de juin 2027.
Le résumé du nouveau calendrier proposé :
- une version majeure tous les 12 mois, contre 6 mois auparavant ;
- 4 à 6 versions mineures par majeure, contre 1 à 3 auparavant ;
- des correctifs et préversions toujours publiés presque chaque semaine ;
- 24 mois de support pour une nouvelle majeure, contre 18 mois auparavant.
Ce changement ralentit donc la rotation des numéros de version et des ruptures de compatibilité. Il ne signifie pas qu'Angular recevra deux fois moins de fonctionnalités.
Une version majeure n'est pas synonyme de grande fonctionnalité
Pour comprendre cette décision, il faut revenir au versionnement sémantique, souvent appelé SemVer. Une version Angular s'écrit avec trois nombres, par exemple 22.1.3 :
22est la version majeure ;1est la version mineure ;3est le correctif, ou patch.
Le changement de nombre n'indique pas seulement la quantité de nouveautés. Il renseigne surtout sur leur compatibilité.
Une version majeure peut contenir des changements incompatibles qui demandent une migration. Une version mineure peut apporter de nouvelles fonctionnalités tant qu'elles restent rétrocompatibles. Un correctif vise les bugs et présente un risque plus faible.
C'est essentiel ici : attendre douze mois avant Angular 23 n'oblige pas l'équipe à conserver toutes les nouveautés pendant un an. Une API terminée et rétrocompatible peut être publiée dans Angular 22.2, 22.3 ou 22.4. Seuls les changements cassants doivent attendre la prochaine version majeure.
Un membre de l'équipe le confirme dans les échanges de la PR : les versions mineures servaient déjà à introduire des fonctionnalités stables, expérimentales ou en developer preview. La roadmap Angular décrit la même logique : une fonctionnalité est livrée dans la prochaine mineure lorsqu'elle est prête, ou dans la prochaine majeure si elle implique une rupture.
Pourquoi abandonner le rythme de six mois ?
La PR donne deux raisons principales.
Réduire la charge des migrations
La communauté et les entreprises demandent depuis longtemps davantage de temps entre deux versions majeures. Même lorsque ng update automatise une grande partie du travail, une migration ne se limite pas à lancer une commande.
Une équipe doit aussi :
- vérifier la compatibilité des bibliothèques tierces ;
- adapter sa chaîne de build et ses outils de test ;
- exécuter les tests de non-régression ;
- mettre à jour sa documentation interne ;
- déployer progressivement la nouvelle version ;
- accompagner plusieurs applications lorsque l'organisation possède un grand parc Angular.
Répéter cette opération tous les six mois peut donner l'impression d'avoir à peine terminé une migration lorsque la suivante arrive. Avec une seule majeure annuelle, les entreprises disposent d'une fenêtre plus lisible pour planifier ce travail.
Stabiliser les API pour les workflows agentiques
L'équipe cite aussi les workflows agentiques, c'est-à-dire les outils où un agent IA lit, génère, modifie et vérifie du code avec une certaine autonomie.
Ces outils sont sensibles aux changements d'API. Leur documentation, leurs exemples, leurs index de recherche et parfois leurs données d'entraînement peuvent rapidement devenir obsolètes. Une API qui reste stable plus longtemps réduit le risque qu'un agent mélange plusieurs générations d'Angular ou propose une migration qui n'est déjà plus adaptée.
Ce motif ne remplace pas le besoin des développeurs humains. Il le prolonge : une surface d'API plus stable profite autant aux équipes, aux bibliothèques et aux formations qu'aux outils d'IA.
Le support passerait de 18 à 24 mois
Le changement le plus concret pour la maintenance est l'allongement du support des nouvelles versions majeures.
Jusqu'à Angular 21, une majeure bénéficiait normalement de 18 mois de support :
- 6 mois de support actif, avec des mises à jour et correctifs réguliers ;
- 12 mois de support à long terme, ou LTS, limité aux problèmes critiques et aux failles de sécurité.
À partir d'Angular 22, la PR propose 24 mois :
- 12 mois de support actif ;
- puis 12 mois de LTS.
La phase active double donc de durée. La phase LTS, elle, reste d'un an.
Attention à la nuance : LTS ne signifie pas que tous les bugs seront corrigés. La politique Angular réserve principalement cette phase aux nouvelles vulnérabilités de sécurité et aux régressions causées par un changement externe, comme une nouvelle version de navigateur.
Quelles versions d'Angular sont encore maintenues ?
Au 20 juillet 2026, les versions concernées sont Angular 22, 21 et 20. La PR propose le calendrier suivant :
| Version | Situation | Fin du support prévue | Ce qu'il faut retenir |
|---|---|---|---|
| Angular 22 | Support actif | Active jusqu'en juin 2027, puis LTS jusqu'en juin 2028 | Première version à profiter du cycle complet de 24 mois |
| Angular 21 | LTS | Juin 2027 | Version de transition, maintenue jusqu'à l'arrivée prévue d'Angular 23 |
| Angular 20 | LTS | 28 novembre 2026 | Son calendrier existant reste inchangé |
Les versions 2 à 19 ne sont plus supportées. Elles peuvent continuer à fonctionner, mais elles ne reçoivent plus les correctifs de sécurité et de compatibilité couverts par la politique Angular.
Il ne faut donc pas comprendre « 24 mois de support » comme une prolongation automatique de toutes les anciennes versions. Angular 22 obtient le nouveau cycle complet. Angular 21 bénéficie d'un calendrier de transition. Angular 20 conserve sa date de fin de support déjà annoncée.
À terme, le rythme annuel devrait généralement laisser deux majeures supportées en parallèle : la version courante en support actif et la précédente en LTS. Pendant la transition de 2026, trois versions restent temporairement dans la fenêtre de support jusqu'à la fin d'Angular 20.
La politique de dépréciation change de formulation, pas de durée minimale
L'ancien calendrier garantissait qu'une API dépréciée resterait disponible pendant au moins deux versions majeures, soit environ un an avec une majeure tous les six mois.
Avec le rythme annuel, la PR remplace cette règle par au moins une version majeure, toujours pendant environ un an. Le nombre de versions change, mais pas la durée minimale recherchée.
Une API dépréciée ne disparaît donc pas immédiatement. Sa suppression reste réservée à une version majeure, avec une période d'avertissement et un chemin de migration documenté. En revanche, il faut retenir que « présente dans la majeure suivante » ne veut pas dire « présente pendant deux années supplémentaires » : le délai minimal reste d'environ douze mois.
Est-ce qu'Angular va évoluer moins vite ?
Pas nécessairement, et ce n'est pas l'objectif annoncé.
La fréquence des ruptures diminue, pas la fréquence du développement. Angular prévoit davantage de versions mineures, environ une tous les deux mois selon le calendrier proposé. Les correctifs et préversions continuent presque chaque semaine.
Une fonctionnalité rétrocompatible pourra donc arriver aussi vite qu'auparavant. Une fonctionnalité expérimentale pourra continuer à évoluer au fil des mineures. En revanche, une suppression d'API, une migration obligatoire ou une mise à jour de dépendance qui casse la compatibilité devra attendre la majeure annuelle.
Il existe tout de même deux nuances.
Premièrement, certaines évolutions réellement incompatibles pourront patienter plus longtemps avant d'atteindre la version stable. C'est précisément le compromis recherché pour diminuer les migrations imposées aux applications.
Deuxièmement, une majeure annuelle pourrait concentrer davantage de changements cassants. La nouvelle cadence ne garantit pas, à elle seule, une migration minuscule. La politique de dépréciation, les migrations automatisées et la discipline de l'équipe resteront déterminantes.
Il serait donc excessif de conclure qu'Angular ralentit ou que Google réduit son investissement dans le framework. La PR ne donne aucune indication de ce type. Elle promet au contraire de continuer à livrer les fonctionnalités dans les versions mineures.
Ce que les équipes Angular doivent changer
Pour une application maintenue activement, ce nouveau rythme simplifie la planification sans supprimer le besoin de mises à jour régulières.
Une stratégie raisonnable consiste à :
- planifier une migration majeure par an au lieu de deux ;
- continuer à installer les correctifs, en particulier ceux de sécurité ;
- évaluer les versions mineures sans attendre la majeure suivante pour profiter des nouveautés ;
- surveiller les dépréciations dès leur apparition ;
- vérifier que les bibliothèques tierces suivent Angular 22 puis Angular 23 ;
- migrer avant la fin du LTS plutôt que de considérer cette date comme le début du projet de migration.
Le changement ne justifie pas de sauter plusieurs majeures. Le guide ng update demande toujours de migrer les versions majeures dans l'ordre. Accumuler plusieurs années de retard peut donc transformer une migration annuelle prévisible en une succession de mises à jour plus coûteuse.
Un Angular plus stable, pas immobile
Cette nouvelle cadence cherche un équilibre assez pragmatique : moins de ruptures imposées aux projets, mais toujours des fonctionnalités publiées lorsqu'elles sont prêtes.
Si la PR est fusionnée telle quelle, Angular 22 restera la version active jusqu'en juin 2027, recevra plusieurs versions mineures, puis passera en LTS lors de la sortie d'Angular 23. Les équipes gagneront six mois de support total et n'auront plus qu'une migration majeure à planifier chaque année.
La vraie question ne sera donc plus « quelle nouvelle majeure arrive dans six mois ? », mais « quelles fonctionnalités de la série Angular 22 pouvons-nous adopter progressivement avant Angular 23 ? ».