★ Le guide de décision · Angular 8 → 17+
Votre Angular 8 tourne encore, donc le sujet attend — c'est le raisonnement qui rend la migration plus chère chaque trimestre. Les versions legacy ne reçoivent plus de correctifs de sécurité, les librairies de l'écosystème meurent une à une, et les développeurs qui acceptent de travailler dessus se raréfient. La vraie question n'est pas « faut-il migrer » mais « migrer, réécrire, ou assumer de ne rien faire » — trois réponses légitimes, à condition de les choisir avec les bons critères. Les voici, tirés d'une migration 8 → 17 que j'ai menée en production, sans downtime.
+cher
chaque trimestre d'attente — sécurité, recrutement, librairies
3
options réelles : migrer, réécrire, ne rien faire
9
versions majeures franchies en prod, de la 8 à la 17
0
minute de downtime pendant cette migration
Il est invisible dans le budget, mais il est là : des failles non corrigées sur un framework en fin de vie, des librairies abandonnées qu'il faut forker pour les maintenir, et un recrutement qui se complique — les bons profils fuient le legacy. Ne rien faire est un choix valable à une condition : que l'application ait une date de fin connue. Sinon, c'est juste une dette qui se compose.
Réécrire séduit parce que c'est repartir de zéro — c'est précisément le problème : pendant douze mois, l'équipe reconstruit ce qui existe déjà au lieu de livrer. La réécriture ne se défend que si le produit change radicalement en même temps, ou si le codebase est si peu testé que toute modification casse autre chose. Si l'app fait son travail, on la migre, on ne la rase pas.
La cause n'est pas technique, elle est organisationnelle : aucune direction produit ne tolère six mois sans nouvelle feature. La branche de migration prend du retard sur la prod, les conflits s'accumulent, et le projet meurt fusionné à moitié. La parade : une version majeure à la fois, chaque étape releasable, les features urgentes qui continuent de sortir en parallèle. C'est ainsi que j'ai franchi neuf majeures sans interruption.
Quatre signaux prédisent le coût mieux que la taille du codebase : la couverture de tests (votre filet de sécurité à chaque montée de version), le nombre de librairies tierces abandonnées (chacune est une décision à prendre), l'âge des patterns RxJS, et la présence d'une config de build maison. Mon audit chiffre ces quatre points et en sort un plan version par version — y compris si la conclusion est « n'y allez pas maintenant ».
8→17
La migration s'est faite pendant que l'application vivait : releases régulières, zéro interruption, et les utilisateurs n'ont rien vu — c'était le but. Le détail des pièges (librairies mortes, RxJS, schematics récalcitrants) est dans la note publiée sur ce site.
CI
Tests, lint et build à chaque montée de version dans le pipeline : quand quelque chose casse, on le sait dans l'heure, sur la branche — pas trois semaines plus tard chez un utilisateur.
Après
Un codebase en Angular moderne — standalone components, signals — une équipe qui comprend chaque choix parce qu'elle a migré avec moi, et une CI qui protège les prochaines montées de version. La mission s'arrête, pas la maintenabilité.
Rejoignez la liste d'attente : je préviens d'abord les personnes inscrites quand un créneau freelance se libère. Laissez votre email ci-dessous, ou écrivez-moi directement à alielmufti25@gmail.com.
Rejoindre la listeHonnêtement : ça dépend de quatre signaux — couverture de tests, librairies abandonnées, patterns RxJS, config de build maison — bien plus que de la taille du codebase. C'est ce que l'audit initial, quelques jours, vient chiffrer : un plan version par version avec une estimation par étape, avant d'engager quoi que ce soit.
Version par version, dans la quasi-totalité des cas : Angular fournit des schematics entre majeures et le produit reste livrable du début à la fin. La réécriture ne se défend que si le produit change radicalement en même temps, ou si le codebase est intestable. Si c'est votre cas, l'audit vous le dira — plutôt que de vous vendre des mois de migration.
Oui — c'est tout le principe, et c'est comme ça que j'ai mené la mienne : chaque étape releasable, la CI qui valide chaque montée de version, les features urgentes qui sortent en parallèle. Vos utilisateurs ne s'aperçoivent de rien.
C'est défendable si l'application a une date de fin connue — on sécurise le périmètre et on laisse vivre. Sinon, chiffrez au moins ce que l'immobilisme coûte par an en sécurité, recrutement et librairies à maintenir : c'est souvent cet exercice qui décide, pas moi.