Arrêtons le faux débat

Chaque semaine, un client me pose la question : "Je pars sur Webflow ou Next.js ?". Et chaque semaine, je donne la même réponse, celle que personne ne veut entendre : ça dépend.

Pas de votre budget. Pas de vos goûts esthétiques. Pas de ce que votre développeur préfère coder le week-end. Ça dépend de ce que votre site doit faire. C'est tout.

J'ai livré des projets sur les deux stacks. Le site de Skello tournait sur Webflow. Le site que vous êtes en train de lire est sur Next.js. Les deux ont bien fonctionné, mais pour des raisons complètement différentes. Et c'est en faisant les deux que j'ai compris quand utiliser l'un plutôt que l'autre.

Ce que Webflow fait mieux que tout le monde

Webflow, c'est un éditeur visuel qui génère du code propre. Vous designez dans le navigateur, vous publiez en un clic. Pas besoin de déployer, pas de serveur à configurer, pas de pipeline CI/CD. C'est d'une simplicité déconcertante quand on vient du monde du code.

Là où Webflow brille vraiment, c'est l'autonomie qu'il donne aux équipes non-techniques. Votre responsable marketing veut changer un texte sur la page d'accueil ? Elle le fait en 30 secondes. Votre designer veut tester une nouvelle mise en page ? Il la déploie en live sans attendre qu'un développeur soit disponible. Dans une startup qui itère vite, ce genre de vélocité, ça change la donne.

Le CMS intégré est solide aussi. Pour un blog, des pages de cas clients, une section actualités, il fait le job. La gestion des images est automatisée (responsive, lazy loading), le SEO de base est bien géré (balises meta, sitemap auto, redirections), et les performances out-of-the-box sont honnêtes.

Chez Skello, c'est Webflow qui nous permettait de lancer des landing pages pour chaque campagne marketing en quelques jours au lieu de quelques semaines. Quand vous gérez 7 marchés européens et que chaque pays a ses propres messages, cette rapidité d'exécution est un avantage concurrentiel réel.

Là où Webflow atteint ses limites

Le problème arrive quand vous voulez sortir des sentiers battus. Vous avez besoin d'un système d'internationalisation avancé avec des routes localisées ? C'est faisable mais c'est un hack. Vous voulez des interactions complexes qui ne se résument pas à des animations au scroll ? Ça devient vite du bricolage. Vous avez besoin d'intégrer une API tierce avec une logique métier côté serveur ? Bonne chance.

L'autre limite, c'est la performance à l'échelle. Webflow charge son propre runtime JavaScript, même si votre site n'en a pas besoin. Sur des pages complexes avec beaucoup d'éléments, les Core Web Vitals peuvent en souffrir. Ce n'est pas rédhibitoire, mais c'est quelque chose à surveiller si le SEO technique est une priorité.

Enfin, il y a la question du verrouillage. Votre site vit dans l'écosystème Webflow. Si demain vous voulez migrer vers autre chose, il n'y a pas de bouton "exporter en React". Vous repartez de zéro.

Ce que Next.js rend possible

Next.js, c'est l'inverse. C'est un framework React qui vous donne un contrôle total sur chaque aspect de votre site. Le rendu côté serveur (SSR), la génération statique (SSG), les API routes, le middleware, l'internationalisation native... Tout est là, et tout est configurable.

Pour ce site (matysbeuriot.com), Next.js était le choix évident. J'avais besoin de routes localisées propres (/fr/cas/skello vs /en/cases/skello), d'animations GSAP pilotées au scroll, d'un système de blog avec génération statique pour le SEO, et d'un contrôle total sur les Core Web Vitals. Essayez de faire ça proprement sur Webflow.

L'écosystème React est un autre avantage énorme. Besoin d'un calendrier Calendly intégré ? Il y a un package. Besoin de gérer des formulaires complexes ? React Hook Form. Besoin de gérer l'état global ? Zustand ou Redux. La communauté est immense et les solutions existent pour à peu près tout.

Côté performance, Next.js excelle. Le code splitting automatique, l'optimisation des images avec le composant Image, le prefetching des liens... Quand c'est bien configuré, les scores Lighthouse sont dans le vert foncé.

Le vrai coût de Next.js

Soyons honnêtes : Next.js a un prix, et ce n'est pas juste le temps de développement initial.

Chaque modification de contenu nécessite un développeur. Changer un texte, c'est un commit, un push, un déploiement. Pour une équipe marketing habituée à la liberté de Webflow, c'est une régression. Vous pouvez atténuer ce problème avec un CMS headless (Sanity, Contentful, Strapi), mais ça ajoute une couche de complexité et de coût.

La maintenance est aussi un sujet. React évolue vite. Next.js évolue vite. Ce qui marche aujourd'hui peut nécessiter une migration dans 18 mois. Si vous n'avez pas de développeur en interne ou un freelance de confiance pour maintenir le site, ça peut devenir un problème.

Mon framework de décision

Après avoir livré une dizaine de projets sur les deux stacks, voici comment je tranche.

Choisissez Webflow si votre site est principalement un outil de communication (site corporate, landing pages, blog), si votre équipe marketing doit pouvoir modifier le contenu en autonomie, si vous avez besoin d'itérer rapidement sur la mise en page, et si vous n'avez pas de besoins techniques spécifiques (API, internationalisation avancée, personnalisation dynamique).

Choisissez Next.js si votre site a des composants applicatifs (dashboard, espace client, outil interactif), si vous avez besoin d'une architecture multi-locale poussée, si la performance et le SEO technique sont des priorités absolues, ou si vous avez des intégrations API complexes à gérer.

Pour être tout à fait transparent : pour 80% des entreprises que j'accompagne, Webflow suffit largement. Le piège classique, c'est de choisir Next.js par fascination technique alors qu'un site Webflow bien construit ferait le même job en moitié moins de temps.

Et si la réponse, c'était les deux ?

Un pattern que j'utilise de plus en plus : Webflow pour le marketing site (pages, blog, landing pages) et Next.js pour la partie applicative. Le site marketing vit sur le domaine principal, l'app vit sur un sous-domaine. Chaque outil fait ce qu'il fait le mieux.

C'est ce qu'on faisait chez Skello : le site marketing sur Webflow pour la vélocité, et l'application produit sur un autre stack. Chaque équipe avait sa liberté sans bloquer l'autre.

Au final, le meilleur outil c'est celui qui vous permet de livrer le bon résultat dans le bon timing. Le reste, c'est de l'ego technique.