Depuis plusieurs années, j’intègre un niveau de sécurité renforcé dans mes contrats de maintenance WordPress. Historiquement, j’ai utilisé SecuPress Pro, qui a été — et a longtemps mérité d’être — une référence française de la sécurité WordPress : durcissement, protection de la connexion, surveillance, etc.
Cependant, mon rôle de webmaster qui propose de la maintenance n’est pas de “défendre un outil”, mais de garantir la disponibilité et la stabilité des sites de mes clients. Or, depuis une mise à jour récente de SecuPress Pro (notamment la branche 2.6), j’ai observé un ensemble d’anomalies techniques suffisamment sérieuses pour perdre confiance dans sa fiabilité en production sur des sites clients.
L’objectif de cet article est d’être transparent sur :
-
les incidents rencontrés (factuels et vérifiables),
-
les impacts possibles sur un site WordPress,
-
la nouvelle stack de sécurité que je déploie dans le cadre de votre maintenance,
-
et ce que cela change (ou ne change pas) pour vous.
Important : cette démarche ne vise pas à dénigrer un éditeur. Elle vise à documenter un changement technique effectué pour maintenir un haut niveau de qualité de service.
SecuPress Pro : une référence… mais un outil doit rester fiable dans le temps
Ce que SecuPress Pro apportait dans une maintenance WordPress
Pendant plusieurs années, j’ai intégré SecuPress Pro dans les sites WordPress que je maintiens. L’outil proposait une approche complète de la sécurité WordPress :
-
durcissement des paramètres de sécurité (hardening),
-
protection contre les tentatives de connexion brute force,
-
surveillance de fichiers sensibles,
-
détection de plugins ou thèmes potentiellement vulnérables,
-
protection de l’URL de connexion WordPress,
-
blocage de certains comportements suspects.
Ce plugin avait également l’avantage d’être développé en France et bien intégré dans l’écosystème WordPress. Pour de nombreux professionnels du web, il a longtemps constitué une solution solide pour renforcer la sécurité d’un site sans complexifier l’administration.
C’est d’ailleurs pour cette raison qu’il a été intégré dans ma stack de maintenance pendant plusieurs années.
Pourquoi je privilégie désormais une approche “sécurité en couches”
Dans la maintenance WordPress moderne, la sécurité ne repose généralement pas sur un seul plugin, mais sur plusieurs niveaux de protection complémentaires.
On parle souvent de défense en profondeur :
-
Protection réseau : filtrer les attaques avant qu’elles n’atteignent le serveur.
-
Renforcement WordPress : sécuriser les accès et les paramètres internes.
-
Supervision technique : détecter les anomalies rapidement.
-
Protection applicative : limiter spam, brute force et comportements abusifs.
Cette approche présente un avantage important : si un outil rencontre un problème, les autres couches continuent de protéger le site.
C’est précisément cette logique qui m’a conduit à repenser l’architecture de sécurité utilisée dans mes contrats de maintenance.
Les problèmes rencontrés : des incidents factuels et répétitifs
Erreurs fatales (E_ERROR) sur plusieurs sites : is_processing() inexistante
Suite à une mise à jour récente de SecuPress Pro (version 2.6), plusieurs sites sous maintenance ont commencé à générer des erreurs fatales PHP dans leurs journaux techniques.
L’erreur la plus fréquente était :
Uncaught error: call to undefined method secupress_background_process_bad_plugins::is_processing()
ou
secupress_background_process_bad_themes::is_processing()
Ces erreurs indiquent que le code du plugin appelle une méthode (is_processing()) qui n’est pas définie dans la classe correspondante.
Modules concernés : détection plugins/thèmes + monitoring fichiers
Ces erreurs apparaissaient dans plusieurs modules du plugin :
-
détection de plugins vulnérables
-
détection de thèmes vulnérables
-
monitoring des fichiers du site
Ces fonctionnalités sont justement celles qui sont censées renforcer la sécurité du site, ce qui rend ces erreurs particulièrement problématiques.
Déclenchement via WP-Cron (exécution automatique)
Les erreurs étaient déclenchées par WP-Cron, le système de tâches planifiées de WordPress.
Cela signifie que :
-
l’erreur pouvait se produire automatiquement,
-
sans action d’un administrateur,
-
parfois en arrière-plan.
Dans certains cas, cela pouvait générer une accumulation d’erreurs dans les logs serveur.
Environnements différents, mêmes symptômes (PHP 7.4 / 8.2 / 8.3)
Ces erreurs ont été observées sur plusieurs environnements :
-
PHP 7.4
-
PHP 8.2
-
PHP 8.3
et sur différents hébergeurs.
Cela laisse penser que le problème n’était pas lié à une configuration spécifique d’hébergement, mais plutôt à une incompatibilité logicielle apparue après mise à jour.
Erreurs de type count() sur valeur null (TypeError)
Un second type d’erreur observé dans les logs était :
TypeError: count(): argument must be of type countable|array, null given
Ce type d’erreur se produit lorsqu’une fonction PHP tente de compter des éléments dans une variable qui ne contient pas de tableau.
Pourquoi ces erreurs sont bloquantes en PHP 8+
Depuis les versions récentes de PHP, la gestion des erreurs est devenue plus stricte.
Ce qui pouvait auparavant générer un simple avertissement peut désormais provoquer une erreur fatale, interrompant l’exécution du script.
Dans un environnement de production, ce type d’erreur peut entraîner :
-
une page blanche,
-
un blocage temporaire d’une fonctionnalité,
-
ou une dégradation des performances.
Parallèlement aux erreurs techniques, plusieurs anomalies ont été constatées dans la gestion de la licence :
-
certaines installations revenaient en version gratuite, malgré le paiement de la licence Pro,
-
l’interface de gestion des sites affichait des informations manquantes (version WordPress, PHP, etc.) et peu lisibles,
-
certains sites apparaissaient en doublon dans la licence (ex. version en www et sans www),
-
le bouton de désactivation ne fonctionnait plus (impossible de retirer un site web de la licence dans le cas d’un client perdu).
Ces anomalies peuvent compliquer la gestion lorsqu’on maintient plusieurs dizaines de sites.
Indisponibilité du service : erreur 503 sur secupress.me
À certaines périodes, l’accès à l’espace client du service renvoyait une erreur :
503 Service Unavailable
Rendant de ce fait l’accès au support technique impossible.
Retours d’expérience publics : problèmes de support et de licence signalés par d’autres utilisateurs
En effectuant quelques recherches, j’ai également trouvé plusieurs avis publics d’utilisateurs mentionnant :
-
des difficultés liées aux licences,
-
un manque de réponse du support,
-
ou des problèmes similaires.
Ces témoignages ne permettent évidemment pas de tirer de conclusion générale, mais ils montrent que certains utilisateurs ont rencontré des difficultés comparables.
Pour transparence, quelques exemples sont reproduits dans cet article.
Pourquoi ces incidents sont incompatibles avec une maintenance professionnelle
Risques pour la disponibilité des sites web
Dans un contexte de maintenance WordPress, la priorité est de garantir :
-
la disponibilité du site,
-
l’accès à l’administration,
-
et la stabilité globale.
Un plugin qui génère des erreurs fatales peut compromettre ces objectifs.
Même si les erreurs ne provoquent pas toujours une panne visible, elles peuvent perturber certaines tâches internes.
Temps d’intervention anormal : nettoyage .htaccess / wp-config.php après désactivation
Un autre problème rencontré l’a été lors de la désactivation du plugin avec la présence de règles de sécurité restées actives dans :
-
.htaccess -
wp-config.php
Certaines clés de sécurité WordPress (salts) avaient également été tout simplement supprimées.
Cela a nécessité une intervention manuelle sur plusieurs sites pour restaurer un fonctionnement normal.
La nouvelle stack de sécurité déployée dans ma maintenance WordPress
Afin de garantir la stabilité des sites que je maintiens, j’ai décidé de remplacer l’outil précédent par une stack plus robuste.
Cette stack repose sur plusieurs outils complémentaires.
Couche 1 : Cloudflare (gratuit) — protection réseau et anti-bots
Cloudflare agit comme un pare-feu réseau (WAF) placé devant le site.
Cela permet de bloquer :
-
bots malveillants
-
scans automatisés
-
attaques par force brute
-
certaines tentatives d’injection
avant même que ces requêtes n’atteignent le serveur du site.
Couche 2 : Solid Security (gratuit) — renforcement WordPress
Solid Security assure le durcissement interne du site WordPress :
-
limitation des tentatives de connexion
-
modification de l’URL de connexion
-
journalisation des accès
-
possibilité d’activer l’authentification à deux facteurs (2FA)
Couche 3 : Supervision / maintenance : WP Umbrella (déjà inclus dans mon process)
WP Umbrella permet de surveiller les sites :
-
disponibilité (uptime monitoring)
-
mises à jour
-
vulnérabilités connues
-
alertes techniques
Cela permet de détecter rapidement un problème.
Couche 4 : Anti-spam : Antispam Bee
Antispam Bee permet de limiter :
-
les commentaires indésirables
-
les tentatives automatisées de publication
sans utiliser de service externe ni de captcha intrusif.
Impact pour vous (clients)
Ce qui ne change pas : identifiants, contenus, fonctionnement du site
Cette évolution technique :
-
ne modifie pas votre contenu,
-
ne change pas vos identifiants,
-
n’impacte pas les fonctionnalités de votre site.
Elle fait simplement partie du travail de maintenance technique.
Ce qui peut changer : notifications, URL de connexion rappelée, 2FA optionnelle
Vous pourriez recevoir :
-
des notifications de sécurité,
-
un rappel de l’URL de connexion,
-
ou une invitation à activer l’authentification à deux facteurs.
Ces messages sont normaux et font partie du renforcement de la sécurité.
La sécurité d’un site WordPress n’est jamais figée.
Les outils évoluent, les technologies changent et il est parfois nécessaire d’adapter la stack utilisée pour garantir la stabilité et la sécurité des sites.
SecuPress Pro a longtemps été une solution pertinente et largement utilisée. Cependant, au regard des incidents rencontrés récemment sur plusieurs sites sous maintenance, j’ai choisi de privilégier une architecture plus robuste basée sur plusieurs couches de protection.
Cette transition s’inscrit dans une démarche simple : continuer à garantir un niveau de sécurité élevé tout en maintenant la stabilité des sites de mes clients.
Si vous possédez un site WordPress et que vous souhaitez :
-
améliorer sa sécurité,
-
éviter les pannes liées aux plugins,
-
bénéficier d’une surveillance technique continue,
je propose un service de maintenance WordPress incluant :
-
mises à jour sécurisées
-
surveillance du site
-
sauvegardes
-
sécurité renforcée
-
assistance technique
👉 N’hésitez pas à me contacter pour un audit rapide de votre site ou pour en savoir plus sur mes forfaits de maintenance.
FAQ
Est-ce que mon site a été piraté ?
Non.
Le changement d’outil de sécurité ne signifie absolument pas que votre site a été piraté.
Il s’agit simplement d’une évolution technique dans le cadre de la maintenance. Lorsqu’un outil de sécurité génère des erreurs techniques ou devient instable, il est préférable de le remplacer par une solution plus fiable afin d’éviter tout risque futur.
Votre site continue d’être surveillé et protégé.
Dois-je faire une action de mon côté ?
Dans la grande majorité des cas : non.
La transition vers la nouvelle solution de sécurité fait partie du travail de maintenance technique que j’assure.
Il peut arriver que vous receviez :
-
une notification de sécurité,
-
un rappel de l’URL de connexion,
-
ou une invitation à activer l’authentification à deux facteurs.
Ces messages sont normaux et ne nécessitent généralement aucune action urgente.
Si une action est réellement nécessaire, je vous en informerai directement.
L’URL de connexion à mon site WordPress a-t-elle changé ?
Non.
Dans la plupart des cas, l’URL de connexion reste identique à celle utilisée précédemment.
Certaines extensions de sécurité envoient simplement un email de notification rappelant l’adresse de connexion, ce qui peut donner l’impression qu’elle a changé.
Si une modification réelle devait être effectuée pour des raisons de sécurité, vous en seriez informé.
Mes identifiants et mots de passe ont-ils été modifiés ?
Non.
Votre identifiant et votre mot de passe restent les mêmes.
Le changement d’outil de sécurité n’a aucun impact sur :
-
votre compte utilisateur,
-
vos accès au site,
-
vos contenus.
La double authentification est-elle obligatoire ?
Non, elle n’est pas obligatoire.
Cependant, elle est fortement recommandée, surtout pour les comptes administrateurs.
L’authentification à deux facteurs ajoute une couche de sécurité supplémentaire : après avoir saisi votre identifiant et votre mot de passe, un code temporaire est demandé pour valider la connexion.
Cela permet de protéger votre compte même si votre mot de passe venait à être compromis.
Comment fonctionne l’authentification à deux facteurs ?
Lorsque la double authentification est activée :
-
Vous entrez votre identifiant et votre mot de passe.
-
Un second code est demandé pour valider la connexion.
Ce code peut être obtenu via :
-
une application mobile d’authentification (Google Authenticator, Authy…)
-
un code envoyé par email
-
des codes de secours enregistrés lors de la configuration.
Le code généré change généralement toutes les 30 secondes, ce qui rend les accès non autorisés beaucoup plus difficiles.
Pourquoi changer d’outil de sécurité ?
Dans le cadre d’une maintenance professionnelle, la priorité est de garantir :
-
la stabilité du site,
-
la disponibilité de l’administration,
-
et un niveau de sécurité fiable dans le temps.
Lorsque des anomalies techniques apparaissent (erreurs, dysfonctionnements, indisponibilité d’un service…), il peut être nécessaire d’adapter les outils utilisés.
Ce changement vise simplement à maintenir un environnement technique plus stable et plus robuste.
Est-ce que cela rend mon site moins sécurisé ?
Non, au contraire.
La nouvelle configuration repose sur une approche en plusieurs couches de sécurité, ce qui est aujourd’hui considéré comme une bonne pratique.
Elle combine :
-
un pare-feu réseau (Cloudflare),
-
un outil de sécurité WordPress,
-
un système de supervision technique,
-
et des protections anti-spam.
Cette architecture permet de répartir les mécanismes de protection plutôt que de dépendre d’un seul outil.
Est-ce que ce changement va ralentir mon site ?
Non.
Les outils utilisés sont justement choisis pour limiter l’impact sur les performances.
Par exemple, certaines protections sont appliquées au niveau du réseau (Cloudflare) avant même que les requêtes n’atteignent le serveur du site.
Cela permet souvent d’améliorer la stabilité globale.
Est-ce que ce changement entraîne un coût supplémentaire ?
Non.
Cette évolution fait partie de la gestion technique de la maintenance et n’entraîne pas de facturation supplémentaire pour les sites déjà sous contrat.
Que faire si je reçois un email de sécurité WordPress ?
La plupart du temps, il s’agit simplement de notifications automatiques.
Si un email vous semble inhabituel ou si vous avez un doute, le plus simple est de me le transférer afin que je puisse vérifier.
Mon site est-il toujours surveillé ?
Oui.
Dans le cadre de la maintenance WordPress, votre site bénéficie toujours :
-
d’un suivi technique,
-
d’un monitoring,
-
de mises à jour régulières,
-
et d’une surveillance des vulnérabilités.
L’objectif reste le même : éviter les incidents avant qu’ils ne se produisent.
Puis-je activer moi-même la double authentification ?
Oui, je vous ai rédigé un guide pour activer la double authentification Solid Security.
Si vous souhaitez renforcer la sécurité de votre compte, je peux également vous accompagner.
N’hésitez pas à me contacter si vous souhaitez mettre en place cette protection supplémentaire.
