Migration Angular 8 → 17 : retour d'expérience sans downtime

Une bonne partie des applications Angular en production aujourd'hui sont coincées quelque part entre la v8 et la v12. Elles marchent, elles rapportent de l'argent, et personne ne veut être celui qui casse tout en voulant « passer à la dernière version ». J'ai mené plusieurs de ces migrations — jusqu'à la v17+ — sur des apps de production réelles, dont un CRM/Extranet migré de la v8 à la v12 sans une minute d'interruption. Voici ce que j'ai appris, sans langue de bois.

Règle n°1 : on migre version par version, jamais d'un bond

La tentation est de sauter directement de la v8 à la v17. C'est la meilleure façon de se retrouver avec une branche morte que personne n'ose merger. Angular fournit un guide de mise à jour officiel (update.angular.io) précisément parce que chaque version majeure a ses dépréciations, ses changements de comportement et ses migrations automatiques (ng update applique des schematics qui réécrivent du code à votre place). On enchaîne donc v8 → v9 → v10 … en validant l'app à chaque palier. C'est plus lent à lire, mais bien plus rapide à livrer, parce qu'on ne débugge jamais dix versions d'écart en même temps.

Le palier v9 (Ivy) est le vrai mur

La v9 active Ivy, le nouveau moteur de compilation et de rendu. Sur le papier, c'est transparent. En pratique, Ivy est plus strict : il fait remonter des erreurs de typage de templates que le View Engine laissait passer en silence, et certaines bibliothèques tierces non compilées pour Ivy doivent passer par ngcc ou être remplacées. C'est le palier où je prévois le plus de marge. Un conseil concret : activez strictTemplates tôt, encaissez les erreurs progressivement, plutôt que de les découvrir toutes en une fois trois versions plus tard.

// tsconfig.json — durcir le typage des templates par étapes
{
  "angularCompilerOptions": {
    "strictTemplates": true,
    "strictInjectionParameters": true
  }
}

Les pièges qui mangent vraiment du temps

• RxJS. Les montées de version d'Angular tirent souvent une montée de RxJS, avec des opérateurs dépréciés (l'ancien toPromise(), les imports de chemins internes) et des changements de typage. Centralisez vos imports RxJS, ça limite la surface des corrections.
• Les dépendances tierces. C'est presque toujours une lib non maintenue qui bloque, pas Angular lui-même. Avant de lancer la migration, faites l'inventaire des paquets et de leur compatibilité — la dette se cache là.
• Le typage TypeScript. Chaque version majeure d'Angular impose une fourchette de versions TypeScript, et TS devient plus strict à chaque fois. Des any implicites qui dormaient depuis des années remontent d'un coup.
• Les tests. Une bonne suite de tests est votre filet de sécurité pendant la migration. Une mauvaise (ou absente) transforme chaque palier en pari. Si la couverture est faible, j'en ajoute sur les chemins critiques avant de migrer.

Standalone components & signals : à faire après, pas pendant

Les standalone components (stables depuis la v15) et les signals (v16+) sont d'excellentes raisons de moderniser une app Angular — moins de NgModule, une réactivité plus fine, un change detection plus simple à raisonner. Mais ce sont des refactorings, pas des étapes de migration. Je sépare toujours les deux chantiers : d'abord remettre l'app sur une version récente et supportée, la stabiliser, puis adopter les nouveaux patterns au rythme des features. Mélanger « je monte de version » et « je réécris l'architecture » dans le même commit, c'est se garantir une régression qu'on ne saura pas attribuer.

Comment on garde le « zéro downtime »

Le secret n'est pas magique : on migre sur une branche, on valide palier par palier en CI, et on ne déploie que des états de l'app entièrement fonctionnels. Sur le CRM v8 → v12, le développement de nouvelles fonctionnalités continuait en parallèle ; la clé était une discipline de merge stricte et une CI/CD qui refusait tout build cassé. À aucun moment la prod n'a vu une version à moitié migrée. Pour l'utilisateur final, la migration a été invisible — ce qui est exactement le but.

Combien de temps ça prend, honnêtement

Ça dépend surtout de deux choses : l'écart de versions et la santé des dépendances. Une app v8 raisonnablement saine vers une version récente, c'est un chantier qui se compte en semaines, pas en jours — et l'essentiel du temps part dans Ivy, les libs tierces et le durcissement du typage, pas dans les commandes ng update elles-mêmes. Méfiez-vous de quiconque vous annonce un forfait sans avoir regardé votre package.json.

Si vous avez une app Angular qui prend la poussière

Le coût de l'immobilisme est réel : failles de sécurité non corrigées, recrutement de plus en plus dur sur une stack obsolète, et un écart qui ne fait que grandir. La bonne nouvelle, c'est qu'une migration bien menée, incrémentale et testée, est un chantier prévisible — pas un saut dans le vide. C'est exactement le genre de mission que je prends en freelance, à Paris ou en remote. Si vous avez une app Angular vieillissante et que vous voulez un avis franc sur l'effort réel, ma page développeur Angular freelance à Paris détaille comment je travaille — ou écrivez-moi directement.