Quitter WordPress ? Ce n'est pas toujours une bonne idée

WordPress fait tourner plus de 40 % des sites web dans le monde, de l’artisan du coin jusqu’à des organisations comme le blog de Microsoft ou le site de la NASA – et jusqu’au site du chocolat Poulain, pour rester plus près de chez nous, chacune sur une version professionnelle du même système. Sa popularité ne le rend ni parfait ni dépassé : comme toute technologie, il a un coût. Un site sous WordPress, quelle que soit sa taille, ce n’est jamais juste « tu le crées et tu publies du contenu dedans ». Il faut penser sécurité, fonctionnalités, performance, référencement – quatre chantiers permanents, pas une case à cocher une fois.

Pourquoi un site WordPress finit toujours par coûter plus cher que prévu

Chaque fonctionnalité ajoutée à un site WordPress – un formulaire de réservation, une galerie photo, un module d’avis clients – a un coût qui ne s’arrête pas au jour de l’installation. Elle coûte en ressources : son code se charge à chaque visite, même sur les pages où elle ne sert à rien, et ralentit le site pour tout le monde. Elle coûte en argent : à l’achat ou à l’abonnement d’abord, puis dans la facture d’hébergement et de maintenance qui augmente avec elle. Et elle coûte en sécurité : chaque fonctionnalité est une porte d’entrée possible dans le système, avec ses propres failles, indépendantes de celles des autres.

Un site WordPress devient lent sans qu’on sache pourquoi

Après quelques années, un site a accumulé des fonctionnalités que plus personne n’utilise mais que personne n’a retirées, par prudence. Sur beaucoup de sites, elles continuent de se charger à chaque visite, même sur les pages où elles ne servent à rien – un chargement conditionnel bien fait limite ça, mais peu de sites le mettent réellement en place. La base de données pèse aussi lourd que le code : 50 articles publiés, chacun avec 200 versions de brouillon enregistrées en cours de route, ça fait une base qui traîne des dizaines de milliers de lignes inutiles. L’effet sur la vitesse dépend surtout des requêtes derrière chaque page, mais sur la majorité des sites que j’audite, cette dette a un coût mesurable. Le site devient lent progressivement, sans qu’aucun événement précis ne l’explique – c’est juste la somme de tout ce qui a été ajouté, écrit, et jamais nettoyé.

Le vrai coût de la maintenance WordPress

WordPress ne coûte pas cher le premier jour. C’est la somme des petites dépenses qui finit par peser : l’hébergement, d’abord – souvent facturé comme si WordPress ne demandait rien de plus qu’un site simple, alors que chaque fonctionnalité sollicite le serveur et la base de données à chaque visite. La maintenance, ensuite – proposée en abonnement séparé, parce qu’un site avec beaucoup de fonctionnalités ne se maintient pas tout seul : chacune reçoit des mises à jour de sécurité qu’il faut appliquer, tester, parfois corriger quand une mise à jour en casse une autre. Les fonctionnalités elles-mêmes, enfin – les mieux tenues sont de plus en plus vendues en abonnement plutôt qu’en achat unique. Ce n’est pas un abus isolé de tel ou tel prestataire : c’est la structure normale de l’écosystème – un modèle économique qui te tient captif. Une fois les habitudes prises et le contenu accumulé, changer de fournisseur de maintenance ou remplacer une fonctionnalité par une autre devient un chantier en soi, presque aussi lourd que de partir complètement. Personne ne te le dit clairement au moment de la vente.

Le piratage arrive même avec de la « maintenance »

Plus un site a de fonctionnalités, plus il a de portes d’entrée possibles – chacune peut avoir une faille découverte à un moment donné, indépendamment des autres. « Faire de la maintenance » veut dire, en théorie, surveiller toutes ces portes en continu et refermer chacune dès qu’une faille est publiée. En pratique, beaucoup de contrats de maintenance se limitent à une mise à jour mensuelle, ce qui laisse une fenêtre ouverte entre la publication d’une faille et sa correction – et c’est exactement dans cette fenêtre que la plupart des piratages ont lieu.

Cette fenêtre peut être minuscule et rester dangereuse. J’ai été touché par une faille majeure sur CyberPanel, l’outil que j’utilise pour administrer mes serveurs, exploitée dans l’heure qui a suivi sa découverte – avant même qu’un correctif officiel soit publié. Résultat : un mélange de minage de cryptomonnaie et de ransomware installé sur le serveur. Je m’en suis sorti sans perte parce que j’avais des sauvegardes récentes des sites clients à restaurer. Sans elles, le calcul aurait été très différent. Payer pour de la maintenance ne garantit rien si elle n’est pas assez réactive – et parfois, même la réactivité ne suffit pas : il faut aussi un filet de secours.

Les deux seuls avantages à quitter WordPress

Il y a deux avantages réels à sortir de WordPress, pas plus. Le premier, c’est la maintenance : plus de fonctionnalités à mettre à jour en continu, plus de correctif d’urgence à appliquer parce qu’une faille vient d’être découverte sur une fonctionnalité que tu avais oubliée. Le second, c’est la performance : un site statique bien construit passe sans effort au-dessus de 90 sur Lighthouse, là où un WordPress, même bien tenu, demande un travail constant pour s’en approcher – pour un coût d’hébergement dérisoire par rapport à WordPress, qui a besoin d’un serveur capable d’exécuter du code et d’interroger une base de données à chaque visite, alors qu’un site statique se contente de fichiers livrés tels quels.

C’est tout. Ce n’est pas rien, mais ce n’est que ça.

Ce que coûte une migration hors de WordPress

En face, il y a un chantier, pas une opération technique isolée. Migrer, c’est tout revoir : le design, souvent, parce qu’un thème WordPress ne se transpose pas tel quel en composants statiques. Les contenus et les images à reprendre – j’ai développé mes propres outils pour récupérer automatiquement les articles et les pages depuis WordPress, rapatrier les médias et optimiser les images, ce qui évite de tout reprendre à la main, mais ça ne dispense pas de vérifier chaque page une par une. Le référencement naturel à surveiller de près, parce qu’un changement d’architecture URL ou de structure de page peut coûter des positions durement acquises. Assisté par l’IA pour aller vite sur la partie code, et avec ces outils pour la partie contenu, c’est trois jours de travail minimum – pas une heure, pas une journée.

Face à ce coût, la question n’est pas « est-ce que le statique est meilleur ? » — il l’est, sur les deux points cités. La question est : est-ce que ces deux gains valent trois jours de chantier, une refonte de design et le risque SEO qui va avec ? Souvent, la réponse est non. On gagne plus, pour beaucoup moins cher, à corriger l’hébergement en place : mise à jour technique du cœur et des plugins, configuration correcte du cache, mise en place de Redis ou Memcached pour soulager la base. Ça règle la lenteur, ça règle une partie de la maintenance, et ça ne touche ni au design ni au référencement.

Ce qu’on garde en restant sous WordPress

Rester, ce n’est pas gratuit non plus. On hérite de la lourdeur propre à l’écosystème : mises à jour régulières obligatoires pour rester sécurisé, plugins performants souvent vendus en abonnement plutôt qu’en licence, dépendance continue à un tiers pour chaque brique un peu avancée. C’est un coût récurrent, diffus, qu’on paie chaque mois plutôt qu’une fois.

Migrer ou rester sous WordPress : le vrai calcul

La migration vers du statique se justifie quand la maintenance et la performance sont des problèmes réels et durables, pas des irritants ponctuels. Pour les clients qui choisissent cette voie, j’ai développé un bridge qui conserve Gutenberg comme interface d’édition : ils continuent à publier articles et pages depuis l’éditeur WordPress habituel, avec une édition avancée possible même pour les pages plus complexes. Ce n’est donc pas un renoncement à peser dans la balance – juste un point à vérifier avec le client avant de démarrer, pour que le futur fonctionnement du site soit clair dès le départ. Dans tous les autres cas – quand ni la maintenance ni la performance ne posent un problème réel – corriger l’hébergement existant coûte moins cher et résout l’essentiel. Le rôle du prestataire, ici, c’est de faire ce calcul avant de vendre le projet – pas après.

Si tu ne sais pas dans quel cas tu te trouves, c’est normal : de l’extérieur, un site lent et un site menacé se ressemblent. Un audit tranche la question sur des données concrètes plutôt que sur une impression – ce qui ralentit vraiment ton site, où sont les failles ouvertes, et si le problème se règle en une remise à niveau ou s’il demande une reconstruction.