Comment choisir un framework pour le développement web sans se tromper

Le mois dernier, un client m'a envoyé un message à 23 h 47 : « On part sur React ou sur Svelte ? Faut trancher demain. » Son équipe comptait deux développeurs. Leur appli : un back-office de gestion de stock pour une PME de 40 salariés. À ce stade, la vraie réponse n'était ni React ni Svelte. C'était « pourquoi vous avez besoin d'un framework JS à la mode pour ça ? ».

Voilà le problème avec la question comment choisir un framework pour le développement web : on la pose souvent trop tard, une fois qu'on a déjà envie d'un nom précis. Je vais vous donner la méthode que j'utilise maintenant—après plusieurs erreurs que je vais raconter sans filtre—pour trancher sur des critères qui tiennent, pas sur le buzz d'un tweet.

Avant de choisir un framework, identifiez le problème que vous résolvez

Un framework web, c'est une structure logicielle qui vous donne des composants, des conventions et un cycle de vie prêts à l'emploi. Gain de temps réel : sur mon dernier projet from scratch, partir d'un socle existant m'a économisé environ deux semaines de plomberie (routing, auth, migrations). Mais ce confort a un prix, et ce prix n'apparaît jamais dans les comparatifs.

Faut-il vraiment un framework ?

J'ai un site vitrine pour un artisan. Une page, un formulaire de contact, trois images. Je l'ai écrit en HTML/CSS pur avec quinze lignes de JS. Un framework là-dessus aurait été une blague.

La règle que j'applique : si le projet tient sur moins de cinq écrans et n'a pas d'état complexe à synchroniser, pas de framework applicatif. Un générateur de site statique suffit. En revanche, dès qu'il y a authentification, permissions par rôle, formulaires dynamiques et une équipe de plusieurs personnes, le framework devient rentable.

Framework front-end et framework backend : deux décisions séparées

On mélange souvent les deux dans un seul débat. Ce sont pourtant des choix indépendants :

• Front-end : React, Vue, Angular, Svelte, ou un simple rendu serveur avec des îlots d'interactivité.
• Backend : Symfony ou Laravel en PHP, Django en Python, NestJS en Node, Spring en Java.
• CSS : Tailwind, Bootstrap, ou CSS écrit à la main. Ce n'est pas la même catégorie de choix et ça ne mérite pas une réunion de deux heures.

Décidez d'abord si votre appli a besoin d'un front riche et séparé. Beaucoup de projets qui « ont besoin de React » fonctionnent très bien en rendu serveur classique, avec un peu d'HTMX pour les interactions. Franchement, sur mon propre outil de facturation, j'ai fini par supprimer la SPA : 40 % de code en moins, zéro régression.

Une grille de décision qui remplace les débats d'opinion

« Je préfère React » n'est pas un argument. « Le recrutement sur React est plus simple dans notre bassin d'emploi » en est un. Le problème, c'est qu'on compare rarement les mêmes choses. Alors je fais poser les critères sur papier, avec un poids et une note.

Critère	Poids	Questions à se poser
Compétences de l'équipe actuelle	×3	Combien de temps pour être productif dès la semaine 1 ?
Recrutement futur	×2	Trouverez-vous des profils formés à cet outil dans 18 mois ?
Maintenance et rythme de releases	×3	Le projet publie-t-il des versions stables ? Des correctifs de sécurité ?
Coût de sortie	×2	Si vous migrez dans 3 ans, combien de jours de réécriture ?
Perf sur votre cas réel	×1	Benchmark sur votre page la plus lourde, pas sur un hello world.

Pourquoi je pèse la maintenance aussi fort que les compétences ? Parce que la première année est facile. C'est la troisième qui fait mal.

Le coût total de possession, l'angle qu'on oublie

Un framework, c'est un abonnement déguisé. Chaque montée de version majeure, c'est du temps non facturé. J'ai vécu une migration Angular d'une version majeure à la suivante sur une équipe de trois : six semaines à temps partiel, pour zéro fonctionnalité livrée au client. Il l'a payé quand même, évidemment.

Ajoutez à ça le verrouillage : si tout votre code s'appuie sur les conventions d'un écosystème très spécifique, sortir coûte cher. Ce n'est pas une raison de fuir, mais une ligne dans le calcul. Les frameworks très opinés (Angular, Spring) vous font gagner en cohérence et perdre en agilité de sortie. Les frameworks minimalistes (Svelte, Alpine, HTMX) font l'inverse.

Framework front-end : les plus utilisés ne sont pas toujours les bons pour vous

Je reçois cette objection régulièrement : « si tout le monde utilise React, autant faire pareil ». Sauf que les courbes d'usage mesurent l'industrie entière, pas votre projet de six mois avec deux devs.

Quel framework front-end choisir ?

Ça dépend de trois paramètres, et de trois seulement, à mon sens :

1. La taille de l'équipe. Un dev seul et un framework minimaliste : productivité immédiate. Cinq devs et trois stagiaires : un cadre opinionné et documenté évite l'anarchie.
2. Le profil recrutable. Le marché de l'emploi local décide pour vous, qu'on le veuille ou non.
3. La durée de vie prévue. Un prototype jetable et un produit maintenu cinq ans n'ont pas les mêmes exigences de stabilité.

Mon avis personnel, et je l'assume : pour un produit neuf avec une petite équipe, Svelte reste le meilleur rapport plaisir/production que j'ai connu. Courbe douce, code court, runtime léger. Mais—et c'est ce qui coince—recruter dessus reste plus difficile, parce que le vivier est plus petit. À vous de voir quel coût vous préférez payer.

Et les frameworks CSS, on en parle ?

Tailwind vs Bootstrap ressemble à un débat de chapelle, mais ça se tranche vite :

• Design sur mesure et cohérent sur le long terme → Tailwind, avec un système de tokens.
• Prototype rapide, back-office interne, équipe sans designer → Bootstrap.
• Site ultra-léger, peu de pages → CSS écrit à la main, ou un framework minimaliste.

Je suis passé par les trois. Sur un back-office interne que trois personnes utilisent, Bootstrap fait le job et coûte moins cher. Personne ne vous jugera. Sur mon propre site, Tailwind.

Le test qui vaut tous les comparatifs : le POC de deux jours

Voici la méthode que j'utilise systématiquement maintenant : réécrire une fonctionnalité représentative du projet, deux jours maximum, dans chacun des deux frameworks candidats.

Pas un hello world. Pas un tutoriel. Votre formulaire le plus complexe, avec votre validation, votre appel API et votre état en erreur.

C'est là que les choses parlent vraiment. Sur un projet, j'ai découvert en trois heures de POC que le framework que je préférais sur le papier imposait trois heures de configuration pour un cas d'authentification qui prenait vingt minutes sur l'autre. Ce test m'a économisé des semaines.

Ce que le POC ne dit pas : sécurité, licence, maintenance

Vérifiez systématiquement, avant de signer : la fréquence des correctifs de sécurité, l'existence de versions maintenues à long terme, la licence (MIT, Apache, AGPL—le choix de licence peut vous obliger à ouvrir votre code propre, ce qui est rédhibitoire pour un logiciel vendu), et la vitalité des contributeurs.

Un indicateur simple : regardez la date du dernier correctif de sécurité publié. Si elle est vieille de plusieurs mois, red flag. Ça ne disqualifie rien à lui seul, mais ça informe.

La décision qui compte, ce n'est pas le framework

Après des années à trancher ces questions, je crois de moins en moins que le choix du framework soit l'élément décisif d'un projet réussi. Les équipes qui livrent tiennent à trois choses : un cadre de décision écrit, un POC rapide, et une équipe prête à changer si le test dit non. Celles qui échouent défendent un choix identitaire.

Le client de 23 h 47 s'en est sorti. On a gardé un rendu serveur, ajouté un peu de JavaScript là où c'était nécessaire. Six mois plus tard, aucune dette, une équipe qui produit. Le framework le plus utile a été celui qu'on n'a pas choisi.

Alors la prochaine fois qu'on vous demande « on part sur lequel ? », retournez la question : « qu'est-ce qu'on ne sait pas encore, et qu'est-ce qui nous coûtera le plus cher dans trois ans ? ». Le reste, c'est du détail.