On m'a posé la question trois fois cette semaine, dans trois contextes différents : « tu mettrais quoi, toi, pour refaire mon site ? » Un cabinet d'avocats, une boutique de céramique, et un pote qui veut lancer un blog sur la randonnée. Trois projets qui n'ont rien à voir. Et pourtant, à chaque fois, la même réponse réflexe sort de la bouche des développeurs : « React ».
C'est souvent une mauvaise réponse. Pas parce que React serait mauvais, mais parce qu'on confond le framework le plus utilisé avec le framework adapté à votre projet. Un framework JavaScript populaire pour créer un site ne se choisit pas au palmarès : il se choisit en fonction de ce que le site doit faire, de qui va le maintenir, et de combien de temps vous voulez passer dessus.
Je vais vous expliquer comment je tranche, concrètement, quand on me confie ce genre d'arbitrage.
Points clés à retenir
- Le « meilleur framework » n'existe pas dans l'absolu : il dépend du type de site (vitrine, blog, e-commerce, application).
- Pour un site de contenu, un framework avec rendu côté serveur ou génération statique bat presque toujours une application 100 % client.
- React reste le plus répandu, ce qui veut dire plus de candidats à l'embauche et plus de réponses en cas de pépin.
- Vue.js offre la courbe d'apprentissage la plus douce pour une petite équipe.
- Svelte et Astro produisent des pages plus légères, au prix d'un écosystème plus restreint.
- Le coût réel d'un framework, ce n'est pas son installation : c'est sa maintenance sur trois ans.
Comment choisir un framework JavaScript quand on veut créer un site
La première erreur que je vois, systématiquement, c'est de partir du framework au lieu de partir du site. On regarde les classements de popularité, on voit React en tête, et on décide. Sauf que la popularité mesure l'usage, pas l'adéquation.
Trois questions suffisent à éliminer 80 % des mauvais choix.
Les trois questions que je pose avant tout
Le contenu change-t-il souvent ? Un blog publié deux fois par semaine n'a pas les mêmes besoins qu'un tableau de bord où les données bougent à la seconde. Si votre contenu est relativement stable, la génération statique est votre amie : vous obtenez des pages rapides, peu coûteuses à héberger, et quasi impossibles à casser.
Qui va maintenir le code ? Si c'est vous seul, le week-end, la courbe d'apprentissage passe avant tout le reste. Si c'est une équipe de cinq personnes en agence, l'écosystème et la disponibilité des compétences comptent davantage.
Le référencement est-il critique ? Là, ça devient sérieux. Un site rendu entièrement côté navigateur dépend d'un moteur de recherche capable d'exécuter votre JavaScript pour voir votre contenu. Ça fonctionne de mieux en mieux, mais c'est un pari que je refuse de prendre sur un site dont le trafic organique est le gagne-pain.
Pourquoi le mode de rendu compte plus que le nom du framework
Beaucoup de gens comparent React, Vue et Angular comme on compare des marques de voiture. Mais React n'est pas un framework au sens strict : c'est une bibliothèque d'interface. Ce qui décide vraiment de la performance et du SEO de votre site, c'est la couche posée par-dessus.
Concrètement :
- Rendu côté client : le navigateur télécharge du JavaScript, puis construit la page. Simple à développer, mais premier affichage plus lent et contenu parfois invisible pour les robots.
- Rendu côté serveur : le serveur envoie du HTML déjà prêt. Bon pour le SEO, mais il faut un serveur qui tourne en permanence.
- Génération statique : le HTML est fabriqué à l'avance, au moment de la publication. Le plus rapide, le moins cher, mais peu adapté aux données personnalisées.
Un site vitrine en rendu client, c'est une Ferrari pour faire le tour du pâté de maisons. Et je l'ai fait. J'ai livré un site d'artisan entièrement en rendu client, persuadé que « Google s'en sortira ». Six mois plus tard, les pages produits n'apparaissaient toujours pas correctement dans les résultats. On a tout rebasculé en génération statique. Trois jours de travail, et le trafic organique a repris en quelques semaines.
Comparatif : quel framework pour quel type de site
Voici le tableau que je sors quand on me demande de trancher. Il n'est pas parfait, mais il évite les décisions prises à l'instinct.
| Framework | Idéal pour | Rendu par défaut | Courbe d'apprentissage | Point faible |
|---|---|---|---|---|
| React (+ Next.js) | Applications riches, gros projets | Les deux, selon la page | Moyenne à élevée | Beaucoup de concepts à digérer |
| Vue.js (+ Nuxt) | Sites de contenu, petites équipes | Les deux, selon la page | Douce | Écosystème plus petit |
| Angular | Applications d'entreprise structurées | Côté serveur possible | Élevée | Verbeux, lourd pour un site simple |
| Svelte / SvelteKit | Sites performants, projets neufs | Les deux | Douce | Moins de recrutement disponible |
| Astro | Vitrines, blogs, documentation | Statique par défaut | Très douce | Moins adapté aux interfaces très interactives |
Une remarque que je répète souvent : la taille du bundle compte plus qu'on ne le croit. Sur une connexion mobile moyenne, chaque kilo-octet de JavaScript se paie en dixièmes de seconde d'affichage. Une page statique bien faite pèse souvent cinq à dix fois moins qu'une application équivalente rendue côté client. Sur un site marchand, cette différence se voit dans le taux de rebond.
Vue JS, c'est fait pour qui ?
Vue.js, c'est mon choix par défaut pour une petite équipe qui démarre, et je l'assume. La syntaxe est lisible, la documentation est claire, et on obtient un résultat présentable en quelques jours plutôt qu'en quelques semaines. J'ai formé deux personnes au front-end sur Vue : les deux produisaient des composants corrects au bout d'une semaine. Avec React, le même profil met généralement deux à trois fois plus longtemps avant d'être autonome sur un projet réel.
Est-ce que ça veut dire que React est mauvais ? Non. Ça veut dire que si vous êtes seul sur votre projet et que vous n'avez pas de bagage technique lourd, le temps que vous économiserez à apprendre vaut plus que le prestige de la techno.
Les erreurs que je vois le plus souvent
Elles ne portent presque jamais sur le framework lui-même. Elles portent sur la façon de décider.
- Choisir par palmarès. Le nombre de téléchargements d'un paquet ne dit rien de votre situation.
- Ignorer le coût de maintenance. Un framework que personne ne connaît dans votre entourage, c'est un framework que vous serez seul à déboguer dans dix-huit mois.
- Empiler les dépendances. Chaque bibliothèque ajoutée est une dette. J'ai repris un projet avec 47 dépendances directes pour un site de cinq pages. On en a supprimé 30. Le site est devenu plus rapide sans qu'on touche au design.
- Repartir de zéro par principe. Parfois, un thème existant bien choisi économise deux mois. Ce n'est pas de la paresse, c'est de l'arbitrage.
Les frameworks web les plus utilisés, et alors ?
React et Vue dominent le marché du front-end côté JavaScript, Angular résiste dans le monde de l'entreprise, et Svelte progresse régulièrement sans atteindre leur volume. Ce classement est stable depuis plusieurs années, ce qui a une conséquence pratique : les compétences disponibles sur le marché du travail se concentrent sur ces noms.
Autrement dit, choisir un framework confidentiel, c'est aussi choisir de ne pas pouvoir déléguer facilement. Pour un projet personnel, peu importe. Pour une entreprise qui devra transmettre le code un jour, c'est un critère qui pèse lourd.
Et les frameworks PHP dans tout ça ?
Question légitime, et la réponse est simple : ils résolvent un autre problème. Un framework PHP comme Laravel ou Symfony gère surtout le back-end, la base de données, l'authentification, la logique métier côté serveur. Le JavaScript prend en charge ce qui se passe dans le navigateur.
Sur un site vitrine classique, les deux cohabitent très bien : PHP ou un CMS génère les pages, et une dose de JavaScript ajoute les interactions. Vous n'avez pas à choisir un camp. Le seul mauvais scénario, c'est de faire porter au JavaScript une charge que le serveur ferait mieux et moins cher.
Ce que je conseille vraiment
Pour une vitrine, un blog ou une documentation : Astro ou Nuxt, avec du contenu généré à l'avance. Vous aurez des pages rapides, un référencement naturel, et une facture d'hébergement proche de zéro.
Pour une boutique en ligne : ne commencez pas par le framework. Commencez par la plateforme e-commerce, puis regardez ce qu'elle accepte côté front-end. Reconstruire un tunnel d'achat à la main, je l'ai fait une fois, et je ne le referai pas : deux semaines perdues sur la gestion des paiements et des taxes.
Pour une application avec comptes utilisateurs et données temps réel : React ou Vue avec une couche serveur. Là, la popularité redevient un argument, parce que vous allez avoir besoin d'aide et de bibliothèques existantes.
Franchement, la meilleure décision technique que j'ai prise sur mes derniers projets n'a pas été de choisir le bon framework. Ça a été de refuser d'en changer tous les six mois. La techno compte moins que la constance qu'on met à la maîtriser.
Alors la prochaine fois qu'on vous dira « prends React », posez une seule question : pour faire quoi, exactement ? Si la réponse est vague, le choix l'est aussi.
