Un CMS pour ne rien publier : le coût du site « modifiable »

La conversation a eu lieu cette semaine, entre nous et un partenaire qui préparait un devis. Son client, une entreprise industrielle, a un site sous Drupal. Le site est vieux, le HTTPS ne fonctionne même pas, et la question était : on fait un lifting sur Drupal, ou on passe à autre chose ? Puis il est allé voir la page des actualités. Dernière publication : 2016.

Dix ans de CMS, dix ans de mises à jour, d’hébergement et de failles à surveiller, pour une page figée. Ce n’est pas un cas isolé, c’est presque la règle. Les clients veulent un CMS « pour pouvoir modifier eux-mêmes ». Ils publient deux ou trois articles la première semaine, puis tout tombe aux oubliettes. Les pages de services, elles, ne bougent jamais.

Le CMS, une assurance qu’on ne réclame jamais

Le réflexe est compréhensible. Personne ne veut dépendre d’un prestataire pour corriger un numéro de téléphone. Le CMS rassure : il y a un bouton « Modifier », donc on est libre.

Dans les faits, on observe toujours la même courbe chez les entreprises que nous accompagnons : un pic d’activité au lancement, quelques actualités, puis le silence. Les pages de services sont écrites une fois et restent telles quelles pendant des années. Ce n’est pas de la paresse : un site d’entreprise change peu, et c’est normal. Ce qui ne l’est pas, c’est de payer chaque jour pour une capacité dont on se sert deux fois par an.

Ce que coûte la flexibilité inutilisée

Un site WordPress ou Drupal exécute du code à chaque visite. Il interroge une base de données, assemble la page, puis l’envoie. Cette mécanique a un prix, que l’on paie même quand personne ne publie rien.

La sécurité. WordPress équipe 39,6 % des sites selon W3Techs, ce qui en fait une cible rentable. Selon Patchstack, éditeur de solutions de sécurité pour WordPress, l’écosystème a compté 11 334 nouvelles failles en 2025, dont 91 % dans les extensions (rapport Patchstack 2026). Patchstack vend de la protection, ses chiffres sont donc à lire comme un ordre de grandeur, mais la tendance ne fait pas débat. Et le socle lui-même n’est pas à l’abri : en octobre 2026, PHP a dû corriger deux failles critiques qui permettaient de prendre la main sur un serveur, comme nous l’expliquons dans l’article sur la faille PHP d’octobre.

La fin de vie. Drupal 7, qui fait encore tourner beaucoup de sites d’entreprise, n’a plus de correctifs de sécurité officiels depuis le 5 janvier 2025 (annonce de Drupal). Un site comme celui de notre exemple n’a pas d’autre choix qu’une migration, quel qu’en soit le chemin.

La vitesse. Sur les mesures de terrain de HTTP Archive, prises chez de vrais visiteurs, 48 % des sites WordPress passent les trois seuils de Google sur mobile, contre 71 % des sites Astro, en septembre 2026. Ce sont deux populations différentes, pas une expérience contrôlée, et un WordPress soigné peut être rapide. Mais l’écart dit quelque chose : moins le serveur a de travail à chaque visite, plus la page arrive vite. Le détail est dans notre comparatif Astro ou WordPress.

Le temps. Mises à jour du cœur, des extensions, du thème, de PHP, sauvegardes de la base, surveillance : c’est un budget de maintenance mensuel, qu’un site publie ou non.

Le site statique : modifiable, sans la machinerie

Un site statique est fabriqué au moment où l’on publie, puis servi tel quel par un réseau de diffusion. Pas de base de données, pas de panneau d’administration exposé, pas d’extension à patcher. Ce qu’un attaquant ne trouve pas, il ne peut pas l’exploiter.

L’objection arrive toujours : « Mais alors, comment je modifie mon site ? » C’est là que le paradigme a changé. Trois façons existent aujourd’hui, toutes aussi simples qu’un CMS :

• En langage naturel. On écrit « remplace le numéro de téléphone du pied de page » ou « ajoute une actualité sur notre nouveau salon », l’IA prépare la modification, un aperçu s’affiche, et un clic la met en ligne. Nous détaillons ce fonctionnement dans l’article sur la modification d’un site en langage naturel.
• Avec un éditeur headless. Pour une équipe qui publie souvent, un éditeur comme Sanity offre les mêmes champs qu’un CMS classique, mais il ne sert pas les pages : il alimente le site au moment de la publication.
• Dans des fichiers texte. Pour un blog, un simple fichier Markdown par article, relu puis publié. Le choix entre les deux dépend du rythme de publication, comme l’explique notre article sur le blog en Markdown ou en CMS.

Chaque modification garde son historique, et chaque erreur se défait en un clic. C’est plus de contrôle qu’un CMS, pas moins.

Pourquoi c’est le bon moment

L’IA a changé la question. Hier, un site statique demandait un développeur pour chaque virgule, et le CMS était le prix de l’autonomie. Aujourd’hui, l’autonomie passe par la conversation : celui qui sait décrire ce qu’il veut peut modifier son site, sans connaître l’outil. Le serveur qui tourne en permanence « au cas où » n’a plus de raison d’être pour la plupart des sites d’entreprise.

Attention au raccourci inverse, pourtant : l’IA ne fabrique pas un site solide en une heure. Elle rend la modification facile une fois le site bien construit, ce qui reste un travail de métier, comme nous le racontons dans « Je peux le faire en 1h avec Astra en ultra code ».

Le CMS reste le bon choix dans certains cas : une rédaction qui publie tous les jours, plusieurs rôles qui valident, une boutique avec des stocks qui bougent. Pour un site vitrine qui change trois fois par an, c’est payer un moteur de course pour aller chercher le pain.

Par où commencer

Regardez la date de votre dernière actualité, et le nombre de fois où vos pages de services ont changé depuis deux ans. Si la réponse tient sur les doigts d’une main, votre site a besoin d’être modifiable, pas d’un CMS.

Notre guide de la migration avec Astro détaille la méthode. Notre migration vers un site statique garde toutes vos adresses et votre référencement, met en place la modification en langage naturel, et forme votre équipe à s’en servir. Votre site devient plus rapide, plus sûr, et vous pouvez enfin oublier les mises à jour d’extensions.

Sources

1. W3Techs, part de marché de WordPress, octobre 2026 (nouvel onglet)w3techs.com
2. Rapport Patchstack 2026 (nouvel onglet)patchstack.com
3. Drupal 7 End of Life (nouvel onglet)drupal.org