Builder.io : le Webflow headless ?

1) Webflow : super outil qui trouve ses limites à l’échelle

Vous avez sûrement déjà entendu parler de Webflow, l’un des outils no-code du moment comme Wix ou Squarespace, qui permet de créer des sites web en mode “drag-and-drop”, telle une diapositive sur Powerpoint. Webflow est très populaire auprès de nombreuses entreprise et startups comme Ornikar, Ksaar ou Fairly Made (Theodo recommande d’ailleurs l’utilisation Webflow !)

Pour rappel, l’une des grandes forces de Webflow est de permettre aux équipes non-techniques, comme le marketing, de créer et modifier les éléments et composants d’une page à travers son interface visuelle, que ce soit la couleur, la forme ou le contenu, la disposition, sans l’intervention d’une équipe technique et à un niveau très poussé.

                                Editeur visuel de Webflow

Webflow est un outil idéal pour créer des sites web simples avec un design très précis (par exemple : sites vitrines). Cependant, lorsqu'on aborde des projets plus complexes, comme des sites e-commerce nécessitant des fonctionnalités spécifiques ou de s’intégrer à d’autres solutions tiers (ERP, Marketing automation e-commerce, etc…), Webflow montre ses limites.

Sur l’un de mes projets, j’en avais rencontré quelques-un :

• Les fonctionnalités proposées par Webflow ne répondaient plus à mes besoins d’évolution, comme créer une fonctionnalité de personnalisation de vêtement.
• Lorsque je mets du code custom sur Webflow, je ne le vois pas sur son interface visuelle. Je dois d’abord publier la page pour voir à quoi cela ça va ressembler. C’est rapidement chronophage.

                            Voici à quoi un code custom intégré ressemble sur l’éditeur visuel de Webflow

• Il est difficile d’optimiser la performance web des 3rd parties intégrées à Webflow. Par exemple, lorsqu’on ajoute des outils d’Analytics comme Google Tag Manager ou Hotjar, cela ajoute des scripts Javascript dans le header, augmentant le temps de chargement des pages, et donc avoir un impact négatif sur le référencement naturel de votre site et l’expérience utilisateur.

Pour pallier ses limites, l’une des actions communes est de migrer de Webflow vers des CMS Headless offrant davantage de flexibilité et de solutions à ces problèmes, tels que des outils comme Strapi ou Contentful.

Personnellement, j'avais décidé de conserver Webflow pour ses fonctionnalités de CMS produit et contenu, mais de développer un front personnalisé et d'utiliser un back afin d'implémenter les nouvelles fonctionnalités que Webflow ne pouvait pas prendre en charge (cela correspond à faire du "Headless" pour les plus initiés d'entre vous).

J’ai pu créer les fonctionnalités souhaitées grâce à cette structure, mais il y avait plusieurs impacts :

• J'ai perdu l'accès à l'interface visuelle de Webflow qui me permettait de faire mes propres modifications du design. Je suis redevenu dépendant de l’équipe technique…
• Cela a nécessité de recréer complètement le design réalisé sur Webflow sur la nouvelle architecture, c’est dommage.

2) La DXCP : une réponse aux limites de Webflow ?

Et c’est là qu’arrive la DXCP (Digital Experience Composable Platform) !

Mais qu’est-ce que c’est ?

La Digital Experience Composition Platform (DXCP) est un type de CMS regroupant les avantages des CMS traditionnels et headless, grâce à une plateforme permettant de gérer et optimiser les expériences numériques sur divers canaux et appareils, en plus d’une interface visuelle intuitive.

La DXCP réunit le meilleur du CMS traditionnel et du CMS Headless en 4 points :

• Fonctionnalité CMS standard : on y retrouve toutes les fonctionnalités essentielles à la gestion de contenu
• Séparation du front et du back (comme un CMS headless) : le front est totalement indépendant du back, permettant l’optimisation de chaque partie de façon indépendante
• Éditeur visuel intégré (comme un CMS standard) : fan de l’éditeur visuel de Webflow ? Vous pourrez l’avoir sur du headless !
• Intégration d'API multiples (comme du développement custom) : vous pourrez utiliser une ou plusieurs APIs (par exemple : Shopify, Strapi, Cloudinary, etc…) sur la même interface, directement dans des composants utilisables et modifiables via l’éditeur visuel de Webflow, ou via le code !

Pour les plus curieux d’entre vous, Pierre explique dans le détail et techniquement en quoi la DXCP est une révolution au niveau des CMS.

                 Fonctionnement de Builder.io via leur éditeur visuel

L'un des produits appartenant à cette mouvance DXCP est builder.io .

Builder.io est une solution de DXCP qui permet de développer des pages web, avec ou sans code, aussi bien par des développeurs que par des non-développeurs. A première vue, c’est un Webflow nativement “headless”, offrant la possibilité aux développeurs et aux équipes non-techniques de collaborer sur la même interface visuelle, tout en disposant d'un CMS.

Builder.io est notamment utilisé par des entreprises comme :

• Zapier
• Vistaprint
• Alo

J’ai donc décidé de creuser pour comprendre les différences entre Builder.io et Webflow.

3) Builder.IO : la collaboration technique et marketing à l’échelle

Très souvent, les entreprises avec des sites web custom, sont très dépendantes de leur équipe technique et/ou leur agence.

Pour les équipes non-techniques, les sujets UX/UI ou marketing sont souvent relégués au second plan par rapport aux aspects fonctionnels. Même pour de petites modifications (changement de couleur d’un bouton, changement de texte, agrandissement d’une image…), les équipes non-techniques restent dépendantes des équipes techniques.

La DXCP, et Builder.io particulièrement, se distingue par sa capacité à optimiser la collaboration entre les équipes techniques et non-techniques, tout en leur offrant la possibilité d'agir de manière autonome.

Par exemple, en tant que personne non-technique, je peux :

• Créer des sections et des composants directement via l’éditeur visuel et voir en direct le résultat de son image
• Prendre des composants, créés et codés par des développeurs, dans le framework de leur choix, puis les intégrer dans Builder, pour créer des pages ou des éléments aux normes de qualité design et techniques. Ils peuvent aussi les modifier directement dans l’éditeur visuel.

L’impact est :

• Les équipes non-techniques sont plus agiles et peuvent déployer plus rapidement des changements design/format, etc, sur les pages concernées en réduisant le lead time, sans compter sur les équipes techniques
• Les équipes non-techniques peuvent réutiliser du contenu et templates, de le personnaliser, de tester plusieurs variantes et itérer à l’échelle, tout en conservant des critères de qualité
• Avec une architecture Mach, Builder.io peut être déployé sur les pages sur lesquelles on veut profiter des avantages de Builder.io et laisser les pages plus tech à la main des concernés.
• L’équipe technique reste maître du code, étant la seule source de vérité.

Il existe tout de même quelques défauts à builder.io :

• Les fonctionnalités sur l’interface visuelle de Builder.io n’est pas aussi complète que Webflow (ex : les animations sont très basiques sur Builder par rapport à Webflow)
• Builder.io facture par utilisateur, tandis que Webflow propose des tarifs basés sur le site
• Builder.io est principalement destiné aux entreprises avec une équipe technique bien structurée, alors que Webflow est beaucoup plus orienté vers les utilisateurs non-techniques.
• Par son manque de maturité, Builder.io manque de documentation technique, notamment sur l’intégration de plugins comme Shopify ou Cloudinary, mais aussi sur les SDK
• Contrairement à un CMS classique, Builder.io ne permet pas d'isoler précisément les champs qui peuvent être modifiés ou non par différents utilisateurs. Cette restriction signifie que tous les utilisateurs ayant accès à un contenu peuvent potentiellement modifier tous les champs de ce contenu, sans distinction. Cela peut poser des problèmes de sécurité et de contrôle de qualité, notamment dans des environnements où les responsabilités éditoriales sont partagées entre plusieurs personnes ou équipes.

Par ailleurs, DXCP a aussi des fonctionnalités standard du CMS (et plus encore !) :

• Figma to code
• Génération composant par IA
• Analytics
• A/B Test
• Gestion SEO
• Contenus dynamiques…

4) Webflow vs Builder : pour qui ?

Je conseille Webflow pour :

1. Les startups et petites entreprises : idéal pour ceux qui cherchent à créer des sites web simples comme des sites vitrines ou des blogs sans e-commerce.

2. Les entreprises sans équipe technique : permet aux équipes non-techniques de créer et modifier des éléments de pages via une interface visuelle intuitive sans dépendre des développeurs.

Je conseille Builder.io pour :

1. Les entreprises avec des besoins de personnalisation et d'intégration à l’échelle : idéal pour les entreprises nécessitant une approche headless, permettant de séparer le backend et le frontend tout en conservant une interface visuelle pour les équipes non-techniques.

2. Les entreprises ayant une équipe technique structurée, ayant une volonté d’améliorer la collaboration entre équipes techniques et non-techniques : les développeurs peuvent utiliser le framework de leur choix pour coder des composants et des pages, tandis que les équipes non-techniques peuvent les modifier via l'interface visuelle.

3. Projets nécessitant une refonte pour obtenir une flexibilité maximale et une indépendance bilatérale : permet aux équipes non-techniques de déployer rapidement des changements de design ou de contenu sans attendre l'intervention des développeurs.

   • Exemple : Une architecture Mach permet de déployer Builder.io sur certaines pages tout en laissant les pages plus techniques aux développeurs.

Il est important de noter que la plupart des CMS actuels évoluent vers la DXCP, en intégrant notamment un éditeur visuel directement dans le front personnalisé. Shopify en est un excellent exemple !