🅰️ Angular : pourquoi je préfère un framework complet à une bibliothèque

📚 Introduction

Il y a un moment, dans à peu près tous les projets frontend que je reprends, où je tombe sur le même fichier : un package.json avec quarante dépendances directes, dont une bonne moitié sert à faire ce qu’un framework fournit d’origine. Un routeur, un client HTTP, une gestion de formulaires, une bibliothèque de state, un runner de tests, un outil d’i18n, une couche SSR. Chacune choisie un jour par quelqu’un, pour de bonnes raisons, et chacune avec son propre rythme de releases.

Ce n’est la faute de personne. C’est la conséquence directe d’un choix de départ : on a pris une bibliothèque et on a construit un framework autour. C’est le modèle React, et c’est parfaitement légitime. Mais ce n’est pas gratuit, et le coût n’apparaît pas à la semaine 2 du projet — il apparaît au mois 30, quand il faut monter une majeure et que six dépendances tirent dans six directions.

Angular fait le pari inverse. J’ai fini par trouver que ce pari est le bon dans la majorité des projets que je vois passer, et cet article explique pourquoi — sans prétendre que c’est toujours vrai.

🧩 Framework ou bibliothèque : qu’est-ce que ça change vraiment ?

Une bibliothèque, tu l’appelles. Un framework, il t’appelle. La formule est jolie mais elle rate l’essentiel. La vraie différence est ailleurs : un framework prend un lot de décisions à ta place, et s’engage à les maintenir cohérentes entre elles dans le temps.

Concrètement, quand tu démarres un projet Angular, les questions suivantes sont déjà tranchées : comment on route, comment on appelle une API, comment on décrit un formulaire et sa validation, comment on injecte une dépendance, comment on écrit un test, comment on rend une page côté serveur, comment on découpe le code. Tu peux être en désaccord avec certaines réponses. Mais elles sont prises, documentées, et surtout : elles évoluent ensemble.

Côté React, ces mêmes questions restent ouvertes, et chaque équipe y répond avec un assemblage différent. Vue est dans une position intermédiaire honnête : le routeur (Vue Router) et le store (Pinia) sont officiels, ce qui réduit nettement le problème — mais ils restent des paquets versionnés séparément, et le reste de la pile (formulaires, HTTP, tests) est toujours à ta charge.

🧱 Ce qu’Angular décide à ta place

La liste des briques officielles, telle qu’elle existe aujourd’hui en v22 :

• Routeur avec lazy loading, guards et resolvers, dans @angular/router.
• Client HTTP (@angular/common/http) avec intercepteurs, XSRF et transfer cache.
• Formulaires : les formulaires réactifs historiques, et depuis la v22 les Signal Forms passées en API publique.
• Injection de dépendances avec un vrai conteneur, des scopes et la fonction inject().
• Rendu serveur et hydratation via @angular/ssr.
• Tests : depuis la v21, un nouveau projet créé par la CLI arrive avec Vitest et jsdom configurés.
• Accessibilité : @angular/aria, stabilisé en v22.
• Internationalisation dans @angular/localize.

Le point n’est pas que chacune de ces briques soit la meilleure de sa catégorie prise isolément. Elle ne l’est pas toujours. Le point est qu’elles portent le même numéro de version, qu’elles sont testées ensemble avant chaque release, et qu’une seule commande — ng update — les fait toutes avancer en appliquant les migrations de code correspondantes.

C’est exactement la même logique qui m’a fait apprécier NestJS côté serveur ou Symfony UX pour des interfaces réactives en Twig : moins de liberté au démarrage, beaucoup moins de dérive à l’arrivée.

💸 Le coût caché de la pile assemblée

Sur un projet qu’on garde deux ou trois ans, l’assemblage se paie sur trois postes.

Le poste « qui monte quoi, et dans quel ordre ». Chaque dépendance a son propre calendrier de majeures, sa propre définition de ce qu’est un breaking change, et sa propre qualité de guide de migration. Quand deux d’entre elles ont des exigences de pairs incompatibles, personne n’arbitre : c’est ton problème.

Le poste « qui maintient ». Une pile de dix bibliothèques, c’est dix projets dont il faut suivre la santé. Certaines sont portées par une entreprise, d’autres par une personne. Sur un projet client de longue durée, l’abandon d’une brique centrale est un risque réel, pas théorique.

Le poste « reprise de projet ». C’est celui que je vois le plus souvent en freelance. Deux applications React de la même époque n’ont presque rien en commun dans leur organisation : la façon de gérer les appels réseau, la structure des dossiers, le style de tests, tout est spécifique à l’équipe qui l’a écrite. Deux applications Angular, oui. Un développeur Angular ouvre un projet Angular qu’il n’a jamais vu et sait déjà où chercher. Sur une mission de reprise, ça se compte en jours facturés.

⚠️ Quelques précautions

Je ne vais pas prétendre qu’Angular gagne partout.

• La courbe d’apprentissage est réelle. DI, décorateurs, change detection, RxJS dans le code existant : une équipe qui n’a jamais fait d’Angular ne sera pas productive en une semaine. React se prend en main plus vite, c’est un fait.
• Sur un prototype ou un widget embarqué, la structure imposée est un coût pur. Pour une landing page ou une démo à jeter, ce n’est pas le bon outil.
• L’écosystème mobile reste un argument massif pour React : si tu vises React Native, la question ne se pose même pas.
• Le vivier de développeurs React est plus large sur le marché français. Ça compte au moment de staffer.
• Beaucoup de projets Angular existants traînent encore du code en modules NgModule et en RxJS partout. L’Angular moderne est agréable ; l’Angular hérité de 2019 l’est nettement moins.

🎉 Conclusion

Mon arbitrage tient en une phrase : plus l’horizon de maintenance est long et plus le nombre de mains qui passeront sur le code est élevé, plus le framework complet est rentable.

Pour une application métier qui doit vivre cinq ans, être reprise par un prestataire qui n’était pas là au début, et suivre les majeures sans réécriture — Angular est un choix beaucoup plus sûr qu’une pile maison. Pour un MVP à sortir en trois semaines, franchement, prends ce que ton équipe connaît déjà.

Dans le prochain article, j’entre dans le détail du tooling : ce que couvre réellement la CLI Angular, du scaffolding aux tests en passant par le SSR.

🔗 Liens utiles

• Site officiel Angular
• Versioning et politique de support Angular
• Dépôt GitHub angular/angular
• React — documentation officielle
• Vue.js — documentation officielle