Audit de sécurité WordPress avec IA : guide étape par étape (2026)

Instalar un plugin de seguridad y dar por hecho que ya estás protegido es el error más repetido en WordPress. Un plugin vigila; una auditoría comprueba. Son cosas distintas, y solo la segunda te dice dónde estás realmente expuesto.

La buena noticia es que una auditoría de seguridad, que hace unos años exigía leer decenas de páginas de documentación, hoy se puede hacer con la inteligencia artificial como copiloto en una tarde. La mala es que hay una parte que la IA no debe decidir por ti, y conviene tenerla clara desde el principio.

Qué aporta la IA en una auditoría de seguridad (y qué no)

Conviene ser honesto antes de empezar, porque hay mucha promesa inflada sobre esto.

La IA es muy buena en:

• Leer un listado largo de plugins con sus versiones y decirte cuáles llevan años sin actualizarse.
• Traducir un aviso técnico de vulnerabilidad a un lenguaje que entiendas.
• Revisar un fichero de configuración y señalar líneas sospechosas.
• Priorizar: ordenar veinte hallazgos por riesgo real en lugar de dejarte una lista plana.
• Redactar el informe final para que puedas pasárselo a un cliente o a tu equipo.

La IA no debe hacer:

• Decidir si una vulnerabilidad te afecta. Eso se comprueba contra la base de datos oficial, no se pregunta.
• Confirmar que una web está limpia. Un modelo puede afirmarlo con toda seguridad y estar equivocado.
• Ejecutar cambios en producción. La IA propone, tú aplicas, y siempre con copia de seguridad delante.

Con esa frontera clara, vamos al procedimiento.

Paso 1: levanta el inventario

No puedes auditar lo que no sabes que tienes. El primer paso es una lista completa de lo que corre en tu WordPress: versión del núcleo, tema activo, tema padre si usas uno hijo, todos los plugins (activos e inactivos) con su número de versión, y la versión de PHP.

El detalle que casi todo el mundo pasa por alto: los plugins desactivados también son código presente en el servidor. Un plugin desactivado con una vulnerabilidad conocida sigue siendo un fichero al que se puede llegar por URL. Si no lo usas, no lo desactives: bórralo.

Para sacar el listado sin instalar nada, ve a Plugins > Plugins instalados, selecciona todo el texto de la tabla y pégalo en un documento. En Outils > Santé du site > Informations tienes la versión de PHP, la del servidor y la de la base de datos, todo junto y copiable con un botón.

Si mantienes varias webs, este inventario merece vivir en una hoja de cálculo y actualizarse cada trimestre. Es la base de todo lo demás.

Étape 2 : confrontez aux vulnérabilités connues

Voici l'étape que la plupart des gens sautent et celle qui évite le plus de problèmes.

Il existe des bases de données publiques qui enregistrent les vulnérabilités publiées des plugins et thèmes WordPress. Les deux de référence sont WPScan y Patchstack. Les deux ont un moteur de recherche web gratuit : vous entrez le nom du plugin et il vous dit s'il y a des vulnérabilités enregistrées et dans quelles versions.

La procédure correcte est la suivante :

1. Prenez votre inventaire de l'étape 1.
2. Demandez à l'IA de trier la liste par ancienneté de la dernière mise à jour, en marquant ceux qui n'ont pas été touchés depuis plus d'un an.
3. Recherchez un par un dans WPScan ou Patchstack ceux que l'IA a marqués.
4. Notez : nom, version que vous avez, version corrigée, gravité.

Notez l'ordre. L'IA délimite le travail —elle vous dit quoi regarder en premier— mais la vérification, vous la faites vous-même contre la source officielle. Demander directement à un modèle « le plugin X version 2.1 a-t-il des vulnérabilités ? » est une mauvaise idée : les données de vulnérabilités changent chaque semaine et le modèle peut répondre avec confiance sur quelque chose qu'il ne sait pas.

Si un plugin a une vulnérabilité sans correctif disponible, la décision n'est pas technique mais commerciale : chercher une alternative, ou assumer le risque en le documentant. Dans notre guide sur comment mettre à jour les plugins WordPress de manière sécurisée nous expliquons comment appliquer ces mises à jour sans casser le site en chemin.

Étape 3 : vérifiez les utilisateurs et les accès

La voie d'entrée la plus courante n'est pas une vulnérabilité exotique : c'est un compte qui ne devrait pas exister ou un mot de passe faible.

Dans Utilisateurs, vérifiez :

• Combien d'administrateurs il y a. Ils devraient être le strict minimum. Chaque administrateur est une clé maîtresse.
• Comptes de personnes qui ne sont plus là: l'ancienne agence, le stagiaire de l'été dernier, le développeur de cette commande ponctuelle.
• Comptes avec nom générique comme « admin », « wordpress » ou « test ».
• Date du dernier accès, si votre plugin de sécurité l'enregistre. Un compte administrateur que personne n'utilise depuis huit mois est un risque sans contrepartie.

Et concernant les mots de passe : n'en réutilisez aucun, et qu'ils soient longs. Vous pouvez en créer un en deux secondes avec notre générateur de mots de passe sécurisés, qui fonctionne dans votre propre navigateur sans rien envoyer à aucun serveur.

Activez également la vérification en deux étapes pour tous les comptes administrateur. C'est la mesure qui offre le meilleur rapport effort-protection de toute cette liste.

Étape 4 : vérifiez l'intégrité des fichiers

WordPress publie les sommes de contrôle de tous les fichiers de chaque version du noyau. Cela permet de détecter si l'un d'eux a été modifié.

Les plugins de sécurité sérieux incluent cette vérification. Dans Wordfence, c'est dans Analyse, et comparez vos fichiers du noyau, thèmes et plugins du dépôt officiel avec les originaux. Si un fichier modifié que vous n'avez pas touché apparaît, vous avez là quelque chose à investiguer.

Deux avertissements importants concernant les résultats :

• Les faux positifs existent. Un thème enfant, un snippet personnalisé ou une personnalisation légitime apparaîtront comme « modifié ». Ce n'est pas une attaque.
• Que rien n'apparaisse ne signifie pas que vous êtes propre. Un fichier malveillant nouveau dans un dossier d'uploads n'apparaît pas comme « modifié » car il n'y avait pas d'original avec lequel le comparer.

Ici, l'IA aide vraiment : collez-lui le contenu d'un fichier suspect et demandez-lui de vous expliquer ce qu'il fait. Elle est particulièrement douée pour détecter le code obfusqué —ces très longues lignes remplies de base64_decode y eval qui n'ont aucune raison légitime d'être dans un thème. Si vous avez déjà des indices que le site est compromis, notre guide de nettoyage d'un WordPress sous attaque couvre le processus complet de désinfection, qui est un travail distinct de cet audit.

Étape 5 : auditez la configuration

C'est la partie où l'IA est la plus performante, car il s'agit de lire la configuration et de détecter les écarts.

Vérifiez ces points :

• Édition de fichiers depuis le tableau de bord. Si un attaquant entre avec un compte administrateur, l'éditeur de thèmes lui donne une exécution de code directe. Il se désactive avec define('DISALLOW_FILE_EDIT', true); en wp-config.php.
• Débogage en production. WP_DEBUG doit être à false sur un site web en production. S'il est actif, les messages d'erreur peuvent révéler des chemins de serveur.
• Permissions des fichiers. L'habituel est 644 pour les fichiers et 755 pour les dossiers. Rien ne devrait être en 777.
• XML-RPC. Si vous n'utilisez pas l'application mobile WordPress ni Jetpack, vous n'en avez probablement pas besoin, et c'est une cible habituelle des attaques par force brute.
• Affichage des répertoires. Entra en tudominio.com/wp-content/uploads/. Si vous voyez une liste de dossiers au lieu d'une erreur, vous avez l'affichage des répertoires actif et il convient de le désactiver.
• Version de PHP. Une version sans support ne reçoit pas de correctifs de sécurité. Nous avons un guide sur comment mettre à jour PHP dans WordPress sans avoir de mauvaises surprises.

Un prompt qui fonctionne bien pour cette phase, en collant en dessous votre wp-config.php avec les identifiants de base de données et les clés de sécurité supprimés:

«Tu es un auditeur de sécurité WordPress. Je te transmets un wp-config.php avec les données sensibles déjà supprimées. Examine la configuration et dis-moi : quelles constantes de sécurité recommandées manquent, quels réglages sont inappropriés pour un environnement de production, et ce que tu trouves qui n'est pas standard pour une installation normale. Classe les constats par risque, du plus élevé au moins élevé, et pour chacun explique la conséquence concrète s'il est exploité. N'invente pas : si tu ne peux pas déterminer quelque chose avec ce que je t'ai donné, dis-le.»

Cette dernière phrase est importante. Demander explicitement qu'il reconnaisse ce qu'il ne sait pas réduit considérablement les réponses inventées.

Étape 6 : révisez les en-têtes de sécurité

Les en-têtes HTTP sont des instructions que votre serveur envoie au navigateur du visiteur. Bien configurées, elles bloquent des familles entières d'attaques.

Vérifiez les vôtres dans un analyseur gratuit comme securityheaders.com: vous entrez votre domaine et il vous donne une note avec ce qui manque. Celles qui importent le plus sont Strict-Transport-Security, qui oblige à toujours utiliser HTTPS ; X-Content-Type-Options, qui empêche le navigateur de deviner les types de fichiers ; et Content-Security-Policy, la plus puissante et aussi la plus facile à mal configurer.

Concernant cette dernière, un conseil pratique : une CSP mal écrite casse le site web, et a tendance à casser précisément ce qui rapporte de l'argent (le formulaire, la passerelle de paiement, le chat). Si vous l'implémentez, faites-le d'abord en mode rapport uniquement pendant quelques jours pour voir ce qu'elle bloquerait avant de l'appliquer réellement.

Étape 7 : transforme les constats en un plan

Un audit qui se termine par une liste de vingt choses éparses ne sert à rien, car personne ne sait par où commencer. C'est là que l'IA boucle la boucle.

Transmets-lui tous tes constats et demande-lui de les organiser ainsi :

«Je te transmets les résultats d'un audit de sécurité WordPress. Organise-les dans un tableau avec ces colonnes : constat, risque (élevé/moyen/faible), effort de correction (minutes/heures/jours) et ordre d'exécution recommandé. Priorise par risque divisé par effort, de sorte que le premier soit ce qui protège le plus avec le moins de travail. Ajoute une colonne finale indiquant si le changement peut casser le site web et doit être effectué dans un environnement de test.»

Cette dernière colonne est celle qui vous épargne les ennuis. Il y a des corrections que vous appliquez à chaud sans crainte, et d'autres — toucher aux permissions, changer la version de PHP, insérer une CSP — qui sont testées au préalable dans un environnement de test.

Les limites : quand cela ne suffit pas

Tout ce qui précède est un audit de configuration et de surface d'attaque. Il couvre l'énorme majorité des cas réels, car l'énorme majorité des WordPress compromis le sont à cause d'un plugin obsolète ou d'un mot de passe faible, et non d'une attaque sophistiquée.

Il y a des situations où cela est insuffisant et il convient qu'une personne y jette un œil :

• Il y a déjà des signes de compromission: redirections étranges, spam dans les résultats Google, avertissements du navigateur. Ce n'est plus un audit, c'est une réponse à incident, et l'ordre des tâches est complètement différent.
• Le site web gère des paiements ou des données personnelles sensibles. Là entrent en jeu des obligations légales qu'aucun outil automatique n'évaluera pour vous.
• Il y a du développement sur mesure. Un plugin propriétaire ou un thème fait à la main ont leur propre code, et ce code n'a jamais été révisé par personne. Un audit de configuration ne le couvre pas.
• C'est un site web critique pour l'entreprise. Si un jour d'interruption vous coûte plus cher qu'une révision professionnelle, le calcul est vite fait.

Questions fréquentes

À quelle fréquence devrais-je auditer mon WordPress ?

Une révision complète comme celle de ce guide, deux fois par an. La vérification des vulnérabilités de l'étape 2, chaque mois : c'est celle qui expire le plus rapidement, car de nouvelles vulnérabilités sont publiées chaque semaine. Et toujours après un changement majeur, comme l'ajout d'un plugin important ou le changement de thème.

Puis-je transmettre mon wp-config.php entier à une IA ?

Non, pas sans le nettoyer d'abord. Ce fichier contient le nom d'utilisateur et le mot de passe de votre base de données ainsi que les clés de sécurité des sessions. Supprimez ces valeurs, remplacez-les par du texte générique et alors seulement vous pourrez demander la révision. Il en va de même pour tout fichier journal susceptible de contenir des adresses IP ou des données utilisateur.

Un plugin de sécurité remplace-t-il l'audit ?

Non, ils font des choses différentes. Le plugin est une surveillance continue : il bloque les tentatives d'accès, filtre le trafic et signale les changements. L'audit est une révision ponctuelle pour vérifier si votre configuration est correcte et si votre logiciel est à jour. Un plugin de sécurité parfaitement configuré ne vous protège pas d'un plugin avec une vulnérabilité connue que vous n'avez pas mis à jour depuis deux ans. Si vous voulez tirer le meilleur du vôtre, nous avons un guide de paramètres peu connus de Wordfence.

Que faire si je trouve quelque chose de grave ?

Avant de toucher à quoi que ce soit, sauvegarde complète : fichiers et base de données. Appliquez ensuite la correction dans un environnement de test si le changement est délicat, et en production s'il est trivial (mettre à jour un plugin, supprimer un compte). Si ce que vous avez trouvé est un fichier malveillant, ne vous contentez pas de le supprimer : ils ne viennent presque jamais seuls, et il faut découvrir par où il est entré ou il réapparaîtra.

Pour finir

L'intelligence artificielle ne fait pas l'audit pour vous, mais elle transforme une tâche de spécialiste en quelque chose que vous pouvez faire avec méthode. Elle délimite où regarder, traduit le jargon technique et organise le résultat en un plan exécutable.

Ce qu'elle ne délègue pas, c'est le jugement : quel risque vous assumez, ce que vous vérifiez par rapport à la source officielle et quels changements vous testez avant d'appliquer. Cette partie reste la vôtre, et c'est précisément ce qui fait la différence entre un véritable audit et une liste de recommandations génériques.

Si vous voulez continuer par ici, dans notre bibliothèque d'outils gratuits vous avez des utilitaires qui fonctionnent entièrement dans votre navigateur, sans rien télécharger sur aucun serveur.