Angular 22 : tout ce qui change vraiment dans cette nouvelle version

Angular 22 arrive début juin 2026. Une release candidate (v22.0.0-rc.2) est déjà publiée sur le dépôt officiel angular/components depuis fin mai, ce qui confirme un lancement imminent. Comme prévu, le cycle reste calé sur la cadence de six mois, et la v22 devient une version LTS — un détail qui compte pour les équipes qui planifient leurs migrations sur plusieurs années.

Cette version ne révolutionne pas le framework : elle consolide. La plupart des fonctionnalités introduites en expérimental dans les v19, v20 et v21 deviennent stables, plusieurs comportements par défaut basculent vers leur version moderne, et un nouveau gros chantier s’ouvre côté intégration avec l’IA. Tour d’horizon de ce qui change réellement.

C’est la vraie nouveauté de la version. Angular intègre, en mode expérimental, un support natif du WebMCP (Web Model Context Protocol), un standard W3C qui permet à une application web d’exposer ses capacités à des agents IA via l’objet navigator.modelContext.

Concrètement, votre app peut déclarer des « tools » appelables directement par un agent IA — Gemini, Claude, ou n’importe quelle extension navigateur compatible — sans que l’agent ait à scraper le DOM pour deviner ce que fait votre interface.

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

bootstrapApplication(AppRoot, {

  providers: [

    provideExperimentalWebMcpTools([

      {

        name: 'exportDashboardReports',

        description: 'Exports the current dashboard analytics.',
        inputSchema: { type: 'object', properties: {} },

        execute: () => ({

          content: [{ type: 'text', text: 'Dashboard export triggered.' 
}],

        }),

      },

    ]),

  ],

});

L’API est marquée experimental par l’équipe Angular : elle peut bouger même hors des versions majeures. Mais l’arrivée dans @angular/core (et pas dans un package séparé) envoie un signal clair sur la direction prise.

À noter : il existe aussi une option withExperimentalAutoCleanupInjectors côté router pour désenregistrer automatiquement les tools quand l’utilisateur change de route — sinon les tools restent accessibles à l’agent même après navigation.

Les APIs resource, rxResource et httpResource, introduites progressivement depuis la v19, passent en stable. Elles offrent une manière signal-native de gérer l’asynchrone, sans devoir jongler entre HttpClient, RxJS et toSignal.

const id = signal(1);

const user = httpResource(() => `/api/users/${id()}`);

// Trois signals exposés automatiquement

user.value();    // la donnée

user.isLoading(); // état de chargement

user.error();     // erreur éventuelle

httpResource est un wrapper réactif autour de HttpClient. À la différence de HttpClient, il initie la requête immédiatement (pas besoin de subscribe), et il réagit automatiquement aux changements des signals qu’il consomme. Pour les requêtes en lecture (GET), c’est souvent suffisant et bien plus concis.

Limite à connaître : la doc officielle recommande de ne pas utiliser httpResource pour les mutations (POST, PUT, DELETE) — pour ça, restez sur HttpClient directement.

Angular 22 fait basculer deux comportements par défaut vers leur version moderne.

OnPush devient le default pour les nouveaux composants. La détection de changement par défaut était historiquement Default (vérification systématique de l’arbre des composants). Avec OnPush, Angular ne vérifie un composant que si ses inputs changent ou si un signal qu’il consomme est mis à jour. Combiné avec le mode Zoneless (déjà default depuis la v21), ça donne une stratégie de change detection précise, prévisible et performante out-of-the-box.

Fetch remplace XMLHttpRequest comme backend par défaut de HttpClient. Plus besoin de provideHttpClient(withFetch()) : provideHttpClient() seul utilise désormais FetchBackend. Un piège à connaître si vous migrez : le FetchBackend ne supporte pas les événements de progression d’upload. Si votre app fait du reportProgress: true pour de l’upload de fichiers, vous devrez explicitement configurer une exception.

Annoncés depuis plusieurs versions, les selectorless components débarquent enfin dans la v22. Le principe : pouvoir utiliser un composant directement dans un template à partir de son import TypeScript, sans avoir à définir ni mémoriser de selector string.

import { UserCard } from './user-card.component';

@Component({

  template: `

    <UserCard [name]="'Manish'" />

  `

})

export class Dashboard {}

Ça résout un vieux pain point : actuellement, vous importez un composant en TypeScript et vous le référencez par sa balise (<app-user-card>) en HTML — deux endroits à garder synchronisés, double risque d’erreur, refactoring pénible. Avec les selectorless components, le lien devient direct et type-safe.

C’est un changement de paradigme qui rapproche Angular de la sensation de composition qu’on trouve en React ou Svelte, sans perdre la DI ni la sécurité de typage.

Angular 22 continue le nettoyage des APIs historiques. Les retraits notables :

• ComponentFactoryResolver est officiellement supprimé. Il était déprécié depuis la v13.2 (janvier 2022). Si vous avez encore du code qui résoud des composants dynamiques via resolver.resolveComponentFactory(...), il faut migrer vers viewContainerRef.createComponent(MyComponent) directement.
• provideRoutes() disparaît au profit de provideRouter(). La migration est triviale mais doit être faite à la main.
• Node.js ≥ 22 et TypeScript ≥ 6 deviennent les versions minimales requises. C’est le piège le plus courant lors d’une migration : oublier le bump de runtime.
• L’intégration HammerJS est sur la rampe de sortie depuis la v20. Les APIs HAMMER_GESTURE_CONFIG et compagnie restent marquées dépréciées avec un retrait planifié. Vérifiez le changelog officiel pour le statut exact en v22 avant de migrer.

À noter aussi sur les routes : en v22, les child routes héritent toujours des paramètres parents par défaut, là où c’était conditionnel en v21. Si vous avez du code qui s’appuyait sur l’ancien comportement, attendez-vous à devoir ajuster.

Si vous êtes en v21, la migration vers v22 reste raisonnable — l’équipe Angular continue de privilégier la modernisation incrémentale sur les breaking changes massifs. L’ordre recommandé :

1. Bumper Node et TypeScript avant tout (nvm use 22, npm install typescript@latest).
2. Lancer ng update @angular/core@22 @angular/cli@22 qui applique automatiquement la majorité des migrations.
3. Chercher manuellement les ComponentFactoryResolver et provideRoutes() restants.
4. Tester les uploads de fichiers — c’est là que le passage à FetchBackend peut surprendre.
5. Revoir le comportement des child routes si vous utilisez beaucoup de routing imbriqué.

Si vous êtes en v19 ou plus ancien, la fenêtre se referme : la v19 a atteint sa fin de support le 19 mai 2026. Un saut direct vers v22 est possible mais demande plus de préparation.

Angular 22 n’est pas une révolution, et c’est probablement sa plus grande force. Le framework consolide ce qu’il a construit depuis trois ans (Signals, Zoneless, Resource APIs, Signal Forms) en les sortant tous de la zone « expérimental » en même temps. Les équipes qui ont attendu un signal clair avant d’adopter ces patterns l’ont maintenant.

Le seul vrai pari nouveau, c’est WebMCP. Il est encore expérimental, mais sa simple présence dans @angular/coreraconte où l’équipe pense que va le web : un écosystème où les apps n’ont plus seulement des utilisateurs humains, mais aussi des agents IA qui les consomment comme des APIs. Pari risqué, ou anticipation lucide ? Les douze prochains mois trancheront.