Vous dirigez le marketing d'une PME B2B et quelqu'un vous a proposé de refaire le site en Webflow. La promesse est séduisante : votre équipe modifiera les pages elle-même, sans attendre un développeur. Elle tient souvent. Mais un site Webflow B2B que l'équipe fait vivre seule se décide surtout avant la première maquette, dans la façon de répartir les rôles et de préparer les contenus.
J'ai conçu et développé des sites en Webflow pour des clients B2B, et j'ai aussi fait le choix inverse : en mai 2026, j'ai refait en Next.js et Sanity le site de Moonworkers, mon entreprise (présentée parmi mes missions), et ce site-ci est construit de la même façon. Voici comment je décide, et comment j'organise un site Webflow quand c'est le bon outil.
01Ce que Webflow fait bien pour un site B2B
Un site B2B a des besoins assez stables : des pages d'offre, des études de cas, un blog, des formulaires de contact ou de démo, parfois deux langues. Webflow couvre tout cela sans développement, avec un CMS pour les contenus qui se répètent et un éditeur visuel pour le reste.
Ce qui m'intéresse le plus, c'est la séparation des rôles. Webflow distingue celui qui gère le site, celui qui dessine, celui qui assemble des pages et celui qui écrit. D'après le centre d'aide de Webflow sur les rôles de site, un « Marketer » crée et modifie des pages à partir de composants existants, un « Content editor » modifie les contenus, et ni l'un ni l'autre ne crée de composant ou de classe. Pour une équipe marketing, c'est exactement le bon partage : la liberté de publier, sans la possibilité de casser la charte par accident.
Le fond, lui, ne dépend pas de l'outil. Une étude ancienne de Nielsen Norman Group mesurait 58 % de réussite des tâches sur les sites B2B, contre 66 % sur les sites grand public (Jakob Nielsen, B2B Usability, 2006). Les causes citées n'ont pas vieilli : aucune idée du coût, des formulaires imposés trop tôt, des rubriques découpées selon l'organisation interne plutôt que selon la façon dont les clients se voient. Webflow ne règle rien de cela tout seul. Le plan du site, si.
02Décider qui touche à quoi avant de dessiner les pages
Le scénario que je cherche à éviter est connu : tout le monde a le même accès, chacun ajoute sa section, sa couleur, son style de bouton, et quelques mois plus tard le site ne ressemble plus à sa maquette. Je règle donc les rôles avant de dessiner, et je les écris dans le cahier des charges.
Les quatre décisions que je prends en premier
- Qui gère le site : une ou deux personnes, pas plus. Ce sont elles qui ont accès au code personnalisé, que le centre d'aide de Webflow réserve aux rôles Site manager et Designer.
- Qui dessine : la personne qui crée les composants, les classes et les variables. Si c'est moi pendant la construction, je prévois qui reprend ce rôle après mon départ.
- Qui assemble les pages : le rôle Marketer, pour l'équipe qui lance une page de campagne ou une page d'événement à partir des blocs prévus.
- Qui écrit et qui publie : les rédacteurs prennent le rôle Content editor, et je décide avec vous qui a le droit de publier le site entier. Webflow permet d'activer ou non ce droit selon les offres.
La vidéo officielle de Webflow sur l'édition de contenu présente justement ce point de vue : ce qu'un rédacteur peut changer (textes, images, contenus du CMS, réglages SEO) sans casser la mise en page. Je n'ai pu en lire que la description et les chapitres, la transcription ne s'étant pas chargée, mais c'est bien le partage que je cherche.
Cette répartition oblige à fabriquer de bons composants. Si l'équipe ne peut assembler que des blocs existants, il faut que ces blocs couvrent ses vrais besoins : un bandeau de preuve, une grille de logos, un tableau comparatif, un bloc d'appel à l'action. Je les liste avec l'équipe, à partir des pages qu'elle a publiées l'an dernier.
03Le CMS, les formulaires et les langues
Trois sujets se découvrent souvent trop tard sur un site Webflow B2B.
Le CMS d'abord. Tout ce qui se répète (articles, études de cas, offres d'emploi, fiches produit) va dans des collections, avec des champs pensés à l'avance. Webflow propose une API qui permet de créer, de gérer et de publier ces contenus depuis un autre outil, et un élément créé par l'API arrive toujours en brouillon avant publication (Webflow, documentation de l'API CMS). C'est utile si vous comptez automatiser la publication un jour : j'ai expliqué dans un autre article pourquoi la mise en ligne est souvent le vrai goulot, avant l'écriture.
Les formulaires ensuite. Un site B2B vit de ses demandes de contact, et elles doivent arriver proprement dans le CRM. J'ai détaillé les trois façons de le faire dans l'article sur l'intégration de HubSpot à un site. Sur Webflow, je décide tôt si le formulaire est celui de Webflow, celui du CRM intégré dans la page, ou un envoi par API, parce que ce choix touche aussi le consentement.
Les langues enfin. Webflow gère une langue principale et des langues secondaires. Sa documentation sur la localisation précise qu'un contenu du CMS traduit garde le même identifiant dans chaque langue, et que par l'API, les pages et composants ne se mettent à jour que dans les langues secondaires. Côté référencement, Google demande que chaque version d'une page liste toutes les autres, elle comprise, et ignore les balises hreflang qui ne pointent pas dans les deux sens (Google Search Central, versions localisées d'une page). Je vérifie toujours ce point sur le site publié, pas dans l'outil.
04Ma façon de lancer un site Webflow B2B
Voici l'ordre que je suis. Il ressemble beaucoup à celui d'un site développé, et c'est voulu.
Avant le design
- Je liste les pages et les types de contenu, avec la personne qui mettra chacun à jour.
- Je reprends le parcours d'un acheteur B2B : ce qu'il cherche en premier, ce qui le fait demander un rendez-vous, ce qui le fait partir.
- Je fixe les rôles, comme décrit plus haut, et je les note dans la spécification.
Pendant le design
- Je montre plusieurs directions de maquette au même niveau de finition. Sur une mission, c'est ce qui a débloqué une décision qui tournait en rond : des pistes aussi abouties les unes que les autres, qu'on pouvait vraiment comparer. Pour les parcours complexes, je passe par un prototype cliquable avant le développement.
- Je construis les composants et les styles avant les pages, puis les pages à partir des composants.
Avant la mise en ligne
- Je branche les formulaires et je fais un envoi réel jusqu'au CRM.
- J'écris la table des redirections si le site remplace un ancien site.
- Je vérifie le site publié comme un visiteur : navigation privée, sans session, sur l'adresse publique. Sur un autre projet, j'ai vu un site qui paraissait normal à l'équipe connectée et qui était cassé pour les visiteurs. Depuis, je ne valide plus rien depuis l'éditeur.
- Je forme l'équipe sur son rôle à elle, avec une page de test qu'elle peut casser sans risque.
05Quand je ne choisis pas Webflow
Je préfère le dire franchement. Pour Moonworkers, j'ai choisi Next.js et Sanity, et je l'ai raconté dans l'article sur la migration d'un site vers Next.js et Sanity. Le site devait porter des calculateurs que je voulais écrire et tester comme du code, et une machine de contenu publie automatiquement des articles. Ce blog fonctionne de la même façon : mes articles partent dans Sanity par un outil, avec un contrôle avant publication.
Je ne prends pas Webflow non plus quand le site ressemble à une application : espace client, logique métier lourde, données qui viennent d'un ERP en continu. Et je déconseille de forcer Webflow à faire ce qu'il ne fait pas avec des empilements de scripts : chaque script ajouté devient du code à maintenir, et le rôle Designer qui le gère doit savoir ce qu'il fait.
À l'inverse, si votre équipe change la page d'accueil toutes les semaines, teste des variantes et veut lancer une page de campagne le jour même, Webflow lui laissera une autonomie qu'un site développé lui retirerait. Je ne crois pas qu'un des deux soit meilleur dans l'absolu. Je regarde surtout qui fera vivre le site dans deux ans.
06Par où commencer cette semaine
Avant de commander une maquette, je vous propose trois choses simples. Listez les pages que votre équipe a créées ou modifiées ces douze derniers mois, et qui les a faites. Écrivez qui, demain, devra pouvoir publier seul, et qui ne doit surtout pas toucher au design. Puis relisez votre site actuel avec les yeux d'un acheteur qui ne vous connaît pas : trouve-t-il en trois clics ce que vous faites, pour qui, et comment vous joindre ?
Avec ces trois listes, le choix entre Webflow et un site développé devient souvent évident. Si vous voulez un regard extérieur sur ce choix ou sur la construction elle-même, mes services décrivent comment je travaille. On peut en parler.