Choisir une stack web : une évaluation honnête

Traduction assistée par IA. Le contenu original a été rédigé en anglais.

La question commence généralement au mauvais endroit. « Quelle plateforme devrions-nous utiliser? » traite la décision comme une comparaison de fonctionnalités. WordPress a des plugins. Shopify gère les paiements. Next.js a des composants serveur. Choisissez le gagnant de votre liste et livrez.

Les meilleures questions : Qu'est-ce que ce site doit faire? Qui le met à jour, et à quelle fréquence? À quoi ressemble la maintenance en année trois? Qu'arrive-t-il quand le développeur qui l'a construit n'est plus disponible?

Je vais parcourir les stacks que j'utilise et recommande réellement, avec les compromis honnêtes pour chacune. Ce n'est pas un avis de fournisseur. C'est un cadre décisionnel construit à partir de sites réels.

HTML et Vite sans framework

L'option la plus simple est souvent la plus défendable.

Un site statique, HTML, CSS et JavaScript sans rendu côté serveur, livre des fichiers préconstruits. Le serveur n'exécute pas de code à chaque requête. Il n'y a pas de base de données. Pas de failles de plugin. La surface d'attaque est petite : le serveur web et les fichiers qu'il sert.

Le plafond de performance des sites statiques dépasse celui de tout CMS. Des scores Core Web Vitals proches de 100 sont atteignables et maintenables parce que rien ne combat le chemin de rendu. Pas de PHP qui s'exécute, pas de requêtes de base de données, pas de scripts de plugin qui chargent avant votre contenu.

Vite change l'expérience de développement sans changer le résultat. Vous écrivez du JavaScript moderne avec des modules, des alias d'importation et TypeScript si vous le souhaitez. Vite regroupe tout en fichiers statiques optimisés au moment de la compilation. Ce site utilise Vite pour son pipeline d'assets : le CSS et le JS sont compilés et versionnés par Vite, servis par Apache.

La contrainte, c'est la modification du contenu. Un site statique n'a pas de panneau d'administration. Les changements passent par un développeur. Pour un site marketing mis à jour une fois par trimestre, ce n'est pas un problème. Pour un site avec une équipe de contenu qui publie chaque jour, c'est éliminatoire.

Statique n'est pas non plus synonyme de simple. Un pipeline Vite, l'optimisation des assets et un bon flux de déploiement, c'est de l'ingénierie réelle. La simplicité est dans le résultat, pas nécessairement dans la mise en place.

Idéal pour : Portfolios, pages de destination, documentation, sites marketing à usage unique. Tout projet où un développeur gère toutes les mises à jour et où la performance est la contrainte principale.

Pas idéal pour : Les éditeurs non techniques qui doivent modifier du contenu sans développeur. Les sites avec des cycles de publication fréquents. Tout ce qui implique plusieurs contributeurs.

WordPress

WordPress fait tourner 42,2 % de tous les sites web et 59,6 % du marché des CMS. Ces chiffres viennent de W3Techs, mis à jour quotidiennement, en date d'avril 2026. Ce niveau d'adoption ne se produit pas par accident. L'interface d'édition de contenu fonctionne. L'écosystème de plugins couvre la plupart des besoins. La communauté de développeurs est immense.

Le coût en performance de cette adoption est documenté. Le Web Almanac HTTP Archive 2024 montre que les sites WordPress passent le seuil « bon » pour le LCP sur mobile à un taux de 40 %. La moyenne mondiale est de 63,4 %. WordPress accuse un retard de 23 points de pourcentage.

Une installation WordPress avec 20 plugins actifs est un problème de performance fondamentalement différent de celui avec trois. Un site bien construit avec un ensemble minimal de plugins, un bon cache et un hébergement de qualité peut bien performer. La plupart des sites WordPress ne sont pas ainsi, parce que la plupart sont mis en place rapidement et laissés à eux-mêmes.

Le portrait de sécurité est nuancé. La base de données de Patchstack recense 38 309 vulnérabilités WordPress, dont 91 % dans les plugins, pas dans le cœur. Le rapport 2023 de Sucuri sur les sites piratés a constaté que 95,5 % des infections ciblant les CMS impliquaient WordPress. Sucuri eux-mêmes notent que cela reflète la dominance du marché plus que la vulnérabilité intrinsèque. Une installation WordPress épurée et à jour est raisonnablement sécurisée. Une installation abandonnée avec des plugins désuets ne l'est pas.

WordPress se fait aussi injustement critiquer par des développeurs qui n'ont vu que des sites mal construits. Un thème sur mesure, un petit ensemble de plugins, un bon hébergement et un calendrier de mises à jour produisent une plateforme solide. L'outil n'est pas le problème. Les installations négligées le sont.

La réalité de maintenance est ce que les clients devraient comprendre avant de choisir. WordPress exige un entretien actif : mises à jour du cœur, mises à jour des plugins, compatibilité des versions PHP, vérification des sauvegardes. Un site construit puis oublié va se détériorer. Ce n'est pas propre à WordPress, mais l'écosystème de plugins signifie qu'il y a plus de choses à maintenir.

Idéal pour : Sites riches en contenu où des éditeurs non techniques ont besoin d'un accès régulier. Entreprises avec une expérience WordPress existante. Projets où une performance modérée est acceptable et où l'écosystème de plugins correspond aux besoins.

Pas idéal pour : Applications critiques en performance. Structures de données personnalisées complexes que les plugins ne peuvent pas exprimer proprement. Clients qui ne s'engagent pas à maintenir les mises à jour.

CMS headless

Le CMS headless sépare la couche de contenu de la couche de présentation. Le CMS stocke et gère le contenu. Un framework frontend, typiquement Next.js, Astro ou Remix, récupère ce contenu via API et gère le rendu. Les deux systèmes sont indépendants et peuvent être déployés, reconstruits ou remplacés sans affecter l'autre.

Sanity, Contentful et Payload sont les options matures en 2026. Sanity offre un studio d'édition entièrement personnalisable. Contentful est axé entreprise avec de solides flux de travail éditoriaux. Payload est auto-hébergé et TypeScript-first, populaire auprès des développeurs qui veulent un contrôle direct sur le modèle de données sans facture d'hébergement fournisseur.

L'avantage architectural est réel. Le frontend peut être reconstruit sans toucher au modèle de contenu. Le contenu peut être livré à un site web, une application mobile et un affichage numérique à partir de la même source de données. Parce que le frontend est typiquement généré statiquement au moment de la compilation, le plafond de performance égale celui d'un site statique codé à la main.

Le coût est la complexité opérationnelle. Vous gérez deux systèmes : le CMS et le frontend, chacun avec son propre environnement d'hébergement. Les temps de compilation ajoutent une latence entre une modification de contenu et une mise à jour en direct. Sur de grands sites, ça peut prendre des minutes.

Les coûts d'infrastructure comptent pour les clients plus petits. Le niveau hébergé de Sanity commence gratuitement ; l'utilisation en production a un coût réel. Le niveau gratuit de Contentful a des limites. Ce sont des coûts qu'un client habitué à un hébergement WordPress à 20 $/mois n'a peut-être pas budgétés.

Idéal pour : Organisations qui livrent du contenu à plusieurs surfaces. Grandes équipes de contenu avec des flux de travail éditoriaux. Projets avec le budget pour deux environnements d'infrastructure et un soutien technique continu.

Pas idéal pour : Petites entreprises avec un site web et un seul éditeur de contenu. Projets sous 10 000 $. Développeurs sans expérience Node.js pour gérer le frontend.

WordPress headless

WordPress headless utilise WordPress comme backend de contenu, WPGraphQL pour exposer ce contenu comme GraphQL API, et un framework frontend séparé (typiquement Next.js) déployé sur une plateforme comme Vercel.

C'est une architecture légitime. Elle se simplifie aussi à l'excès dans les conversations de développeurs, où « utilise juste WordPress headless » minimise ce à quoi vous vous engagez réellement.

La proposition de valeur est la continuité. Si vous avez un site WordPress existant avec des années de contenu et une équipe qui connaît le panneau d'administration, migrer vers un CMS headless pur signifie migrer le contenu et recycler les éditeurs. C'est un coût réel. WordPress headless vous permet de découpler le frontend et d'obtenir les avantages de performance d'un framework moderne, sans ce coût de migration.

Pour les équipes qui travaillent déjà en Next.js (17,9 % des développeurs selon le sondage Stack Overflow 2024), WPGraphQL est une intégration gérable. L'outillage est mature et bien documenté. Les champs personnalisés via ACF se mappent à GraphQL proprement pour la plupart des modèles éditoriaux.

Le coût honnête est que vous faites encore tourner WordPress. Ça signifie patcher les plugins, maintenir l'hébergement PHP, gérer la base de données et rester à jour sur les mises à jour du cœur, en plus de déployer et maintenir le frontend Next.js sur Vercel. Deux stacks, deux factures d'hébergement, deux surfaces pour que les choses brisent.

Pour un projet greenfield, ce calcul de coût a rarement du sens. En partant de zéro, il n'y a pas d'argument de continuité. Vous hériteriez de la surface de sécurité de WordPress, des frais généraux des plugins et de l'exigence d'hébergement PHP sans aucune justification de coût de transition.

Idéal pour : Sites WordPress établis avec un contenu substantiel et des éditeurs formés. Équipes frontend qui travaillent déjà en Next.js et prennent en charge un client WordPress. Projets où les exigences de design ou de performance dépassent ce qu'un thème WordPress peut livrer, et où la familiarité avec l'admin WordPress est non négociable.

Pas idéal pour : Nouvelles constructions sans contenu WordPress existant. Projets où le mainteneur à long terme n'a pas d'expérience JavaScript. Petites entreprises où le coût de deux environnements n'est pas justifié.

PHP sur mesure

Le PHP sur mesure sans framework CMS, c'est ce que j'utilise pour la couche de routage et de gabarits de ce site, et pour les projets clients qui ont besoin d'une logique qu'aucune plateforme existante ne gère proprement. Vite gère le pipeline d'assets frontend par-dessus, mais il n'y a pas de framework, pas d'ORM, pas de CMS entre les deux.

L'argument en sa faveur n'est pas la nostalgie. C'est l'absence de surcharge d'abstraction. Une application PHP construite autour d'exigences spécifiques n'exécute que le code qui sert un but. Pas de plugin qui charge des scripts sur chaque page. Pas de panneau d'administration à renforcer. Pas d'ORM qui génère des requêtes pour un modèle de données qui n'est pas le vôtre.

La performance est proportionnelle à ce que vous avez construit. La surface de sécurité est proportionnelle à ce que vous avez construit. La maintenance évolue avec l'application, pas avec le calendrier d'un fournisseur. C'est le même raisonnement derrière la construction de notre propre CRM plutôt que d'adapter celui de quelqu'un d'autre.

L'argument contre est la portabilité. Une application sur mesure est maintenue par celui qui l'a construite, ou par quelqu'un prêt à l'apprendre à partir de la documentation. WordPress est portable parce que chaque développeur PHP a travaillé avec. Un code sur mesure nécessite un développeur prêt à lire les docs et à adopter les conventions. Ça fonctionne bien dans une relation de développement stable à long terme. C'est un problème quand le projet doit changer de mains rapidement.

Idéal pour : Projets avec des structures de données, des flux de travail ou une logique personnalisés qu'aucune plateforme existante n'exprime proprement. Relations de développement à long terme où la continuité est stable. Applications critiques en performance qui n'ont pas besoin d'interface d'édition de contenu.

Pas idéal pour : Sites où des utilisateurs non techniques doivent modifier du contenu. Projets qui seront transférés à un autre développeur sans documentation adéquate. Tout ce qui correspond aux exigences d'une plateforme existante.

eCommerce : Stripe, WooCommerce et Shopify

L'eCommerce complique la décision de stack parce que la bonne réponse dépend de ce que vous vendez, du nombre de produits et de la surcharge opérationnelle que vous pouvez absorber.

Stripe

Stripe est un processeur de paiement, pas une plateforme eCommerce. Vous construisez le panier, le flux de paiement, la gestion des commandes et l'interface client. En échange, vous obtenez un contrôle total et la surcharge la plus faible : aucun frais de plateforme au-delà du pourcentage de transaction de Stripe.

Pour une entreprise qui vend un ou deux produits, un service à prix fixe ou un abonnement avec une structure définie, Stripe est souvent le bon choix. Un développeur peut construire un flux de paiement propre en quelques jours. Rien ne porte plus de coût que nécessaire.

Pour un catalogue de 50+ produits avec suivi des stocks, tarification variable et expédition complexe, Stripe seul est un projet d'ingénierie important. C'est là qu'une plateforme eCommerce dédiée gagne ses frais.

WooCommerce

WooCommerce gère 49,3 % des plateformes eCommerce [W3Techs, avril 2026]. C'est un plugin WordPress qui transforme un site WordPress en boutique. La gestion de contenu et le commerce vivent dans la même interface d'administration.

L'avantage est la familiarité. Si le client est déjà sur WordPress, WooCommerce est une extension naturelle. L'écosystème de plugins couvre la plupart des exigences eCommerce : abonnements, retrait local, produits variables, réservations.

Le compromis de performance est réel et se cumule. WooCommerce ajoute un poids significatif à une stack déjà challengée en performance. Un magasin WooCommerce bien optimisé est réalisable avec du cache, un bon hébergement et une gestion disciplinée des plugins. Un magasin non géré avec des plugins de paiement, des scripts marketing et des carrousels d'images produits empilés peut devenir très lent. Les boutiques en ligne lentes perdent des ventes à un taux plus élevé que les sites informatifs lents.

Shopify

Shopify gère 30,2 % des plateformes eCommerce [W3Techs, avril 2026]. C'est une plateforme hébergée : Shopify gère l'infrastructure, la conformité PCI et la mise à l'échelle. Vous payez des frais mensuels plus des frais de transaction.

La proposition de valeur est la simplicité opérationnelle. Fiabilité du paiement, traitement des paiements, SSL, CDN : géré. Pour une entreprise où le commerce est le produit principal et où l'infrastructure est une distraction, ça vaut le coût de la plateforme.

La contrainte est la personnalisation. Le langage de gabarit Liquid de Shopify est capable mais spécifique. La personnalisation profonde requiert un développeur qui le connaît. Vous louez aussi : si Shopify change ses prix ou abandonne une fonctionnalité, vos options sont limitées.

Pour la plupart des projets : produit unique ou service simple, utilisez Stripe. Site WordPress existant avec un catalogue gérable, utilisez WooCommerce. Entreprise axée sur le commerce avec des ambitions de croissance, utilisez Shopify.

Prendre la décision

Quatre questions vous amènent la plupart du chemin au-delà de ce tableau.

Qui met à jour le site, et à quelle fréquence? Les éditeurs non techniques qui mettent à jour le contenu régulièrement ont besoin d'un CMS. Un développeur qui gère toutes les mises à jour signifie qu'un CMS est optionnel.

Quel est le budget de maintenance sur trois ans? Les architectures sur mesure et headless portent des coûts continus plus élevés que WordPress ou Shopify. Le coût total de possession vaut la peine d'être modélisé avant de choisir une plateforme.

Qu'est-ce que la performance doit faire? Si les Core Web Vitals sont des résultats d'affaires mesurables pour ce projet, les choix de stack qui les atteignent sont plus restreints. Un site qui prend six secondes à charger sur mobile perd des clients avant qu'ils aient lu un mot.

Qu'arrive-t-il quand le développeur original n'est plus disponible? Cette question est celle qui se fait le plus ignorer et qui coûte le plus quand elle compte. Les constructions sur mesure ont besoin de documentation et d'un plan de succession. Les plateformes établies achètent la portabilité au coût de la flexibilité.

Répondez à ces quatre questions et généralement une ou deux options restent. La conversation sur la stack est plus productive après que vous sachiez ce que le site doit vraiment faire. C'est à ça que sert la découverte.

Si vous travaillez sur une décision de stack et souhaitez un deuxième avis, contactez-nous. Je suis heureux d'en discuter.