Migration AngularJS → Next.js — Moderniser votre SPA Angular 1.x sans Interruption

#AngularJS EOL en 2026 — Risque sécurité réel, pas un argument marketing

AngularJS (Angular 1.x) n'est plus maintenu depuis le 31 décembre 2021 — date d'End of Life officielle confirmée par l'équipe Angular de Google sur le blog Angular officiel. Trois ans et demi plus tard, en 2026, la situation est sans ambiguïté pour les équipes techniques qui maintiennent encore des SPA AngularJS en production.

#CVEs actives et non patchables sur AngularJS

Depuis la date d'EOL, des vulnérabilités identifiées sur AngularJS ne recevront jamais de correctif officiel. Les plus documentées : CVE-2023-26116 — vulnérabilité ReDoS (Regular Expression Denial of Service) dans le module angular-resource, exploitable via des requêtes HTTP malformées ciblant les endpoints $resource avec des patterns RegExp non bornés. CVE-2023-26117 — ReDoS dans $location, exploitable sur les SPAs qui construisent des URL dynamiques à partir d'inputs utilisateur. CVE-2023-26118 — XSS (Cross-Site Scripting) via la directive ng-srcset, permettant l'injection de code JavaScript dans des contextes src dynamiques. Ces trois CVEs ont été publiées en 2023 — soit deux ans après l'EOL — et n'ont reçu aucun patch. D'autres CVEs documentées sur les versions AngularJS antérieures (CVE-2019-10768, CVE-2020-7676, CVE-2022-25844) restent non patchées sur les versions EOL. En pratique : npm audit sur tout projet AngularJS retourne des alertes critiques ou high que l'on ne peut pas résoudre sans changer de framework.

#Écosystème npm AngularJS en décomposition

Les dépendances de l'écosystème AngularJS — angular-ui-router, angular-resource, angular-animate, angular-sanitize, angular-mocks — ne reçoivent plus de mises à jour de sécurité. Les librairies tierces construites sur AngularJS (composants UI, modules d'internationalisation, adaptateurs REST) sont massivement abandonnées sur npm, avec des peer dependencies non résolues sur Node.js 20+ et 22+. Les outils de build historiques associés (Grunt, Gulp, Bower) sont eux-mêmes en fin de vie ou maintenus a minima par la communauté. Les pipelines CI/CD qui s'appuient sur ces stacks génèrent des alertes de sécurité à chaque audit — difficile à justifier en audit de sécurité SI ou lors d'une certification ISO 27001.

#Marché du talent AngularJS

En France en 2026, le nombre de développeurs maîtrisant réellement AngularJS (pas Angular 2+, pas React) et capables de maintenir une SPA Angular 1.x complexe est en forte contraction. Les développeurs juniors et mid-level formés depuis 2018 n'ont jamais touché AngularJS dans leurs cursus (bootcamps, masters, licences pro). Les développeurs seniors qui connaissent AngularJS sont sur React, Vue ou Angular 2+ depuis des années. Conséquence directe : coût de maintenance croissant, délai de correction des bugs allongé, onboarding difficile pour les nouveaux arrivants dans les équipes. La dette de connaissance s'ajoute à la dette technique.

#Deux chemins de migration — Micro Frontend (Module Federation) vs Réécriture complète

Il n'existe pas une seule bonne façon de migrer une SPA AngularJS vers Next.js. Le choix dépend de la taille de la codebase, de la complexité de l'état partagé, des contraintes de continuité de service, et du rythme d'évolution fonctionnelle attendu pendant la migration. Chez Nehos, deux approches sont industrialisées.

#Approche A — Micro Frontend progressif avec Module Federation

L'approche Module Federation est la plus adaptée aux grandes SPA AngularJS (50 000 lignes et plus) et aux équipes qui ne peuvent pas se permettre un freeze fonctionnel pendant la migration. Le principe : installer un shell applicatif Next.js 15 comme Host de Module Federation, exposer les modules AngularJS existants comme Remote via la configuration ModuleFederationPlugin de webpack 5, et migrer les routes une à une vers des composants React/Next.js natifs.

Concrètement, la SPA AngularJS tourne en parallèle du shell Next.js derrière le même domaine et le même reverse proxy (nginx ou Vercel). Les utilisateurs voient une interface cohérente — les routes migrées servent du Next.js, les routes non encore migrées continuent de servir l'AngularJS encapsulé comme Remote module. Des feature flags (LaunchDarkly, Unleash, ou flags simple via variables d'environnement) permettent de basculer route par route et de rollback immédiatement en cas de régression. Cette coexistence AngularJS + Next.js peut durer plusieurs mois sans impact sur les utilisateurs.

Détail technique de l'intégration Module Federation AngularJS : les widgets AngularJS sont compilés en Angular Elements (Web Components standards) ou encapsulés via un wrapper React (un composant React qui monte l'application AngularJS dans un div avec angular.bootstrap) pour être exposés comme Remote modules. La communication entre le shell Next.js et les Remote AngularJS se fait via props/events standardisés, ou via un bus d'événements partagé. Les deux applications partagent certaines dépendances (React, lodash, les bibliothèques UI communes) via le système de shared de Module Federation, ce qui maintient un bundle raisonnable.

#Approche B — Réécriture complète guidée par les tests E2E Playwright

L'approche réécriture est adaptée aux SPA AngularJS de taille modérée (jusqu'à environ 30 000 lignes de code fonctionnel) où le refactoring progressif coûterait plus cher que la réécriture propre. Elle convient aussi quand la SPA AngularJS a une architecture désorganisée (controllers tentaculaires, services imbriqués, $scope pollué, directives sans contrat clair) qui rendrait la migration Micro Frontend très complexe.

La première étape est critique : instrumenter l'application AngularJS existante avec Playwright pour couvrir tous les parcours utilisateur critiques en tests E2E. Ces tests définissent le contrat comportemental de l'application — ce que le produit doit faire, indépendamment de la technologie. Ce filet de tests Playwright est ensuite utilisé comme oracle de non-régression tout au long de la réécriture Next.js. On démarre la réécriture avec un objectif simple : chaque test Playwright qui passait sur l'AngularJS doit passer sur le Next.js. Pas de nouveaux bugs, pas de régressions fonctionnelles, même si l'architecture interne est entièrement refaite.

La réécriture se fait composant par composant, de l'intérieur vers l'extérieur (composants feuilles en premier, puis composants parents), ce qui permet d'accumuler de la couverture de tests unitaires Vitest en parallèle.

#Module Federation en détail — Shell Next.js + Remote AngularJS

L'architecture Module Federation pour la migration AngularJS → Next.js suit un pattern en trois couches.

Couche 1 — Shell Next.js (Host) : l'application Next.js 15 avec App Router qui gère le layout global, l'authentification, la navigation principale, et le routing. Elle importe dynamiquement les Remote modules selon la route active. Configuration webpack dans next.config.ts avec NextFederationPlugin (paquet @module-federation/nextjs-mf).

Couche 2 — Remote AngularJS : le bundle webpack de l'application AngularJS existante reconfiguré pour exposer ses modules via ModuleFederationPlugin. Chaque widget ou module AngularJS exposé est soit un Angular Element (Web Component), soit un module qui exporte une fonction de bootstrap Angular. La SPA AngularJS tourne sur son propre build pipeline (webpack 4 ou 5, selon la version) et est servie depuis un endpoint dédié (même domaine, path différent, ou sous-domaine interne).

Couche 3 — Feature flags : la décision de servir le composant Next.js natif ou le Remote AngularJS pour une route donnée est contrôlée par un feature flag évalué au runtime. Le flag peut être activé par pourcentage d'utilisateurs (déploiement progressif), par groupe utilisateur (bêta testeurs internes d'abord), ou par route. Le flag est évalué côté serveur dans le Server Component Next.js (async function Page()) pour éviter le flash de contenu.

Ce pattern permet une migration route par route sur plusieurs mois, avec validation métier à chaque étape, sans jamais exposer les utilisateurs à un état intermédiaire instable.

#Migration TypeScript — De $scope/controller/plain JS vers TypeScript strict

AngularJS a été conçu à une époque où TypeScript n'existait pas. La majorité des codebases AngularJS sont en JavaScript pur, parfois avec des typings @types/angular partiels ajoutés a posteriori. La migration vers Next.js TypeScript strict est une opportunité de rétablir la rigueur de typage — mais c'est aussi un travail non trivial.

Stratégie de migration des types chez Nehos. Phase 1 : migration JavaScript → TypeScript avec noImplicitAny: false et strict: false. On renomme les fichiers .js en .ts, on corrige les erreurs de compilation évidentes, on laisse les types any là où le typage est complexe. C'est la migration à coût minimal qui débloque les outils TypeScript (autocomplétion, refactoring sûr dans VS Code/Cursor). Phase 2 : activation progressive de strict: true module par module, en commençant par les modules les plus isolés (services utilitaires, helpers, constantes). Chaque module passé en strict est couvert par des tests Vitest avant et après. Phase 3 : remplacement des any résiduels par des types réels, notamment sur les interfaces d'API (génération de types depuis les schémas OpenAPI/Swagger backend via openapi-typescript), les states (interfaces Zustand/Jotai typées), et les props des composants React (interface Props ou type Props strict).

Points d'attention spécifiques AngularJS → TypeScript strict. Les $scope d'AngularJS sont des objets non typés avec mutations implicites — ils n'ont pas d'équivalent direct en React/TypeScript. La migration force à expliciter les states (ce qui est souvent l'occasion de simplifier l'état global de l'application). Les $injector et les patterns d'injection de dépendance AngularJS disparaissent au profit des imports ESM natifs. Les filtres AngularJS ({{ value | currency }}) deviennent des fonctions utilitaires TypeScript pures, testables unitairement.

#Migration de la gestion d'état — $scope/services → React Context/Zustand/Jotai

La gestion d'état est souvent le point le plus complexe d'une migration AngularJS. Dans une SPA AngularJS, l'état est distribué entre les $scope des controllers (état local), les services Angular (état partagé entre controllers via l'injection de dépendances), et les variables globales sur $rootScope (état global, souvent un anti-pattern mais fréquemment rencontré sur les vieilles codebases).

La stratégie de migration d'état dépend de la structure trouvée. État local controller → state local React avec useState. État partagé via services Angular → choix selon la complexité : React Context pour les états simples partagés entre quelques composants proches dans l'arbre, Zustand pour les états transversaux avec des mutations fréquentes (panier, préférences utilisateur, notifications), Jotai pour les états atomiques avec dérivations complexes. $rootScope → server-side state via React Server Components (données chargées une fois côté serveur, injectées dans le tree via props), ou Zustand avec store global si l'état doit survivre aux navigations côté client. La règle Nehos : on choisit la solution la moins complexe qui couvre le besoin — pas besoin d'un store Redux complet si Zustand couvre le cas d'usage à 20 lignes.

#Migration de la couche API — $http vers Server Actions / tRPC / fetch + SWR

Le service $http d'AngularJS est le point d'entrée de toutes les communications avec le backend. Sa migration vers les patterns Next.js modernes est structurante pour l'architecture finale.

Pour les APIs REST classiques : remplacement de $http.get() / $http.post() par fetch natif dans les React Server Components (appels côté serveur, données fraîches à chaque requête, pas de state client nécessaire), et SWR ou React Query pour les appels client-side qui nécessitent du cache local, de l'invalidation, du polling ou de l'optimistic update. Pour les mutations complexes (formulaires, actions utilisateur) : Next.js Server Actions — fonctions async marquées 'use server' qui tournent côté serveur et peuvent être appelées directement depuis les Client Components. Pour les frontends avec une API GraphQL ou tRPC côté backend : migration vers un client tRPC typé de bout en bout (types partagés entre backend et frontend sans génération de code intermédiaire). Un point de vigilance : les intercepteurs $http d'AngularJS (gestion des tokens auth, des erreurs globales, des headers communs) doivent être recréés sous forme de middleware Next.js ou de wrappers fetch centralisés.

#Stratégie de tests — Playwright comme contrat comportemental

La stratégie de tests est le filet de sécurité de la migration. Sans elle, chaque sprint de migration devient un saut dans le vide — on ne sait pas si on a cassé quelque chose avant de le voir en production.

Tests E2E Playwright : couvrent les parcours utilisateur critiques (connexion, navigation principale, CRUD des entités clés, exports, formulaires complexes). Ces tests s'exécutent contre l'application AngularJS existante pour établir le référentiel de non-régression, puis contre l'application Next.js pendant la migration pour valider chaque route migrée. Playwright est particulièrement adapté à ce contexte car il peut tester aussi bien des pages AngularJS (qui nécessitent d'attendre la fin du cycle digest Angular) que des pages Next.js modernes. Configuration Playwright avec plusieurs projets (angularjs-baseline, nextjs-migrated) pour exécuter les mêmes tests contre les deux versions en parallèle pendant la période de coexistence.

Tests unitaires Vitest : pour chaque nouveau composant React, chaque hook custom, chaque service TypeScript réécrit. Vitest est choisi pour sa compatibilité native avec Vite et le tooling Next.js moderne, sa vitesse d'exécution (worker threads), et son API compatible Jest (pas de ré-apprentissage pour les équipes). Les tests Vitest couvrent la logique métier pure (transformations de données, validators, helpers), les composants React unitairement (via @testing-library/react), et les hooks custom.

Tests d'accessibilité axe : intégrés dans les tests Playwright via axe-playwright — chaque nouvelle page Next.js est testée WCAG 2.1 AA automatiquement dans le pipeline CI. C'est souvent une opportunité d'amélioration significative par rapport aux SPA AngularJS historiques.

#Migration du routing — ngRoute/ui-router → Next.js App Router

Les SPAs AngularJS utilisent soit ngRoute (le router officiel minimaliste), soit angular-ui-router (le router communautaire plus puissant, avec les états imbriqués). La migration vers Next.js App Router est l'occasion de tirer parti des fonctionnalités modernes : layouts imbriqués, loading states, error boundaries, parallel routes, et surtout le rendu côté serveur (RSC).

Correspondances de migration. Routes ngRoute simples ($routeProvider.when('/users/:id', {...})) → segments de route dynamiques Next.js (app/users/[id]/page.tsx). États imbriqués ui-router (parent state + child states) → layouts Next.js (layout.tsx à chaque niveau de route pour les éléments communs). Résolution de données avant rendu (resolve dans ui-router) → async Server Component qui fetch les données avant de render (async function Page({ params })) — plus simple, plus performant, sans waterfall client-side. Guards de navigation ($routeChangeStart, onBeforeExit) → middleware Next.js pour les guards d'authentification, useEffect + router.push pour les guards client-side complexes. Animations de transition entre routes → Framer Motion avec AnimatePresence ou CSS transitions via le nouveau système de View Transitions API (supporté dans Next.js 15).

#Gains de performance — Dirty checking vs React Server Components

AngularJS est basé sur un mécanisme de dirty checking : à chaque événement (click, input, requête HTTP, timer), Angular parcourt l'intégralité des watchers ($watch) enregistrés sur les $scope pour détecter les changements et mettre à jour le DOM. Sur une SPA complexe avec plusieurs centaines de watchers, ce cycle digest devient le goulot d'étranglement de performance — c'est pourquoi les SPAs AngularJS volumineuses ont des scores Lighthouse typiquement entre 25 et 45 sur mobile.

Next.js 15 + React Server Components résout ce problème fondamentalement différemment. Les composants serveur (async function MyComponent()) rendus côté serveur n'ont aucun watcher — ils envoient du HTML statique au client. Les composants client ('use client') utilisent le Virtual DOM React avec réconciliation sélective — seuls les composants dont les props changent re-renderent. Le résultat mesurable : Lighthouse score typiquement 88-96 sur mobile pour une application Next.js correctement configurée (RSC pour les données, Client Components pour les interactions, images optimisées next/image, fonts auto-optimisées next/font, streaming SSR pour les parties lentes). Sur nos migrations AngularJS → Next.js, le gain Lighthouse moyen sur le score Performance mobile est de +45 à +60 points.

Autres gains mesurables : Time to First Byte (TTFB) drastiquement réduit grâce au SSR Next.js (vs rendu purement client-side de l'AngularJS), First Contentful Paint (FCP) amélioré par le HTML initial servi par le serveur (pas de blanc écran pendant le boot JavaScript), Cumulative Layout Shift (CLS) éliminé par le rendu serveur (pas de shifts causés par l'hydratation côté client).

#Méthodologie Nehos — Phases et calendrier

Phase 0 — Audit codebase AngularJS (10 à 15 jours, à partir de 32 000 € HT déductibles du projet). Inventaire exhaustif des composants : controllers, directives, services, filtres, providers. Cartographie des dépendances npm et statut de maintenance. Mesure de la couverture de tests existants (souvent quasi-nulle sur les vieilles codebases AngularJS). Audit des performances Lighthouse actuelles (mobile + desktop). Identification des patterns AngularJS les plus complexes à migrer ($rootScope, $broadcast/$emit, directives compile/link, custom transclusion). Output : document d'architecture cible, plan de migration route par route avec estimation T-shirt, recommandation de l'approche (Module Federation vs réécriture), chiffrage définitif.

Phase 1 — Mise en place socle technique (3 à 4 semaines). Initialisation du projet Next.js 15 (App Router, TypeScript strict, ESLint, Prettier, Husky pre-commit hooks). Configuration CI/CD (GitHub Actions : lint, type-check, tests Vitest, tests Playwright, build, déploiement preview Vercel). Configuration Module Federation si approche progressive (Host Next.js + Remote AngularJS). Mise en place du monitoring (Sentry, Datadog ou Vercel Analytics selon contexte). Premiers tests Playwright sur l'application AngularJS existante pour établir le référentiel.

Phase 2 — Migration par sprints (6 à 18 mois selon taille). Sprints de 2 semaines. Chaque sprint migre 1 à 3 routes selon complexité. Chaque route migrée est couverte par des tests Playwright et des tests Vitest avant merge. Démo métier à la fin de chaque sprint. Feature flags activés progressivement sur les routes migrées (10 % → 50 % → 100 % des utilisateurs). Les routes migrées bénéficient immédiatement des gains Lighthouse.

Phase 3 — Bascule finale et décommission AngularJS (2 à 3 semaines). Désactivation des feature flags (100 % Next.js sur toutes les routes). Tests de charge et validation Lighthouse globale. Suppression des dépendances AngularJS du projet (réduction significative du bundle, résolution des alertes npm audit). Documentation technique de la nouvelle architecture. Formation des équipes développement sur les patterns Next.js, React, TypeScript.

#ROI — Cas SaaS ERP AngularJS → Next.js

Cas client de référence : éditeur SaaS ERP B2B (ETI industrielle), SPA AngularJS de 80 000 lignes de code, en production depuis 2014, 600 utilisateurs actifs quotidiens. Enjeux initiaux : Lighthouse mobile à 38 (plaintes utilisateurs sur mobile, perte de prospects lors des démos), 3 failles CVE actives non corrigeables sans migration, coût de maintenance en hausse (difficulté de recrutement AngularJS, onboarding 8 semaines pour un nouveau dev), blocage fonctionnel (impossible d'intégrer une librairie UI moderne incompatible avec AngularJS).

Mission Nehos : migration Micro Frontend progressive sur 14 mois. Phase 0 audit (12 jours). Phase 1 socle (3 semaines). Phase 2 migration route par route (12 mois, 22 routes migrées). Phase 3 bascule finale (2 semaines). Investissement total : 271 k€ HT. Résultats à 6 mois post-bascule finale : Lighthouse mobile 94 (de 38 à 94, +56 points), 0 downtime pendant toute la migration, 3 CVEs éliminées (npm audit clean), onboarding nouveau dev réduit de 8 semaines à 3 semaines, livraison fonctionnelle accélérée (vélocité sprint +35 % grâce à TypeScript et tooling moderne), conversion mobile lors des démos commerciales +22 %. Voir le cas client ERP SaaS AngularJS → Next.js.

#Tarification — 8,5 k€ HT

Trois fourchettes de prix selon la taille de la SPA et l'approche de migration.

SPA AngularJS 15 000 à 30 000 lignes — réécriture complète guidée tests : 35 à 611 k€ HT sur 4 à 6 mois. Inclut l'audit Phase 0, la mise en place du socle Next.js + CI/CD, la réécriture composant par composant sous couverture Playwright, la migration TypeScript strict, et 1 mois de stabilisation post-déploiement.

SPA AngularJS 30 000 à 60 000 lignes — Module Federation progressif : 65 à 1211 k€ HT sur 8 à 12 mois. Inclut l'audit Phase 0, le shell Next.js + Module Federation, la migration route par route avec feature flags, les tests Playwright et Vitest, la formation de l'équipe interne, et la décommission finale AngularJS.

SPA AngularJS 60 000 à 100 000+ lignes — Module Federation multi-équipes : 271 k€ HT sur 12 à 18 mois. Inclut tout le périmètre précédent avec coordination multi-équipes (si l'éditeur a plusieurs équipes produit qui contribuent à la SPA), intégrations complexes (micro-services, GraphQL, BFF), migration de l'infrastructure de tests (CI/CD AngularJS → CI/CD Next.js), et accompagnement au changement pour les équipes dev.

Tous les tarifs incluent l'audit initial de 10-15 jours. Estimation précise en 30 minutes via RDV : [Calendly migration AngularJS](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe