Un client m'appelle un mardi matin, un peu paniqué. Son application de gestion de chantier rame, l'équipe de dev veut tout réécrire, et lui veut juste savoir s'il doit dire oui. Je lui pose une question bête : « Combien de temps cette appli doit encore vivre ? » Silence. Il n'y avait jamais pensé. On était partis sur du React parce que « c'est ce que tout le monde fait », et deux ans plus tard, personne ne se souvenait pourquoi.
Choisir un framework JavaScript adapté à son projet, ce n'est pas désigner un vainqueur entre React, Angular et Vue. C'est répondre à une poignée de questions précises sur votre équipe, la durée de vie de votre produit et votre tolérance à la dette technique. Le reste, franchement, c'est de la décoration.
Points clés à retenir
- Le bon framework est celui que votre équipe pourra maintenir dans trois ans, pas celui qui brille sur les réseaux ce mois-ci.
- La durée de vie prévue du projet pèse plus lourd que la popularité du moment.
- Un framework lourd se justifie pour un produit complexe et durable ; il devient un boulet pour une page vitrine.
- Le coût réel n'est pas le temps de démarrage, c'est le coût de migration et le recrutement.
- Une grille de décision pondérée prend une heure et vous évite des mois de regrets.
Pourquoi le bon framework est celui que vous garderez, pas celui qui brille
La plupart des guides vous présentent trois candidats, comparent leurs courbes de popularité, puis vous laissent choisir. Ce n'est pas une aide, c'est un menu sans prix.
Le vrai critère, celui que personne ne met en avant, c'est votre horizon. Un framework n'est pas un outil qu'on prend et qu'on jette. C'est une fondation. Une fondation, on la choisit en pensant au bâtiment qu'on veut dessus dans cinq ans.
Le coût de migration, toujours oublié
J'ai vu une équipe migrer d'AngularJS vers Angular en pleine refonte, en pensant que ce serait « l'affaire de quelques semaines ». Six mois plus tard, on y était encore. Le produit avait pris du retard, deux clients étaient partis, et le CTO avait changé de boîte. Personne n'avait chiffré ce chantier au moment de la décision initiale.
Le coût total d'un framework, ce n'est pas le temps que vous mettez à écrire la première ligne. C'est :
- le temps de formation de l'équipe,
- le coût de recrutement sur ce profil précis,
- la durée de vie des dépendances et le rythme des mises à jour majeures,
- et surtout, le jour où vous devrez en sortir.
Ce dernier point, dans mon expérience, représente souvent plus de la moitié du coût total — et il est presque toujours absent des tableaux comparatifs.
La grille de décision pondérée : une heure qui change tout
Voici la méthode que j'utilise désormais systématiquement. Elle ne donne pas un nom de framework : elle vous dit lequel est le moins risqué pour votre contexte.
Vous notez chaque candidat de 1 à 5 sur une série de critères, puis vous multipliez par un poids qui dépend de votre situation. Le poids, c'est là que tout se joue.
| Critère | Poids pour un produit long terme | Poids pour un prototype |
|---|---|---|
| Facilité de recrutement | 4 | 1 |
| Taille de la communauté et documentation | 4 | 2 |
| Courbe d'apprentissage initiale | 2 | 5 |
| Perte de performance sur le rendu | 3 | 3 |
| Risque de dette technique à 3 ans | 5 | 1 |
| Facilité de sortie / interopérabilité | 4 | 2 |
Regardez la ligne « courbe d'apprentissage ». Pour un prototype qu'on jettera dans deux mois, elle écrase tout le reste. Pour un produit qui doit tenir cinq ans, elle passe au second plan. Le même framework peut donc gagner dans un contexte et perdre dans l'autre — et c'est exactement le genre de nuance qu'on ne trouve nulle part.
React, Angular, Vue : comment les départager vraiment
Bon, il faut bien y venir. Mais je vais le faire autrement que par un classement.
Angular, le framework qui vous impose ses règles
Angular est un cadre complet. Il vous donne tout : routage, formulaires, injection de dépendances, structure de projet. Pour une grande équipe avec des profils hétérogènes, cette rigidité est une bénédiction. Tout le monde écrit du code qui se ressemble, et un nouveau venu comprend l'architecture en quelques jours.
Le revers : c'est lourd. Sur un petit projet, vous payez pour des fonctionnalités que vous n'utiliserez jamais. Et si votre équipe est composée de deux personnes, la cérémonie Angular peut devenir étouffante.
Vue, l'équilibre qui ne fait pas de bruit
Vue occupe l'entre-deux. Sa courbe d'apprentissage est la plus douce des trois pour quelqu'un qui vient du HTML et du JavaScript classique. Sa documentation est, à mon avis, la plus agréable à lire, ce qui compte énormément quand on onboarde quelqu'un à 22 h un dimanche.
Sa faiblesse n'est pas technique, elle est de recrutement. Il y a moins de profils Vue sur le marché. Pour une petite équipe qui recrute beaucoup, ça pèse.
React, l'écosystème qui ne finit jamais
React n'est pas un framework, c'est une bibliothèque de rendu autour de laquelle vous assemblez ce dont vous avez besoin. Cette liberté est formidable et épuisante. Vous passerez un temps non négligeable à choisir votre routeur, votre gestion d'état, votre outil de build — et à les remplacer plus tard quand la mode aura tourné.
En échange, vous avez le vivier de recrutement le plus large. Si vous devez embaucher trois développeurs en un mois, ça change tout.
Et les alternatives, on en parle ?
Svelte, Solid, Qwik, Remix, Astro. La liste s'allonge chaque année, et à chaque fois quelqu'un vous jure que c'est la fin du trio.
Mon avis est moins enthousiaste. Ces outils sont souvent excellents — Svelte produit un code d'une lisibilité rare, Astro est redoutable pour un site de contenu. Mais un choix technique n'est pas un choix esthétique. C'est un choix de risque.
La question à se poser : si la personne qui a choisi cet outil part demain, qui reprend le code ? Si la réponse est « personne », la beauté du framework n'a plus grande importance.
Faut-il vraiment suivre la tendance ?
Non, et ce n'est pas grave de ne pas la suivre. J'ai maintenu une application en Backbone bien après que tout le monde l'avait déclaré mort, et elle tournait. Elle ne coûtait rien, elle faisait son travail, et la réécrire n'aurait rien apporté au client.
La mode est un signal, pas une instruction. Quand un framework devient majoritaire, ce qui devient vrai, c'est que le recrutement sera plus simple et la documentation plus abondante. Ce sont des bénéfices concrets, pas des arguments de style.
Ce que j'ai fait de travers
Une erreur que j'ai commise tôt : choisir pour moi plutôt que pour l'équipe. J'adorais un framework parce que je le trouvais élégant, et je l'ai imposé à trois développeurs qui ne le connaissaient pas. Résultat, six semaines de productivité en berne et deux départs. La leçon a été chère.
L'autre erreur, plus sournoise : décider seul. Le choix d'un framework engage toute l'équipe pendant des années. Le faire sans les concernés, c'est préparer une résistance passive qui vous coûtera bien plus qu'une réunion d'une heure.
Depuis, je fonctionne autrement. Je remplis la grille, je présente les deux options en tête, j'explique les compromis — et je laisse l'équipe trancher. Parfois elle choisit contre mon intuition. Elle assume, et ça marche mieux.
La seule règle qui tienne vraiment
Si je devais réduire tout ça à une phrase : choisissez le framework que votre équipe pourra maintenir sans vous.
Pas le plus rapide à démarrer. Pas le plus élégant. Pas celui dont on parle le plus. Celui qui, dans trois ans, quand la moitié de l'équipe aura changé, restera lisible et documenté.
Et si vous hésitez encore après avoir rempli la grille, c'est probablement que les deux options se valent. Dans ce cas, prenez celle que vos développeurs connaissent déjà. Le meilleur framework reste celui qu'on maîtrise — et ça, aucune courbe de popularité ne vous le dira.
