Migration d'Angular de v10 à v21 : Le Guide complet version par version

Migrer une application d'Angular 10 vers Angular 21, c'est passer par onze versions majeures, chacun avec ses propres changements radicaux. Le faire d’un seul coup n’est jamais une option réaliste : l’équipe Angular lui-même recommande mises à niveau séquentielles, une majeure à la fois, en utilisant ng update à chaque passage. Ce guide couvre l'ensemble du parcours : ce qui change dans chacun version, les commandes exactes à exécuter, les problèmes les plus courants rencontrés dans les migrations réelles, l'impact sur les performances et les offres groupées, et un plan opérationnel de 30/60/90 jours pour gérer les risques sur un projet entreprise.

Note importante : Quelques détails de version (notamment pour Angular 19, 20 et 21, le plus récent au moment de la rédaction) doit toujours être vérifié par rapport à la documentation officielle avant de planifier une mise à niveau en production, avec npm view @angular/core versions et ng version en projet réel.

Matrice de compatibilité

Angulaire	TypeScript	RxJS	Node	Angulaire CLI	Angulaire Matériel
10	3,9	6,5 / 6,6	10,13 / 12.11	10	10
11	4.0	6.5.3	10.13 / 12.11	11	11
12	4.2	6.5.3 / 7	12.14 / 14	12	12
13	4.4	6.5.3 / 7	12.20 / 14	13	13
14	4.6 / 4.7	6.5.3 / 7	14.15 / 16	14	14
15	4,8 / 4,9	6.5.3 / 7	14,20 / 16	15	15
16	4.9 / 5.1	6.5.3 / 7	16 / 18	16	16
17	5.2	6.5.3 / 7	18.13 / 20	17	17
18	5.4 / 5.5	6.5.3 / 7	18.19 / 20 / 22	18	18
19	5.5 / 5.6	6.5.3 / 7	18.19 / 20 / 22	19	19
20	5.6+ (vérifier)	7	20/22 (vérifier)	20	20
21	à vérifier	7	à partir de vérifier	21	21

Pour Angular 20 et 21, vérifiez toujours les exigences exactes avant de planifier : npm view @angular/core@21 peerDependencies renvoie les versions minimales actuellement requises d'installation, plus fiable que n'importe quelle table statique.

ng commandes de mise à jour : le modèle séquentiel

# Pattern generale per ogni step (mai saltare una major)
ng update @angular/core@X @angular/cli@X --force
npm install
ng build
npm test

# Esempio concreto: da 10 a 11
ng update @angular/core@11 @angular/cli@11

L'indicateur --force contourne les contrôles de compatibilité des dépendances homologues lorsqu'un la bibliothèque tierce n'a pas encore publié le support pour la nouvelle version majeure - utilisez-la uniquement une fois que vous l'avez vérifié manuellement que la bibliothèque fonctionne de toute façon, jamais par défaut automatique. --migrate-only exécute uniquement les schémas de migration sans toucher aux versions du packages (utile pour réexécuter une migration spécifique après un correctif manuel), tandis que --de/--à vous permettent de cibler une plage de versions spécifique lorsque ng update ne détecte pas automatiquement la version de démarrage correcte.

Angular 11 → 12 : De View Engine à Ivy Everywhere

Aperçu et rupture de changement

• Angular 11 (novembre 2020) : TypeScript 4.0, traces de pile plus lisibles, remplacement de module à chaud en option.
• Angular 12 (mai 2021) : Ivy devient également le compilateur/runtime par défaut pour la publication de bibliothèques (Angular Package Format mis à jour), mode strict activé par défaut sur les nouveaux projets, dépréciation formelle de View Engine.
• API obsolètes : entryComponents n'est plus nécessaire avec Ivy, relativeLinkResolution dans le routeur est obsolète.

ng update @angular/core@12 @angular/cli@12

// tsconfig.json — strict mode raccomandato da Angular 12 in poi
{
  "compilerOptions": { "strict": true },
  "angularCompilerOptions": { "strictTemplates": true }
}

Angular 13 : Adieu à View Engine et IE11

Aperçu et rupture de changement

• View Engine complètement supprimé : uniquement Ivy à partir de cette version, ngcc n'est plus nécessaire pour les bibliothèques publiées avec le nouveau format de package angulaire.
• Prise en charge d'Internet Explorer 11 supprimée — si votre audience inclut toujours IE11, il s'agit d'un élément majeur à évaluer attentivement.
• Nouvelle API pour les composants dynamiques (ViewContainerRef.createComponent sans ComponentFactoryResolver).

// Prima (Angular 12 e precedenti)
constructor(private resolver: ComponentFactoryResolver) {}
createDynamic() {
  const factory = this.resolver.resolveComponentFactory(MyComponent);
  this.container.createComponent(factory);
}

// Dopo (Angular 13+) — nessun ComponentFactoryResolver necessario
createDynamic() {
  this.container.createComponent(MyComponent);
}

Angular 14 : composants autonomes dans l'aperçu du développeur

Aperçu et rupture de changement

• Composants/directives/pipes autonomes introduits (aperçu pour les développeurs, non encore recommandé pour la production).
• Formulaires réactifs typés : FormControl et similaires deviennent génériques, ce qui entraîne des erreurs de type sur le code existant qui supposait any.
• Les diagnostics étendus du compilateur signalent des modèles à risque dans les modèles déjà en phase de construction.

ng update @angular/core@14 @angular/cli@14

// Typed forms — il compilatore ora rileva errori prima invisibili
const form = new FormGroup({ email: new FormControl('', { nonNullable: true }) });
// form.value.email è ora tipizzato string, non any

Angular 15 : autonome stable et NgOptimizedImage

Aperçu et rupture de changement

• L'API autonome devient stable et recommandée pour les nouveaux projets.
• Directive NgOptimizedImage stable : chargement paresseux automatique et dimensionnement de l'image avec impact direct sur LCP.
• Angular Material passe à la nouvelle architecture basée sur MDC (Material Design Components), avec d'éventuelles différences visuelles mineures sur les composants existants.

// Componente standalone — nessun NgModule richiesto
@Component({ selector: 'app-widget', standalone: true, imports: [CommonModule], template: `...` })
export class WidgetComponent {}

<img ngSrc="hero.jpg" width="800" height="400" priority />

Angular 16 : signaux dans l'aperçu du développeur

Aperçu et rupture de changement

• Signaux introduits dans l'aperçu développeur : réactivité granulaire alternative/complémentaire à Zone.js.
• Builder esbuild dans l'aperçu du développeur pour ng build : temps de construction nettement plus rapides.
• Entrées requises (@Input({ requis : true })) et balises à fermeture automatique dans les modèles ().
• Prise en charge expérimentale de Jest en tant qu'exécuteur de test alternatif à Karma.

ng update @angular/core@16 @angular/cli@16
# Opt-in al builder esbuild (developer preview in questa versione)

// Signal — reattività granulare senza dipendere dal digest di Zone.js
count = signal(0);
doubled = computed(() => this.count() * 2);

Angular 17 : nouveau flux de contrôle et Vite/esbuild par défaut

Aperçu et rupture de changement

• Nouvelle syntaxe de flux de contrôle dans les modèles (@if, @for, @switch) stable, remplace *ngIf/*ngFor avec de meilleures performances de rendu.
• Le constructeur basé sur esbuild/Vite devient par défaut pour les nouveaux projets (développement de serveur considérablement plus rapide).
• @defer pour le chargement paresseux déclaratif des blocs de modèles (vues différées).

<!-- Prima: *ngFor/*ngIf -->
<div *ngIf="user">{{ user.name }}</div>
<li *ngFor="let item of items; trackBy: trackById">{{ item.name }}</li>

<!-- Dopo: nuovo control flow, track obbligatorio in @for -->
@if (user) { <div>{{ user.name }}</div> }
@for (item of items; track item.id) { <li>{{ item.name }}</li> }

<!-- @defer — carica il blocco solo quando entra in viewport -->
@defer (on viewport) {
  <heavy-chart />
} @placeholder {
  <div class="skeleton"></div>
}

Angular 18 : Expérimental et matériel sans zone 3

Aperçu et rupture de changement

• Détection expérimentale de changement sans zone : possibilité de supprimer Zone.js du bundle pour les applications basées sur Signal.
• Angular Material 3 (Material Design 3) stable, avec de nouvelles conceptions de jetons thématiques.
• Relecture d'événements pour les applications avec SSR/hydratation : les événements utilisateur pendant l'hydratation ne sont plus perdus.

// main.ts — opt-in sperimentale a zoneless (rimuove la dipendenza da Zone.js)
bootstrapApplication(AppComponent, {
  providers: [provideExperimentalZonelessChangeDetection()],
});

Angular 19 : autonome par défaut et hydratation incrémentielle

Aperçu et rupture de changement

• Les nouveaux projets générés par ng new sont autonomes par défaut : NgModule n'est plus l'échafaudage par défaut.
• Hydratation incrémentale : hydratation sélective de parties de la page au lieu de l'ensemble de l'application en masse, avec des avantages directs sur le temps d'interactivité.
• Nouvelles primitives basées sur le signal (linkedSignal, resource) pour l'état dérivé et la récupération de données réactives.

ng update @angular/core@19 @angular/cli@19

// resource() — data fetching reattivo basato su Signal (verificare API esatta nella versione installata)
userResource = resource({
  request: () => this.userId(),
  loader: ({ request }) => fetchUser(request),
});

Angular 20 et 21 : vérifiez toujours la documentation officielle

Pour ces deux versions, les plus récentes au moment de la rédaction de ce guide, les détails exacts de Les changements de rupture et les exigences de dépendance doivent toujours être confirmés avec les commandes officielles avant planifier la mise à niveau - la direction générale est la consolidation des signaux et le sans zone vers le stabilité totale, réduction supplémentaire du bundle par défaut et évolution continue du constructeur esbuild/Vite, mais les dates exactes et les détails spécifiques de l'API doivent être vérifiés au cas par cas.

# Verifica sempre versione corrente, changelog e requisiti prima di procedere
npm view @angular/core versions --json | tail -20
ng version
npx ng update @angular/core@21 @angular/cli@21 --dry-run

RxJS : de rxjs-compat à la suppression

Dans les projets démarrés à partir d'Angular 10, il est courant de trouver encore rxjs-compat installé pour prend en charge la syntaxe avec des opérateurs concaténés pré-pipebles. Il doit être retiré le plus rapidement possible : en plus de gonfler le bundle cache des dépréciations que le compilateur signalerait autrement immédiatement.

// Prima — operatori concatenati (richiede rxjs-compat)
source.map(x => x * 2).filter(x => x > 10).subscribe();

// Dopo — pipeable operators, nessuna dipendenza da rxjs-compat
source.pipe(map(x => x * 2), filter(x => x > 10)).subscribe();

npm uninstall rxjs-compat

Test : de Karma/Rapporteur à Jest/Cypress

Protractor est obsolète par l'équipe Angular elle-même depuis 2022 et devrait être remplacé quoi qu'il en soit. Version cible angulaire. Karma reste fonctionnel plus longtemps, mais Jest (supporté expérimentalement Angular 16 et versions ultérieures) offre des temps d'exécution nettement plus rapides en CI.

# Migrazione E2E: rimuovi Protractor, installa Cypress
ng g @angular/cli:e2e-e2e-schematic-removal 2>/dev/null || echo "rimuovi manualmente e2e/ e protractor.conf.js"
npm install --save-dev cypress
npx cypress open

// Test aggiornato — Jest invece di Jasmine/Karma
describe('UserCardComponent', () => {
  it('mostra il nome utente', () => {
    const fixture = TestBed.createComponent(UserCardComponent);
    fixture.componentRef.setInput('user', { name: 'Mario' });
    fixture.detectChanges();
    expect(fixture.nativeElement.textContent).toContain('Mario');
  });
});

Scripts d'automatisation pour les mises à niveau séquentielles

#!/bin/bash
# upgrade-sequenziale.sh — esegue ng update versione per versione con report
set -e
VERSIONS=(11 12 13 14 15 16 17 18 19)
for v in "${VERSIONS[@]}"; do
  echo "=== Upgrade a Angular $v ==="
  ng update @angular/core@$v @angular/cli@$v --force
  npm install
  npm run build > "report-build-v$v.log" 2>&1 || { echo "❌ Build fallita su v$v"; exit 1; }
  npm test -- --watch=false > "report-test-v$v.log" 2>&1 || echo "⚠️  Test falliti su v$v, controllare report-test-v$v.log"
  git add -A && git commit -m "chore: upgrade Angular a v$v"
done
echo "✅ Upgrade sequenziale completato fino a v${VERSIONS[-1]}"

Monorepo : Espace de travail Nx, Lerna et pnpm

Dans un monorepo avec des bibliothèques internes partagées, l'ordre de mise à jour est important : mettre à jour en premier bibliothèques partagées (en vérifiant que chaque peerDependencies déclare une plage compatible avec la nouvelle majeure), recompilez-les, puis mettez à jour les applications grand public. Avec Nx, nx migre Latest orchestre automatiquement cet ordre pour les packages gérés par l'espace de travail.

# Nx — migrazione orchestrata dell'intero workspace
npx nx migrate latest
npx nx migrate --run-migrations

CI/CD : Mise à jour des pipelines

# GitHub Actions — matrice Node/Angular coerente con la versione target
jobs:
  build:
    strategy:
      matrix:
        node-version: [20.x]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run build -- --configuration production
      - run: npm test -- --watch=false --browsers=ChromeHeadless

Mettez toujours à jour la version du nœud dans le pipeline avant en cours d'exécution ng update localement : une inadéquation entre le Node local et le Node CI est une cause fréquente de "fonctionne sur mon ordinateur" lors des mises à niveau.

Impact sur les performances et le bundle

• Ivy vs View Engine : bundles plus petits en moyenne et tremblement d'arbre plus efficace déjà depuis la transition vers Ivy (Angular 9-13).
• Suppression de ngcc : builds plus rapides après Angular 13, lorsque toutes les bibliothèques sont publiées au format de package angulaire natif Ivy.
• esbuild/Vite : Réduisez considérablement les temps de construction et de développement du serveur par rapport à l'ancien générateur Webpack, à partir d'Angular 16-17.
• Composants autonomes : éliminez le passe-partout des NgModules et améliorez le tremblement d'arbre à grain fin par composant.
• Signaux et sans zone : Suppression potentielle de Zone.js du bundle final, entraînant une réduction de la taille et des boucles de détection de changements inutiles.
• Chargement différentiel : supprimé dans les versions plus récentes car la prise en charge des navigateurs modernes a rendu obsolète le besoin de bundles ES5/ES2015+ séparés.

Problèmes connus et solutions de contournement courantes

• Tapez les erreurs après avoir activé le mode strict : activez-le progressivement fichier par fichier avec // @ts-strict-ignore temporaire au lieu de bloquer toute la mise à niveau.
• Bibliothèques tierces obsolètes : Vérifiez d'abord avec npm outdated et envisagez des forks ou des correctifs temporaires via patch-package si la bibliothèque est abandonnée.
• Conflit de dépendance entre pairs avec --force : documentez toujours pourquoi cela était nécessaire, afin de ne pas perdre la trace de la dette technique cachée.
• @for sans track : le nouveau flux de contrôle nécessite track obligatoire, une erreur de construction courante lors de la migration depuis *ngPour.

Liste de contrôle préalable à la mise à niveau

• Branche dédiée à la mise à niveau, jamais directement sur le main.
• Couverture de test existante mesurée comme référence avant de commencer.
• Nettoyer le suivi des problèmes : aucun bug connu déjà ouvert qui pourrait être confondu avec une régression de mise à niveau.
• Balise de sauvegarde/Git de la version de travail actuelle, prête pour une restauration immédiate.

Liste de contrôle de restauration

• Version de pré-mise à niveau Balise Git toujours créée avant le démarrage (Git tag pre-upgrade-v10).
• package-lock.json validé à chaque étape, afin de restaurer exactement le graphe de dépendances précédent.
• Pipeline CI/CD capable de déployer la version balisée précédente sans modifications manuelles.
• Si le projet comporte des migrations de données liées à une fonctionnalité de la nouvelle version, vérifiez qu'elles sont réversibles avant le déploiement.

Plan opérationnel de 30/60/90 jours

Jours 1 à 30 : Angulaire 10 → 14

• Mise à niveau séquentielle 10→11→12→13→14 sur branche dédiée — KPI : green build à chaque étape, 0 régression fonctionnelle connue.
• Suppression de rxjs-compat et du ViewEngine résiduel — KPI : 0 avertissement de dépréciation dans build.

Jours 31-60 : Angulaire 15 → 18

• Adoption de composants autonomes sur les nouveaux modules, migration E2E vers Cypress — KPI : 0 tests Protractor résiduels.
• Mise à niveau séquentielle 15→16→17→18, adoption d'un nouveau flux de contrôle dans les modèles les plus visités — KPI : temps de build réduit mesuré avant/après.

Jours 61-90 : Angulaire 19 → 21

• Mise à niveau finale jusqu'à la version cible, vérifiée par rapport à la documentation officielle à chaque étape — KPI : taux de réussite du build et des tests à 100% sur la version finale.
• Évaluation sans zone/signaux sur les composants de trafic les plus élevés — KPI : taille finale du paquet par rapport à la référence de pré-mise à niveau.

Étude de cas 1 : Application d'entreprise avec Monorepo Nx

Une application d'entreprise sur monorepo Nx (8 bibliothèques internes partagées, Angular 10) est terminée mise à niveau vers Angular 18 en 14 semaines avec 1,5 développeurs dédiés (~ 420 heures-personnes totaux). Principaux problèmes : 3 bibliothèques tierces sans prise en charge native d'Ivy, corrigées avec ngcc forcé jusqu'à Angular 12 et remplacement ultérieur par des alternatives conservées. Résultat : bundle initial réduit de 28 % (composants autonomes + esbuild), temps de build CI réduit de 9 à 3 minutes.

Étude de cas 2 : Commerce électronique avec un matériau angulaire

Un site de commerce électronique fortement dépendant d'Angular Material (Angular 11) a terminé la mise à niveau vers Angular 17 en 8 semaines avec 2 développeurs à temps partiel (~180 heures-personnes). Le passage au Matériau 3 (basé sur MDC) nécessitait un audit visuel complet des composants personnalisés, le plus problème cher de toute la migration. Résultat : 12 bugs de mise en page latents corrigés lors de l'audit, Time to Interactive amélioré de 22 % grâce au nouveau flux de contrôle et @defer sur widgets non critiques au-dessus de la ligne de flottaison.

FAQ

Pouvez-vous ignorer une version majeure lors de la mise à niveau ?

Non recommandé : ng update appliquer des schémas de migration spécifiques à chaque majeure, en sauter un risque des transformations de code incomplètes.

Combien de temps prend en moyenne une mise à niveau d'Angular 10 vers 21 ?

Dépend fortement de la taille du projet et des bibliothèques tierces impliquées ; Les projets d'entreprise réels nécessitent généralement 2 à 4 mois avec un effort dédié partiel.

Devez-vous réécrire tous les composants autonomes ?

Non, autonome et NgModule peuvent coexister pendant longtemps ; la migration peut être bienvenue et opportuniste sur les modules touchés pour d'autres raisons.

Que faire si une bibliothèque tierce ne prend pas en charge la nouvelle majeure ?

Vérifiez les alternatives maintenues, envisagez un fork temporaire avec un minimum de correctifs ou isolez la bibliothèque derrière un adaptateur pour la remplacer plus facilement à l'avenir.

ng update --force est-il sûr ?

Seulement après avoir vérifié manuellement que les bibliothèques concernées fonctionnent toujours ; ce n'est pas un indicateur à utiliser comme valeur par défaut automatique.

Zone.js doit-il être supprimé immédiatement ?

Non, le mode sans zone évolue toujours dans les versions plus récentes ; n'envisagez la suppression qu'après un audit complet des composants qui dépendent implicitement du résumé automatique.

Comment les failles de sécurité se produisent-elles lors de la mise à niveau ?

Avec npm audit à chaque étape et, pour les projets d'entreprise, un scanner dédié comme Snyk intégré à CI.

Avez-vous vraiment besoin de migrer de Karma vers Jest ?

Non, Karma reste pris en charge plus longtemps ; Jest est une option pour accélérer l'IC, et non une exigence obligatoire pour les nouvelles spécialisations.

Qu'arrive-t-il aux tests Protractor existants ?

Ils doivent être remplacés par Cypress ou Playwright, quelle que soit la version cible, car Protractor est obsolète par l'équipe Angular elle-même.

Comment estimez-vous l'effort d'une mise à niveau multi-majeure ?

La somme des efforts pour chaque élément majeur (construction, correction des modifications, test) plus un tampon pour les bibliothèques tierces non mises à jour représente généralement le plus grand risque.

Est-il nécessaire de mettre à jour Node avec chaque majeur Angular ?

Pas toujours pour chaque majeure, mais cela doit être vérifié dans la matrice de compatibilité : certaines majors augmentent l'exigence minimale de Node.

Est-il préférable de procéder à une mise à niveau dans un grand PR ou dans plusieurs petits ?

De nombreux petits PR, un pour la version majeure, pour isoler le risque et faciliter l'annulation d'une seule étape en cas de régression.

Erreurs courantes à éviter

• Passer la version majeure pour "le faire en premier" : les schémas de migration sont destinés à être appliqués séquentiellement, en sauter une entraîne des transformations incomplètes.
• Ne lisez pas le journal des modifications de chaque majeur : certaines modifications cassantes n'ont pas de schéma automatique et nécessitent une intervention manuelle.
• Ignorer les avertissements de dépréciation : ils deviennent des erreurs bloquantes dans la prochaine majeure, mieux vaut les résoudre lorsqu'ils ne sont encore que des avertissements.
• --force utilisé sans vérification : masque les incompatibilités réelles qui apparaîtront plus tard dans la production.
• Ne mettez pas à niveau Node dans CI avant le code local - entraîne des builds qui ne fonctionnent que sur une seule machine.
• Retarder la suppression de rxjs-compat : masquer les dépréciations RxJS que le compilateur signalerait autrement.
• Aucune balise Git avant de commencer la mise à niveau : Rend la restauration beaucoup plus lente et plus risquée en cas de régression.
• Tests E2E sur Protractor conservés "pour l'instant" : Protractor est obsolète, chaque mois de retard de migration augmente la dette technique.
• Activer le mode strict TypeScript sur l'ensemble du projet d'un seul coup : générer des centaines d'erreurs simultanées, de préférence module par module.
• Ne mesurez pas la taille du bundle avant/après : sans référence, il n'est pas possible de vérifier si la mise à niveau a réellement apporté les avantages attendus en termes de performances.
• Mettre à jour les bibliothèques monorepo internes après les applications grand public : provoque des incompatibilités temporaires, l'ordre correct est toujours les bibliothèques en premier, les applications plus tard.
• Aucun plan de restauration pour les pipelines CI/CD : Une mise à niveau qui interrompt la version de production sans un chemin de restauration rapide transforme un problème technique en incident.

Comment vérifier

• Vérifiez la version actuelle et disponible : ng version et npm view @angular/core versions.
• Effectuez un essai à sec avant chaque mise à jour réelle : ng update @angular/core@X --dry-run.
• Vérifiez les vulnérabilités après chaque étape : audit npm.
• Vérifiez la version de production : ng build --configuration production.
• Exécutez l'intégralité de la suite de tests : npm test -- --watch=false et la suite E2E Cypress.
• Mesurez la taille du bundle avant/après avec npx webpack-bundle-analyzer ou la sortie de build Angular CLI.

Conclusion

Une mise à niveau d'Angular 10 vers 21 n'est pas un événement unique, mais un programme de plusieurs mois avec onze étapes séquentielles, chacune avec ses propres risques et avantages. Le modèle qui fonctionne dans la pratique est toujours pareil : un majeur à la fois, ng update suivi de builds verts et de tests avant continuez, des balises Git à chaque étape pour un retour en arrière rapide et une vérification systématique de documentation officielle pour les versions plus récentes dont les détails ne sont pas encore consolidés dans le mémoire collective de l'équipe.

Voulez-vous un plan de migration détaillé pour votre projet spécifique ou une évaluation de l'effort demandé ? Demander un audit technique : en quelques heures d'analyse du codebase c'est Vous pouvez estimer les délais, les principaux risques et les bibliothèques tierces à surveiller pendant la mise à niveau.