Silex vs Webstudio : connecter un site à un CMS, honnêtement

Si vous concevez des sites web visuellement et que vous voulez y afficher du vrai contenu issu d'un CMS, vous cherchez la même chose que beaucoup de monde aujourd'hui : un outil de design web visuel qui construit des pages à partir de données réelles, pas de lorem ipsum. Silex, Webstudio et Webflow appartiennent tous à cette famille d'outils de création web visuels et no-code. Cet article compare la façon dont Silex et Webstudio relient un site à vos données, et ce que ce choix coûte vraiment sur le long terme.

Nous avons écrit sur cette idée de « design sur données réelles » quand nous avons reconstruit Silex de zéro. Pour le contexte, lisez Pourquoi Silex v3 : en résumé, un éditeur de site moderne devrait permettre de glisser-déposer des listes, des textes et des images, puis de concevoir les pages avec le contenu qui vit dans votre CMS, le tout sur une base logicielle libre et open source.

Ce que « connecter un CMS » veut vraiment dire

Aucun de ces deux outils ne vous demande de coder l'intégration à la main. L'idée est la même dans les deux cas : vous gardez votre contenu dans un backend que vous appréciez déjà (WordPress, Strapi, Directus, un CMS headless, une base de données avec une API), et l'éditeur visuel devient le front-end. Vous concevez une mise en page une fois, vous pointez un composant vers un champ de contenu, et l'outil répète et remplit cette mise en page à partir de vos données.

Mais avant que tout cela fonctionne, il y a une question qu'on saute souvent : comment l'outil sait-il qu'une page a un titre, ou qu'un bloc « hero » contient une image et deux textes ? C'est le vrai cœur de la connexion d'un CMS, et il vaut la peine de s'y attarder.

Le modèle de contenu vient d'abord

Tout site piloté par les données repose sur un modèle de contenu : la forme de vos données. Un blog peut avoir un type Post avec un title, un body, une date publishedAt et un groupe hero qui contient une image et deux champs texte. Cette structure ne vit pas dans l'éditeur visuel. Elle vit dans votre CMS : champs personnalisés WordPress, type de contenu Strapi, collection Directus, table de base de données. Le CMS définit les champs ; l'outil visuel les lit et vous laisse associer chaque champ à un composant.

Les deux outils découvrent ce modèle de façons différentes.

Silex se connecte à une source de données GraphQL et introspecte son schéma. Comme GraphQL décrit ses propres types et champs, Silex sait à l'avance qu'un Post a un title, que hero contient une image et deux textes, et ainsi de suite. Ces champs apparaissent comme des tokens que vous choisissez par autocomplétion pendant que vous construisez. En langage Silex, un token est une propriété de la source de données, par exemple post.data.attributes.title. Vous liez ensuite un token à un composant : déposez le token hero.image dans le src d'une image, mettez title dans le contenu d'un titre, et ainsi de suite. Silex applique ces liaisons sur des propriétés comme innerHTML, src, href, alt, class et style. Voyez la page Silex CMS basics pour le modèle complet.

Webstudio découvre le modèle à partir des données qu'il récupère. Vous créez une Resource (une requête HTTP vers votre CMS ou API), et les champs de la réponse deviennent des variables que vous pouvez lier. On accède à un champ imbriqué en tapant un point, comme CMS Data.title, et l'éditeur autocomplète les enfants. La forme vient de votre requête et du JSON qui revient, donc en pratique votre requête GraphQL ou votre endpoint REST définit quels champs sont disponibles à lier. Webstudio documente cela dans son guide data variables.

À retenir : aucun des deux outils n'invente votre modèle de contenu. Votre CMS en est propriétaire. Silex l'apprend en lisant le schéma GraphQL ; Webstudio l'apprend en lisant la réponse d'une Resource. Dans les deux cas, le travail que vous faites dans l'éditeur consiste à associer des champs à des composants visuels.

Lier des champs et construire de vraies expressions

Associer un seul champ à un seul composant, c'est le cas facile. Les vrais projets ont besoin de valeurs composées : un texte alt qui aide le référencement, un permalien construit à partir d'un nom de page, un libellé qui mêle une date et un préfixe. Les deux outils ont un éditeur d'expressions pour ça, et ils prennent des routes différentes.

Silex construit les expressions à la manière no-code, en cliquant. Une expression est faite de tokens, et vous pouvez faire passer ces tokens à travers des filtres Liquid pour les transformer. Silex écrit les expressions sous une forme lisible comme object > property | filter: option1, option2. Deux exemples concrets :

• Un attribut alt favorable au référencement qui donne « nom de l'image plus titre de la page » : prenez le token du nom de l'image, puis chaînez un filtre qui ajoute le token du titre de la page. Vous composez les deux morceaux dans l'éditeur, et Silex assemble la chaîne finale.
• Un permalien construit à partir du nom de page : prenez le token page name et faites-le passer par un filtre d'encodage d'URL pour que le résultat soit sûr dans une URL.

Le détail important : vous n'écrivez jamais de Liquid vous-même. Silex génère le Liquid en coulisses et expose les filtres Liquid dans l'éditeur d'expressions comme des options que vous choisissez et configurez. Vous n'avez pas besoin de connaître le langage de templating pour construire ces expressions. Les filtres peuvent même prendre d'autres tokens en arguments, ce qui permet de combiner plusieurs champs en une seule valeur.

Webstudio utilise un sous-ensemble restreint et sûr de JavaScript dans son éditeur d'expressions. Vous concaténez des valeurs avec + ou avec des littéraux de gabarit, et vous avez accès à des méthodes de chaîne sûres comme toLowerCase, replace, slice et split. Les deux mêmes exemples à la façon de Webstudio :

• Le texte alt : CMS Data.imageName + " " + Page.title, ou un littéral de gabarit qui place les deux variables dans une seule chaîne.
• Le permalien : prenez la variable du nom de page et appliquez-lui des méthodes de chaîne (mise en minuscules, remplacement des espaces) pour produire un slug propre.

Les deux approches permettent de construire des expressions composées et réalistes. Silex s'appuie sur des tokens visuels et des filtres Liquid pour qu'aucun code ne soit nécessaire ; Webstudio s'appuie sur une syntaxe familière proche du JavaScript. Aucune n'a tort. Choisissez celle qui correspond à votre façon de travailler.

Comment Webstudio se connecte à un CMS

La position de Webstudio est rafraîchissante de clarté : il ne fournit pas de CMS. Il se présente comme « connectez-vous à n'importe quel CMS headless, visuellement », et il le pense vraiment. Webstudio est un front-end visuel pour n'importe quel backend qui parle HTTP.

La brique de base est la Resource décrite plus haut : une variable dont la valeur vient d'un fetch HTTP. Cela peut être un simple appel REST ou une Resource GraphQL dédiée avec sa propre requête, ses variables et ses en-têtes. Comme REST est pris en charge nativement, vous pouvez brancher un éventail énorme de services sans passerelle intermédiaire. Webstudio documente plus de 20 intégrations, dont WordPress, Drupal, Strapi, Sanity, Contentful, Hygraph, Directus, Payload, Ghost, Notion, Airtable et Baserow, et en pratique tout ce qui a une API HTTP est jouable.

À partir de là, le modèle visuel est solide. Les pages dynamiques utilisent des paramètres de chemin (/post/:slug). Les Collections imbriquées répètent un composant par élément. L'éditeur d'expressions lie les champs du CMS aux champs des composants, avec conditions et valeurs de repli, et permet même d'insérer des valeurs dynamiques en ligne dans du texte par ailleurs statique. L'authentification passe par les en-têtes, la pagination gère à la fois l'offset et le curseur, et vous pouvez piloter une page 404 depuis une expression. C'est un vrai travail de routage dynamique et de liaison de données, mature.

Le modèle d'exécution est la chose à comprendre. Les sites Webstudio récupèrent les données au moment de la requête, sur des Cloudflare Workers, avec un cache en périphérie selon les en-têtes de cache de votre propre CMS. Le contenu est donc quasi en direct : modifiez-le dans le CMS et il apparaît sans rebuild. Le compromis, c'est que ce n'est pas un build statique : la page dépend de cette couche d'hébergement et de la disponibilité de votre CMS quand un visiteur arrive. Une autre limite bonne à connaître : le texte enrichi peut embarquer du HTML ou du Markdown, mais vous ne pouvez pas placer de composants Webstudio en ligne à l'intérieur du texte enrichi du CMS.

Sur l'ouverture, Webstudio est honnête, et nous devrions l'être aussi. L'éditeur est en AGPL et peut être auto-hébergé via Docker. Mais la plateforme est en open-core : auto-héberger l'éditeur en production est décrit comme « non recommandé », et en pratique vous êtes orienté vers Webstudio Cloud sur Cloudflare. Vous pouvez exporter un site comme application Remix/React, ce qui est une sortie propre et portable, ou le pousser en un clic vers leur cloud.

Rendons à César ce qui lui appartient : REST natif, contenu en direct, une expérience de liaison soignée et un export Remix propre font de Webstudio un bon outil. Rien de ce qui suit n'enlève à sa qualité.

Comment Silex se connecte à un CMS

Silex aborde le même problème par l'autre bout. Sa couche de données est GraphQL d'abord : vous ajoutez une source de données dans la boîte de dialogue des réglages, Silex introspecte le schéma, et vos champs s'autocomplètent comme des tokens pendant que vous construisez. Vous liez ensuite le contenu, les attributs, les classes ou la visibilité d'un composant à ces tokens, visuellement. Les états des champs contrôlent ce qui est produit et ce qui reste interne : les états hidden aident à construire d'autres expressions et à façonner la requête générée sans être rendus, les états public exposent des valeurs réutilisables, et les états private portent des données propres à un élément comme innerHTML, src ou href. Vous obtenez des boucles et des collections avec offset, limite et tri.

Les pages de collection de Silex suivent le modèle popularisé par Webflow, où un même design génère plusieurs pages à partir d'une liste, chacune avec sa propre URL et son propre SEO. Si vous connaissez Webflow, sa façon de structurer et styliser les pages de collection vous semblera familière. Dans Silex, les pages de collection sont pilotées par l'objet de pagination d'11ty, que vous atteignez aussi via l'éditeur d'expressions.

REST n'est pas natif ici. Si votre backend ne parle que REST, vous l'enveloppez avec une couche comme GraphQL Mesh ou Graphweaver pour l'exposer en GraphQL. C'est un vrai travail de mise en place, et c'est le coût honnête de l'approche de Silex. Côté positif, n'importe quelle API GraphQL fonctionne : WordPress via WPGraphQL, Strapi, Squidex, Directus, KeystoneJS et Supabase (attention à la mise en garde CORS).

La différence clé, c'est le modèle de build. Quand vous publiez, Silex génère des pages et des fichiers de données Eleventy (11ty) qui interrogent votre API au moment du build. Le build lui-même tourne en CI, sur des pipelines GitLab, et produit un site statique simple : du HTML que vous pouvez déployer n'importe où. La plupart des gens ne pensent jamais à cette étape de build ; elle se lance simplement quand vous cliquez sur publier. Les utilisateurs avancés peuvent s'y intéresser, car c'est là qu'on ajoute des plugins 11ty ou qu'on personnalise le build, mais vous n'avez pas besoin d'y toucher pour publier un site normal. Votre CMS est interrogé pendant le build et n'est *pas exposé du tout au runtime*. Personne qui visite le site ne touche votre CMS ni une quelconque fonction serveur en direct. Cela signifie une meilleure sécurité (aucun endpoint de données en direct à attaquer), de fortes performances (fichiers statiques sur n'importe quel hébergeur ou CDN) et une pile complètement standard et portable : Eleventy plus GraphQL, sans runtime propriétaire.

Le revers mérite d'être dit franchement. Le contenu n'est aussi frais que votre dernier build, donc les mises à jour en direct impliquent de déclencher un rebuild, généralement via un webhook. Il y a un peu plus de configuration au départ, et l'écosystème et la doc sont plus petits que ceux d'un concurrent financé par du capital-risque. Vous pouvez essayer tout le flux dans l'éditeur Silex avant de vous engager, et il existe un court guide pour démarrer avec un CMS qui construit une liste en direct à partir d'une API GraphQL publique en quelques clics.

Là où Silex est intransigeant, c'est sur la propriété. Il est entièrement libre, en AGPL, sans piège open-core : pas de palier premium, pas de CLA, aucune fonctionnalité retenue pour un cloud payant. Il est porté par l'association à but non lucratif Silex Labs, existe depuis 2009, et chaque fonctionnalité est gratuite. Quand nous disons « libre », nous parlons de liberté, pas seulement de gratuité.

Voir ça en action

Lire sur la liaison de données ne mène qu'à un certain point. Deux courtes vidéos sur la chaîne Silex montrent le workflow de bout en bout :

• Silex Quick Start : créez et publiez votre premier site
• L'éditeur Silex : visite guidée

D'autres démonstrations vivent sur la chaîne vidéo Silex, et la doc écrite couvre la fonctionnalité CMS, les concepts de base et un guide d'intégration Supabase. Les développeuses et développeurs qui veulent personnaliser le build peuvent lire la doc développeur du CMS Silex.

Côte à côte

	Webstudio	Silex
Source du modèle de contenu	Le CMS le définit ; lu depuis la réponse d'une Resource	Le CMS le définit ; lu via l'introspection du schéma GraphQL
Découverte des champs	Variables issues du JSON récupéré, autocomplétion par point	Tokens issus du schéma, autocomplétion pendant la construction
Protocole de données	REST et GraphQL, tous deux natifs	GraphQL natif ; REST nécessite une passerelle (Mesh/Graphweaver)
Portée CMS	Toute API HTTP, plus de 20 documentées	Toute API GraphQL (WPGraphQL, Strapi, Squidex, Directus, KeystoneJS, Supabase)
Expressions	Sous-ensemble de JavaScript, + et littéraux de gabarit, méthodes de chaîne sûres	Tokens no-code passés dans des filtres Liquid, aucun Liquid à écrire
Quand les données sont récupérées	Au moment de la requête, en périphérie	Au moment du build, en CI (GitLab)
Sortie	Application dynamique sur Cloudflare Workers ; export Remix/React	Site HTML statique, déployable partout
Fraîcheur du contenu	Quasi en direct	Aussi fraîche que le dernier build (rebuild via webhook)
Routage et pagination	Routes dynamiques, offset et curseur, 404 pilotée par expression	Pages de collection (façon Webflow) avec SEO, offset/limite/tri
Texte enrichi	Embarque HTML/Markdown, pas de composants en ligne	Lié via expressions et filtres
Dépendance au runtime	Dépend de la couche d'hébergement et du CMS en direct	Aucune ; le CMS n'est jamais exposé au runtime
Modèle de licence	Open-core (éditeur AGPL, auto-hébergement en prod déconseillé)	Entièrement libre AGPL, sans open-core, à but non lucratif
Coût	Palier gratuit plus cloud payant	Toutes les fonctionnalités gratuites

Qui devrait choisir quoi

Optez pour Webstudio si le REST natif compte pour vous, si vous avez besoin que le contenu apparaisse en direct dès qu'il change, ou si vous voulez le routage dynamique et la pagination les plus matures d'emblée et que tourner sur leur cloud ne vous dérange pas. C'est un outil capable et bien construit, et pour un site marketing adossé à un CMS headless qui change toutes les heures, son modèle de fetch au runtime est un vrai avantage.

Optez pour Silex si vous voulez un site statique que vous pouvez héberger littéralement n'importe où, si vous tenez à ce que votre CMS ne soit jamais exposé au public au runtime, et si vous voulez un outil que vous possédez entièrement, sans palier premium prêt à verrouiller la fonctionnalité dont vous aurez besoin l'an prochain. Si votre contenu change à un rythme humain plutôt qu'à la minute, un flux « rebuild à la publication » est un bon compromis pour cette robustesse et cette indépendance.

Une conclusion sous le signe du logiciel libre

La distinction honnête et centrale est celle-ci : Silex est statique d'abord, récupère les données au moment du build et est entièrement libre ; Webstudio fait du fetch au runtime en périphérie, atteint une surface « n'importe quel CMS » plus large et est en open-core. Silex échange le REST natif et le confort du contenu en direct contre la propriété, la portabilité et la robustesse du statique. C'est un vrai compromis, et pour certains projets, le côté de Webstudio est le bon choix.

Mais open-core et entièrement libre ne sont pas la même chose, et la différence n'a rien d'académique quand vous choisissez un outil dont vous allez *dépendre*. Open-core signifie que l'éditeur décide où s'arrête l'édition gratuite et où commence la payante, et cette ligne peut bouger. C'est un risque au cas par cas, pas une accusation, et Webstudio est transparent sur le fonctionnement de sa plateforme. Reste qu'un outil entièrement libre et porté par une communauté ne peut pas être discrètement racheté, fermé ou enfermé derrière un nouveau paywall. Vous gardez le code source, vous gardez le site, vous gardez le contrôle.

C'est pour ça que nous construisons Silex comme nous le faisons. Pas parce qu'« open source » est un joli badge, mais parce que la liberté d'exécuter, d'étudier, de modifier et de partager le logiciel est ce qui protège réellement la personne qui en dépend. Si cela compte pour vous, essayez l'éditeur, lisez la doc, regardez les vidéos et venez dire bonjour dans la communauté. Et si Webstudio convient mieux à votre projet, c'est aussi une bonne issue. Choisir ses outils en connaissance de cause, c'est tout ce qui compte.