Sites statiques, données dynamiques : comment Silex relie vos contenus à un design visuel

Les sites statiques sont la façon rapide, sûre et sobre de publier sur le web. Mais ils traînent une réputation : « statique » sonne comme « figé », une pile de pages écrites à la main que personne, à part un développeur, ne saurait modifier. Cette réputation a pris un coup de vieux. Avec Silex, vous concevez une page visuellement, vous la branchez sur une source de données — un CMS headless ou n'importe quelle API — et vous publiez un site fait à 100 % de fichiers statiques, mais alimenté par des contenus que vos clients continuent d'éditer eux-mêmes.

C'est le mécanisme distinctif qui est au cœur de Silex, et il est générique : la même approche fonctionne que vos contenus vivent dans WordPress, Directus, Supabase, Strapi, Squidex ou n'importe quelle API GraphQL. Cet article est le guide de fondation. Il explique ce qu'est une source de données, comment lier des champs, boucler sur une collection, générer une page par élément, gérer les slugs et permaliens sans plugin, et publier le tout sous forme de site statique qui se reconstruit tout seul quand le contenu change. Les guides appliqués, spécifiques à un CMS (comme WordPress headless avec Silex), reposent tous sur ce qui est décrit ici.

Le problème : le statique est rapide, mais le contenu bouge

Éditer le contenu directement dans un éditeur visuel convient très bien à un site d'une page ou à une petite plaquette. Cela craque dès qu'il y a du volume réel. Comme le résumait l'équipe Silex en direct : saisir 500 pages de contenu dans un outil de design « ce n'est tout simplement pas possible, c'est un cauchemar ». Votre client veut se connecter à un back-office qui lui est familier, ajouter un article, remplacer une image, remplir une section — et voir le site public se mettre à jour, sans toucher ni au design ni au code.

La réponse classique, c'est un CMS piloté par une base de données qui génère chaque page à chaque requête. Vous gagnez le contenu éditable, mais vous perdez précisément ce que le statique fait de mieux : la vitesse, une surface d'attaque réduite, une empreinte énergétique légère. Silex prend un autre chemin. Il garde le contenu éditable et la sortie statique, en séparant les deux et en ne les réunissant qu'au moment de la construction (le build).

L'idée centrale : brancher une source de données, construire des fichiers statiques

Voici tout le mécanisme en une phrase : Silex lit vos contenus depuis une source de données pendant que vous concevez, puis fige ces contenus dans de simples fichiers statiques au moment de publier.

Rien de dynamique ne tourne sur le serveur public. Le contenu est récupéré une seule fois, au moment du build, et écrit en HTML. Quand le contenu change, le site est reconstruit. Concrètement, le flux tient en quatre pièces :

1. Votre contenu vit dans un CMS headless ou une API. Articles, produits, membres de l'équipe, champs personnalisés — quelle que soit la donnée — elle reste dans l'outil que votre client utilise déjà.
2. Silex s'y connecte comme source de données. Dans les réglages du CMS, vous pointez Silex vers la source (une API GraphQL est le format natif ; les API REST peuvent y être passerellées). Silex lit le contenu disponible et sa structure, si bien que vous concevez sur de vraies données, pas sur des placeholders.
3. Vous liez des champs et définissez des boucles dans l'éditeur visuel. Vous choisissez quel élément affiche quel champ, et à quel endroit le site doit répéter un design le long d'une liste d'éléments.
4. La publication lance une construction statique. Silex génère le site avec Eleventy (11ty), qui télécharge exactement les données dont il a besoin et écrit des pages statiques. Le résultat est du HTML et du CSS standard, hébergeables n'importe où.

Comme le site publié n'est fait que de fichiers, vous récoltez tous les bénéfices du statique — et comme ces fichiers ont été générés depuis votre CMS, le contenu reste aussi éditable qu'avant.

Les deux mécanismes à comprendre

Tout ce que Silex fait avec les données se ramène à deux briques. Maîtrisez ces deux-là, et le reste en découle.

1. Les listes (boucles) : un design, répété par élément

Une boucle prend un seul élément que vous avez conçu — une carte, une ligne, un item de liste — et le répète une fois pour chaque entrée d'une collection. Vous construisez une carte, vous dites à Silex de la boucler sur votre liste d'articles (ou de produits, ou de continents, ou de membres de l'équipe), et au moment du build il produit une carte par entrée.

À l'intérieur de l'élément bouclé, vous liez les champs au contenu : ce titre affiche le titre de l'élément, cette image affiche sa photo, ce paragraphe affiche sa description. Vous pouvez aussi filtrer et trier la liste — n'afficher que les éléments publiés, ordonner par date, inverser l'ordre — le tout depuis l'éditeur. Un design en entrée, une liste complète en sortie.

2. Les pages de collection : une page, générée par élément

Une boucle répète un élément à l'intérieur d'une page. Une page de collection monte d'un cran : elle génère une page entière par entrée d'une collection. Vous concevez une seule page « article », vous l'attachez à votre collection d'articles, et Silex produit une page distincte — avec sa propre URL — pour chaque article.

C'est ainsi qu'on obtient un vrai site de contenu à partir d'un seul modèle : un design de page produit devient des centaines de pages produits, une mise en page d'article devient tout votre blog. Chaque page générée peut elle-même contenir des boucles (une page article qui liste les articles liés, une page catégorie qui liste ses produits), si bien que les deux mécanismes s'imbriquent naturellement.

Slugs et permaliens, sans plugin

Une page par élément n'a d'intérêt que si chacune a une URL propre et unique. Dans un CMS traditionnel, c'est le travail d'un plugin de permaliens. Dans Silex, c'est intégré.

Pour une page de collection, vous définissez le permalien à partir des données de l'élément lui-même. En général, vous prenez un champ — le nom ou le titre de l'élément — et vous le passez dans un filtre de slug qui retire les espaces et les accents et met en minuscules, de sorte que « Amérique du Nord » devient amerique-du-nord. Vous pouvez ajouter des barres obliques au début et à la fin pour façonner le chemin final, /amerique-du-nord/. La même valeur « sluggifiée » pilote aussi les liens entre pages : une carte dans une liste pointe vers sa page de détail en construisant le href à partir des données de l'élément, si bien que la navigation reste correcte quelle que soit la croissance du contenu. Pas de plugin, pas de gestion manuelle d'URL — les URL viennent du contenu lui-même.

Attributs dynamiques : liens, images, texte alternatif, SEO

La liaison ne se limite pas au texte visible. Dans Silex, vous pouvez alimenter n'importe quel attribut HTML depuis les données, et c'est ce qui donne à la sortie l'allure d'un vrai site construit à la main plutôt que d'un gabarit rempli :

• Liens — l'attribut href est construit à partir des données de l'élément (voir les permaliens ci-dessus).
• Images — l'attribut src est lié à un champ, si bien que chaque élément bouclé affiche sa propre image ; vous pouvez même construire l'URL d'un service d'images à partir d'un champ (un code pays qui pilote une image de drapeau, un identifiant produit qui pilote une photo).
• Texte alternatif et SEO — comme alt peut être une expression, chaque image générée reçoit une description propre et parlante au lieu d'une chaîne répétée, ce qui est bon à la fois pour l'accessibilité et le référencement. Idem pour le titre SEO, la description et l'image de partage social de chaque page : ce sont des champs que vous mappez, si bien que chaque page générée est optimisée individuellement.

Le build : le contenu figé, reconstruit au changement

Quand vous publiez, Silex lance une construction (sur GitLab CI, avec Eleventy). Le build va chercher votre source de données, télécharge seulement les données nécessaires, et écrit les pages statiques avec leur contenu. Un site avec une page par pays et une par continent, c'est quelques minutes de build pour un site statique complet et navigable.

La conséquence importante : une fois le build passé, le site en ligne est indépendant de la source. Si le CMS change, le site publié reste exactement tel qu'il était jusqu'au prochain build — ce qui est une fonctionnalité, pas un défaut, pour la stabilité et la sécurité. Pour refléter un nouveau contenu, vous reconstruisez, et cela peut être automatique : un webhook depuis votre CMS (par exemple un petit plugin sur WordPress) prévient le système de build que le contenu a changé, un nouveau build se lance, et quelques minutes plus tard le site en ligne porte les nouvelles données. Votre client édite dans son back-office, clique sur publier, et n'ouvre jamais Silex.

Pourquoi statique + données, plutôt qu'un CMS en direct

Séparer le design du contenu et construire du statique vous apporte quatre choses concrètes.

Vitesse. Aucun code serveur à exécuter ni base de données à interroger quand un visiteur arrive — les pages sont servies comme des fichiers.

Sécurité et faible maintenance. Sans rien de dynamique sur le serveur public, il n'y a presque rien à attaquer. Le CMS peut être restreint ou tenu hors de l'internet public ; le contenu sort vers le build, rien n'y revient. Un CMS en direct pas à jour est une cible ; un site statique, non.

Sobriété. Le coût énergétique du web est bien réel. Générer une page depuis une base de données à chaque visite, multiplié à l'échelle d'internet, finit par peser lourd. Construire une fois et servir des fichiers est nettement plus léger — et une base statique propre vous donne un socle solide pour des pages accessibles et respectueuses des standards.

Pas d'enfermement. Un site Silex, c'est du HTML et du CSS standard. Hébergez-le gratuitement sur GitLab Pages, sur du FTP, sur votre propre serveur, sur n'importe quel CDN. Aucun runtime propriétaire dessous, aucune plateforme qui retient votre site en otage. Votre contenu reste dans votre CMS ; vos pages restent portables.

Le même mécanisme, n'importe quel CMS

Comme la source de données n'est qu'une API, ce schéma n'est lié à aucun outil en particulier. Le mécanisme décrit ci-dessus est exactement ce qui anime notre guide appliqué WordPress headless avec Silex — WordPress comme back-office que vos clients connaissent déjà, Silex comme façade statique rapide. (Pour les champs personnalisés WordPress, nous privilégions Pods : entièrement libre, sous licence GPL, avec le support de WPGraphQL intégré.)

Remplacez WordPress par Directus, Supabase, Strapi, Squidex ou n'importe quelle API GraphQL et rien ne change à l'approche : connectez la source, liez les champs, bouclez, générez les pages de collection, construisez du statique. Choisissez le CMS dont votre projet a besoin ; Silex le lit de la même façon.

Quand statique + données n'est pas le bon choix

Cette approche est un compromis, pas une victoire gratuite. Soyons honnêtes sur les cas où elle ne convient pas :

• Interactivité en temps réel. Tout ce qui doit réagir à chaque visiteur au fil de l'eau — une recherche en direct sur un grand jeu de données, de la personnalisation à la volée, un chat en direct, un panier avec stock instantané — a besoin de code qui tourne au moment de la requête. Une façade statique vous compliquera la vie ici.
• Contenu propre à chaque utilisateur connecté. Si chaque visiteur doit voir une vue authentifiée différente (un tableau de bord membre, un espace de compte privé), cet état ne peut pas être figé au moment du build.
• Contenu qui doit se mettre à jour à l'instant même où il change. Un rebuild prend quelques minutes. Pour la plupart des sites, c'est invisible ; pour un tableau de score en direct ou un cours de bourse, non.
• Écritures très fréquentes depuis les visiteurs. Du contenu généré par les utilisateurs, soumis et affiché en continu, s'accorde mal avec un modèle « construire puis servir ».

Si l'un de ces cas est central à votre projet, une architecture dynamique rendue côté serveur est la recommandation honnête. Pour l'immense espace des sites de contenu — plaquettes, blogs, catalogues, portfolios, documentation, sites vitrines —, le statique avec une source de données est souvent le meilleur outil.

À voir en action

Alex Hoyau, créateur de Silex, déroule ce mécanisme entier en direct — source de données, boucles, pages de collection, permaliens, attributs dynamiques et build statique — aux côtés de Brice Martin, contributeur Silex de longue date et web designer travaillant avec le studio Internet 2000 :

Du CSS au CMS : créer des sites statiques à données dynamiques, avec Alex Hoyau (créateur et développeur principal de Silex) et Brice Martin (contributeur Silex, studio Internet 2000).

Pour finir, côté libre

Statique ne veut pas dire figé. Avec Silex, un site statique peut porter tout le contenu dynamique et éditable par le client d'un CMS piloté par base de données, tout en gardant ce que le statique a de bon : la vitesse, une surface d'attaque minuscule, une empreinte légère et des fichiers standard hébergeables n'importe où. Vous concevez une fois, vous liez votre contenu, et vous laissez le build faire le travail répétitif.

Et Silex est un logiciel libre — pas seulement « open source » au sens marketing. Il est sous licence AGPL et porté par l'association à but non lucratif Silex Labs, sans offre premium ni piège de l'open-core : chaque fonctionnalité est incluse, pour toujours. Cela compte pour un outil sur lequel vous bâtissez le travail de vos clients. Aucune entreprise ne peut le refermer en douce, clôturer la fonctionnalité dont vous aurez besoin l'an prochain, ou prendre votre site en otage — ce sont des fichiers standard et un outil détenu par la communauté, de bout en bout. « Open source » est l'expression que les gens recherchent ; la liberté est la raison pour laquelle il est construit ainsi.

Si cela colle à votre façon de travailler, ouvrez l'éditeur, lisez la documentation et venez poser vos questions dans la communauté. Puis choisissez votre CMS et commencez à concevoir sur de vraies données.