React, Angular : les frameworks des géants de la tech sont-ils vraiment fiables ?

Lorsqu’il s’agit de choisir une technologie pour un projet web, la stabilité et la pérennité du framework sont des critères essentiels. Avec React et Angular, la tentation est grande de croire en une certaine fiabilité. Mais dans un contexte de restructurations, de licenciements et d’intérêts parfois divergents entre entreprises et développeurs, peut-on vraiment considérer ces frameworks soutenus par des géants de la tech comme des choix sûrs sur le long terme ? 

Imaginons qu’en ce début d’année 2025, vous soyez amené à démarrer un projet web. Ce peut être pour votre client ou un projet perso, mais dans tous les cas un projet sur lequel vous voulez investir dans la durée.

Très rapidement, vous allez vous poser la question du choix de votre librairie Front-End. Et avec l’explosion du nombre de librairies et de frameworks disponibles, chacune avec ses approches différentes, l’écosystème Javascript n’a jamais semblé aussi confus et illisible en apparence.

Par conséquent, vous allez sans doute vouloir vous orienter sur React ou Angular, des solutions déjà largement adoptées par de nombreuses entreprises et qui bénéficient du soutien de grands groupes de la tech, Meta d’un côté, Google de l’autre. Ce soutien est très certainement un gage de sérieux et de stabilité conduisant donc à un choix sûr et éclairé, n’est-ce pas ?

Eh bien, les choses ne sont pas si simples ! Ces dernières années, les grandes entreprises de la tech américaine ont connu leur lot de bouleversements : redéfinition de leurs priorités dans un contexte post-covid, vagues de licenciements, changement de gouvernance… Sans exagérer leur importance, il serait faux de dire que ces événements n’ont eu aucun impact sur notre écosystème.

Dans cet article, je vous propose d’interroger ensemble la situation de deux des trois librairies front-end les plus populaires et, par la même occasion, d’élargir la réflexion à des facteurs que nous ne prenons à mon avis pas suffisamment en compte au moment de faire un choix de technologie sur un projet.

Angular, la chasse gardée de Google

Débutons par le framework phare développé par les équipes de Google. Tout comme React, Angular est un projet open source, ce qui veut dire que tout développeur pourrait potentiellement contribuer au projet et proposer de nouvelles fonctionnalités. Mais l’équipe en charge de la maintenance de ce projet – notamment de la plupart des nouvelles fonctionnalités majeures et de la validation des pull requests des contributeurs et contributrices tiers – reste pour l’essentiel interne à Google et sa maison mère, Alphabet.

Angular a connu une période un peu délicate au début des années 2020. La complexité apparente du framework semblait être un désavantage par rapport aux librairies concurrentes telles que Vue et React. Mais plus encore, Angular semblait aussi accuser un retard important par rapport à l’évolution des pratiques dans le développement Front, notamment sur plusieurs features importantes que ses concurrents possédaient déjà : 

• Support du SSR (server-side rendering, rendu côté serveur) ;
• Gestion de la réactivité ;
• Sans parler du couplage fort avec l’architecture en modules qui pouvait être vue comme un cadre beaucoup trop contraignant sur certains projets.

Et puis, à partir de l’année 2023, la confiance est revenue alors que ce retard était progressivement rattrapé :

• Arrivée progressive du support des standalone components à partir d’Angular 15 ;
• Support du SSR à partir d’Angular 17 ;
• Déploiement progressif des signaux pour la gestion de la réactivité à partir d’Angular 16.

Tous ces efforts ont payé pour regagner la confiance de la communauté – dont la mienne –, et tant mieux. Mais on peut se poser des questions sur la roadmap de développement du framework qui reste en premier lieu développé pour répondre aux besoins de Google qui l’utilise sur une très grande majorité de ses outils.

Google a aussi connu des vagues de licenciements ces dernières années : 12 000 personnes en janvier 2023 et plus d’un millier au cours de l’année 2024.

Le cas Flutter

Si un seul développeur de l’équipe Angular a été affecté (en 2023) par ces licenciements, on peut se pencher sur le cas d’un autre produit open source maintenu en interne par Google : Flutter, un framework de développement d’applications cross-platform (notamment pour mobile). Alors que Flutter gagnait de plus en plus en popularité, les licenciements de 2024 eurent un effet assez lourd sur l’équipe, poussant au départ plusieurs contributeur·ices clés du projet, et ce dans un contexte où la communauté était plutôt satisfaite du projet en l’état mais déplorait la faible régularité des mises à jour.

Cela a amené des collectifs de devs à créer un fork du projet, Flock, pour palier l’absence d’investissement continu de Google dans Flutter.

Alors la même chose pourrait-elle arriver à Angular ?

Début 2025, la firme de Montain View a également annoncé un plan de départ volontaire proposé à plus de 25 000 salarié·es. Nous connaîtrons courant mars le nombre exact ayant accepté ces conditions, et si des licenciements complémentaires sont prévus.

On peut mettre dans la balance la criticité beaucoup plus importante pour Google d’Angular par rapport à Flutter. Toujours est-il qu’en fin de compte, l’équipe Angular n’est pas à l’abri de départs soudains et/ou de restructurations comme l’ont été d’autres équipes chez Google. On ne peut douter de la bonne foi des personnes qui travaillent sur le projet et sont souvent très investies auprès des communautés de dev, mais la décision ne leur appartient pas.

React, une gouvernance contestable ?

L’histoire récente de React est légèrement différente. Reconnaissons d’ores et déjà ce mérite, l’équipe (ou « Core Team ») qui maintient le projet est beaucoup plus transparente sur sa composition, et celle-ci n’est plus, depuis plusieurs années, composée uniquement d’ingénieurs de Meta.

À ce jour, elle est constituée :

• De 14 ingénieurs de Meta ;
• De 5 ingénieurs de Vercel ;
• Et de 2 ingénieurs indépendants.

Focus sur Vercel

Revenons sur le rôle de Vercel car vous ne connaissez peut-être pas cette entreprise. Fondée en 2015, Vercel propose des services d’hébergement et de déploiement simplifiés pour tous types d’application, avec notamment un fort focus sur les offres serverless (en s’appuyant derrière sur les infrastructures d’AWS et de Cloudflare). Il s’agit donc notamment d’un concurrent à des services comme Heroku ou Netlify.

Vercel maintient également le framework Next.js depuis sa création. Next.js apporte à React, sur lequel il repose entièrement, une couche de SSR très appréciée et toutes les fonctionnalités qui vont avec (notamment la partie référencement, toujours difficile à gérer avec les frameworks Front modernes).

Next.js est devenu très populaire après son adoption par plusieurs grands groupes (dont le Washington Post aux États-Unis). Et, disons-le clairement… C’est aussi un vecteur de communication important pour Vercel qui n’hésite pas à revendiquer la parenté du projet sur son site (quand bien même celui-ci est open source).

Ce ne serait pas un problème si Next.js répondait aux cas d’usage de la plus grande partie de la communauté. Mais il y a un hic : le déploiement d’une application Next.js, en particulier en serverless, designé pour être grandement facilité sur Vercel et qui peut demander bien plus d’efforts sur d’autres plateformes.

Plusieurs ingénieurs de Vercel sont des contributeurs de longue date de React et ont des échanges continus avec la Core Team. Mais les choses s’accélèrent début 2021 quand Vercel recrute Sebastian Markbåge, membre de la Core Team React chez Meta.

Les problèmes posés par cette proximité deviennent apparents à la conférence Next.js 2023, où Vercel annonce une nouvelle fonctionnalité de routing pour son framework, l’App Router. Cette fonctionnalité reposait sur une nouveauté tout juste intégrée à React, à la surprise de la communauté qui n’y voyait pas une priorité : les React Server Components dédiés au rendu côté serveur.

Des inquiétudes ont rapidement émergé quant au risque que la Core Team React, désormais composée en partie de développeurs de Vercel, privilégie Next.js par rapport aux autres frameworks de rendu côté serveur (SSR) pour React, et plus largement, qu’elle oriente React vers cet usage au détriment de son utilisation principale en Single Page Application (SPA). En témoignent par exemple les nombreux échanges dans les espaces de discussions dédiés à la librairie.

Où en est-on aujourd’hui ?

Je pensais m’arrêter là au sujet de Vercel, mais pendant la rédaction de cet article, je suis tombé sur d’autres informations surprenantes :

1. La première a été assez peu médiatisée : en 2024, plus de la moitié des commits (changements dans le code) effectués sur la base de React provenaient de l’équipe Vercel.
2. La deuxième est l’annonce sur le blog de l’équipe, le 14 février 2025, de l’abandon du module de base de création d’application React (create-react-app). Cette suppression était attendue du fait de la popularité grandissante d’un autre outil de build ces dernières années : Vite.

Vite est un outil qui a considérablement amélioré les performances de développement, notamment en local. Il est agnostique, pouvant être utilisé avec la plupart des librairies Front-End utilisées. Son adoption a explosé ces deux dernières années. Il a été créé par Evan You, un développeur indépendant également à l’origine de Vue.js, un « concurrent » de React. Or, dans son article, l’équipe React ne préconise pas une migration vers Vite, qui couvrirait 90% des besoins et serait rapide à mettre en œuvre, mais plutôt vers des solutions de type framework, comme par exemple… Next.js !

En définitive, l’orientation de React semble de plus en plus tournée vers le SSR, couplée avec les efforts de Vercel, et revient sur certains de ses choix de philosophie d’origine, notamment celui d’être agnostique en termes de librairies/frameworks à utiliser en complément.

Et même quand l’équipe de Meta s’implique, ce n’est pas toujours avec les intérêts de la communauté comme souci principal. En juin 2024, une mise à jour sur les Suspense, une fonctionnalité de React permettant de gérer les comportements asynchrones (appels API, etc.), a radicalement changé leur comportement, au détriment des performances de la plupart des applications utilisant cette fonctionnalité.

Un changement assez incompréhensible par les devs les plus calés sur le sujet et qui, après investigation, se révèlera avoir été introduit… pour les besoins d’Instagram ! Le sujet avait même été couvert par des médias en ligne spécialisés. L’équipe fera finalement machine arrière, non sans avoir perdu la confiance d’une partie de la communauté.

Pourquoi tout cela est-il problématique ?

Si votre projet est prévu pour avoir une durée de vie courte et ne nécessitera pas forcément un important travail de maintenance à l’avenir, ces points-là ne vous concernent sans doute pas. Personnellement, je suis même plutôt satisfait de voir Angular remis au goût du jour et un peu plus à l’écoute de ses utilisateur·ices.

Mon intention était surtout de montrer que le fait de voir un grand nom adossé à une librairie n’est pas forcément un gage de confiance et de stabilité, et, qu’au contraire, l’orientation donnée à l’évolution de cette dernière peut correspondre à des impératifs et des besoins qui ne sont pas ceux de la communauté au sens large.

Je trouve que la conclusion de l’article de developpez.com cité plus tôt résume bien la question qui se pose : comment s’assurer que les évolutions de ces librairies sont compatibles avec le besoin de stabilité et de maintenabilité pour les applications existantes ? Et que la communauté est impliquée dans les discussions et les décisions sur leur futur ?

Mais au-delà de ces préoccupations, le cas de Flutter montre bien que, même si l’équipe en charge d’un outil est impliquée et prend en compte les retours, l’appartenance à un grand groupe crée de fait une vulnérabilité face aux décisions macroscopiques qu’une telle entreprise peut être amenée à prendre.

À titre personnel, j’ai beaucoup entendu de critiques sur le statut de Vue, une librairie qui, du point de vue de certains décideurs techniques avec qui j’ai déjà échangé, ne méritait pas la même considération qu’Angular ou React du fait du soutien que Google et Meta leur apportaient. Cette indépendance m’apparaît aujourd’hui plutôt une force, mais aussi être plus proche de la philosophie d’origine de l’open source. Et la diffusion rapide des innovations portées par l’environnement Vue dans le reste de l’écosystème Javascript, avec de vrais bénéfices pour les utilisateurs, semble leur donner raison.