Comment choisir son framework JavaScript pour un projet web

Le vendredi 14 heures. Un client m'appelle, paniqué : son équipe de trois développeurs vient de passer six semaines à prototyper une application de gestion avec Svelte, et le premier client potentiel exige soudain une intégration avec un progiciel qui n'expose qu'un SDK React. Six semaines. Un seul critère oublié. On a tout réécrit en cinq jours avec Next.js, et le projet a démarré avec trois semaines de retard.

Ce genre d'histoire, je pourrais vous en raconter une dizaine. Et à chaque fois, la même cause : on a choisi un framework sur sa popularité ou ses benchmarks, pas sur les contraintes réelles du projet. Choisir son framework JavaScript pour un projet web, ce n'est pas un concours de goûts. C'est un arbitrage entre cinq ou six variables qu'on peut chiffrer.

Je vais vous donner la grille que j'utilise désormais systématiquement, avec des seuils concrets. Et je vais aussi vous raconter les deux fois où je me suis planté, parce que c'est là qu'on apprend le plus.

Pourquoi le choix du framework conditionne la réussite de votre projet

Un framework, ce n'est pas un outil qu'on remplace. C'est une dette ou un actif, selon ce que vous en faites.

La différence entre les deux se joue rarement au moment du choix. Elle se joue dix-huit mois plus tard, quand vous devez recruter quelqu'un en urgence, quand une librairie critique n'est plus maintenue, ou quand votre client veut une fonctionnalité qui existe partout sauf dans votre stack.

Le mythe du choix technique pur

J'entends souvent : "on choisit ce qui est techniquement supérieur". Franchement, cette phrase n'a pas de sens. Techniquement supérieur pour quoi ? Sur quel axe ? Un framework dont le temps de rendu initial est deux fois plus rapide mais qui vous coûte 15 000 € de plus en recrutement sur deux ans n'est pas supérieur, il est juste différent.

Ce que j'ai fini par comprendre en accompagnant des équipes, c'est que le framework est un choix social autant que technique. Il détermine qui vous pourrez embaucher, à quel prix, et combien de temps vous mettrez à former ceux qui arrivent.

Ce que les benchmarks ne mesurent pas

Les tests de performance publient des chiffres de rendu à la milliseconde près. Ces chiffres sont exacts. Ils sont aussi presque inutiles dans la majorité des cas, parce que la performance perçue d'une application dépend beaucoup plus de la qualité de votre code, de votre stratégie de cache et de votre backend que du framework lui-même.

Une application mal architecturée sera lente en Svelte. Une application bien pensée sera fluide en Angular. J'ai vu les deux cas de mes propres yeux, et ça remet pas mal de certitudes en place.

React, Angular, Vue, Svelte : la grille réelle

Bon. Passons au concret.

Je classe les frameworks selon quatre familles de critères : la disponibilité des compétences, la profondeur de l'écosystème, la courbe d'apprentissage, et la gouvernance à long terme. Voici comment je les note selon les projets que je vois passer.

Comparatif synthétique

Critère	React	Angular	Vue	Svelte
Vivier de candidats	Très large	Large mais cher	Moyen	Étroit
Courbe d'apprentissage initiale	Moyenne (2 à 3 semaines)	Raide (6 à 10 semaines)	Douce (1 à 2 semaines)	Très douce (quelques jours)
Taille du bundle par défaut	Élevée	Très élevée	Moyenne	Faible
Gouvernance	Meta + communauté	Google	Communauté + sponsors	Équipe réduite + Vercel
Outillage intégré (routing, état, formulaires)	À assembler	Complet	Quasi complet	À assembler
Renouvellement des versions majeures	Progressif	Ruptures lourdes	Modéré	Rapide mais bien accompagné

Deux choses sautent aux yeux. La première : Angular est le seul à fournir un cadre complet sans rien assembler, ce qui explique qu'il reste dominant dans les grands groupes. La seconde : Svelte est imbattable sur la légèreté et la simplicité, mais ce n'est pas là que se joue la décision dans 80 % des cas.

Le critère qui compte vraiment : le vivier de compétences

React domine le marché de l'emploi front-end. Ce n'est pas une opinion, c'est ce que je constate en publiant des offres : sur une annonce React, je reçois cinq à dix fois plus de candidatures crédibles que sur une annonce Svelte équivalente, à budget identique.

Et ça a un effet direct sur le coût. Sur les missions que je vois passer, un développeur Angular senior se négocie en moyenne 15 à 25 % plus cher qu'un profil React de même séniorité, parce que l'offre est plus rare et la demande concentrée dans les grands comptes.

Svelte, c'est encore autre chose. Le vivier est réel mais étroit. Si vous cherchez un profil Svelte confirmé en province, vous allez attendre longtemps.

Comment choisir selon la taille de l'équipe et du projet

Voici la partie que j'aurais aimé lire il y a dix ans.

Moins de trois développeurs, projet de moins d'un an

Prenez Vue ou Svelte. Sans hésitation.

Sur une petite équipe, la vélocité initiale domine tout le reste. Un développeur seul qui met une semaine à être productif en Vue contre trois semaines en Angular, ça fait deux semaines d'avance sur la première livraison. Sur un projet de six mois, c'est énorme.

J'ai monté deux applications métier avec Vue dans cette configuration. La première, trois développeurs, livrée en cinq mois. La seconde, deux développeurs, en trois mois. Aucune n'a eu besoin d'un écosystème React.

Trois à dix développeurs, projet de un à trois ans

C'est là que React devient le choix par défaut, et ce n'est pas par paresse.

À cette échelle, vous allez recruter au moins deux ou trois personnes pendant la vie du projet. Vous allez intégrer des bibliothèques tierces pour la datagrid, les graphiques, l'authentification, l'internationalisation. Sur React, chacune de ces briques a trois ou quatre options matures. Sur Vue, une ou deux. Sur Svelte, parfois une seule, parfois aucune.

• Recrutement : un vivier dix fois plus large vous évite les mois de recherche infructueuse.
• Écosystème tiers : c'est là que se creuse réellement l'écart, pas sur les performances.
• Turnover : quand un développeur part, le suivant trouve des ressources en français en quinze minutes.
• Contraintes clients : beaucoup de prestataires imposent leur stack, et React est celle qu'on rencontre neuf fois sur dix.

Plus de dix développeurs, ou projet critique sur cinq ans

Angular redevient pertinent.

Je sais que ce n'est pas populaire de le dire. Mais sur une application bancaire ou un portail réglementaire avec quinze développeurs répartis sur trois équipes, le cadre très structuré d'Angular, sa gestion de l'injection de dépendances et son typage strict par défaut évitent des dérives que j'ai vues sur des gros projets React mal encadrés.

Le coût est réel : profils plus chers, courbe d'apprentissage plus raide, migrations majeures douloureuses. Mais sur ce type de projet, la cohérence du code vaut ce prix.

Les deux fois où je me suis planté

Parce qu'un article qui ne parle que de succès n'aide personne.

Erreur n°1 : choisir Svelte pour un client réglementé

Il y a quatre ans, j'ai convaincu un client du secteur de la santé de partir sur SvelteKit. Les arguments étaient bons : bundle léger, développeur unique et rapide, projet de huit mois. Ce que je n'avais pas anticipé, c'est la contrainte de conformité : le client exigeait un audit de sécurité sur toutes les dépendances, avec une équipe externe qui ne connaissait que les stacks React et Angular. Résultat, deux mois de retard pour documenter et faire valider chaque brique.

Le framework n'était pas en cause. Le contexte réglementaire l'était, et je l'ai ignoré.

Erreur n°2 : sous-estimer la durée de vie du projet

Un projet "rapide" de quatre mois s'est transformé en produit maintenu sur trois ans. On avait choisi un framework de niche, avec une communauté microscopique. À la deuxième année, deux bibliothèques critiques n'étaient plus maintenues, et on a dû migrer. Coût de l'opération : environ un mois-homme de travail, plus les bugs de régression.

Franchement, ça aurait pu être pire. Mais la leçon est claire : posez toujours la question de la durée de vie à trois ans, pas à trois mois.

Comment choisir son framework JavaScript pour un projet web quand React, Angular et Vue ne conviennent pas

Il reste des cas où aucun des trois grands ne colle.

Si votre besoin principal est la performance brute sur du contenu majoritairement statique, regardez du côté d'Astro : il envoie très peu de JavaScript au navigateur, ce qui change tout sur les Core Web Vitals. J'ai migré un site de documentation avec cette approche, et le temps de chargement perçu est passé de plus de deux secondes à moins d'une seconde, sans changer le contenu.

Si vous avez besoin d'interactivité fine sur une page existante, sans réécrire l'application, Alpine.js fait le travail pour quelques kilo-octets. C'est l'outil que j'utilise pour les petits widgets embarqués chez des clients dont le site est en PHP ou en Rails. Pas besoin de sortir l'artillerie lourde.

Si votre besoin est mobile, et pas web, le débat est différent : React Native et Flutter occupent le terrain, et le choix se fait sur d'autres critères (accès natif, performance, partage de code avec le web).

Et le SSR dans tout ça ?

Question qu'on me pose à chaque mission : faut-il du rendu serveur ?

Réponse courte : si votre référencement compte, oui. Une application purement côté client rend le travail d'indexation plus difficile, et même si les moteurs se sont améliorés, je n'ai jamais vu un projet où le SSR était un handicap. Next.js pour React, Nuxt pour Vue, SvelteKit pour Svelte, Angular Universal pour Angular : chacun a sa solution.

Le seul cas où je m'en passe volontiers, c'est une application interne derrière authentification, où l'indexation n'a aucun enjeu.

La grille de décision en pratique

Si vous ne devez retenir qu'une chose, prenez celle-ci. Elle tient sur une feuille et m'a évité plusieurs erreurs depuis que je l'applique.

1. Combien de développeurs, aujourd'hui et dans deux ans ? Moins de trois : Vue ou Svelte. Plus de dix : Angular sérieusement envisagé. Entre les deux : React.
2. Quelle est la durée de vie réelle du projet ? Si vous n'êtes pas sûr, comptez trois ans. C'est presque toujours plus long que prévu.
3. Y a-t-il des contraintes externes ? Audit de sécurité, prestataire imposé, charte technique d'un grand compte. Elles priment sur tout le reste.
4. Quel est votre budget de recrutement ? Estimez le surcoût d'un profil rare avant de choisir le framework rare.
5. Quelle est votre tolérance à la dette ? Un framework à écosystème étroit génère plus de code maison, et le code maison vieillit mal.
6. Le SEO compte-t-il ? Si oui, SSR ou SSG dès le départ, pas après.
7. Qui maintient ce projet dans deux ans ? Si la réponse est "on verra", prenez le framework avec le plus grand vivier, pas celui qui vous plaît le plus.

Cette grille ne donne pas de réponse magique. Elle élimine les mauvaises options, ce qui est déjà beaucoup.

Ce qu'on oublie toujours de vérifier

Trois points que personne n'aborde dans les comparatifs et qui m'ont coûté cher.

L'accessibilité. Certains frameworks rendent plus difficile le respect des normes ARIA, notamment sur les composants complexes (modal, combobox, datagrid). Vérifiez la qualité des bibliothèques accessibles disponibles dans votre stack avant de vous engager. Sur un projet soumis à obligation d'accessibilité, ce point peut devenir bloquant.

La gouvernance. Un framework piloté par une entreprise peut changer de cap. Angular suit la feuille de route de Google, Svelte est passé sous l'aile de Vercel, React appartient à Meta. Ce n'est pas nécessairement un problème, mais c'est une donnée à intégrer : vous dépendez en partie d'arbitrages stratégiques que vous ne contrôlez pas.

Le support à long terme. Combien de temps les versions majeures restent maintenues ? Quelle est la politique de migration ? Certains frameworks imposent des ruptures tous les dix-huit mois, d'autres étalent leurs évolutions. Sur un projet de cinq ans, cette variable pèse plus lourd que la performance au rendu.

Je termine par une question qui m'a fait changer d'avis deux fois : quel framework accepteriez-vous de défendre devant un comité d'architecture dans trois ans, quand vous ne serez peut-être plus dans l'équipe ? Si la réponse vous met mal à l'aise, votre choix n'est probablement pas encore stabilisé.