Webflow vs Framer : après le no-code, code ou canvas ?

En janvier 2012, Bret Victor monte sur scène à Montréal pour donner une conférence devenue culte dans le monde du design logiciel : Inventing on Principle.

Son idée est simple : un créateur doit rester au contact direct de ce qu’il crée. Modifier quelque chose, en voir immédiatement l’effet, sans rupture entre l’intention et le résultat.

Vlad Magdalin, le fondateur de Webflow, fait partie de ceux que la conférence marque profondément. Webflow naîtra en grande partie de cette intuition : permettre de concevoir directement pour le web sans passer par le cycle traditionnel code, compilation, rafraîchissement.

Des années plus tard, Bret Victor lui-même lui fera pourtant une remarque qui restera : selon lui, Webflow n’était pas vraiment fidèle à ce principe.

C’est cette anecdote que Webflow choisit de raconter le 4 août 2026 dans Getting to the source, un texte signé par Ben Haefele, Chief Product Officer, et Utkarsh Sengar, VP Engineering.

Et ce n’est pas un simple billet d’opinion.

Webflow y annonce une direction produit beaucoup plus radicale qu’un nouveau module d’IA : l’entreprise veut reconstruire sa plateforme autour du code comme source de vérité.

Deux semaines plus tard, le 18 août, Ben Haefele récidive avec Kevin Wong, VP Design, dans Made to measure. Cette fois, le point de départ n’est plus Bret Victor, mais HyperCard, lancé par Apple en 1987 et conçu par Bill Atkinson.

HyperCard permettait à des utilisateurs ordinaires de fabriquer des logiciels à partir de cartes, de boutons et de scripts. Le jeu Myst est notamment né de cet environnement.

Le message de Webflow est clair : si l’IA rend désormais le logiciel plus malléable, l’interface elle-même n’a peut-être plus besoin d’être identique pour tout le monde.

À deux semaines de la Webflow Conf 2026, prévue du 1er au 3 septembre à Boston et en ligne, l’entreprise ne décrit donc plus seulement comment construire des sites avec de l’IA. Elle commence à expliquer ce qu’elle pense que le logiciel de création doit devenir.

Le no-code reposait sur une contrainte que les agents commencent à supprimer

Le fonctionnement historique de Webflow repose sur une abstraction.

L’utilisateur manipule visuellement une représentation propriétaire du site. Webflow transforme ensuite cette représentation en HTML, CSS et JavaScript au moment de la publication.

Cette couche a fait le succès du produit : elle permet de travailler visuellement sans avoir à écrire directement le code exécuté par le navigateur.

Mais elle crée aussi une séparation entre ce que l’utilisateur manipule et ce qui est réellement livré.

Dans Getting to the source, Webflow estime désormais que cette séparation peut devenir un problème. Les agents savent lire, écrire, expliquer et refactorer du code avec suffisamment de fluidité pour rendre cette matière technique accessible à des personnes qui n’écriront jamais elles-mêmes une ligne de JavaScript.

La conséquence est assez paradoxale.

Pendant une décennie, cacher le code était une fonctionnalité. Si un agent peut désormais agir sur ce code à notre place, le code peut redevenir central sans redevenir une barrière.

Webflow formule donc une nouvelle architecture : le code doit devenir l’artefact canonique, celui que le canvas affiche, que les agents manipulent et que l’utilisateur possède.

Le Designer visuel et la conversation avec l’IA ne seraient plus deux couches au-dessus d’un format intermédiaire propriétaire, mais deux façons différentes d’interagir avec la même source réelle.

C’est un changement de philosophie majeur pour une entreprise devenue emblématique du mouvement no-code.

Le « SaaSpocalypse » donne aussi un contexte économique à ce virage

Made to measure ajoute une couche moins technique et plus stratégique.

Webflow y revient sur le terme « SaaSpocalypse », né sur une salle de marché pendant la chute des valeurs software au début de l’année 2026.

La peur derrière le mot est assez simple : si n’importe qui peut demander à un agent de produire un logiciel, que devient l’économie des entreprises SaaSSoftware as a Service : logiciel livré en ligne par abonnement, multi-tenant en général. qui facturent un produit standardisé par utilisateur ?

Webflow ne pense pas que le logiciel va disparaître. Mais l’entreprise conteste une hypothèse qui a structuré le SaaS pendant vingt ans : celle selon laquelle un même produit doit nécessairement présenter une interface fixe à tous ses utilisateurs.

Et le texte insiste sur un point important : cette standardisation n’était pas d’abord une philosophie de design. C’était une contrainte économique qui a fini par être traitée comme une philosophie.

Il était simplement trop coûteux de concevoir un logiciel différent pour chaque rôle, chaque équipe ou chaque manière de travailler.

L’IA change potentiellement ce coût marginal.

Webflow imagine donc un produit dont la source, les données, les permissions, l’historique et les règles restent stables, mais dont l’interface peut évoluer autour de la tâche.

Un designer pourrait voir un environnement centré sur le design system. Un marketer une vue liée aux campagnes et aux performances. Une équipe transverse une interface construite autour d’un workflow précis.

Le produit ne disparaît pas derrière un chatbot universel. Il devient davantage adaptable autour d’une infrastructure commune.

Cette stratégie n’est déjà plus théorique

C’est ici que les chiffres publiés par Webflow deviennent particulièrement importants.

L’entreprise indique que plus de 30 % de ses clients Enterprise font déjà tourner des agents contre leurs sites Webflow en production via MCP.

L’usage a été multiplié par environ quatre depuis janvier 2026.

Et un chiffre est encore plus frappant : dans son communiqué de lancement de MCP 2.0, Webflow indique que près de 90 % des utilisateurs MCP passent aujourd’hui par Claude, d’AnthropicLaboratoire d’IA américain à l’origine des modèles Claude, accessibles par API et non téléchargeables..

Autrement dit, il ne s’agit déjà plus d’un usage expérimental réservé à quelques démonstrations.

Des agents interviennent sur des sites réels, avec des conséquences réelles sur les pages, le CMS, les performances et la production.

Ce chiffre éclaire aussi la stratégie de Webflow : à mesure que les agents deviennent des collaborateurs opérationnels, le problème n’est plus seulement de leur donner accès au produit. Il faut leur imposer les mêmes garde-fousRègles et filtres (policy, classifiers, allowlists) qui limitent les sorties ou actions dangereuses d’un système IA. qu’aux humains.

MCP 2.0 : quand l’agent obtient les mêmes règles que l’équipe

C’est précisément l’objectif de Webflow MCP 2.0, lancé le 21 juillet 2026.

Le protocole permet à des outils comme Claude, ChatGPT ou Cursor d’interagir avec Webflow.

Mais la vraie nouveauté n’est pas la conversation en langage naturel.

Les agents peuvent travailler avec le contexte du design system, du CMS et des données analytiques. Ils peuvent intervenir sur des branches isolées, respecter les rôles et permissions définis dans l’entreprise et laisser leurs actions dans les journaux d’activité.

La logique est claire : si les agents font partie de l’équipe, ils doivent aussi entrer dans le système de gouvernance de l’équipe.

C’est probablement là que la compétition entre les builders devient plus intéressante que la simple génération de landing pages.

Créer une première version d’une page avec un promptConsigne / contexte fourni au modèle pour orienter sa génération (system, user, exemples, outils). devient vite une commodité. Faire travailler designers, développeurs, marketeurs et plusieurs agents sur le même site de production sans casser le design system, le contenu ou les règles de publication est un problème beaucoup plus difficile.

GSAP n’était qu’une des premières briques

Cette nouvelle direction permet de relire plusieurs décisions de Webflow avec davantage de cohérence.

Le 15 octobre 2024, Webflow rachète GreenSock, l’entreprise derrière GSAP, l’une des bibliothèques d’animation JavaScript les plus répandues du web.

En avril 2025, GSAP et ses plugins deviennent gratuits. Quelques mois plus tard, Webflow reconstruit son système d’interactions autour de GSAP.

À l’époque, l’acquisition pouvait surtout se lire comme un investissement dans le motion design.

Aujourd’hui, GSAP ressemble davantage à la brique « comportement et interaction » d’un système plus vaste.

Elle n’est d’ailleurs pas seule.

Webflow cite lui-même plusieurs fondations de cette nouvelle architecture dans Getting to the source :

• AI Code Components, qui permettent aux agents et aux utilisateurs de générer directement des composants React compatibles avec un design system ;
• le passage à un CMS headless de nouvelle génération, avec de véritables APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). de content delivery afin que le contenu puisse être consommé par autre chose que le renderer historique de Webflow ;
• MCP 2.0, avec branching, permissions et gouvernance ;
• Webflow Cloud, qui rapproche la plateforme d’applications modernes construites avec des frameworks comme Next.js ou Astro ;
• et le rachat de Vidoso.ai le 12 mars 2026, qui ajoute une brique de génération de contenus visuels et vidéo alignés avec une marque.

Webflow insiste d’ailleurs sur le fait que ces paris ne sont pas indépendants. Ce sont les poutres d’une même fondation posées progressivement.

Le rachat de GSAP paraît donc aujourd’hui moins isolé qu’en 2024.

Webflow assemble peu à peu les primitives nécessaires pour qu’un humain ou un agent puisse agir sur la structure, le contenu, le code, les composants, les interactions et la diffusion d’un même projet.

Framer n’a pas répondu à Webflow : il l’a précédé

La question naturelle serait de savoir si Framer va suivre cette voie.

Mais chronologiquement, la formulation serait trompeuse.

Framer a pris le virage agentique avant les deux textes de Webflow.

Le 16 juin 2026, l’entreprise a présenté Framer 3.0, avec Framer Agents, le branching et une nouvelle Community.

Les Agents travaillent directement dans le canvas. Ils peuvent générer des pages, reproduire une interface à partir d’une capture, ajuster les breakpoints responsive, modifier les styles, créer des interactions, écrire des composants en code, intervenir sur le CMS, générer des métadonnées SEOSearch Engine Optimization : ensemble de pratiques pour améliorer la visibilité organique dans les moteurs de recherche. ou auditer la cohérence d’un site.

Dans son billet officiel de lancement, Framer résume lui-même son ambition par une formule efficace : « Cursor for design ».

L’entreprise permet également à des agents externes — notamment Codex, Claude Code ou Cursor — d’agir sur un projet Framer.

La convergence avec Webflow est donc déjà là.

Les deux plateformes partent du principe que les sites professionnels seront de plus en plus construits et maintenus par des équipes hybrides mêlant humains et agents.

La différence la plus intéressante se trouve ailleurs.

Webflow parie sur la source ; Framer protège le canvas

Dans son article technique Building Agents for Framer, Framer explique pourquoi il ne veut pas simplement laisser une IA produire un gros volume de code.

Pour un designer non-développeur, ce résultat reste difficile à comprendre, modifier et posséder.

L’agent doit donc travailler dans le même canvas que l’humain.

C’est là que la divergence philosophique devient nette.

Webflow dit : le code doit devenir la source de vérité, et le canvas comme la conversation avec l’IA deviennent différentes représentations de cette source.

Framer dit plutôt : le canvas doit rester l’espace commun de compréhension, et l’agent doit apprendre à y travailler aux côtés du designer.

La différence n’est évidemment pas absolue. Framer produit du code et Webflow conservera un environnement visuel.

Mais les deux entreprises semblent placer leur centre de gravité à des endroits différents.

Webflow part de l’artefact technique et veut multiplier les interfaces qui permettent de le manipuler.

Framer part de l’interface créative et veut faire entrer l’agent dans cet environnement sans priver l’humain de sa capacité à comprendre le résultat.

Webflow parie sur la source. Framer protège le canvas.

La prochaine guerre des website builders ne portera peut-être plus sur le « no-code »

Cette opposition rend presque obsolète le débat historique entre code et no-code.

Le no-code s’est développé parce que le code constituait une barrière entre l’intention et l’exécution.

Les agents peuvent réduire cette barrière sans faire disparaître le code.

Si l’utilisateur peut demander « agrandis ce titre sur mobile », « transforme ce composant », « crée une variante conforme au design system » ou « réorganise ce contenu » sans écrire lui-même la syntaxe correspondante, alors le code peut redevenir la matière première sans redevenir l’interface obligatoire.

Le véritable enjeu se déplace.

Qui possède la source ?

Comment l’humain comprend-il ce que l’agent a changé ?

Comment plusieurs agents collaborent-ils avec plusieurs métiers ?

Comment maintient-on les permissions, le design system, la marque, le CMS, les performances et l’historique lorsque la production accélère ?

Et surtout, que se passe-t-il une fois la page publiée ? Dans What we’ve heard, and what comes next, Webflow insiste précisément sur ce point : l’IA a accéléré la construction, mais l’essentiel du travail commence après la mise en ligne — mise à jour, tests, optimisation, personnalisation et maintien de la cohérence dans le temps. La plateforme veut donc étendre la logique agentique au-delà du simple moment de création.

C’est probablement sur ces questions que se jouera la prochaine bataille des website builders.

Et c’est aussi pourquoi la Webflow Conf du 1er au 3 septembre 2026 mérite désormais d’être surveillée de près : Made to measure se termine explicitement par la promesse que Webflow y montrera ce qu’il a construit pour cette vision.

Framer, de son côté, a déjà placé ses Agents au centre de Framer 3.0 et continue de les faire évoluer à un rythme rapide.

La question n’est donc plus de savoir si Framer suivra Webflow vers l’IA.

Il l’a précédé sur le calendrier.

La question est désormais beaucoup plus intéressante : l’avenir des outils créatifs sera-t-il organisé autour d’une source technique commune que différentes interfaces viennent manipuler, ou autour d’un canvas humain dans lequel les agents apprennent à travailler ?

Pour Webflow et Framer, la bataille d’après le no-code a déjà commencé.