Angular 2 a servi de base à une génération d’applications web plus structurées, mais sa vraie valeur aujourd’hui est surtout pédagogique et patrimoniale: comprendre ce qu’il a apporté aide à lire du code legacy, à éviter les mauvais réflexes et à mieux saisir la logique du framework côté frontend. Dans cet article, je passe en revue son architecture, ses forces, ses limites et la façon la plus réaliste d’aborder un projet hérité en 2026. Je ne traite pas cette version comme une curiosité de musée: je la lis comme un socle dont il faut connaître les règles avant de le maintenir ou de le remplacer.
Ce qu’il faut garder en tête avant de travailler sur cette base front-end
- La version 2 d’Angular a marqué une rupture nette avec AngularJS en imposant une approche centrée sur les composants et TypeScript.
- Son architecture repose sur quelques briques simples à nommer, mais exigeantes à bien séparer: composants, services, injection de dépendances, templates et routage.
- Le gain principal était la maintenabilité des applications longues à faire vivre; le coût réel, une discipline plus stricte et une courbe d’apprentissage plus raide.
- En 2026, on rencontre surtout ce socle dans des projets existants à maintenir ou à migrer, pas comme point de départ pour une application neuve.
- La bonne stratégie est presque toujours incrémentale: comprendre, tester, isoler, puis moderniser par étapes.
Ce que cette version a changé dans le paysage frontend
La rupture principale a été nette: on ne parle plus d’un simple rafistolage d’AngularJS, mais d’une refondation pensée pour les applications riches et durables. Le framework a imposé une logique plus claire autour des composants, de TypeScript et de l’injection de dépendances, ce qui a rendu les grandes bases de code plus prévisibles.
Dans la pratique, cela signifiait trois choses. D’abord, l’interface n’était plus vue comme un ensemble de fragments dispersés, mais comme une somme de composants bien définis. Ensuite, la séparation entre rendu, état et services devenait plus lisible. Enfin, l’équipe acceptait un peu plus de rigueur au départ pour gagner en stabilité sur la durée. Pour comprendre ce que cela changeait concrètement, il faut regarder la mécanique interne du framework.
L’architecture à comprendre pour lire un projet hérité
Je résume toujours cette architecture en huit briques. C’est simple à l’énoncer, mais c’est précisément cette simplicité qui rend le code ancien lisible quand elle est respectée.
| Brique | Rôle | Lecture pratique |
|---|---|---|
| Composant | Porte une partie visible de l’interface et la logique associée | C’est l’unité de base que je teste et que je fais évoluer en premier |
| Template | Décrit le HTML rendu à l’écran | Il doit rester déclaratif, sinon il devient vite difficile à relire |
| Liaison de données | Relie l’état du composant au DOM | Plus le flux est clair, moins le code devient fragile |
| Directive | Ajoute un comportement au balisage | Utile, mais à utiliser sans multiplier les exceptions |
| Service | Encapsule la logique métier, les appels API et les règles partagées | Évite de surcharger les composants avec des responsabilités inutiles |
| Injection de dépendances | Fournit les services aux bonnes briques | Réduit le couplage et facilite les tests |
| NgModule | Organise un ensemble de fonctionnalités | Très présent dans les projets anciens, moins mis en avant dans les projets neufs |
| Routeur | Gère la navigation dans une application monopage | Indispensable dès que l’app dépasse quelques écrans |
Je lis toujours ce modèle comme une chaîne: le composant expose un état, le template l’affiche, le service porte la logique, et l’injection de dépendances relie tout cela sans couplage brutal. Cette chaîne paraît évidente sur le papier, mais c’est elle qui fait la différence entre un projet lisible et une application qui se fragmente au moindre changement. Une fois ce socle clair, on peut juger plus honnêtement ce qu’il apportait à une équipe frontend.
Ce que cela apporte et ce que cela coûte à une équipe frontend
Ce que l’approche rendait plus solide
Le principal avantage était la prévisibilité. Quand les rôles sont bien séparés, on sait où mettre une règle métier, où placer un affichage, où brancher un flux asynchrone, et surtout où chercher quand quelque chose casse.
- Les composants restent plus petits et plus testables.
- Les services centralisent la logique commune au lieu de la répandre partout.
- Les équipes peuvent se répartir les écrans sans réécrire les mêmes règles.
- Le routage rend les parcours plus lisibles dans les applications monopage.
Sur des produits amenés à durer, ce cadre a vraiment aidé à éviter le chaos. Pour autant, ce confort avait un prix, et c’est là que beaucoup de projets hérités révèlent leurs faiblesses.
Ce qui compliquait vraiment la vie
Le coût le plus visible était la courbe d’apprentissage. TypeScript, les décorateurs, les services, le routage, les flux réactifs et la séparation stricte des responsabilités demandaient plus de discipline qu’un petit projet JavaScript classique.
- Le code peut vite devenir verbeux si on met trop de logique dans les composants.
- RxJS apporte une vraie puissance, mais aussi une complexité réelle dès qu’on gère plusieurs sources asynchrones.
- Les modules et la structure de projet peuvent donner une impression de lourdeur si l’équipe n’a pas de conventions claires.
- Le piège le plus courant consiste à contourner le framework au lieu de travailler avec lui, par exemple en manipulant le DOM directement là où un binding suffisait.
- Autre erreur fréquente: migrer une application sans tests solides et sans inventaire des dépendances critiques.
Quand on garde cette base en 2026, la vraie question devient donc opérationnelle: comment la reprendre sans casser la production.
Comment aborder un projet hérité sans casser la chaîne
Sur un projet ancien, je pars presque toujours du même principe: une migration directe vers une base moderne sera coûteuse, et souvent irréaliste sans étapes intermédiaires. Le bon réflexe n’est pas de tout réécrire, mais d’identifier ce qui protège réellement le métier, puis de moderniser par couches.
Commencer par l’inventaire
Avant de toucher au code, j’identifie la version du framework, les dépendances majeures, les zones couvertes par des tests et les écrans les plus sensibles. Dans beaucoup de cas, les risques se concentrent sur quelques parcours: authentification, paiement, back-office, formulaires lourds ou synchronisation avec des API critiques.
Sécuriser la première marche
Je préfère ajouter de la couverture là où le coût d’une régression serait élevé. Cela peut vouloir dire quelques tests unitaires sur les services, des tests d’intégration sur les flux les plus risqués, et une mise à plat du build ou du linting avant toute autre chose. C’est moins spectaculaire qu’une refonte, mais bien plus rentable.
Lire aussi : ARIA - Maîtrisez l'accessibilité sans fausse note
Moderniser par couches
Ensuite seulement, je découpe le chantier en petites tranches. Un écran, un service, un module, puis un autre. Cette approche évite le piège classique: mélanger une vieille architecture, un nouveau style de code et des corrections d’urgence dans la même branche pendant des semaines. L’ancienne documentation sert alors à comprendre l’existant, tandis que les règles actuelles du framework guident les choix neufs.
Une fois cette méthode en tête, la comparaison avec l’Angular actuel devient beaucoup plus parlante qu’un discours abstrait sur la modernité.
Angular v2 face à l’Angular actuel
La différence la plus utile à garder en tête n’est pas une opposition brutale entre “ancien” et “nouveau”. C’est surtout une simplification progressive du modèle d’écriture. Le cœur conceptuel reste proche, mais l’outillage et les conventions ont évolué vers quelque chose de plus direct pour le code neuf.
| Aspect | Version 2 | Angular actuel |
|---|---|---|
| Construction de l’application | NgModules très présents et démarrage par module | Composants autonomes recommandés pour le nouveau code, avec un démarrage plus direct |
| Templates | *ngIf, *ngFor, *ngSwitch | @if, @for et @switch intégrés au langage de template |
| Réactivité | Observables et RxJS au centre de nombreux flux | Signals et Observables selon le besoin |
| Outillage | Cadre plus lourd et plus dépendant des conventions de l’époque | CLI, DevTools, hydratation et pipeline de build plus modernes |
| Statut pratique | Base héritée à maintenir ou à migrer | Base recommandée pour les nouveaux projets |
Je retiens surtout une chose: le framework n’a pas changé de philosophie du tout au tout, il a surtout rendu ses idées plus simples à exprimer. D’ailleurs, la documentation actuelle recommande les composants autonomes pour le code neuf, ce qui confirme le mouvement de fond vers une écriture plus légère. Reste alors la décision la plus utile pour un lecteur technique: quoi faire, concrètement, selon le contexte du projet.
Les décisions qui évitent de transformer la dette technique en chantier infini
Si vous tombez sur une base fondée sur cette génération du framework, je vous conseille de raisonner en fonction de l’objectif immédiat, pas d’une idée abstraite de “propreté”:
- Pour comprendre le frontend, concentrez-vous sur les composants, les services, l’injection de dépendances, le routage et les flux de données.
- Pour maintenir un projet ancien, protégez d’abord les parcours critiques avec des tests, puis modernisez les zones les plus fragiles.
- Pour lancer une application neuve en 2026, partez sur les pratiques actuelles plutôt que sur un ancien modèle qui impose plus de contraintes que nécessaire.
Je retiens une règle simple: cette version appartient au passé du framework, mais elle explique encore beaucoup du présent. La traiter avec méthode permet soit de la lire correctement, soit de s’en sortir proprement; la traiter comme un code à “nettoyer vite” produit presque toujours l’inverse.
