Next.js, WordPress, Webflow ou Framer ?
Choisissez la bonne plateforme selon le workflow éditorial, la liberté créative, les intégrations, la propriété et les risques d'exploitation.
La bonne plateforme web est celle qui correspond au fonctionnement réel du client après le lancement. Next.js, WordPress, Webflow et Framer permettent tous de produire un excellent site, mais n'optimisent pas les mêmes équipes, workflows de contenu, besoins d'intégration ou contraintes de propriété. Le choix doit partir du brief et du handover, pas de l'outil préféré de l'équipe de production.
Ce cadre aide une agence à décider avant que le design et le développement deviennent coûteux à modifier.
Décider avec des contraintes plutôt qu'une liste de fonctions
Les comparatifs échouent souvent parce que chaque produit semble tout savoir faire dans un tableau générique. Commencez par les contraintes qui compteront encore un an après le lancement.
Demandez-vous :
- Qui publie le contenu et à quelle fréquence ?
- Les pages suivent-elles un modèle structuré ou les éditeurs composent-ils librement les layouts ?
- Quel niveau de liberté visuelle et d'interaction est indispensable ?
- Quels systèmes métier doivent être connectés ?
- Faut-il de l'authentification, de la personnalisation ou des flows proches d'une application ?
- Qui maintiendra le projet après le handover ?
- Le client impose-t-il un hébergement, une gestion des données ou une procédure d'achat ?
- Combien de langues, marchés et workflows de validation sont concernés ?
Classez ensuite les exigences en indispensables, importantes et optionnelles. Une plateforme doit être écartée lorsqu'elle échoue sur un indispensable, même si elle est excellente ailleurs.
Quand Next.js est le meilleur choix
Next.js est un framework React destiné aux expériences web personnalisées. Il est généralement pertinent lorsque le site se comporte comme un produit, exige de nombreuses intégrations ou nécessite une architecture frontend sur mesure.
Choisissez-le lorsque :
- le design system comporte des états réutilisables complexes ;
- le contenu provient d'un CMS headless ou de plusieurs API ;
- le projet inclut recherche, calculateur, zone authentifiée, personnalisation ou parcours produit ;
- l'agence veut contrôler le rendu, le cache, les métadonnées et le déploiement ;
- le dépôt et l'infrastructure doivent pouvoir être transférés à une autre équipe d'ingénierie.
La contrepartie est opérationnelle. Les éditeurs ont besoin d'un CMS séparé pour publier sans code, et le client doit conserver un accès à des compétences techniques pour la maintenance. Plus de liberté architecturale implique aussi une review plus rigoureuse.
La checklist de production Next.js couvre notamment le routing, le cache, l'accessibilité, la sécurité, les métadonnées, les Core Web Vitals et l'analyse du bundle. Utilisez-la comme base, puis ajoutez les critères propres au projet.
Quand WordPress est le meilleur choix
WordPress reste efficace lorsque l'autonomie éditoriale, une administration familière et un vaste écosystème comptent davantage qu'une architecture d'application très personnalisée.
Choisissez-le lorsque :
- les équipes contenu connaissent déjà WordPress ;
- le site repose sur des articles, landing pages, ressources ou contenus structurés ;
- le client souhaite gérer utilisateurs, publication et médias dans une interface établie ;
- des extensions compatibles couvrent le workflow requis ;
- le responsable de maintenance peut gouverner mises à jour, extensions, sauvegardes et sécurité.
WordPress permet de créer des systèmes éditoriaux réutilisables grâce aux blocs et aux patterns. La documentation officielle explique comment les patterns de blocs peuvent être créés, synchronisés, détachés et gérés. Cette flexibilité est utile, mais elle exige des garde-fous pour éviter la dérive des mises en page.
Le principal risque vient de l'accumulation d'extensions. Chaque plugin ajoute un propriétaire, un chemin de mise à jour et une question de compatibilité. Documentez les extensions essentielles, leurs licences et le plan prévu si l'une d'elles disparaît.
Quand Webflow est le meilleur choix
Webflow convient bien aux sites marketing pilotés par le design, avec un environnement de production visuel et un CMS structuré dans le même système.
Choisissez-le lorsque :
- le projet est avant tout un site marketing, pas une application sur mesure ;
- designers ou producteurs no-code maintiendront les layouts ;
- les éditeurs ont besoin de Collections structurées pour articles, équipes, projets ou ressources ;
- les interactions souhaitées entrent dans le modèle natif ;
- un hébergement géré et un workflow de publication unifié sont acceptables.
La documentation officielle décrit les Collections comme des bases structurées dont les éléments alimentent des templates partagés. La localisation peut gérer des éléments et paramètres propres à chaque langue. Comparez le fonctionnement du CMS et celui de la localisation des Collections au vrai plan de contenu.
La limite principale est celle de la plateforme. Un backend très personnalisé, des exigences de déploiement inhabituelles ou un état applicatif complexe peuvent transformer un build visuel simple en contournement permanent. Testez l'exigence la plus difficile avant d'engager tout le système.
Quand Framer est le meilleur choix
Framer est souvent adapté aux sites marketing compacts et expressifs qui doivent être itérés rapidement par une équipe orientée design.
Choisissez-le lorsque :
- la vitesse de lancement et l'itération visuelle sont prioritaires ;
- le modèle de contenu reste compact ;
- les designers doivent contrôler la majorité des changements ;
- le motion et le storytelling de campagne comptent ;
- les intégrations restent dans un périmètre de site marketing maîtrisable.
Framer propose un CMS et des fonctions de localisation documentées dans ses ressources officielles. Vérifiez pendant la découverte les limites du plan, les rôles de publication, les redirections et le workflow multilingue : ce sont des exigences d'exploitation, pas des détails à reporter au handover.
Le risque principal est de demander à un système orienté campagne de devenir une plateforme produit sur mesure. Fixez la frontière tôt.
Comparer le modèle d'exploitation
| Domaine | Next.js | WordPress | Webflow | Framer |
|---|---|---|---|---|
| Comportement applicatif personnalisé | Fort | Possible avec une architecture maîtrisée | Limité par le modèle | Limité par le modèle |
| Familiarité éditoriale | Dépend du CMS choisi | Souvent forte | Forte pour les Collections | Forte pour un contenu marketing compact |
| Itération visuelle | Pilotée ou partagée avec l'ingénierie | Dépend du thème et des blocs | Pilotée visuellement | Pilotée par le design |
| Contrôle de l'infrastructure | Élevé | Élevé à moyen | Plateforme gérée | Plateforme gérée |
| Maintenance | Compétence d'ingénierie | Gouvernance des mises à jour et extensions | Gouvernance plateforme et workspace | Gouvernance plateforme et workspace |
| Usage par défaut | Expérience intégrée sur mesure | Site éditorial riche | Site marketing structuré | Lancement ciblé et expressif |
Ce tableau est un point de départ, pas un verdict. Un WordPress discipliné peut surpasser un build custom négligé. Un site Framer ciblé peut être plus pertinent qu'une stack impressionnante que le client ne sait pas exploiter.
Prototyper l'exigence la plus risquée
Avant la production complète, testez ce qui pourrait invalider le choix : relation de contenu complexe, workflow de traduction, intégration CRM, interaction responsive exigeante, processus de preview, accessibilité ou contrainte d'export et de propriété.
Ne prototypez pas le hero. Prototypez le cas limite.
Rendre la décision transférable
Consignez la décision dans une page : objectifs, contraintes indispensables, plateformes évaluées, raisons des rejets, hypothèses de l'option choisie, limites connues, modèle de maintenance et conditions qui obligeraient à réexaminer le choix.
La meilleure plateforme n'est pas celle qui affiche le plus de fonctions. C'est celle qui permet au client de publier, maintenir, intégrer et transférer le site sans combattre le système.
Passez ensuite à la checklist de handoff design-to-code et QA pour transformer ce choix en brief de production exécutable.