API Webflow vs CMS sans tête : limites de débit et véritables compromis

Webflow est un outil de création de sites visuel qui inclut par hasard un CMS et une API. Un CMS sans interface, en revanche, est un stockage de contenu axé sur l’API, ne disposant absolument pas d’outil de création visuel. La différence entre les deux n’apparaît que lorsque le trafic généré par l’API atteint ses limites, et non pendant que l’on organise encore des éléments sur une page.

Les gens confondent constamment les deux, principalement parce que Webflow propose bien une véritable API. Mais cette API n’a pas été conçue pour servir de backend principal de contenu en dehors des pages que Webflow rend lui-même. Cet article explique dans quels cas cette API fonctionne bien, et dans quels cas elle échoue, ainsi que les limites spécifiques qui déterminent quel scénario s’applique à vous.

Quel est vraiment le CMS de Webflow ?

Le CMS de Webflow est axé sur les collections, qui équivalent à des types de contenu. Vous les remplissez via le même éditeur visuel utilisé pour concevoir vos pages, de sorte que la création de contenu et la conception des pages s’effectuent dans une seule application. C’est là toute sa valeur ajoutée, et pour un site de marketing ou un portfolio, c’est une proposition très solide.

L’API s’ajoute à cette architecture. Elle expose les éléments des collections via des points de terminaison REST, permettant des lectures ainsi qu’un ensemble restreint d’écritures. Son existence vise à permettre aux outils externes d’envoyer des données dans le système de rendu propre à Webflow, et non pas pour que des interfaces frontales distinctes, des applications mobiles ou des tableaux de bord internes puissent tous tirer des données d’une même source partagée. Ce type de configuration destinée à plusieurs utilisateurs est précisément ce pour quoi un CMS sans tête comme Draftbase a été conçu dès le début.

Webflow est-il un CMS sans tête ?

Non. Webflow est un CMS fortement couplé qui expose par hasard une API. Un CMS véritablement headless ne dispose d’aucune couche de rendu intégrée ; chaque élément de markup provient du frontend que vous créez vous-même. Webflow, quant à lui, rend toujours d’abord ses propres pages — l’API fonctionne comme un canal secondaire, et non le moyen principal par lequel le contenu atteint le lecteur.

Les vraies limites de l’API de Webflow (et pourquoi elles posent problème)

Presque tous les articles de comparaison mentionnent que « Webflow a des limites », mais très peu d’entre eux indiquent les chiffres réels, et presque aucun n’explique quelle limite spécifique cause de vrais problèmes une fois que l’on utilise ce système en production.

Les limites de fréquence et l’exception que personne ne mentionne

D’après la documentation destinée aux développeurs de Webflow, l’API Data autorise 60 requêtes par minute pour les forfaits Starter et Basic, ce chiffre montant à 120 requêtes par minute pour les forfaits CMS, eCommerce et Business. Les clients Enterprise négocient un plafond personnalisé. Si vous dépassez cette limite, vous recevez une réponse 429.

Ce détail est souvent omis dans les articles : les requêtes adressées à l’API de distribution de contenu qui proviennent du cache ne sont pas prises en compte dans ce quota. Seules les appels qui atteignent réellement le serveur d’origine de l’API Data le sont. Ainsi, si votre intégration lit en boucle du contenu déjà publié sans le modifier, votre limite de vitesse pratique est considérablement plus élevée que ce qui est indiqué. En revanche, si vous enregistrez des données ou lisez du contenu non stocké en cache à chaque appel, ce plafond de 120 requêtes par minute est rapidement atteint dès que vous synchronisez plus de quelques centaines d’éléments.

Collectes et limites de champs

Avec les forfaits CMS et Business, chaque collection est limitée à 60 champs, et tout champ multi-référence ne peut pointer que vers un maximum de 1 000 éléments. La mise à jour des tarifs de Webflow en mai 2026 a également introduit des plafonds d’éléments par forfait : le forfait CMS est limité à 2 000 éléments de collection, Business peut atteindre 20 000 éléments avec l’achat d’extensions, tandis que l’offre Enterprise bénéficie d’une limite personnalisée négociée. Aucun de ces seuils ne pose de problème à un petit site de marketing disposant d’un blog associé. Ils deviennent importants lorsque le catalogue de produits ou l’ensemble de documents dépasse les capacités autorisées par votre forfait — il en va de même pour une bibliothèque de contenu couvrant plusieurs localisations.

Une publication par minute

D’après la documentation officielle de Webflow concernant les limites de fréquence, les actions de publication de site sont limitées à une publication réussie par minute. Un pipeline CI configuré pour déclencher une publication à chaque fusion dans la branche main commencera à s’insérer en file d’attente dès qu’il percevra un trafic réel, et non seulement dans le cadre d’un cas hypothétique.

Où une API de CMS headless est complètement différente

La différence structurelle fondamentale réside dans le fait qu’un CMS sans interface utilisateur considère le modélisation du contenu comme son interface centrale, toute couche visuelle étant optionnelle ou complètement séparée de celle-ci. Webflow inverse cette hiérarchie : l’éditeur visuel constitue l’interface principale, tandis que l’API n’est qu’un complément ajouté par la suite. Cette différence de priorité se reflète clairement dans le choix que fait chaque produit pour développer en premier lors de l’ajout de nouvelles fonctionnalités.

Où Webflow gagne réellement

Il est utile d’être clair à ce sujet. Pour une équipe de marketing qui souhaite un rendu visuel parfait sans écrire une seule ligne de code, l’outil de création de Webflow surpasse ce que l’on peut obtenir avec Draftbase ou toute autre solution headless pour cette tâche précise. Un contrôle du layout au niveau des pixels grâce au glisser-déposer n’est tout simplement pas un défi que les plateformes headless cherchent à relever, et prétendre le contraire induirait en erreur quiconque compare ces deux approches. Lorsque toutes les personnes travaillant sur le contenu ne sont pas techniques et que le site se compose principalement de pages statiques, le flux de travail unique offert par Webflow constitue un véritable atout, et non quelque chose avec lequel on se contenterait.

Où un CMS headless l’emporte

Considérez un cas où le même contenu doit alimenter un site web, une application mobile et quelques outils internes, tous à partir d’un même schéma. Avec Webflow, ce scénario se heurte immédiatement aux limites de nombre d’éléments et aux plafonds de champs prévus par chaque forfait, ce qui transforme une tâche qui devrait être routinière en un véritable effort de migration. Un CMS headless vous offre dès le départ des champs saisissables et une intégrité des références. Son API de livraison est conçue pour gérer des milliers d’appels par jour sans problème. Aucun plafond artificiel n’est intégré. L’API n’a pas été conçue à la hâte en fonction des schémas d’utilisation d’un outil de création visuelle ; elle fait partie intégrante du produit lui-même.

Quand devriez-vous utiliser Webflow plutôt qu’un CMS headless ?

Préférez Webflow lorsque les personnes qui modifient le contenu ne sont pas des développeurs, que le site compte un nombre limité de pages, et qu’aucun outil en dehors du moteur de rendu de Webflow n’est nécessaire pour traiter ce contenu. Pensez au site web d’un restaurant, à une seule page d’accueil pour un produit, ou au portfolio d’une petite agence. Dans ces cas, l’éditeur visuel de Webflow offre sans conteste un avantage en termes de rapidité de mise en ligne.

Pouvez-vous combiner Webflow avec un CMS headless ?

Oui, et d’ici 2026 cette combinaison sera assez courante. Conservez le site de marketing sur Webflow afin de bénéficier de ses outils de conception. Ensuite, extrayez tout ce qui constitue des données structurées, comme un catalogue de produits, une bibliothèque de documentation ou du contenu généré par les utilisateurs, et gérez-le via un CMS headless distinct, en le rendant sur son propre ensemble de routes. De cette façon, le personnel non technique peut toujours utiliser l’éditeur de Webflow pour le contenu qu’il gère réellement, tandis que chaque partie du système où le volume de contenu ou le nombre d’applications consommatrices dépasse les capacités d’un CMS couplé dispose alors d’une API de livraison adaptée.

FAQ

Webflow compte-t-il comme un CMS headless ? Pas vraiment. Il expose une API permettant de lire des données et d’écrire dans des collections de manière limitée, mais à l’essentiel c’est un CMS couplé conçu avant tout pour rendre ses propres pages. Un véritable CMS headless ne dispose absolument pas de couche de rendu intégrée.

Quel est le plafond de fréquence applicable à l’API de Webflow ? Selon la documentation destinée aux développeurs de Webflow, les forfaits Starter et Basic offrent 60 requêtes par minute, les forfaits CMS, eCommerce et Business en offrent 120, tandis que les forfaits Enterprise permettent de négocier un plafond personnalisé. Il convient de noter que les réponses mémorisées provenant de l’API de distribution de contenu ne sont pas prises en compte dans ce quota.

Quel est le nombre maximal d’éléments qu’une collection Webflow peut contenir ? 2 000 éléments pour le forfait CMS, montant à 20 000 avec des compléments payants pour le forfait Business, et un plafond négociable pour les forfaits Enterprise. Ces chiffres proviennent de la mise à jour des tarifs de Webflow en mai 2026.

Est-il possible d’utiliser le CMS de Webflow comme backend pour une application complètement distincte ? En principe, oui, grâce à son API. Mais vous rencontrerez bien avant les limites de nombre d’éléments, les restrictions des champs et les limitations de vitesse mentionnées précédemment que dans le cas d’un système conçu spécifiquement pour la diffusion de contenu. L’API de Webflow a été créée pour synchroniser les données dans son propre pipeline de rendu, et non pour servir de backend polyvalent à des applications externes.

La réponse honnête

Webflow et un CMS headless sont conçus pour résoudre des problèmes différents, et non comme des versions concurrentes du même outil. Les contraintes API décrites dans cet article ne constituent pas une faille de conception, mais plutôt le résultat naturel du fait que l’API ait été développée autour d’un outil de création visuelle plutôt que l’inverse. Si votre équipe ne compte pas de développeurs et que le site rentre facilement dans les limites du forfait choisi, Webflow vous permettra d’y parvenir plus rapidement. Si vous devez alimenter plusieurs interfaces utilisateur à partir d’un même modèle de contenu, le CMS headless de Draftbase a été conçu dès le début pour éviter complètement ces limites. Un article complémentaire aborde plus en détail l’aspect implementation de cette décision. Vous pouvez le trouver sur HackMD : il traite du chargement et du stockage en cache de contenu à partir d’une véritable API de livraison, en utilisant Node.js et Express.

Lectures complémentaires

• Benchmarking du compilateur Go de TypeScript 7 sur une application Next.js réelle — Une comparaison pratique des temps d’exécution de tsc entre TypeScript 6 et 7 sur un codebase Next.js réel, incluant un bug lié à des incohérences dans CI ainsi que des conseils pour l’upgrade.
• 20 patterns avancés de Next.js pour des applications App Router de niveau production — Découvrez vingt patterns de haut niveau pour Next.js couvrant la conception server-first, le streaming, le cache, le routage et les performances, afin de créer des applications de production plus rapides et scalables.