Webflow vs CMS Headless : Webflow est-il encore pertinent ?

Webflow est très bon pour lancer un site vite. Il l’est beaucoup moins dès qu’il faut organiser du contenu, composer des pages et faire évoluer l’ensemble dans le temps.

En refaisant récemment le site de Dernier Cri, nous nous en sommes rendus compte de façon assez nette : une trentaine de pages ont dû être montées à la main dans le Page Builder, impossible à automatiser. À cette échelle, cela reste supportable. Mais cela dit quelque chose d’important sur le produit : chez Webflow, ce qui permet de composer une page n’est pas vraiment ce qui permet de structurer le contenu.

Pour comprendre le problème, il faut regarder les différentes manières de composer des pages offertes par Webflow.

Webflow : fonctionnalité CMS : bonne pour des structures fixes, limitée pour composer

La première manière de composer des pages est de créer des templates et d’alimenter leur contenu via le CMS intégré à Webflow.

Le CMS Webflow est très correct pour un besoin classique :

• une collection “Articles”
• une collection “Cas clients”
• une collection “Équipe”
• quelques templates

Tout fonctionne tant que la page s’appuie sur une structure figée. On modifie les contenus, mais la structure, elle, ne bouge pas.

Les choses se compliquent dès que les besoins suivants se présentent :

• “cette landing page, on l’imagine avec un Hero, trois sections de fonctionnalités, un bloc de témoignages et une FAQ”
• “celle-ci aurait un Hero différent, une grille de tarifs, une section logos partenaires, puis un appel à l’action”
• “et il faut que l’équipe marketing puisse réorganiser, ajouter, retirer des sections à sa guise”

En clair : construire la page comme une suite de blocs modulaires.

Webflow autorise quelques astuces : on duplique des pages, on crée plus de collections, on joue avec des règles conditionnelles. Pour un petit projet, on peut s’en accommoder. Mais dès que l’on pousse l’exercice, on repose tout sur un CMS pensé pour des “modèles de pages”, alors qu’on voudrait un CMS orienté “assemblage de blocs”.

L’écueil est le même chez les outils pensés pour le design. Ainsi, Framer brille lorsqu’il s’agit de prototyper ou de sortir rapidement une mise en page. Mais dès qu’il s’agit d’instaurer une logique éditoriale ou de structurer un véritable système, la promesse s’étiole.

Webflow : fonctionnalité “Page Builder” : bonne pour composer, terriblement limitée pour scaler

Pour composer des pages “librement”, Webflow propose une autre fonctionnalité : le Page Builder.

La fonctionnalité permet d’assembler rapidement des composants existants, de jouer sur quelques paramètres, et de générer des pages sans avoir à tout reconstruire à chaque fois. Lorsqu’on se trouve dans l’interface Webflow, l’expérience est fluide et plaisante. On avance sans efforts superflus, porté par un outil pensé pour cette agilité de composition.

Mais attention : le Page Builder ne produit pas du contenu mais des pages statiques. Il ne s’appuie pas sur la fonctionnalité CMS.

Le CMS se concentre sur la gestion des collections et des champs, là où le Page Builder de Webflow orchestre la composition directement dans la plateforme. Concrètement, toute la logique de composition reste encapsulée côté Webflow : impossible d’obtenir via l’API CMS une représentation “headless” claire et exploitable ailleurs. La création et l’évolution des pages demeurent donc indissociablement liées à l’éditeur Webflow. Pire encore, impossible, via l’API ou via l’interface Webflow, d’automatiser la composition des pages.

Malheureusement, ce choix semble intentionnel, car il reste d’une certaine manière cohérent avec la promesse de Webflow… Fin 2025, à la Webflow Conf, Webflow a annoncé un “next gen CMS”. C’est une vraie évolution. Mais ce qu’on comprend surtout, c’est qu’il s’agit de faire sauter des limites qui semblaient d’un autre temps : permettre des collections imbriquées, supprimer des contraintes historiques, aller au-delà de 10.000 éléments par collection, etc. Tout cela reste utile, mais ce n’est pas, à ce stade, un CMS orienté “sections/slices”, où une page est une liste de blocs composables et où cette composition est une donnée de premier ordre, accessible proprement.

Tout cela donne l’impression que Webflow privilégie volontairement une composition qui reste dans Webflow. D’un point de vue stratégie produit, la logique se tient : proposer une composition ouverte, c’est amoindrir le fameux lock-in. On cesse d’être la plateforme centrale pour devenir une brique interchangeable. Alors que justement, Webflow a prospéré jusqu’à aujourd’hui en contrôlant l’ensemble : éditeur, hébergement, structure des modèles.

Dès lors, si l’on sait que migrer, composer ailleurs ou automatiser cette composition peut devenir un critère, il faut prendre cette question très au sérieux dès le départ.

Le headless (Dato, etc.) : la page comme liste de sections

Les CMS headless (DatoCMS, Contentful, Sanity, Prismic, Storyblok…) reposent sur une idée simple : séparer le contenu et la présentation.

Mais surtout, ce qui nous intéresse particulièrement ici, c’est qu’ils proposent tous un modèle de composition de page assez proche de ce que nous voulons faire :

• une page = une suite de sections
• chaque section = un type (Hero, Features, FAQ, Pricing…)
• chaque section a ses champs
• on peut réordonner, activer/désactiver, varier

Selon les outils, ça s’appelle “sections”, “blocks”, “slices”, “modules”. Peu importe le mot : l’important, c’est le modèle.

Exemple avec une page “Produit”

• Hero (titre, sous‑titre, image)
• FeatureGrid (liste de features)
• Quote (citation + auteur)
• FAQ (liste)
• CTA (titre + bouton)

L’équipe marketing n’édite pas “une page HTML”. Elle manipule une composition. Et cette composition est accessible :

• dans l’UI du CMS
• via l’API
• donc dans n’importe quel front (Next.js, Rails, Astro, un site statique, etc.)

On peut changer de front sans avoir à réécrire tout son contenu. On peut faire évoluer le design sans risquer de briser le modèle qui structure les données. On garde la capacité de versionner le code, de tester, de déployer, le tout sans jamais toucher aux données éditoriales.

Choisir entre Webflow et un CMS headless… en 2026

Ce qui a changé récemment, en particulier depuis 2025, c’est le coût du sur-mesure. Pendant des années, Webflow a souvent été la réponse à une contrainte très concrète : “on n’a pas le temps / le budget / l’équipe pour coder un site”. Mais ce coût a bougé. Pas parce que “les devs disparaissent”, mais parce que le temps de production d’un site codé a chuté. Avec Cursor et l’IA en général, il devient normal de :

• prototyper vite
• itérer sur le design directement en code
• générer une première version propre
• puis faire le vrai travail : simplifier, factoriser, rendre maintenable

On le voit déjà dans des équipes très orientées design : les designers ne restent plus “dans Figma”. On attend d’eux qu’ils comprennent un système, qu’ils soient à l’aise avec un repo, qu’ils puissent toucher le front, non pas pour “faire du backend”, mais pour faire avancer le produit.

Ce n’est pas “transformer des designers en développeurs”. C’est réduire la frontière : le design n’est pas une image, mais un ensemble de comportements, de composants, de contraintes. Et l’IA aide à franchir cette frontière sans transformer chaque itération en projet.

Alors, en définitive, on en arrive à la conclusion suivante :

Si l’objectif est d’aller vite, ici et maintenant, avec quelques pages dont la structure change peu, Webflow s’impose : on publie, on itère, terminé.

Si le site a vocation à évoluer, à multiplier les pages, à varier les formats, à donner de l’autonomie à l’équipe marketing, à s’intégrer à d’autres outils, alors un CMS headless apporte une structure plus robuste : le contenu devient composable, et cette composition reste exploitable via une API. Autrement dit, dès que l’on sait que le site doit devenir un système, pas juste une vitrine, le headless est un meilleur pari.

Le compromis tentant serait de se dire : “on commence sur Webflow et l’on migrera plus tard”. Oui, mais il faut garder en tête que l'on accumule une dette invisible dans la structure même du contenu. On s’habitue aux contournements, on copie-colle, on duplique, on bricole, et le jour où l’on veut migrer, tout est plus coûteux que prévu, précisément parce que rien n’a été pensé comme une donnée portable. Dans un monde où l’IA réduit le coût de build, le “lock-in” devient le vrai prix à payer.

TL;DR : nos convictions à dates sont les suivantes :

• Webflow reste pertinent si l’on souhaite aller vite, avec une structure de page relativement figée.
• Les CMS Headless (DatoCMS & consorts) sont plus intèressant dès lors que l’on veut assembler des pages à partir de sections, et que l’on souhaite garder cette composition exportable et pilotable via une API, et que le vendor lock-in est un sujet.
• Ce qui a changé depuis 2025 : l’IA a fait baisser le coût du site “développé sur mesure”. Au coût du “développé sur-mesure” s’oppose désormais, plus que jamais, celui du “verrouillage” sur la plateforme (lock-in).

Notre choix récent pour refaire le site derniercri.io

Nous avons récemment refait le site Dernier Cri, et nous nous sommes posé la question de la pertinence de Webflow pour le projet.

Nous avons finalement opté pour Webflow car le time-to-market était le plus court et que c’était, pour nous, le critère décisif. Nous avons de nombreuses pages composées manuellement via le Page Builder. Une trentaine. Elles ont toutes dû être éditées à la main, une par une, et cela a été assez fastidieux. Mais à cette échelle, cela reste encore raisonnable. Autrement dit, nous ne regrettons pas ce choix. En revanche, si notre nombre de pages devait augmenter radicalement, ce mode de fonctionnement deviendrait vite une limite très concrète.