Et si WordPress pouvait rester un excellent outil de rédaction sans être nécessairement celui qui affiche le site aux visiteurs ? Avec Silex, l’objectif est de conserver le confort de publication de WordPress tout en générant un site statique, plus léger et davantage maîtrisé. Une expérimentation qui mêle souveraineté numérique, logiciel libre, no-code et, prochainement, intelligence artificielle.
Actuellement, ce site fonctionne avec WordPress. Mais depuis déjà quelque temps revient l’idée de faire évoluer sa partie visible vers un fonctionnement beaucoup plus simple : des pages statiques.
En effet, la plupart des pages que vous consultez ici n’ont pas besoin d’être régénérées par le serveur chaque fois qu’un visiteur les affiche. Un article publié hier reste, pour l’essentiel, le même pour tout le monde. Pourquoi, dans ce cas, solliciter systématiquement WordPress, une base de données et toute une mécanique technique simplement pour afficher un texte et quelques images ?
Autant rendre statique ce qui l’est déjà.
Et cette idée présente plusieurs avantages : la page peut s’afficher plus rapidement. Elle demande également moins de calculs au serveur et donc moins de ressources pour accomplir une tâche finalement très simple. Enfin, en évitant d’exposer directement WordPress aux visiteurs, il devient possible de limiter les risques en cas de faille depuis le système de gestion de contenu (on dit souvent CMS en anglais) ou dans l’une de ses extensions.
Cela ne rend évidemment pas un site invulnérable et WordPress doit toujours être correctement protégé s’il continue à fonctionner en arrière-plan. Mais le principe paraît cohérent : ne pas mobiliser une infrastructure complexe lorsqu’une simple page suffit.
Simplifier pour mieux maîtriser
La souveraineté numérique est souvent réduite à une question de localisation : savoir dans quel pays sont hébergées les données ou à quelle entreprise appartient le service utilisé. Ces questions sont importantes, mais elles ne suffisent pas.
Être souverain, c’est aussi être capable de comprendre, maîtriser et faire évoluer son propre environnement numérique. Or, chaque logiciel, extension ou service supplémentaire crée une nouvelle dépendance qu’il faudra maintenir, mettre à jour et parfois remplacer.
La simplicité n’est donc pas seulement une affaire de confort technique. Elle peut devenir une manière de conserver davantage de maîtrise : éviter les dépendances qui n’apportent rien pour mieux contrôler celles qui sont réellement nécessaires.
Un site statique n’est pas automatiquement écologique
La même logique peut être appliquée à la sobriété numérique.
Un site statique n’est pas, par défaut, écologique : une page peut parfaitement être statique tout en étant très lourde, chargée d’images surdimensionnées, de vidéos, de polices, de scripts ou de services extérieurs inutiles.
Le statique peut en revanche participer à une démarche plus sobre lorsqu’il permet d’éviter des traitements qui n’apportent rien à l’utilisateur.
L’important n’est donc pas seulement de choisir une technologie réputée plus légère, mais de réduire ce qui est superflu, limiter les ressources mobilisées et adapter la complexité technique au service réellement rendu.
La sobriété numérique commence souvent par ce type de question : de quoi peut-on se passer sans dégrader l’usage ?
Des solutions comme Hugo ou Jekyll permettent depuis longtemps de construire ce type de sites. Elles sont puissantes, mais demandent tout de même une certaine aisance technique.
Dans mon cas, le problème n’était pas l’envie d’apprendre, mais plutôt le sentiment de ne pas encore disposer des connaissances suffisantes pour me lancer sereinement. Hugo et Jekyll sont donc restés dans un coin de ma tête, accompagnés de cette petite phrase que l’on connaît bien : « un jour, il faudra vraiment que je m’y penche ».
Un jour qui, jusqu’ici, n’est jamais arrivé. Et il faut bien reconnaître que je n’ai pas non plus fait énormément d’efforts pour le provoquer…
Puis il y a eu une rencontre : lors de l’OW2con’26, dont j’ai déjà raconté ici la journée, et fait la connaissance, pendant le déjeuner, d’Alex Hoyau, aux côtés de Brice Martin.
Alex est cofondateur, avec Moly Richez, de l’agence web Internet 2000, mais il est aussi l’un des créateurs de Silex.
Notre discussion avait justement porté sur cette idée qui me trottait dans la tête depuis longtemps : conserver un système comme WordPress pour gérer mes contenus, tout en proposant aux visiteurs une partie visible du site beaucoup plus légère et statique.
Pour la première fois, il ne semblait plus nécessaire de choisir entre deux solutions peu satisfaisantes : conserver toute la mécanique de WordPress pour afficher des pages qui changent peu, ou acquérir suffisamment de compétences en développement pour construire soi-même un site avec Hugo ou Jekyll.
Silex ouvrait cette troisième voie : conserver la simplicité de publication de WordPress tout en pouvant construire visuellement un site statique.
Petite présentation de Silex :
Silex est un outil permettant de créer visuellement des sites statiques. Le projet est porté par l’association française à but non lucratif Silex Labs. Il fait partie d’OW2 et bénéficie notamment du soutien du programme européen NGI0 Commons Fund.
Le projet a d’ailleurs récemment reçu une reconnaissance au sein de cet écosystème : lors de l’OW2con’26, en juin de cette année. Silex a reçu un OW2 Best Project Award dans la catégorie Technologie.
Une récompense qui distingue plusieurs années de travail autour de l’idée d’un web libre, open source et accessible grâce au no-code, mais aussi grâce à l’implication d’une communauté qui teste, signale les problèmes et contribue au projet.
Son origine française et son inscription dans un écosystème européen suffisent déjà à attirer l’attention lorsqu’on s’intéresse à la souveraineté numérique. Cet ancrage ne résume pourtant pas le projet. En échangeant avec Alex sur les statistiques d’utilisation, les pays d’origine des utilisateurs et ceux des contributeurs, apparaît au contraire une réalité beaucoup plus large : Silex est déjà utilisé et développé bien au-delà de la France et de l’Europe.
Au fil du temps, ses utilisateurs et ses contributeurs se le sont approprié dans de nombreux pays, donnant au projet une dimension désormais largement internationale.
Mais, à mes yeux, l’essentiel est encore ailleurs.
Être libre, c’est aussi pouvoir partir
Ce qui compte davantage, c’est la manière dont l’outil a été pensé : Silex est un logiciel libre. Son code est ouvert, il peut être installé sur son propre serveur et il produit des fichiers dans des formats standards du Web.
Cette liberté peut sembler secondaire tant que tout fonctionne bien. Pourtant, elle change profondément la relation avec l’outil.
Avec certaines plateformes, créer un site revient aussi à accepter une forme de dépendance au service, à son infrastructure, à ses tarifs ou encore aux décisions que l’entreprise pourra prendre demain. Changer de solution peut alors devenir compliqué, jusqu’à devoir reconstruire une partie importante du travail réalisé.
Avec Silex, le principe est différent : le site conçu ne reste pas enfermé dans Silex.
Les fichiers peuvent être récupérés, hébergés ailleurs et continuer à vivre sans l’outil qui a servi à les créer.
Cette liberté est aussi une manière très concrète d’aborder la souveraineté numérique : éviter qu’un choix technique décidé aujourd’hui ne devienne une dépendance dont il serait difficile de s’affranchir demain.
De FrontPage Express à Dreamweaver
Pour comprendre ce qui rend Silex intéressant, un petit détour par l’histoire du Web s’impose.
Pour situer l’époque : adolescent au moment où Google faisait ses premiers pas, Internet était aussi celui de Multimania, iFrance, iBazar, RealPlayer, Napster, Winamp, Voilà, Wanadoo, Caramail, Dmoz, Flash Player ou Netscape.
Obtenir une connexion à Internet à la maison constituait déjà une première bataille.
Mais une fois cette porte ouverte, une découverte allait être déterminante : le Web n’était pas seulement quelque chose que l’on pouvait consulter. Chacun pouvait aussi y créer son propre site et y dessiner son propre territoire dans ce qu’on appelelait alors le cyberespace.
Les premiers essais se sont faits avec l’un des outils déjà disponibles sous Windows : FrontPage Express (mais aussi FrontPage 98)
FrontPage Express permettait de créer une page Web un peu comme un document dans un traitement de texte. Du texte, des images, des liens : il était possible de placer les éléments visuellement sans connaître parfaitement le langage utilisé pour fabriquer une page Web.
Quelques années plus tard, Dreamweaver, développé par Macromedia (avant son rachat par Adobe), allait pousser cette idée beaucoup plus loin.
Ces logiciels appartenaient à la famille des outils dits WYSIWYG, pour What You See Is What You Get. En français : ce qui apparaît à l’écran pendant la création doit ressembler à ce que verra ensuite le visiteur.
Dreamweaver permettait de construire un site de manière très visuelle : ajouter une image, placer un texte, créer un tableau, modifier une couleur ou fabriquer un menu. En arrière-plan, le logiciel se chargeait de produire une grande partie du code nécessaire.
Pour toute une génération, ces outils ont considérablement abaissé la barrière d’entrée du Web. Il n’était pas nécessaire d’être développeur pour commencer à fabriquer son propre site.
Quand le Web invitait encore à construire
Ce souvenir n’est pas seulement nostalgique. Il rappelle aussi une caractéristique importante du Web de cette époque : on n’y était pas seulement spectateur, on pouvait assez facilement en devenir un acteur.
Cette liberté demandait un peu d’apprentissage et beaucoup de bricolage, mais chacun pouvait construire son propre espace, choisir son hébergeur, son nom de domaine, son apparence et la manière dont ses contenus seraient présentés.
Une grande partie de nos usages s’est depuis déplacée vers des plateformes qui ont rendu la publication infiniment plus simple, mais qui en fixent aussi le cadre. Sur un réseau social, la présentation, les fonctionnalités et parfois même la visibilité d’un contenu dépendent de règles que l’on ne maîtrise pas.
C’est aussi une question de souveraineté numérique : conserver la possibilité de publier sans dépendre entièrement d’un intermédiaire pour accéder à son propre public.
Sous cet angle, Silex permet de retrouver une partie de cette liberté du Web personnel, sans pour autant revenir à l’époque où chaque page devait être fabriquée « à la main ».
Pourquoi Dreamweaver a-t-il quasiment disparu du paysage ?
Le problème n’était pas forcément Dreamweaver. C’est surtout le Web autour de lui qui a changé.
Au début des années 2000, un site était souvent constitué de pages que le webmaster fabriquait sur son ordinateur avant de les envoyer sur un serveur FTP.
Puis les systèmes de gestion de contenu, comme WordPress, et même un peu avant, avec TYPO3, PHP-Nuke et SPIP, ont profondément simplifié la publication. Plus besoin de créer manuellement une nouvelle page et de l’envoyer ensuite sur le serveur : il suffisait désormais de se connecter, d’écrire et de cliquer sur « Publier ».
Dans le même temps, les smartphones et tablettes ont imposé des sites capables de s’adapter à des écrans très différents, tandis que les services en ligne devenaient de plus en plus complexes.
Le métier de webmaster a lui aussi changé. Ce qui pouvait autrefois être pris en charge par une seule personne s’est progressivement réparti entre plusieurs métiers spécialisés.
Dreamweaver s’est alors retrouvé entre deux usages : d’un côté, les développeurs se sont tournés vers des outils pensés avant tout pour écrire et organiser du code, de l’autre, le grand public a adopté WordPress, Wix, Squarespace, Shopify et plus récemment Webflow ou Framer ainsi que d’autres services accessibles directement depuis un navigateur.
L’éditeur visuel n’avait pourtant pas dit son dernier mot.
Silex ressemble à Dreamweaver… mais le principe a changé
Lorsque j’ai découvert Silex, le rapprochement avec Dreamweaver m’a semblé assez évident. Une page blanche apparaît à l’écran, les éléments se manipulent visuellement et il n’est pas nécessaire d’écrire soi-même chaque ligne de code.
Alors, après plus de vingt ans d’évolution du Web, aurait-on simplement réinventé Dreamweaver version no-code ?
Pas vraiment.
Dreamweaver permettait avant tout de fabriquer des pages. Avec Silex, il devient possible de préparer une fois la manière dont elles devront être présentées, puis de laisser le système les produire à partir des contenus disponibles.
Prenons l’exemple de ce site. Plutôt que de fabriquer séparément la page de chaque article, Silex peut définir une présentation commune : le titre ici, l’image là, puis le texte et la date, avant de l’appliquer ensuite aux différents contenus.
C’est précisément ce qui me permet d’envisager de conserver WordPress. Il resterait l’endroit où les articles sont écrits, classés et administrés, tandis que Silex récupérerait ces contenus pour produire les pages statiques visibles par les lecteurs.
WordPress resterait l’arrière-boutique (ou back office) ; Silex construirait la vitrine.
Le retour du visuel, vingt ans plus tard
Le succès actuel des outils dits no-code peut sembler paradoxal. Le Web s’est éloigné des éditeurs visuels comme Dreamweaver à mesure qu’il devenait plus complexe, et voici que des outils visuels reviennent aujourd’hui sur le devant de la scène.
Mais il ne s’agit pas vraiment d’un retour en arrière.
Le no-code ne signifie pas qu’il n’y a plus de code. L’utilisateur n’a simplement plus besoin de tout écrire lui-même : le logiciel se charge d’en produire ou d’en assembler une grande partie.
C’est ce qui distingue ces outils de l’ancien modèle de Dreamweaver. Ils ne cherchent plus seulement à rendre la création d’une page plus visuelle, mais à rendre plus accessible une mécanique technique devenue de plus en plus complexe.
No-code : que peut-on réellement emporter avec soi ?
Le no-code ne pose pas seulement la question de la simplicité. Il pose aussi celle de la dépendance : à qui appartient réellement le travail accompli lorsque vient le moment de partir ?
Toutes les plateformes ne répondent pas de la même manière.
Avec Wix, le site reste largement lié à l’infrastructure du service. Squarespace permet de récupérer certains contenus, mais pas nécessairement l’ensemble du site tel qu’il a été conçu. Webflow, lui, va plus loin, mais uniquement dans certaines formules plus onéreuses, qui permettent d’exporter les fichiers du site et de les héberger ailleurs. Mais plusieurs fonctions propres à la plateforme restent difficiles, voire impossibles, à transposer ailleurs.
Ces solutions ne sont pas des pièges. Elles offrent une simplicité et une prise en charge technique qui peuvent parfaitement convenir à certains usages. La dépendance devient surtout un problème lorsqu’elle n’a pas été choisie en connaissance de cause.
Silex fait ici un choix différent : ne pas transformer la simplicité d’usage en dépendance.
Un prix peut augmenter, une offre disparaître, une entreprise changer de stratégie ou être rachetée. Ces évolutions font partie de la vie normale d’un service numérique. L’enjeu est donc de ne pas laisser ces changements décider, à notre place, de l’avenir de ce que nous avons construit.
Au fond, Silex répondait assez précisément à ce que je cherchais depuis le départ : conserver WordPress pour écrire, tout en allégeant ce que voit réellement le lecteur.
Restait maintenant à passer de l’idée à la pratique : comprendre comment fonctionne Silex, découvrir son modèle, sa communauté et ses formations, puis confronter l’outil à mes propres usages, à ses limites (et surtout aux miennes) et aux évolutions déjà annoncées pour sa prochaine version.
Silex : un outil, mais aussi tout un écosystème
Après cette première découverte de Silex et de son histoire, il était temps d’aller un peu plus loin et de regarder ce qu’il est réellement possible de faire avec l’outil.
L’interface se rapproche de ce que l’on peut attendre aujourd’hui d’un outil de création visuelle : les éléments de la page peuvent être positionnés et modifiés directement, tout en conservant, derrière cette couche graphique, la possibilité de travailler beaucoup plus finement sur la structure du site.
Silex souffre néanmoins encore de sa relative jeunesse dans sa forme actuelle : le catalogue des modèles reste pour l’instant assez limité. Il est toutefois possible de se faire une idée beaucoup plus concrète du résultat avec, par exemple, le modèle ci-dessous, que je trouve particulièrement intéressant pour illustrer les possibilités de Silex.
Dans l’univers des créateurs de sites, les modèles constituent souvent un marché en soi : des éditeurs et des graphistes vendent individuellement leurs thèmes, parfois pour quelques dizaines d’euros, souvent beaucoup plus. Silex prend ici une autre direction. Certains futurs modèles font l’objet d’un financement participatif : la communauté contribue jusqu’à réunir le montant nécessaire pour rémunérer le travail de conception graphique et d’intégration. Une fois financé et réalisé, le modèle est ensuite mis à disposition de tous sous licence libre. Silex indique d’ailleurs explicitement que ses modèles sont gratuits et que le financement collectif sert à en développer de nouveaux.
Cette approche illustre assez bien une idée qui me paraît essentielle dans le logiciel libre : open source ne signifie pas gratuit.
Derrière un modèle, comme derrière un logiciel, il y a des personnes qui travaillent.
Un graphiste, un intégrateur ou un développeur doivent pouvoir être rémunérés.
La différence tient ici au modèle choisi : plutôt que de laisser chacun acheter séparément le même produit, la communauté finance collectivement sa création, et une fois le travail payé, le résultat devient disponible pour tout le monde.
Il y a aussi, dans cette approche, un concept que je défends souvent : la transparence.
On sait ce qui doit être financé, pourquoi et dans quel but.
Apprendre, comprendre et participer
Au-delà de l’éditeur, Silex a aussi construit tout un environnement et une communauté pour apprendre, partager et contribuer.
Le projet organise régulièrement des événements et des formations autour du webdesign, du développement web, du vibe coding, de l’intelligence artificielle ou, tout simplement, de la prise en main de Silex. Une plateforme dédiée rassemble ces rendez-vous et les formations proposées par la communauté.
Mais ce qui m’intéresse surtout, ce sont toutes les portes laissées ouvertes à celles et ceux qui veulent comprendre le projet plutôt que simplement consommer un service.
Il existe ainsi un forum communautaire, sur lequel il est possible de poser des questions, signaler des problèmes ou échanger autour des usages. Le code source de Silex est également public sur GitHub : le dépôt compte plusieurs milliers de commits et permet de suivre le développement, les demandes d’évolution et les contributions. Le projet est sous licence AGPL et accepte les contributions de la communauté.
Silex possède également sa propre instance PeerTube, avec de nombreuses vidéos permettant de découvrir les fonctionnalités de l’outil, de suivre des démonstrations ou de mieux comprendre certains concepts. À cela s’ajoute une documentation complète.
Cette documentation devrait d’ailleurs prochainement évoluer. D’après mes échanges avec Alex Hoyau, cofondateur du projet, une mise à jour est prévue avec l’arrivée des prochaines évolutions de Silex. Le développement reste particulièrement actif : au moment où j’écris ces lignes, de nouvelles versions et préversions continuent d’être publiées.
Tout cela participe à quelque chose que je considère comme essentiel dans un projet open source : la possibilité de ne pas être uniquement utilisateur.
On peut apprendre. On peut poser une question. On peut documenter. On peut signaler un bug. On peut tester une nouvelle version ou proposer du code et participer à la traduction dans différentes langues. Mais il existe aussi une autre manière de contribuer : financer le projet.
Silex possède pour cela un espace sur Open Collective qui permet de faire un don ponctuel ou récurrent, de participer au financement de son hébergement ou de devenir un sponsor. Les recettes et les dépenses y sont visibles publiquement.
J’insiste particulièrement sur ce point : utiliser du logiciel libre sans jamais participer à son financement est évidemment possible, et c’est même l’une des libertés qu’il garantit. Mais lorsque l’on utilise réellement un projet, que l’on souhaite qu’il continue à évoluer et que l’on en a les moyens, la contribution financière fait aussi partie des moyens de faire vivre cet écosystème.
Le code peut être libre ; le temps de celles et ceux qui le produisent ne l’est pas.
Et c’est probablement aussi par ce modèle, associant code ouvert, documentation, transmission des connaissances, gouvernance communautaire et financement collectif, que Silex a toutes les chances de devenir progressivement un véritable commun numérique.
Et WordPress dans tout ça ?
Au départ, mon objectif était assez radical : passer complètement à une architecture WordPress + Silex.
J’ai donc suivi la formation permettant de connecter les deux solutions et j’y suis arrivé. Le principe consiste à transformer WordPress en source de contenu : les articles restent gérés dans son interface, puis Silex récupère ces données notamment grâce à WPGraphQL afin de générer le site statique. C’est précisément l’un des usages désormais documentés par le projet.
J’ai ensuite voulu comprendre toute la chaîne de publication en testant la méthode proposée dans le tutoriel, pour connecter Silex à GitLab et automatiser la génération puis la publication du site. Là encore, cela a fonctionné.
Techniquement, j’avais donc réussi ce que j’étais venu chercher :
WordPress → Silex → génération du site → GitLab → publication.
Mais je me suis arrêté là.
Non pas parce que le système ne fonctionnait pas, mais parce que je ne me voyais pas encore confier l’intégralité de mon site à cette chaîne de publication, et encore moins changer mon hébergement pour adopter GitLab Pages. Mon site est aujourd’hui hébergé chez OVHcloud et je souhaite, pour le moment, conserver ce contrôle.
Il y avait aussi une autre raison : je ne suis pas encore totalement à l’aise avec le concept de forge, même si j’y contribue déjà, notamment à travers la traduction et la remontée de bogues.
GitLab, GitHub et les outils du même type ont évidemment des avantages que je commence à percevoir : versionnement, automatisation, historique des modifications, déploiements…
Je sais que je devrai tôt ou tard mieux comprendre cet univers. Mais je ne voulais pas ajouter ce sujet à ce chantier.
Et surtout, arrivé à ce stade, le plus gros travail restait devant moi : reconstruire toute l’interface graphique de Souverain pour le transformer en véritable modèle Silex.
Or il faut être clair : même si Silex réduit considérablement la quantité de code qu’il faut écrire, concevoir correctement un site demande encore certaines compétences. Il faut comprendre le webdesign, l’intégration, le responsive, l’accessibilité et disposer malgré tout de quelques notions de développement.
C’est donc ici que ma première expérimentation s’est arrêtée.
Mais l’idée, elle, ne s’est pas arrêtée.
Le projet a depuis mûri
Après plusieurs semaines de réflexion, je sais aujourd’hui beaucoup mieux quel type d’architecture je voudrais adopter.
Le premier élément resterait WordPress, mais avec un changement majeur : il ne serait plus installé sur mon serveur public.
WordPress fonctionnerait directement en local sur mon ordinateur et retrouverait finalement le rôle dont j’ai principalement besoin : celui d’un excellent outil de rédaction.
Je continuerais ainsi à profiter de son interface pour écrire mes articles, gérer leur mise en forme, insérer des liens ou intégrer facilement des images. Mais cette installation WordPress ne serait plus exposée sur Internet.
Le deuxième élément serait Silex, lui aussi sous mon contrôle.
Sur ce point, mon choix n’est pas encore arrêté. Deux possibilités m’intéressent : utiliser Silex Desktop directement sur mon ordinateur, ou auto-héberger Silex sur l’un de mes serveurs.
Silex peut officiellement être utilisé en ligne, via une application ou en mode auto-hébergement.
La chaîne deviendrait alors quelque chose comme ceci :
WordPress en local sur mon ordinateur → Mes contenus → Silex → Génération du code → HTML / CSS / JavaScript / images → Transfert via FTP chez mon hébergeur OVH
Et là, changement majeur : le serveur public n’aurait plus besoin de WordPress pour afficher ce site. Lorsque quelqu’un consulterait un article, OVH n’aurait plus à exécuter WordPress, interroger sa base de données et générer une page avec PHP. Il lui suffirait d’envoyer un fichier HTML déjà construit.
C’est exactement le principe du WordPress headless associé à Silex : WordPress conserve les contenus, tandis que Silex génère, lors de la compilation du site, les fichiers qui seront réellement servis aux visiteurs.
Et sans forcément passer par GitLab
C’est également un point important dans ma réflexion.
Je voudrais automatiser au maximum le transfert du site généré vers mon hébergement FTP OVH, sans être obligé de faire de GitLab un maillon indispensable de la chaîne.
Silex prend officiellement en charge la publication ou l’hébergement via FTP/SFTP, en plus de GitLab Pages et d’autres méthodes.
Lors de mes premiers tests avec une instance hébergée par Silex, j’avais d’ailleurs vu cette possibilité. En revanche, je n’ai pas encore retrouvé le même fonctionnement directement dans Silex Desktop. D’après mes échanges avec Alex Hoyau, cette possibilité doit évoluer avec la prochaine version.
Je dois donc encore déterminer la meilleure méthode.
Mais le principe que je recherche est désormais clair : j’écris, je génère, et je publie. Avec le moins possible d’étapes manuelles entre les trois.
Et cette fois, l’IA va vraiment intervenir
Il reste toutefois le plus gros morceau : le modèle de ce site.
Au départ, je pensais essayer de reproduire assez fidèlement mon site actuel. Ma réflexion a là aussi évolué : quitte à reconstruire entièrement le front, autant en profiter pour le repenser.
Dans l’idéal, j’aurais adoré pouvoir mener ce travail avec des graphistes, des designers et des spécialistes de l’ergonomie. C’est un métier pour lequel j’ai énormément de respect, précisément parce qu’un bon design ne consiste pas simplement à rendre une page « jolie ».
Il faut penser les usages, la hiérarchie de l’information, la lisibilité, l’accessibilité, les interactions, les différents écrans et tous ces détails presque invisibles qui font qu’un site devient agréable ou pénible à utiliser.
Il y a d’ailleurs beaucoup de personnes et de collectifs dont je suis le travail avec intérêt et avec lesquels j’aurais aimé pouvoir imaginer ce nouveau site. Je pense notamment à Timothée Goguely, Camille Baudelaire et Olivia Grandperrin de l’Atelier Baudelaire, Nolwenn Maudet, le collectif Designers Éthiques, Olivier Bergère, Emilie Nguyen Van Yen, Marie et Julien, Natouille, Timothé Jeanne, Jean-Paul Bagnis ou encore Geoffrey Dorne.
Cette liste n’est évidemment pas exhaustive. Elle dit surtout quelque chose de ma manière d’aborder ce chantier : je ne considère absolument pas que l’intelligence artificielle remplace ces métiers. Au contraire, plus je m’intéresse au design, plus je mesure tout ce qu’il y a derrière une interface réussie.
Mais pour cette nouvelle version de Souverain, j’ai envie de tenter une autre expérience : concevoir entièrement le prochain design du site avec l’aide de l’intelligence artificielle.
Pas simplement lui demander de produire une page.
L’idée sera plutôt de m’en servir comme d’un outil d’accompagnement tout au long du processus : confronter des idées, tester des structures, travailler la hiérarchie de l’information, corriger des incohérences et recommencer autant de fois que nécessaire.
Le véritable enjeu sera d’obtenir un modèle dont je sois réellement satisfait en matière d’ergonomie, de responsive, de lisibilité et surtout d’accessibilité. Une fois cette première étape validée, je voudrais continuer à utiliser l’IA pour m’aider à transformer ce design en composants et modèle exploitables dans Silex.
Cette perspective est d’autant plus intéressante que Silex travaille justement à rapprocher l’intelligence artificielle de son éditeur. La version application, intègre désormais à titre expérimental un serveur MCP (Model Context Protocol), un protocole ouvert permettant à un assistant IA de communiquer directement avec une application.
Silex n’impose ni assistant ni modèle d’intelligence artificielle. Le serveur MCP sert de passerelle et permet de connecter différents outils compatibles, comme Claude Code, Goose ou OpenCode, mais aussi des modèles exécutés localement avec Ollama. L’application elle-même fonctionne en local, sans compte obligatoire, et conserve les fichiers du site sur l’ordinateur. Une approche qui reste donc assez cohérente avec le fil rouge de toute cette expérimentation : conserver autant que possible la maîtrise de ses outils et de ses données.
L’IA peut alors intervenir directement dans l’éditeur : créer ou modifier des pages et des styles, comprendre la structure du document, manipuler les ressources et les sources de données ou encore déclencher la génération et la prévisualisation du site. D’après Alex Hoyau, les ambitions vont encore plus loin : faciliter le passage d’une maquette Figma vers Silex, accompagner la connexion à WordPress ou aider à vérifier que le site respecte les bonnes pratiques. C’est précisément le type de passerelle qui pourrait m’aider à passer du design imaginé grâce à l’IA, à un véritable modèle Silex.
Cette évolution n’en est encore qu’à ses débuts. Silex la présente actuellement comme un prototype en cours de développement et recherche des personnes prêtes à le tester. Un formulaire permet déjà de demander un accès à cette version alpha, avec l’idée que les retours des premiers utilisateurs participent directement à son évolution.
Une autre piste pourrait venir prolonger cette logique. Alex m’a également indiqué travailler avec le CNRS (Centre national de la recherche scientifique) sur la possibilité de proposer des modèles d’intelligence artificielle répondant à des critères éthiques, mais aussi accessibles par API, et capables de fonctionner directement en local. Si cette piste aboutit, elle ajouterait une dimension supplémentaire à l’expérience : utiliser l’IA pour abaisser la barrière technique de la création Web sans nécessairement remplacer une dépendance par une autre.
Ce sera probablement, pour moi, la partie la plus difficile du projet.
Mais ce sera aussi celle qui poussera le plus loin la réflexion : voir jusqu’où il est possible d’aller lorsque l’on dispose de peu de compétences en webdesign et en intégration, mais que l’on accepte de travailler par essais, erreurs et itérations avec l’IA.
Quelques sacrifices seront nécessaires
Passer de WordPress à un site statique signifie cependant renoncer à une partie de ce qui fait justement la force de cette solution : son immense écosystème d’extensions (+ de 73 000).
Et j’en utilise quelques-unes.
Matomo devra quitter WordPress
La première concerne les statistiques.
Actuellement, j’utilise Matomo Analytics, configuré de manière à rendre la collecte aussi respectueuse que possible de la vie privée, avec des données anonymisées.
Aujourd’hui, son intégration à WordPress est très simple grâce à une extension.
Avec mon futur site statique, cette extension disparaîtra.
Mais Matomo existe heureusement aussi sous forme autonome et auto-hébergeable. Mon hébergement mutualisé OVH permet justement d’exécuter PHP et de disposer d’une base de données MySQL : je peux donc installer une instance Matomo séparée de mon futur site statique.
Le script de suivi Matomo serait ensuite intégré directement au modèle de Silex et se retrouverait automatiquement dans toutes les pages générées.
Pour les statistiques classiques : visiteurs, pages consultées, provenance du trafic, il n’est même pas nécessaire d’effectuer un véritable plan de taggage page par page. Celui-ci ne deviendrait nécessaire que si je voulais mesurer précisément certaines interactions : clic sur un bouton, téléchargement ou autre événement particulier.
Matomo fera donc partie des rares composants qui resteront dynamiques.
Et il faudra continuer à le maintenir à jour.
Mais finalement, ce n’est pas fondamentalement différent de ce que je fais déjà aujourd’hui : une extension WordPress doit elle aussi être mise à jour régulièrement.
Le formulaire de contact
Deuxième élément à remplacer : mon formulaire de contact. Il repose actuellement lui aussi sur une extension WordPress. Un fichier HTML statique ne peut évidemment pas, à lui seul, recevoir un message et l’envoyer par courriel. Il faudra donc que je trouve un autre mécanisme pour assurer cette fonction.
Je n’ai pas encore arrêté mon choix, mais je suis assez confiant sur ce point : il existe suffisamment de solutions pour qu’il ne constitue probablement pas l’obstacle le plus compliqué de cette migration.
Et les commentaires ? Là, c’est le changement radical, ou pas…
Le troisième changement sera en revanche beaucoup plus radical. Il concerne les commentaires. Et soyons francs : sur ce point, WordPress fait très bien le travail. Son système de commentaires intégré est simple, efficace, administrable et parfaitement adapté à un blog. Il serait donc très facile de considérer sa disparition comme une régression.
Pourtant, cette fois, j’ai envie d’en profiter pour expérimenter autre chose.
Je défends régulièrement la nécessité de tester des alternatives aux grandes plateformes centralisées comme X, Facebook et plus largement celles des GAFAM. Il me paraît donc cohérent d’essayer d’appliquer cette logique jusqu’au système de commentaires de mon propre site.
L’idée serait de relier les commentaires au Fediverse et au protocole AT (utilisé actuellement par Bluesky)
Autrement dit, plutôt que de recréer ici un énième espace dédié aux commentaires, les réactions pourraient venir directement de Mastodon, de Bluesky ou d’autres plateformes compatibles avec ces protocoles.
Je suis parfaitement conscient de la contrepartie.
Dans un premier temps, cela exclura probablement certains lecteurs qui ne possèdent aucun compte sur ces réseaux. C’est même presque l’inverse de la logique habituelle, qui cherche à réduire au maximum les frictions pour obtenir davantage de commentaires.
J’ai justement envie que ce mécanisme puisse devenir une petite incitation à découvrir ces alternatives. Pas une obligation d’adopter définitivement ces outils, mais au moins, une occasion de les essayer.
C’est encore Alex Hoyau qui m’a soufflé cette idée et m’a indiqué une solution permettant de réaliser ce type d’intégration.
Il m’a notamment orienté vers le dépôt rss-to-graphql, auquel il a lui-même contribué. Mais reprendre ce projet pour l’adapter précisément à mon besoin s’est rapidement révélé plus difficile que je ne l’imaginais. Plutôt que de multiplier les modifications sur un code que je ne maîtrisais pas suffisamment, j’ai préféré repartir d’une feuille blanche, tout en conservant l’idée qui m’avait été suggérée.
Pendant la rédaction de cet article, j’ai donc construit un premier prototype capable de faire dialoguer deux univers : ActivityPub, et le protocole AT. L’objectif est de permettre à un lecteur de retrouver les réactions publiées sur ces réseaux, mais aussi de participer directement à la conversation depuis le site.
L’expérience est déjà accessible sur une page de test. Elle est encore très largement perfectible et c’est précisément pour cette raison que les retours sont précieux : critiques, problèmes rencontrés, idées d’amélioration ou simples impressions sont les bienvenus.
Et les premiers échanges ont déjà déplacé la réflexion là où je ne l’attendais pas forcément.
J’abordais jusque-là le sujet essentiellement comme un problème technique : connecter les protocoles, authentifier les utilisateurs, récupérer les réponses et permettre leur publication. L’un des premiers retours reçus ne concernait pourtant pas le code, mais la modération.
Cette remarque m’a obligé à regarder le projet autrement. Faire remonter sur son propre site des conversations publiées ailleurs ne pose pas seulement la question de savoir si cela fonctionne techniquement. Il faut aussi réfléchir à ce que l’on choisit d’afficher, à la manière dont les contenus peuvent être modérés et, plus largement, aux responsabilités qui accompagnent un tel système. Autant de questions que mon approche, jusque-là très centrée sur la mécanique technique, avait laissées au second plan.
C’est aussi tout l’intérêt de confronter une idée à ses premiers utilisateurs : le prototype ne sert plus seulement à vérifier que quelque chose fonctionne, il révèle les questions auxquelles on n’avait pas encore pensé.
Et si l’expérience ne fonctionne pas, je reviendrai peut-être en arrière. C’est aussi le principe de ce genre d’expérimentation.
Le flux RSS devra lui aussi survivre
Dernier élément auquel je devrai faire attention : le flux RSS.
Pour les personnes utilisant un lecteur RSS afin de suivre l’actualité de plusieurs sites, au même endroit, ou faire de la veille, ce flux reste particulièrement pratique : il permet de recevoir automatiquement les nouveaux articles sans avoir besoin de consulter régulièrement chaque site.
Aujourd’hui, WordPress le génère automatiquement et il contient naturellement les bonnes adresses vers les articles du site. Avec un WordPress installé uniquement en local, ce fonctionnement devra être adapté pour éviter que le flux ne renvoie vers des adresses locales inaccessibles aux lecteurs.
L’objectif restera donc de conserver un véritable flux RSS public, généré à partir de WordPress mais avec les urls du site public. Ce n’est probablement pas l’un des points les plus complexes de la migration, mais c’est exactement le genre de détail qu’une architecture plus statique oblige à prendre en considération.
Où en suis-je réellement aujourd’hui ?
À ce stade, il est important de distinguer ce que j’ai déjà réussi à faire de ce que je projette encore de finaliser : j’ai testé Silex dans sa version hébergée, puis installé et essayé Silex Desktop.
J’ai réussi à connecter WordPress à Silex, puis à récupérer ses contenus.
Enfin, j’ai testé la chaîne de publication utilisant GitLab et celle-ci a fonctionné.
Autrement dit, les différentes briques techniques que j’ai expérimentées fonctionnent.
Ce que je n’ai pas encore fait, c’est de les assembler selon l’architecture que je viens de décrire et, surtout, reconstruire entièrement ce site autour de ce modèle.
Je ne peux donc pas encore écrire que cette migration est une réussite.
Je peux seulement dire qu’elle est désormais suffisamment crédible techniquement pour que j’aie envie d’aller jusqu’au bout.
Et c’est précisément ce que je compte faire.
Cette expérience continuera d’être documentée ici, y compris si certaines idées ne fonctionnent pas comme prévu. Et lorsque le nouveau site sera réellement construit et mis en ligne, je pourrai enfin répondre à la question qui était à l’origine de toute cette expérimentation : Peut-on conserver le confort de rédaction de WordPress tout en proposant aux internautes un site statique, plus accessible et plus rapide ?