Pourquoi j'ai quitté WordPress pour Astro

Pourquoi j’ai quitté WordPress

Migrer de WordPress vers Astro, c’est un sujet tendance en ce moment — tendance dans la tendance, même, puisqu’il est toujours fécond sur LinkedIn de pester sur les maigres performances de WordPress et les projets catastrophiques qu’il permet de réaliser. Je n’ai rien personnellement contre WordPress : il est tout à fait adapté à certains contextes. Le fait est que pour mon usage personnel, il était devenu totalement inadapté. Je travaille majoritairement dans une console, et je rédige mes fichiers en Markdown. Alors lorsque d’aventure je voulais publier un billet, je me retrouvais comme une poule devant un mégot devant le back-office de WordPress.

Le WordPress qui ressemble à la créature de Frankenstein

Le cas le plus caricatural, c’est celui du « WordPress créature de Frankenstein » : une instance qui empile des dizaines d’extensions qui n’ont rien à voir entre elles, au point de ressembler à la créature de Frankenstein — assemblée à partir de morceaux de cadavres qui n’étaient pas faits pour aller ensemble.

C’est le cas de beaucoup de sites vitrines qui, pour des raisons graphiques ou inhérentes à l’outil, éclatent le contenu en une multitude de briques gérées par une galaxie d’extensions. Dès que je me penche sur l’écriture, je me retrouve à cliquer sans fin dans une interface pour découper mon contenu. J’écris pourtant d’abord ailleurs, mais les contraintes de découpage finissent par déstructurer l’écriture.

Côté sites clients, je retrouve régulièrement des installations embourbées avec dix-huit extensions pour un pauvre site plaquette de six pages.

Ce que ça coûte vraiment : performance et conversion

Le premier impact, ce sont les performances. C’est un vrai sujet aujourd’hui : la plupart des moteurs de recherche, Google en tête, accordent une prime au site le plus rapide.

Il y a aussi un impact côté conversion — pas tant le passage du prospect au client que celui du prospect qui lit au prospect qui vous contacte. Dans mon cas, vendre des prestations web avec un WordPress à rallonge, ce n’est pas vendeur du tout : c’est poussif.

La maintenance qu’on ne voit pas passer, jusqu’au jour où

Un site WordPress, c’est au final un coût de maintenance relativement lourd : mise à jour du noyau, mise à jour des extensions, surveillance de l’instance. Si on est joueur, on peut mettre tout ça en automatique, mais ça peut occasionner d’autres grosses surprises — je déconseille de ne pas y jeter un œil régulièrement tout de même. La plupart des clients qui arrivent chez moi avec leur WordPress ont fait l’impasse sur cette partie, et ça commence par une joyeuse journée de nettoyage de scripts dans l’ensemble de l’arborescence.

WordPress est effectivement une cible facile des script kiddies. On forme d’ailleurs aux scripts d’attaque dans l’ensemble des cursus de sécurité informatique — le mien y consacre un atelier pratique avec Kali Linux, la distribution de référence pour les tests d’intrusion.

Ce qu’un scanner trouve sur un WordPress mal tenu

Kali embarque, entre autres, des outils de reconnaissance et de scan de vulnérabilités. Sur un WordPress, le plus emblématique est WPScan : il énumère les extensions et le thème installés, les compare à une base de failles connues, et liste ce qui est exploitable — sans avoir besoin d’accéder à l’administration. À côté, des scanners plus généralistes comme Nmap (reconnaissance réseau) ou Nikto (audit de serveur web) complètent le tableau. Une extension non mise à jour n’est donc pas un risque théorique : c’est une ligne dans le rapport d’un de ces outils.

Ce qui n’a pas non plus un super bilan carbone : empiler autant de code a un coût énergétique, plus de calcul serveur à chaque requête, plus de base de données sollicitée.

Astro, concrètement, c’est quoi

Astro se présente comme un framework JavaScript orienté contenu. En clair, dans la configuration où j’ai migré mon vieux WordPress, Astro permet de générer un site statique en HTML, CSS, JavaScript — à l’ancienne, comme je faisais quand j’avais vingt ans. Il se base, pour le stockage des contenus, sur du Markdown.

Ce que ça apporte : évidemment beaucoup plus de performances — un fichier statique, il n’y a rien de plus rapide à servir, si les médias sont bien optimisés. Et une sécurité quasi sans faille : moins il y a de code exécuté côté serveur, moins il y a de surface d’attaque.

Comment j’ai construit ce site

Pour sujetverbecomplement.com, j’ai simplement opté pour construire avec Astro une version statique, et la publier en poussant le HTML sur le serveur. Je travaille seul, et j’écrivais déjà la plupart du temps en Markdown : ça collait parfaitement bien.

J’ai utilisé mes supports de cours, déjà écrits en Markdown avec Quarto — un outil qui me sert à générer mes cours à la fois en PDF et en présentation reveal.js, et dans d’autres formats si on me les demande (un article à part viendra là-dessus). J’ai ainsi rapidement monté un site avec, dès le départ, des préoccupations de référencement naturel. Résultat : le site est en ligne, et les indicateurs de performance Google (PageSpeed Insights, Core Web Vitals) sont au vert.

Cet article-même en est une démonstration : je l’ai dicté, Maurice (Claude, le modèle d’Anthropic) l’a rédigé à partir de mes notes, et je l’ai relu avant publication. Rien n’y figure qui ne vienne de ce que j’ai dicté. Le détail du procédé — ce qu’il reçoit en entrée, ce qu’il n’a pas le droit d’inventer, qui relit — est sur la page Maurice.

Ce qu’Astro ne résout pas

C’est vachement bien, mais ça ne règle pas tout. Si on a une boutique, un site de presse, un site transactionnel ou un extranet avec des espaces personnalisés, il ne faut pas rêver : un site statique ne va pas suffire.

Confier le site à quelqu’un qui n’écrit pas en Markdown

Il y a aussi un obstacle plus terre à terre : difficile de mettre dans les mains d’un client quelque chose qui ne s’édite qu’en Markdown, dans un éditeur de texte. J’ai un prototype en cours avec Sveltia CMS : une interface web posée directement sur le dépôt Git, qui édite les fichiers Markdown sans qu’on touche au code, et qui produit un commit à chaque enregistrement.

Sveltia CMS n’est pas seul sur ce créneau. En priorisant les outils réellement libres plutôt que les offres adossées à un cloud propriétaire : Decap CMS (l’héritier de Netlify CMS) fonctionne sur le même principe, tout aussi open source ; Keystatic l’est également et propose une intégration officielle pour Astro. TinaCMS s’en approche, mais son usage complet passe par son propre service cloud. Sveltia CMS reste le plus récent des trois, et celui que j’ai retenu pour mon prototype. Un prochain article détaillera l’édition de contenu pour Astro, avec ce panorama développé.

Pour les acharnés WordPress, il y a une autre option : garder WordPress uniquement comme back-office de rédaction, et brancher Astro dessus. WordPress expose son contenu par API (REST ou WPGraphQL), Astro va le chercher au moment du build et génère les pages statiques. Le rédacteur retrouve l’interface qu’il connaît ; le site public, lui, n’exécute plus une ligne de PHP.

Il existe aussi des solutions pour rendre WordPress lui-même plus efficace sur les sites complexes qui ne s’y prêtent pas — un cache applicatif comme Varnish, du load balancing, une configuration plus musclée. C’est le type de sujet que je traite en accompagnement Site web & CMS.