Builder.io : le Webflow headless ?

Webflow : un très bon 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 entreprises et startups, comme Ornikar, Ksaar ou Fairly Made. D'ailleurs, Theodo recommande l’utilisation de 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 à un niveau avancé grâce à son éditeur visuel, sans l’intervention d’une équipe technique.

                                Editeur visuel de Webflow

Webflow est un outil idéal pour créer des sites web simples avec un design précis, comme des 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 à des solutions tiers (ERP, Marketing automation e-commerce, etc…), Webflow montre ses limites.

J'ai notamment rencontré 2 limites :

• Les fonctionnalités proposées par Webflow ne répondaient plus à mes besoins d’évolution. Par exemple, j'avais besoin de créer une interface utilisateur interactive permettant aux clients de personnaliser des produits en temps réel, mais Webflow ne permettait pas de réaliser cela avec les composants disponibles.
• Lorsque j'utilisais du code custom sur Webflow, je ne le voyais pas sur son interface visuelle. Je devais d’abord publier la page pour voir à quoi cela ça allait ressembler. C’était 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 third parties intégrés à Webflow. Par exemple, lorsque j'ajoutais des outils d’analytics comme Google Tag Manager ou Hotjar, cela ajoutait des scripts Javascript dans le header, augmentant le temps de chargement des pages, et cela avait donc un impact négatif sur le référencement naturel du site et l’expérience utilisateur.

Pour pallier ces limites, l’une des actions est de migrer de Webflow vers des CMS Headless offrant davantage de flexibilité, tels que Strapi ou Contentful.

Personnellement, j'avais décidé de conserver Webflow comme un CMS Headless, mais j’ai dû aussi développer un front personnalisé et utiliser un back afin d'implémenter les nouvelles fonctionnalités que Webflow ne pouvait pas prendre en charge.

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.

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

Mais qu’est-ce que c’est ?

La DXCP et Builder : une réponse aux limites de Webflow ?

La 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.

L'un des produits appartenant à cette mouvance DXCP est Builder.io, 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.

                      Editeur visuel de Builder.io

Builder.io est notamment utilisé par des entreprises comme Zapier, Vistaprint ou Alo.

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

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

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 ce que l'on produit.
• Prendre des composants créés et/ou codés par des développeurs dans le framework de leur choix, puis les intégrer dans Builder.io, pour créer des pages ou des éléments aux normes de qualité design et techniques. Je peux aussi les modifier directement dans l’éditeur visuel.

Cela crée un impact significatif sur la collaboration au sein des équipes pour le développement de fonctionnalités :

• 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 temps de traitement, sans dépendre des équipes techniques.
• Les équipes non-techniques peuvent réutiliser du contenu et templates, les personnaliser, 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 ses avantages et laisser les pages plus tech à l'équipe dédiée.
• L’équipe technique reste maître du code, étant la seule source de vérité.

                 Fonctionnement de Builder.io via leur éditeur visuel

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

• Les fonctionnalités sur l’interface visuelle de Builder.io ne sont pas aussi complètes que Webflow. Par exemple, les animations proposées par Builder.io sont très basiques par rapport à Webflow)
• Builder.io est récent et manque donc de documentation technique, notamment sur l’intégration de plugins comme Shopify,Cloudinary ou 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, Builder.io a aussi des fonctionnalités standard d'un CMS (et plus encore !) :

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

Webflow vs Builder : pour qui ?

Webflow et Builder.io sont deux solutions qui se distinguent par leurs approches différentes, tout en répondant à des besoins similaires.

Je conseille Webflow pour :

1. Les projets de sites web simples comme des sites vitrines ou des blogs sans e-commerce.

2. Les projets qui ne veulent pas dépendre des équipes techniques, permettant de créer et modifier des éléments de pages via une interface visuelle intuitive.

Je conseille Builder.io pour :

1. Les projets 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. Les projets nécessitant une refonte pour obtenir une flexibilité maximale et l'autonomie des équipes : permet aux équipes non-techniques de déployer rapidement des changements de design ou de contenu sans attendre l'intervention des développeurs. Par exemple, une architecture Mach permet de déployer Builder.io et ses fonctionnalités sur une page comme la page d'accueil ou une bannière publicitaire, tout en laissant les pages plus techniques aux développeurs.

En résumé, la DXCP représente une évolution naturelle des CMS classiques intégrant notamment un éditeur visuel directement dans le front personnalisé afin d'améliorer la collaboration entre équipes techniques et non-techniques.

Les CMS suivent déjà cette voie, Shopify en est un bon exemple avec Hydrogen et il ne serait pas surprenant que Webflow suive cette tendance pour attirer des entreprises de plus grande envergure.

Builder.io, quant à lui, est né dans la mouvance DXCP, ce qui en fait un produit natif de cette évolution.

Hâte de voir dans quelques années ce qu'ils deviendront !