Trois ans sans entretien : ce qui arrive vraiment à un site WordPress

Le site a été lancé avec soin. Les photos étaient belles, le formulaire fonctionnait, le conseil d’administration était content. Puis la personne qui s’en occupait est partie, le budget a servi ailleurs, et le site a continué de tourner. En apparence, rien n’a changé.

C’est le piège. Un site WordPress ne tombe pas en panne d’un coup. Il se dégrade par couches, sans bruit, et chaque couche coûte plus cher à réparer que la précédente.

L’entretien d’un site web d’organisme sert précisément à interrompre ce mouvement. Des mises à jour, des sauvegardes, une surveillance, quelques vérifications régulières : rien de spectaculaire. C’est justement ce qui disparaît quand personne n’en a la charge.

En bref

• Un site WordPress ne tombe pas en panne d’un coup : il se dégrade par couches, et chaque couche coûte plus cher à réparer que la précédente.
• Depuis la version 3.7, WordPress applique seul les mises à jour de sécurité mineures de son cœur ; les extensions et le thème, non.
• Selon Patchstack, 91 % des nouvelles vulnérabilités de l’écosystème WordPress en 2025 se trouvaient dans les extensions.
• PHP 8.1 ne reçoit plus de correctifs depuis le 31 décembre 2025 ; PHP 8.2 cessera le 31 décembre 2026.
• L’entretien préventif tient en quelques gestes répétés : mises à jour vérifiées, sauvegardes hors du serveur, test des formulaires.

Les six premiers mois : rien ne se voit

Un site WordPress repose sur trois couches qui évoluent chacune de leur côté : le logiciel WordPress lui-même, le thème qui lui donne son apparence, et les extensions qui ajoutent des fonctions, comme le formulaire de don ou le calendrier d’activités. Chacune reçoit des mises à jour régulières.

Pendant les premiers mois, ces mises à jour s’accumulent dans le tableau de bord. Une pastille rouge affiche un chiffre qui grossit. Le site, lui, fonctionne normalement. Personne ne voit de raison d’intervenir.

WordPress envoie pourtant des avis par courriel : mise à jour appliquée, problème détecté. Ils partent vers l’adresse de l’administrateur inscrite à l’installation. Si c’était celle d’une personne qui a quitté l’organisme, ces avis n’arrivent plus à personne.

Une partie du travail se fait quand même toute seule. Depuis la version 3.7, WordPress applique automatiquement les mises à jour de sécurité mineures de son cœur. C’est une bonne nouvelle, et les données le confirment : dans son rapport portant sur 2023, l’entreprise de sécurité Sucuri note que ces mises à jour automatiques ont nettement réduit les attaques visant le cœur de WordPress.

Le problème se déplace donc ailleurs. Les extensions et le thème, eux, ne se mettent pas à jour seuls à moins que quelqu’un l’ait activé, extension par extension. Et c’est précisément là que se concentrent les failles.

De six à dix-huit mois : les premiers symptômes

Les premiers signes sont rarement techniques. Ce sont des petits dérangements qu’on attribue à autre chose.

Le formulaire de contact n’envoie plus rien, ou les messages aboutissent dans les indésirables. Souvent, personne ne s’en rend compte avant qu’un partenaire ne téléphone pour dire qu’il a écrit trois fois sans réponse. Un formulaire qui échoue en silence est le symptôme le plus coûteux de cette période, justement parce qu’il ne se voit pas.

La mise en page commence aussi à se décaler sur téléphone. Un bouton déborde, un menu ne s’ouvre plus, une image s’affiche en double. Les navigateurs évoluent, le thème ne suit pas.

Le site ralentit, enfin. Les extensions désactivées mais jamais supprimées s’empilent, la base de données grossit, les images ajoutées au fil des publications n’ont jamais été optimisées. Aucun de ces problèmes n’est grave seul. Ensemble, ils envoient aux visiteurs le message d’un organisme qui ne suit plus.

De dix-huit à trente-six mois : l’effet domino

C’est la période où la dette technique devient visible, et où les réparations cessent d’être simples.

La version de PHP. WordPress fonctionne grâce à un langage de programmation, PHP, installé sur le serveur. Selon le calendrier publié par le projet PHP, chaque version reçoit deux ans de support complet, puis deux ans de correctifs de sécurité seulement. Ensuite, plus rien. PHP 8.1 a cessé de recevoir des correctifs le 31 décembre 2025, et PHP 8.2 cessera à son tour le 31 décembre 2026.

Un site qui tourne sur une version abandonnée fonctionne encore. Mais chaque faille découverte dans cette version reste ouverte. Et le jour où l’hébergeur impose une version plus récente, les vieilles extensions qui n’ont jamais été mises à jour peuvent cesser de fonctionner, parfois en affichant une page blanche.

Les extensions abandonnées. Une extension installée en 2023 n’a peut-être plus d’auteur actif aujourd’hui. Dans son rapport sur 2024, l’entreprise Patchstack indique que plus de la moitié des développeurs d’extensions auxquels elle a signalé une faille ne l’avaient pas corrigée avant sa divulgation publique. Dans son rapport sur 2025, elle situe 91 % des nouvelles vulnérabilités de l’écosystème WordPress dans les extensions, 9 % dans les thèmes, et seulement six, de faible gravité, dans le cœur.

Les incompatibilités en cascade. Après trois ans, on ne peut plus tout mettre à jour d’un coup sans risque. Mettre à jour le thème exige une version récente de WordPress, qui exige elle-même une version récente de PHP, qui fait tomber une extension que plus personne ne maintient. Ce qui aurait pris quelques minutes par mois devient un chantier à planifier, avec une copie de test du site.

Quand une faille est exploitée

Un site piraté ne s’annonce pas toujours. Les attaques les plus courantes cherchent justement à rester discrètes, pour utiliser le site le plus longtemps possible.

Le rapport de Sucuri sur 2023 donne une idée de ce qu’on retrouve lors d’un nettoyage. Des comptes administrateurs malveillants étaient présents dans 55,2 % des bases de données infectées : l’intrus s’était créé un accès pour revenir. Du pourriel destiné aux moteurs de recherche était présent sur 20,3 % des sites infectés. Le même rapport précise qu’au moment de l’infection, 39,1 % des sites touchés tournaient avec une version périmée de leur logiciel de gestion, et que 13,97 % comportaient au moins une extension ou un thème vulnérable.

Ces chiffres portent sur les sites que Sucuri a nettoyés, et l’entreprise précise qu’ils ne représentent pas l’ensemble du Web. Ils montrent tout de même la forme que prend une intrusion : un accès caché, du contenu étranger injecté, et un site qui continue d’afficher sa page d’accueil normale.

Pour un organisme, les conséquences dépassent la technique. Les navigateurs peuvent afficher un avertissement aux visiteurs avant même qu’ils atteignent votre page. Les donateurs qui voient ce message ne reviennent pas forcément. Le nettoyage, lui, se fait dans l’urgence : il faut trouver quelqu’un disponible, restaurer une sauvegarde saine si elle existe, retrouver la porte d’entrée pour qu’elle ne serve pas une deuxième fois, puis changer tous les mots de passe.

Si votre site est relié à la Search Console de Google, un avertissement de sécurité peut aussi y apparaître. Encore faut-il que quelqu’un consulte ce compte.

Et si aucune sauvegarde récente n’existe, le nettoyage devient une reconstruction partielle.

Ce que coûte l’inverse

L’entretien préventif n’a rien de mystérieux. Il tient en quelques gestes répétés, dont aucun n’est long pris isolément.

• Appliquer les mises à jour du cœur, du thème et des extensions, en vérifiant le site après chaque passage.
• Supprimer les extensions inutilisées plutôt que de les laisser désactivées.
• Faire des sauvegardes automatiques, conservées hors du serveur, et tester de temps en temps qu’on sait les restaurer.
• Surveiller la version de PHP et planifier le passage à la suivante avant sa fin de support.
• Envoyer un message test par chaque formulaire, au moins une fois par mois.
• Surveiller la disponibilité du site pour être averti d’une panne avant les visiteurs.

Ce contrôle après chaque mise à jour peut s’automatiser. Chez 1001Web, nous avons publié une extension gratuite sur WordPress.org, 1001Web Maintenance & Launch Pages, qui affiche une page de maintenance pendant les mises à jour, suspend le cache, puis compare les pages principales avant et après pour signaler celles qui ont cessé de répondre.

Une précaution change beaucoup de choses : une copie de test du site, sur laquelle on applique les mises à jour délicates avant de toucher au site public. Si quelque chose casse, c’est la copie qui casse, pas la page que vos donateurs consultent.

Pris un par un, ces gestes prennent peu de temps. Ce qui coûte cher, c’est de les rattraper tous en même temps après trois ans, ou de les découvrir en pleine crise. La vraie comparaison n’est donc pas entre « payer l’entretien » et « ne rien payer ». Elle se fait entre un coût régulier et prévisible, et un coût imprévisible qui tombe au pire moment, souvent en pleine campagne de financement.

Beaucoup d’organismes n’ont simplement personne dont c’est le rôle. Ce n’est pas une négligence : c’est un angle mort. La première étape consiste à le nommer. Qui, dans votre organisme ou chez un fournisseur, est responsable de ces gestes, et à quelle fréquence ?

Ouvrez le tableau de bord de votre site et regardez le nombre de mises à jour en attente, puis la version de PHP indiquée dans l’outil de santé du site. Ces deux chiffres vous diront en cinq minutes à quelle année de ce récit votre site se trouve.

Sources consultées le 11 septembre 2026. Sucuri : « 2023 Hacked Website & Malware Threat Report » (données de nettoyage de 2023, publiées en juin 2024). Patchstack : « State of WordPress Security in 2025 » et « State of WordPress Security in 2026 ». Projet PHP : page « Supported Versions » (php.net) et calendriers de fin de support des versions 8.1 et 8.2.

Serge, webmestre chez 1001Web, agence web à Montréal (Anjou) depuis 2008, spécialisée dans les sites d’OBNL et d’OSBL.