Webflow ou Framer pour un site d'annonces : le chemin d'écriture décide
Pour un site dont le contenu est un flux, ni l'outil de design ni le plafond d'éléments ne tranchent. Ce qui tranche, c'est comment les annonces entrent, à qui appartient la clé qui les y met, et ce qui se passe quand la synchronisation meurt à mi-chemin.
Un site d'annonces n'est pas un site vitrine avec plus de pages. Son contenu vient d'ailleurs, change sans que personne n'ouvre l'éditeur, et ne vaut plus rien dès qu'il est périmé. Cela déplace la décision loin de l'outil de design et loin du plafond d'éléments, vers une question plus étroite : comment les annonces entrent-elles, et que se passe-t-il la nuit où cela s'arrête.
Le comparatif général des plafonds mérite d'être lu d'abord, car il fixe les chiffres et corrige une affirmation que la plupart des comparatifs répètent encore : voir CMS Webflow ou CMS Framer. Cet article reprend là où l'autre s'arrête, au moment où le contenu est un flux plutôt qu'un ensemble de pages.
Vérifiez d'abord si le CMS est même concerné
Dans l'immobilier résidentiel américain, les annonces viennent en général d'un MLS via IDX, et le produit IDX les affiche lui-même. iHomeFinder, IDX Broker et Realtyna livrent chacun sa recherche, ses pages de détail et sa capture de leads. Le CMS porte les pages sur l'agent, pas les annonces. Si le projet a cette forme, ce comparatif ne décide rien, et les vraies questions sont la gestion d'un embed tiers et la destination du lead. Nous avons traité les deux volets : IDX sur Webflow et la configuration iHomeFinder, aux côtés du travail immobilier plus large.
Le CMS ne tranche que si vous êtes propriétaire des données. Des locations que vous gérez, l'inventaire d'un promoteur, un annuaire, des locaux commerciaux, ou tout marché sans flux MLS. C'est ce cas qu'aborde cet article, et c'est aussi celui où un espace protégé pour les recherches enregistrées commence à compter.
Les plafonds vont à l'inverse de la réputation
Framer publie un plafond d'éléments plus élevé que Webflow. Avec les options sur Pro, il atteint 40,000 éléments et 40 collections ; le plan Business de Webflow avec options atteint 20,000. Les deux chiffres viennent de l'éditeur lui-même, consultés le 4 septembre 2026, et sont détaillés dans la référence des limites Webflow et celle de Framer. La réputation dit l'inverse, ce qu'il vaut mieux savoir avant qu'on écarte Framer en réunion de lancement.
De toute façon, il contraint rarement. Vingt mille, c'est beaucoup d'annonces, et un portefeuille de cette taille a en général dépassé le constructeur de sites pour des raisons qui n'ont rien à voir avec le comptage. Le plafond est le mauvais axe. Le chemin d'écriture est le bon.
Comment les annonces entrent réellement
| Question | Webflow | Framer |
|---|---|---|
| Chemin d'écriture serveur | Data API, disponible | Server API, bêta ouverte depuis le 12 fév. 2026 |
| Éléments par requête | 100 | Non publié |
| Requêtes par minute | 60 sur Starter et Basic, 120 sur CMS, eCommerce et Business | Non publié |
| Publication à l'écriture | Create Live Items publie à la création | La publication est un appel distinct |
| Fréquence de publication du site | Une publication réussie par minute | Non publié |
| Portée des identifiants | Jeton de site, créé par site | Clé API liée à un projet |
Les deuxième et troisième lignes décident d'une reconstruction nocturne. Vingt mille annonces à 100 éléments par requête font 200 requêtes, et à 120 par minute cela représente moins de deux minutes de temps de requête. Qu'un rafraîchissement complet soit raisonnable ou hors de question dépend de ces deux chiffres, et un comparatif écrit sur l'outil de design ne les atteint jamais.
Côté Framer, ces cases sont vides parce que l'éditeur ne les a pas remplies. Le Server API fait le travail : il existe pour mettre à jour et publier un projet depuis n'importe quel serveur sans l'ouvrir depuis un client, et synchroniser une base externe vers le CMS est le premier cas d'usage qu'il cite. Ce qui manque, c'est le cadre opérationnel, et un cadre illisible est un cadre qu'on découvre en production.
À qui appartient la clé après le départ de l'agence
Un jeton de site Webflow se génère dans les réglages du site sous Apps et intégrations, uniquement par un administrateur, et Webflow recommande elle-même de révoquer le jeton d'un administrateur qui part. Le jeton appartient au site. Une clé API Framer est différente par conception : la documentation indique que les clés authentifient votre script en tant qu'utilisateur qui les a créées, et qu'elles sont liées à un projet précis. La synchronisation tourne donc au nom d'une personne. Sur un projet d'agence, c'est une vraie question de passation, car le script fonctionne exactement aussi longtemps que ce compte, et rien sur le site ne dit lequel. Notez-le à la construction, au même endroit que le DNS et le dépôt, sinon le premier partant emporte le flux d'annonces avec lui.
Une note pratique tirée de la pratique. La documentation du Server API indique que la clé se génère dans la section General des réglages du site. Sur le projet que nous avons construit, les clés se créaient plutôt via la palette de commandes, ouvrir les réglages puis API Keys. Prévoyez que la doc et le produit divergent sur ce point.
Ce qu'une page a le droit d'afficher
Webflow publie des limites par page et les a mises à jour récemment. Lues le 4 septembre 2026 : jusqu'à 40 listes de collection par page, jusqu'à 10 listes imbriquées par page, 100 éléments par liste sans pagination, et 100 éléments par liste imbriquée. Pour une grille d'annonces contenant des cartes d'agent, ces quatre chiffres sont tout le cahier des charges.
Deux conséquences. Le chiffre de cinq éléments dans une liste imbriquée, que les comparatifs répètent encore, est obsolète : une maquette écartée sur cette base mérite d'être revue. Et Framer ne publie pas de page équivalente : son article d'aide sur la limitation des éléments visibles explique où se trouve le réglage sans nommer de maximum, ce qui, pour une page affichant un grand jeu de résultats, est un manque que l'on comble en testant plutôt qu'en lisant.
Ce qui casse à mi-chemin
Aucun des deux chemins d'écriture n'est transactionnel. Sur le Server API de Framer, nous avons vu un script mourir en cours d'exécution et laisser le projet à moitié mis à jour sans moyen d'annuler le reste : une synchronisation doit donc être écrite pour être relançable sans risque, pas pour réussir une fois. Le mode de défaillance de Webflow est plus étroit pour une raison simple : son Data API touche aux éléments du CMS et à rien d'autre, tandis que le Server API peut aussi déplacer le canevas et les réglages du projet, si bien qu'une mauvaise exécution y modifie le design autant que les données. Dans les deux cas la règle est la même. Rendez le script idempotent, indexez chaque élément sur l'identifiant du flux lui-même, et ne faites jamais dépendre l'exactitude du fait qu'une exécution aille jusqu'au bout.
Alors lequel
- Les annonces viennent d'un MLS via IDX : ce n'est pas le comparatif à faire. Comparez plutôt la gestion des embeds et l'acheminement des leads.
- Vous possédez les données et elles se synchronisent chaque nuit depuis un serveur : Webflow, sur le seul cadre opérationnel publié.
- Le catalogue est vraiment énorme et change rarement : Framer a le plafond le plus élevé des deux.
- Quelqu'un met les annonces à jour à la main dans l'éditeur : les deux conviennent, et c'est finalement l'outil de design qui tranche.
Rien de tout cela n'est permanent. Les deux éditeurs bougent, le Server API est encore en bêta ouverte, et les manques de sa documentation sont exactement du genre à se combler. Datez le tableau, gardez les liens vers les sources, et revérifiez-les avant le prochain projet plutôt que de vous fier à un comparatif écrit il y a un an, celui-ci compris.
