Webflow nous a construits. Il ne nous définit plus à lui seul.
Studio Relief s’est d’abord fait connaître comme un studio Webflow. Le choix avait du sens, et il en a toujours. Il réunit design visuel, CMS, hébergement et publication dans un même environnement. Cette continuité nous a permis de produire des sites sur mesure sans transformer chaque mise à jour en ticket de développement.
Depuis longtemps, nous ne voulions plus que toute l’activité du studio soit dépendante d’un seul outil. Être Webflow-only, c’était accepter qu’une évolution tarifaire, une nouvelle limite ou un changement de stratégie puisse directement modifier notre manière de produire. La restructuration annoncée par Webflow en mai 2026 nous a poussés à accélérer cette réflexion. Webflow a présenté cette décision comme une adaptation à un marché transformé par l’IA, et confirmé sa volonté de devenir une plateforme marketing pensée pour le « web agentique ». De notre côté, cet épisode nous a surtout rappelé une chose : une agence ne devrait pas laisser toute sa capacité de production dépendre de la trajectoire d’une seule entreprise.
L’essor de l’IA a creusé un écart entre Webflow et les projets code-first. Le MCP 2.0 a bien tenté de le réduire, mais il reste limité aux actions ouvertes par la plateforme, là où un agent peut intervenir dans l’ensemble d’un dépôt. Ce retard accumulé est un constat largement partagé par la communauté Webflow, où des spécialistes comme Timothy Ricks ou Julian Galluzzo explorent désormais des workflows plus ouverts.
Webflow semble avoir pris la mesure de ce mouvement. Dans sa communication autour de la Webflow Conf, l’entreprise ne présente plus le code comme un simple format d’export, mais comme la future source de vérité du projet. Ce que l’on conçoit et ce qui est réellement livré auraient enfin vocation à ne faire qu’un. La direction annoncée est clairement plus code-first. Cette évolution nous intéresse forcément. Nous connaissons l’outil, nous y sommes attachés et nous avons hâte de voir la forme que prendra cette vision.
En attendant de la voir se concrétiser, nous avançons avec une approche plus ouverte. Webflow fait toujours partie de nos outils et nous continuons à le recommander lorsque son environnement correspond réellement aux besoins d’un client. Pour une organisation qui veut permettre au marketing de composer, modifier et publier des pages sans maintenir un dépôt de code, Webflow reste une réponse très solide. La différence, c’est qu’il n’est plus notre réponse automatique.
Le contenu prend son indépendance, les équipes gardent la main
Pour Studio Relief, livrer un site, c’est aussi donner aux équipes les moyens de le faire vivre sans dépendre de nous. Cette autonomie se pense dès le départ. Webflow en a fait l’une de ses grandes forces en réunissant le site et son interface d’édition. Grâce à des rôles bien définis, les équipes peuvent modifier et publier leurs contenus dans leur contexte, sans toucher au design ni au code.
Cette autonomie offerte aux équipes n’est toutefois plus réservée aux plateformes tout-en-un. Sanity ne se contente pas de séparer le contenu du front : il permet de concevoir le back-office autour du fonctionnement réel de chaque équipe. Les champs, les relations entre les contenus, les droits et les règles de publication peuvent être adaptés au projet. Avec la prévisualisation en direct et l’édition visuelle, les équipes continuent de voir leurs modifications dans le contexte du site. Le contenu structuré peut ensuite alimenter différentes pages ou interfaces sans dépendre d’un seul front.
Chez Webflow, cette expérience est intégrée au produit. Avec Sanity, elle se conçoit avec le reste de l’architecture. Cela demande davantage de travail au départ, mais offre aux équipes un outil de gestion pensé pour leurs usages et capable d’évoluer avec le projet.
L’IA change notre rapport au code
Passer d’un environnement de développement visuel au code demandait encore récemment d’apprivoiser tout un nouvel écosystème. L’IA ne fait pas disparaître cette étape, mais elle la rend beaucoup plus accessible.
Les assistants IA peuvent parcourir un dépôt complet, suivre le chemin d’une donnée, comprendre un composant inconnu, préparer une migration ou lancer un audit complet d’un site. On ne travaille plus uniquement à partir d’un extrait isolé, le contexte du projet devient lisible et interrogeable. Cela change concrètement notre capacité à explorer : on passe plus vite de l’idée au prototype et l’on peut suivre un problème à l’échelle du projet sans perdre le fil.
Claude ou Codex ne transforme pas une personne en développeur senior après trois prompts et un skill. Ils peuvent toujours proposer une architecture inutilement complexe, manquer une contrainte de sécurité, ou encore résoudre avec assurance le mauvais problème. Pourtant, ils ont déjà bouleversé l’écosystème et font évoluer notre métier un peu plus chaque jour. Notre rôle change avec eux : nous passons moins de temps à chercher la syntaxe et davantage à vérifier l’intention, l’architecture et les conséquences. Il faut toujours relire, tester, mesurer et savoir écarter une solution séduisante, mais mal adaptée aux besoins. Cette puissance ne remplace pas notre expertise : elle lui donne plus de portée.
À l’échelle du studio, cette évolution ne s’arrête pas au code. L’IA crée un fil plus direct entre la conception et le développement : nous pouvons préparer plus tôt le passage de la maquette aux composants, confronter une intention visuelle aux contraintes de l’intégration et faire circuler les ajustements dans les deux sens. Design et développement avancent moins en étapes isolées et davantage par itérations.
Elle améliore également nos livrables. Nous pouvons documenter plus systématiquement l’architecture, les composants, les modèles de contenu et les règles de publication dans des fichiers Markdown. Ces fichiers .md sont lisibles aussi bien par leurs équipes que par les agents IA qui pourront intervenir plus tard sur le projet.
L’IA réduit les frictions, pas la valeur de la prestation. Le temps gagné sur la recherche de syntaxe, les tâches répétitives ou la première passe de documentation peut être réinvesti dans les arbitrages, les tests et la qualité de finition. Le résultat n’est pas une prestation au rabais réalisée plus vite. Ce sont des livrables plus complets, mieux documentés et plus simples à reprendre, pensés pour des équipes qui travailleront elles aussi de plus en plus avec l’IA.
Le projet donne la direction
Les progrès des CMS headless et l’émergence de l’IA ne désignent pas un nouvel outil gagnant. Ils élargissent notre liberté de conception. Webflow conserve ses forces, Astro et Next.js nous permettent d’explorer d’autres manières de construire.
Un site n’est pas « un site ». Une landing page destinée à valider une offre, un média de marque et un espace connecté n’ont ni la même durée de vie, ni les mêmes équipes, ni les mêmes responsabilités. Partir d’une stack unique oblige pourtant à poser la question à l’envers : « Comment faire ce projet avec notre outil ? »
On préfère désormais commencer par les usages. Qui publie ? Qui maintient ? Où vivent les contenus ? Qu’est-ce qui doit évoluer ? Quelle autonomie faut-il préserver ? Quel rôle le site pourrait-il prendre demain ? Le nom de la technologie arrive après.
Parfois, la réponse reste Webflow. Son environnement intégré, son interface visuelle et sa gestion des rôles peuvent être exactement ce qu’il faut. Parfois, le projet gagne à séparer son contenu, son front ou sa logique applicative. Aucun de ces chemins n’est plus avancé qu’un autre. Chacun répond à une réalité différente.
Lorsque la performance et le référencement naturel sont prioritaires, Astro offre un socle particulièrement intéressant. Son architecture permet de livrer des pages très légères, de limiter le JavaScript au strict nécessaire et de garder la main sur la construction des composants. Il peut aussi devenir le front d’une boutique Shopify grâce à la Storefront API, sans imposer le thème Shopify comme expérience côté visiteur.
Lorsqu’un site se rapproche davantage d’une application, Next.js nous permet de réunir l’interface, les données, les comptes utilisateurs et la logique métier dans une architecture plus cohérente. Pour ce type de projet, nous préférons pouvoir maîtriser l’ensemble plutôt que d’accumuler des couches comme Wized, Memberstack et plusieurs automatisations autour de Webflow. Cela ne rend pas ces outils inutiles. Leur pertinence dépend simplement du niveau de complexité, de contrôle et d’évolution attendu.
Studio Relief n’applique donc pas une recette préparée à l’avance. Le projet donne la direction, notre expérience permet de choisir comment lui donner vie.
Un positionnement Design First plus fort que jamais
Étoffer notre stack pourrait donner l’impression que Studio Relief devient plus technique. Et c’est bien réel, mais cette évolution ne relègue pas pour autant le design au second plan. Bien au contraire, cela nous permet de l’appliquer avec davantage de latitude. Notre positionnement Design First est donc plus assumé que jamais.
Webflow offre un terrain de création très large, mais il possède forcément ses propres règles. Lorsqu’une expérience sort de ce cadre, il faut parfois simplifier une interaction, adapter la structure du contenu, empiler du code personnalisé ou faire appel à un service supplémentaire. Ce ne sont pas toujours des blocages. Ce sont plutôt de petits compromis qui, mis bout à bout, peuvent légèrement impacter les performances et l’expérience.
Astro et Next.js nous donnent davantage de liberté. Avec Astro, nous pouvons construire nos composants sans dépendre de ceux proposés par une plateforme, contrôler précisément le JavaScript envoyé au navigateur et protéger la performance dès l’architecture. Avec Next.js, nous pouvons prolonger une direction artistique dans des expériences plus applicatives, avec des comptes, des données personnalisées ou une logique métier plus présente. Nous pouvons ainsi pousser une idée plus loin, sans l’arrêter à la frontière de l’outil.
Sanity ouvre la même liberté du côté des équipes qui feront vivre le site. Le back-office peut être conçu autour de leurs vrais besoins, avec ses propres champs, blocs, relations et règles de publication. L’édition visuelle et la prévisualisation restent possibles, mais dans un environnement construit pour le projet. Le Design First ne concerne donc plus seulement ce que les visiteurs voient. Il s’étend aussi à l’expérience des personnes qui utilisent le site au quotidien.
Cette ouverture rapproche design et développement : les composants, les animations et les règles du système peuvent évoluer ensemble, de la maquette à la mise en ligne. Les besoins techniques, le budget et la maintenance restent déterminants, mais le design est présent dans chaque arbitrage, jusqu’au résultat final.
