Migration Angular 20 vers Angular 22 : reprendre une application sans tout casser

Beaucoup de reprises d’applications commencent par une phrase simple : “il faut mettre Angular à jour”. En réalité, le sujet est rarement aussi direct. Avant de passer d’Angular 20 à Angular 22, il faut savoir ce que l’application fait, quelles dépendances elle utilise, quels écrans sont critiques et où une régression coûterait cher.

Angular 22 est la version active depuis juin 2026, tandis qu’Angular 20 reste en LTS jusqu’au 28 novembre 2026 selon les repères officiels Angular. Cela donne une fenêtre raisonnable pour préparer une migration propre. Ce n’est pas une invitation à lancer une commande en production sans audit.

Faire auditer mon application Angular/Ionic

Pourquoi une migration Angular est souvent une reprise d’application

Sur une application récente, bien testée et peu personnalisée, une montée de version peut être assez directe. Sur une application métier réelle, c’est souvent différent : il y a des formulaires, des règles de gestion, des permissions, des appels API, des composants Ionic personnalisés, parfois une PWA, parfois du Capacitor, parfois des écrans que personne n’a touchés depuis longtemps.

Le risque principal n’est pas que la migration échoue immédiatement. Le vrai risque est de livrer une application qui compile, mais dont un parcours important ne marche plus correctement : une facture impossible à valider, un formulaire qui perd le focus, une notification qui ne se déclenche plus, une modal inaccessible ou un écran mobile rogné par la safe area.

Avant de lancer ng update : vérifier l’existant

La première étape consiste à faire un état des lieux. Ce diagnostic permet de savoir si la migration peut se faire rapidement, si une phase de nettoyage est nécessaire ou si certains morceaux doivent être sécurisés avant de toucher aux versions Angular.

Commandes de diagnostic

npm ls @angular/core @angular/cli @ionic/angular @capacitor/core typescript
node -v
npm run build

Ne pas sauter les majeures Angular

La documentation Angular recommande de mettre à jour une version majeure à la fois. Pour passer d’Angular 20 à Angular 22, l’approche prudente consiste donc à passer par Angular 21, vérifier, puis seulement ensuite préparer Angular 22.

Cela peut sembler plus long, mais c’est souvent plus rapide au final. Quand plusieurs changements majeurs sont empilés, il devient difficile de savoir quelle version, quelle dépendance ou quelle modification a introduit une régression.

Principe de migration progressive

# Exemple de principe : une majeure Angular à la fois.
ng update @angular/core@21 @angular/cli@21
npm run build
npm run test

ng update @angular/core@22 @angular/cli@22
npm run build
npm run test

Cas Ionic et Capacitor : le mobile ne se teste pas seulement dans Chrome

Une application Ionic Angular peut très bien fonctionner dans le navigateur et se comporter différemment en PWA installée, sur iOS, sur Android ou dans une WebView Capacitor. Une migration Angular doit donc vérifier plus que le build web.

Ne pas casser les templates Angular modernes

Dans une reprise d’application Angular 20, il faut respecter les choix déjà faits. Si le projet utilise les syntaxes modernes @if et @for, il n’y a aucune raison de revenir à *ngIf ou *ngFor. Le but est de réduire la dette technique, pas d’introduire un style parallèle.

Template Angular moderne à conserver

@if (client(); as client) {
  <ion-card>
    <ion-card-header>
      <ion-card-title>{{ client.name }}</ion-card-title>
    </ion-card-header>

    <ion-card-content>
      @for (invoice of client.invoices; track invoice.id) {
        <ion-item lines="none">
          <ion-label>
            <h2>{{ invoice.reference }}</h2>
            <p>{{ invoice.status }}</p>
          </ion-label>
        </ion-item>
      }
    </ion-card-content>
  </ion-card>
} @else {
  <ion-card>
    <ion-card-content>Aucun client sélectionné.</ion-card-content>
  </ion-card>
}

Le même principe vaut pour Ionic. Si un écran peut être construit avec ion-row, ion-col, ion-card, ion-item ou ion-button expand="block", il vaut mieux éviter une structure de div custom qui recrée moins bien le responsive et l’accessibilité.

Disposition Ionic simple

<ion-row>
  <ion-col size="12" size-md="6" size-xl="4">
    <ion-button expand="block" routerLink="/contact">
      Demander un audit
    </ion-button>
  </ion-col>
</ion-row>

Ce qu’il faut tester après la migration

Un build vert est nécessaire, mais il ne suffit pas. Une application reprise doit être validée par scénarios. Les tests doivent couvrir les parcours qui font réellement tourner l’activité.

Quand la migration révèle de la dette technique

Une migration Angular met souvent en lumière des problèmes qui existaient déjà : composants trop lourds, services mélangés, CSS global fragile, routes difficiles à tester, dépendances peu maintenues ou logique métier dispersée dans les templates.

Tout ne doit pas être corrigé en même temps. Le bon arbitrage consiste à distinguer ce qui bloque la migration, ce qui menace la production, et ce qui peut rejoindre une feuille de route technique plus longue.

Livrable utile pour une reprise Angular/Ionic

Pour une TPE, une PME, une association ou une structure locale qui dépend déjà d’un outil numérique, le livrable le plus utile n’est pas toujours une migration immédiate. C’est souvent un audit court, lisible, qui permet de décider.

Comment je peux vous accompagner

Si votre application Angular/Ionic est déjà en production, l’enjeu n’est pas de tout reprendre d’un coup. Je peux vous aider à transformer une situation floue en plan d’action lisible : ce qui est urgent, ce qui peut attendre, ce qui doit être testé et ce qui risque réellement de casser.

L’accompagnement peut rester court si le besoin est simplement de décider. Il peut aussi aller plus loin si l’application doit être stabilisée, migrée, corrigée ou préparée pour une nouvelle version web, PWA ou mobile.

Dans quels cas demander de l’aide

Une aide extérieure devient utile quand l’équipe n’a plus une vision claire de l’existant ou quand la migration risque d’impacter une activité réelle. C’est souvent le cas si plusieurs versions Angular ont été sautées, si l’application utilise beaucoup de composants Ionic personnalisés, si Capacitor est connecté à des fonctions natives, ou si le projet compile encore mais reste difficile à faire évoluer.

Demander un accompagnement Angular/Ionic

Aller plus loin

Questions fréquentes

Faire auditer mon application Angular/Ionic avant migration

Conclusion

Migrer Angular 20 vers Angular 22 peut être une bonne décision, mais seulement si la méthode est claire. Pour une application métier, Ionic, Capacitor ou PWA, il faut d’abord comprendre l’existant, sécuriser les parcours importants, respecter les patterns déjà en place et tester sur les supports réellement utilisés.

La meilleure migration n’est pas celle qui change le plus de choses. C’est celle qui rend l’application plus fiable, plus maintenable et plus simple à faire évoluer sans dégrader le service déjà utilisé.