Nouveautés d'Angular 22 (3 juin 2026)

Angular 22 est officiellement disponible. Le tag v22.0.0 a été publié sur GitHub le 3 juin 2026, dans la fenêtre annoncée par le calendrier officiel d'Angular pour la semaine du 1er juin 2026.

Cette version n'est pas seulement une addition de petites APIs. Elle pousse Angular un cran plus loin vers son modèle moderne : composants plus prévisibles, réactivité par Signals, asynchrone mieux représenté, SSR plus automatique, et moins d'anciennes abstractions à maintenir.

Le résumé court :

• OnPush devient la stratégie de détection de changements par défaut pour les composants qui ne précisent rien.
• ChangeDetectionStrategy.Eager sert à conserver explicitement l'ancien comportement.
• Les Signal Forms arrivent dans la surface publique d'Angular 22, avec de nouvelles APIs comme FormField, FormRoot, SignalFormControl, getError() et reloadValidation().
• @Service() et injectAsync() modernisent l'injection de dépendances.
• provideExperimentalWebMcpTools() et declareExperimentalWebMcpTool() confirment l'orientation IA d'Angular.
• FetchBackend devient le backend HTTP par défaut.
• L'hydratation incrémentale devient le comportement par défaut côté navigateur.
• Plusieurs APIs historiques disparaissent : ComponentFactoryResolver, ComponentFactory, createNgModuleRef, provideRoutes(), l'intégration Hammer.js, etc.

Voyons ce que cela change vraiment pour une application Angular.

OnPush devient le comportement par défaut

C'est probablement le changement le plus structurant d'Angular 22.

Jusqu'ici, un composant sans configuration utilisait la stratégie historique de détection de changements, aujourd'hui nommée Default. Angular 21.2 avait introduit l'alias ChangeDetectionStrategy.Eager pour préparer la transition : Eager décrit mieux ce comportement, car Angular vérifie plus largement les composants.

Avec Angular 22, un composant sans changeDetection devient OnPush par défaut.

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `{{ count() }}`
})
export class CounterComponent {
  count = signal(0);
}

Ce composant est implicitement OnPush.

Ce changement a du sens dans un monde où l'état lu par les templates est de plus en plus porté par des Signals. Quand un Signal change, Angular sait précisément quel template doit être mis à jour. Il n'a plus besoin de vérifier toute une grande portion de l'arbre de composants "au cas où".

Pour garder l'ancien comportement, il faut l'écrire :

import { ChangeDetectionStrategy, Component } from '@angular/core';

@Component({
  selector: 'app-legacy-panel',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `{{ title }}`
})
export class LegacyPanel {
  title = 'Ancien comportement';
}

La migration Angular 22 ajoute ChangeDetectionStrategy.Eager là où c'est nécessaire afin d'éviter qu'une application existante change brutalement de comportement. C'est donc moins une rupture immédiate qu'un nouveau défaut pour le futur.

Le point à surveiller dans vos composants : les mutations de champs classiques.

items.push(newItem);

Sous OnPush, ce type de mutation silencieuse est plus fragile. Préférez un état réactif et immuable :

items.update((value) => [...value, newItem]);

Si votre application est déjà largement passée aux Signals, cette évolution devrait être naturelle. Si elle repose encore beaucoup sur des propriétés mutées dans des callbacks, la migration mérite une vraie passe de tests.

Les Signal Forms deviennent beaucoup plus concrets

Les Signal Forms étaient l'une des grandes annonces d'Angular 21. Angular 22 les fait entrer dans une phase beaucoup plus exploitable : plusieurs symboles apparaissent maintenant dans la surface publique @publicApi 22.0 des types publiés. La documentation peut toutefois garder des mentions expérimentales selon les pages, donc il faut lire cette évolution comme une consolidation importante, pas comme un signal pour migrer tous les formulaires dès maintenant.

Le principe reste le même : le modèle du formulaire est un Signal, et Angular construit un arbre de champs autour de ce modèle.

import { Component, signal } from '@angular/core';
import { FormField, form, required, schema } from '@angular/forms/signals';

@Component({
  selector: 'app-login',
  imports: [FormField],
  template: `
    <input [formField]="loginForm.email">
  `
})
export class LoginComponent {
  login = signal({ email: '' });

  loginForm = form(this.login, schema((path) => {
    required(path.email);
  }));
}

La syntaxe importante en Angular 22 est [formField]. Elle remplace l'ancien réflexe de lier un champ de formulaire avec une directive nommée Field dans les exemples de Developer Preview.

Angular 22 ajoute aussi des briques très utiles pour des cas réels :

• FormRoot pour lier un arbre de formulaire à un élément <form>.
• FieldState.getError() pour récupérer une erreur précise de manière réactive.
• FieldState.reloadValidation() pour relancer les validations asynchrones.
• validateAsync() et validateHttp() avec option de debounce.
• SignalFormControl dans @angular/forms/signals/compat pour faire le pont avec les Reactive Forms.
• FormValueControl et FormCheckboxControl pour les composants personnalisés orientés Signal Forms.

Il faut garder une nuance : cela ne signifie pas que toutes les applications doivent migrer leurs formulaires existants dès aujourd'hui. Les Reactive Forms restent supportés et indispensables dans beaucoup de bases de code. En revanche, pour un nouveau formulaire complexe, Angular 22 donne enfin une API Signal Forms beaucoup plus sérieuse que le simple aperçu d'Angular 21.

Resource, httpResource et debounced : l'asynchrone côté Signals

Angular 22 continue aussi le travail autour de la Resource API.

Une Resource représente une donnée asynchrone sous forme réactive : valeur, chargement, erreur, rechargement, annulation. C'est plus riche qu'un simple Promise, et plus directement compatible avec les Signals qu'un Observable utilisé seul.

La release ajoute notamment :

• la possibilité de cacher des Resources pendant le SSR ;
• des statuts spéciaux pour les paramètres de Resources ;
• des valeurs synchrones pour les stream Resources ;
• des correctifs de fuite de souscription pour rxResource et httpResource ;
• debounced() dans @angular/core, qui retourne une Resource représentant une version temporisée d'un Signal.

Exemple simple :

import { Component, debounced, signal } from '@angular/core';

@Component({
  selector: 'app-search',
  template: `{{ query.value() }}`
})
export class SearchComponent {
  search = signal('');
  query = debounced(this.search, 300);
}

Le but n'est pas de remplacer RxJS partout. Le but est de rendre les dépendances asynchrones plus lisibles quand elles dépendent directement d'un état Signal.

@Service() et injectAsync()

Angular 22 introduit officiellement @Service() dans @angular/core.

Nous avions déjà détaillé cette API dans l'article sur le décorateur @Service(). La version publiée confirme l'intention : simplifier le cas le plus courant des services auto-fournis.

import { Service, signal } from '@angular/core';

@Service()
export class PreferencesStore {
  theme = signal<'light' | 'dark'>('light');
}

@Service() ne remplace pas tous les usages de @Injectable(). Pour des providers avancés, des tokens particuliers ou des besoins très spécifiques, @Injectable() reste pertinent. Mais pour un service applicatif simple, @Service() rend l'intention plus directe.

La deuxième nouveauté liée à la DI est injectAsync().

import { injectAsync } from '@angular/core';

export class SettingsButton {
  preferences = injectAsync(() =>
    import('./preferences.store').then((m) => m.PreferencesStore)
  );

  async loadTheme() {
    const store = await this.preferences();
    return store.theme();
  }
}

Cette API permet de charger paresseusement un service auto-fourni. D'après les types Angular 22, le service doit être décoré avec @Injectable({ providedIn: 'root' }) ou @Service() pour bénéficier de ce mécanisme.

C'est intéressant pour des dépendances rarement utilisées : panneau d'administration, outil de debug, intégration lourde, action déclenchée après interaction utilisateur.

WebMCP : Angular prépare les applications lisibles par les agents IA

Angular 22 contient aussi provideExperimentalWebMcpTools() et declareExperimentalWebMcpTool().

Le mot important est Experimental. L'API existe dans @angular/core, mais elle n'est pas à lire comme un standard de production figé.

L'idée est cependant forte : une application Angular peut exposer des outils structurés à un agent IA, au lieu de laisser cet agent deviner les actions possibles en observant seulement le DOM.

Nous avons déjà un article dédié : WebMCP dans Angular 22. Le bon résumé est celui-ci : WebMCP ne remplace pas l'interface utilisateur, mais il peut offrir à un agent un chemin plus fiable pour exécuter une action métier déclarée par l'application.

HTTP : FetchBackend devient le défaut

Angular 22 change le backend HTTP par défaut : HttpClient utilise désormais FetchBackend.

En pratique, cela veut dire que provideHttpClient() s'appuie sur fetch sans avoir besoin de withFetch(). La release déprécie donc withFetch, devenu inutile.

import { ApplicationConfig } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient()
  ]
};

Si vous avez besoin de conserver l'ancien backend basé sur XMLHttpRequest, Angular 22 fournit withXhr() :

import { ApplicationConfig } from '@angular/core';
import { provideHttpClient, withXhr } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withXhr())
  ]
};

Le cas typique concerne les rapports de progression d'upload. La release précise que FetchBackend ne supporte pas les progress events d'upload. Angular 22 ajoute aussi des options plus explicites, reportUploadProgress et reportDownloadProgress, tandis que reportProgress est déprécié.

SSR et hydratation : plus d'automatisme

Angular 20 avait stabilisé l'hydratation incrémentale. Angular 22 la rend maintenant comportement par défaut côté platform-browser.

L'hydratation incrémentale permet d'éviter de réactiver toute la page d'un coup côté client. Certaines parties peuvent être hydratées au moment utile, par exemple quand elles entrent dans la viewport ou après une interaction.

Angular 22 ajoute aussi une capacité de cache des Resources pour le SSR. C'est cohérent avec la direction globale : si une donnée asynchrone est chargée pendant le rendu serveur, Angular doit mieux savoir comment la représenter et éviter les rechargements inutiles côté client.

Templates, diagnostics et langage service

Angular 22 continue d'améliorer le typage des templates.

Le compilateur permet maintenant à la navigation optionnelle de mieux réduire les types nullables. Il aligne aussi le comportement de l'optional chaining Angular avec JavaScript : une expression optionnelle retourne undefined.

Ce point peut déclencher des diagnostics existants comme nullishCoalescingNotNullable et optionalChainNotNullable dans des projets qui étaient jusque-là silencieux. La migration Angular 22 peut les désactiver temporairement dans tsconfig, mais il vaut mieux les lire comme des signaux de code à clarifier.

Le langage service gagne aussi :

• des inlay hints pour les templates Angular ;
• des Document Symbols dans les templates ;
• du support pour les timeouts idle dans les blocs @defer ;
• un meilleur support des @Input avec transform.

Ce sont des améliorations moins visibles qu'OnPush, mais elles comptent dans les grandes applications : meilleur typage, meilleure navigation IDE, meilleurs diagnostics.

Router : quelques comportements à vérifier

Le routeur reçoit plusieurs changements utiles :

• withComponentInputBinding() accepte de nouvelles options, dont unmatchedInputBehavior.
• RouterLink ajoute une entrée browserUrl.
• CanMatchFn reçoit maintenant un troisième paramètre currentSnapshot requis.
• paramsInheritanceStrategy passe par défaut à always.
• provideRoutes() est supprimé.

Le changement sur paramsInheritanceStrategy mérite attention. Avant, le comportement par défaut était emptyOnly. Avec always, les paramètres sont hérités depuis tous les parents. Si votre routing dépend finement de l'ancien comportement, configurez explicitement :

provideRouter(routes, withRouterConfig({
  paramsInheritanceStrategy: 'emptyOnly'
}));

Les suppressions à connaître avant de migrer

Angular 22 retire plusieurs APIs historiques. La plupart étaient déjà dépréciées, mais leur suppression peut casser des bibliothèques anciennes ou du code d'infrastructure.

À vérifier :

• ComponentFactoryResolver et ComponentFactory ne sont plus disponibles.
• createNgModuleRef disparaît ; utilisez createNgModule.
• ChangeDetectorRef.checkNoChanges est supprimé de l'API publique.
• L'intégration Hammer.js est supprimée.
• provideRoutes() est supprimé.
• getAngularLib et setAngularLib disparaissent côté @angular/upgrade.
• Les validateurs min et max des formulaires n'acceptent plus les valeurs chaîne : utilisez des nombres ou null.
• TypeScript 5.9 et les versions plus anciennes ne sont plus supportés.

Il y a aussi des ruptures plus subtiles :

• les attributs préfixés data- ne lient plus des inputs ou outputs ;
• Angular lance une erreur en cas de doublon entre input, output ou model sur le même nom ;
• les éléments qui correspondent à plusieurs sélecteurs peuvent maintenant produire un diagnostic de compilation ;
• les styles associés à un host supprimé peuvent être retirés.

Pour une migration propre, ne vous contentez pas de ng update. Lancez les tests, vérifiez les composants dynamiques, les formulaires, les routes imbriquées, les uploads HTTP et les composants qui dépendaient implicitement du comportement eager.

Et Angular Aria ?

Angular Aria reste un sujet important autour d'Angular 21/22, surtout pour les design systems headless accessibles.

Mais il faut être précis : au moment de la publication d'Angular 22.0.0, @angular/[email protected] n'est pas publié sur npm. Cet article ne le présente donc pas comme une nouveauté stable de cette release core. C'est un chantier à suivre séparément, notamment côté package et documentation.

Ce qu'il faut retenir

Angular 22 est une version de bascule.

Angular ne se contente plus de proposer des APIs modernes en option. Il commence à les utiliser comme comportement par défaut : OnPush, FetchBackend, hydratation incrémentale, services plus courts, formulaires orientés Signals, asynchrone représenté par Resources.

Pour les nouveaux projets, c'est une bonne nouvelle : moins de configuration pour obtenir les bonnes pratiques modernes.

Pour les applications existantes, c'est une version à migrer sérieusement. Les migrations automatiques aideront, mais les vrais points de vigilance restent humains : composants qui mutent leur état, formulaires avec validateurs historiques, routing imbriqué, uploads HTTP, bibliothèques encore dépendantes de ComponentFactoryResolver.

Angular 22 raconte surtout une chose : le framework assume maintenant sa direction Signal-first.

Sources

• Angular v22.0.0 - GitHub release
• Angular versioning and releases
• Forms with Angular Signals
• Signal Forms API - form
• HttpClient setup
• provideZonelessChangeDetection
• Article angular.fr : Angular 21
• Article angular.fr : Angular 21.2
• Article angular.fr : Resource API
• Article angular.fr : WebMCP dans Angular 22
• Article angular.fr : le décorateur @Service