Nous avons supprimé WordPress de notre propre site

Le point de départ

Notre ancien site faisait ce qu’on lui demandait. Il était propre, il chargeait correctement, il n’avait pas été négligé.

Mais en regardant honnêtement son usage, un constat s’imposait :

• le contenu changeait quelques fois par mois, pas plusieurs fois par jour,
• une seule personne y publiait,
• aucune vente, aucun catalogue, aucun compte client,
• et pourtant, chaque visite déclenchait une exécution PHP et des requêtes en base.

Autrement dit : nous faisions tourner un moteur d’édition permanent pour un contenu quasi figé.
Un CMS résolvait un problème que nous n’avions plus.

Ce que nous avons construit à la place

Le nouveau site est généré statiquement. À chaque mise en ligne, l’ensemble des pages est produit une fois pour toutes, puis servi tel quel.

Concrètement, cela donne :

• Aucune base de données. Rien à interroger, rien à sauvegarder, rien à corrompre.
• Aucune extension. Chaque fonctionnalité est écrite, donc comprise et maîtrisée.
• Aucune surface d’administration publique. Il n’existe pas de page de connexion à attaquer.
• Un contenu versionné. Chaque modification est tracée, datée, réversible.

Le site compte aujourd’hui 103 adresses publiées, en français, en néerlandais et en anglais, générées à partir d’une source unique.

Ce que ça coûte réellement

Un article honnête doit nommer les contreparties. Elles sont réelles.

• Plus de tableau de bord. On ne corrige pas une coquille depuis un navigateur, dans le train.
• Chaque modification passe par une mise en ligne. Quelques minutes, pas quelques secondes.
• Le contenu devient du code. C’est rigoureux, mais ce n’est pas ouvert à tout le monde.
• La traduction se gère à la main. Aucun plugin ne la fabrique à notre place.

Pour une agence qui maîtrise sa propre chaîne technique, ces contraintes sont acceptables.
Pour un client qui publie trois actualités par semaine, elles seraient absurdes.

Les chiffres, et ce qu’ils ne disent pas

C’est ici que le sujet devient intéressant, parce que la mesure contredit l’intuition.

En conditions de laboratoire, sans scripts tiers, le site obtient un score de performance mobile de 95 sur 100. Premier affichage à 0,9 seconde, décalage visuel nul.

En conditions réelles, le même site, la même page, sur le même serveur : 71.

L’écart ne vient pas du code. Il vient de deux scripts que nous avons choisi de garder : la bannière de gestion des cookies et le suivi statistique.

La leçon est inconfortable mais utile :

• une refonte technique parfaite ne garantit pas un bon score public,
• les scripts tiers pèsent souvent plus lourd que l’ensemble du site,
• et un score PageSpeed mesure une page réelle, pas la qualité d’un développement.

Nous aurions pu retirer ces scripts et publier un joli 95.
Nous aurions perdu le consentement des visiteurs et toute mesure d’audience. Le score aurait été meilleur, le site moins utile.

Migrer sans perdre son référencement

Changer de technologie ne doit jamais coûter une position acquise.

Avant la bascule, nous avons relevé les 34 adresses réellement indexées de l’ancien site, puis vérifié une par une leur destination dans le nouveau. Trente-trois correspondaient à une page existante ; la dernière a reçu une redirection explicite.

S’y ajoutent les éléments que l’on oublie systématiquement :

• les flux RSS hérités du CMS, redirigés vers le nouveau flux,
• les données structurées, réécrites plutôt que reconduites,
• le plan de site, soumis aux moteurs dès la mise en ligne,
• le protocole IndexNow, qui signale les changements en heures plutôt qu’en semaines.

Une migration réussie ne se voit pas. C’est exactement son objectif.

Alors pourquoi continuons-nous à recommander WordPress ?

Parce que le problème n’a jamais été WordPress.

WordPress est un excellent outil dès qu’un site vit : quand plusieurs personnes publient, quand un catalogue évolue, quand le contenu est le cœur du projet plutôt que sa vitrine.

Ce que nous refusons, ce n’est pas le CMS. C’est la manière dont on l’assemble trop souvent :

• un thème générique acheté puis surchargé,
• une trentaine d’extensions empilées par facilité,
• un constructeur de pages qui produit un balisage illisible,
• et personne, au bout du compte, pour expliquer ce que fait réellement le site.

Notre approche est constante depuis des années : nous développons des thèmes sur mesure et nous éliminons la quasi-totalité des extensions au profit de code écrit pour le projet.

Le bénéfice est mesurable sur quatre plans :

• Performance. Seul le nécessaire est chargé, parce que rien n’est générique.
• Sécurité. Chaque extension retirée est une porte d’entrée en moins.
• Fiabilité. Une mise à jour ne casse pas ce qui ne dépend de personne.
• Longévité. Un site qu’on comprend se fait maintenir dix ans, pas dix-huit mois.

Un WordPress construit ainsi n’a rien à envier à un site statique. Il vit simplement, en plus.

La vraie question : que fait votre site ?

Le choix technique ne se décide pas par préférence, mais par usage.

Un CMS s’impose quand :

• plusieurs personnes doivent publier en autonomie,
• le contenu change chaque semaine ou plus souvent,
• un catalogue, des stocks ou des commandes sont en jeu,
• des comptes clients ou un espace privé existent.

Un site généré statiquement suffit quand :

• le contenu est stable et structurant,
• l’édition reste entre peu de mains,
• la performance et la sécurité priment sur la souplesse d’édition,
• et que le site doit tenir des années sans maintenance corrective.

Notre site relevait du second cas. La plupart des projets de nos clients relèvent du premier.

Conclusion

Nous n’avons pas quitté WordPress. Nous avons cessé de l’utiliser là où il ne servait à rien.

La bonne question n’est pas :

“Quelle technologie est la meilleure ?”

Mais :

“Qu’est-ce que ce site doit faire, et pendant combien d’années ?”

Une agence qui répond toujours la même chose ne raisonne pas : elle applique une habitude.
C’est cette exigence de raisonnement que nous appliquons chez Inside Web, sur notre propre site comme sur ceux que nous construisons.