Audit WordPress avec WP Doctor : guide 2026

Un audit WordPress complet consiste à contrôler au minimum la sécurité exposée publiquement, le temps de réponse, le cache, les balises SEO, le sitemap et les directives d’indexation. WP Doctor automatise ce premier diagnostic depuis votre terminal, sans installer de plugin sur le site audité. Une commande produit un score sur 100, une note de A à F, des preuves vérifiables et un plan de correction classé par gravité. Dans ce tutoriel, nous allons installer l’outil, lancer un audit réel sur wpadminlab.com, lire chaque résultat, exporter un rapport HTML et intégrer le contrôle dans une chaîne CI.

Le but n’est pas de remplacer un pentest, PageSpeed Insights ou Google Search Console. WP Doctor sert de contrôle technique reproductible : la même commande peut être relancée après une mise à jour, une migration ou une modification du serveur. L’outil est open source, écrit en Python, sans dépendance externe et conçu pour n’envoyer que des requêtes HTTP publiques. Vous gardez donc la méthode, le rapport et les données de l’audit sur votre machine.

Qu’est-ce qu’un audit WordPress complet ?

Un audit WordPress est une photographie technique du site à un instant précis. Il répond à des questions simples mais déterminantes : le site est-il accessible en HTTPS ? Des fichiers sensibles sont-ils servis publiquement ? Les utilisateurs peuvent-ils être énumérés ? La page d’accueil répond-elle rapidement ? Un cache est-il détectable ? Les robots de recherche trouvent-ils un title, une description, une URL canonique, des données structurées, un fichier robots.txt et un sitemap ?

Il faut distinguer ce diagnostic externe d’un audit interne. Depuis l’extérieur, un outil voit ce qu’un visiteur, un robot ou un attaquant non authentifié peut demander. Il peut analyser les en-têtes HTTP, le HTML, les redirections, les fichiers connus et les endpoints publics de WordPress. En revanche, il ne lit pas la base de données, les options privées, les journaux du serveur, les comptes administrateurs ou le contenu des fichiers PHP. Cette limite n’est pas un défaut : elle définit précisément le périmètre.

Un contrôle complet combine donc plusieurs couches. WP Doctor couvre le diagnostic HTTP externe. L’outil Santé du site de WordPress couvre une partie de l’environnement interne. Search Console mesure le crawl et l’indexation. Un scanner de vulnérabilités comme WPScan rapproche les versions détectées d’une base de CVE. Enfin, une revue humaine vérifie la logique métier, les permissions, les sauvegardes et la restauration. Ce tutoriel vous montre comment faire de WP Doctor la première étape rapide de cette chaîne.

Pourquoi utiliser WP Doctor plutôt qu’une checklist manuelle ?

Une checklist papier est utile pour cadrer un audit, mais elle devient vite incohérente dès que plusieurs sites ou plusieurs dates sont concernés. Un technicien peut oublier un endpoint, interpréter différemment un code HTTP ou ne pas conserver la preuve observée. WP Doctor transforme les vérifications répétitives en code : même ordre, mêmes seuils, mêmes formats de sortie et même calcul du score.

L’outil présente quatre avantages pratiques. Premièrement, il ne demande aucun accès wp-admin. Deuxièmement, il ne dépose aucun plugin sur le site cible. Troisièmement, son code est consultable sur GitHub, ce qui permet de vérifier exactement les chemins testés et la logique de détection. Quatrièmement, il sait sortir du JSON et renvoyer un code d’erreur : un audit peut ainsi devenir un contrôle automatique dans GitHub Actions, GitLab CI ou un script de déploiement.

WP Doctor est particulièrement utile après une migration, un changement de thème, l’installation d’un cache, une modification de robots.txt, un durcissement des en-têtes ou une mise en production. On lance l’audit avant l’intervention, on conserve le rapport, on applique les corrections, puis on relance exactement la même commande. La différence entre les deux rapports devient une preuve de résultat plutôt qu’une impression.

Ce que WP Doctor vérifie réellement

Le moteur est organisé en trois catégories : sécurité, performance et SEO technique. Il commence par normaliser l’URL et récupérer une seule fois la page d’accueil. Cette réponse sert à détecter WordPress, le thème visible, les éventuels plugins exposés et les caractéristiques générales du serveur. Les modules spécialisés lancent ensuite leurs requêtes publiques et agrègent les observations.

Sécurité HTTP et empreinte WordPress

Le module de sécurité examine les en-têtes HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy et Permissions-Policy. Il teste l’exposition de fichiers courants comme .env, wp-config.php.bak, debug.log, .git/config, backup.sql, readme.html ou license.txt. Il vérifie aussi XML-RPC, l’énumération via l’API REST, la redirection ?author=1, la page de connexion et le listing de répertoires.

Performance observable depuis l’extérieur

Le module de performance mesure le temps de réponse HTTP, cherche les en-têtes de cache courants, contrôle la compression gzip ou Brotli, estime le poids du HTML et compte les ressources CSS/JavaScript. Il repère également un grand nombre d’images sans lazy-loading ou le chargement du script emoji de WordPress.

SEO technique de la page d’accueil

Le module SEO contrôle le title, la meta description, la canonical, Open Graph, les données structurées, le H1, la langue du document, robots.txt, le sitemap et un éventuel noindex sur la home. Il sait distinguer un Disallow: / appliqué à tous les robots d’une règle réservée à un bot particulier, ce qui évite un faux positif classique.

Prérequis et règle d’autorisation avant de scanner

WP Doctor exige Python 3.8 ou une version plus récente. Aucun paquet tiers n’est requis : le projet utilise la bibliothèque standard de Python pour les requêtes, l’analyse et la génération des rapports. Git est recommandé pour cloner le dépôt, mais vous pouvez aussi télécharger l’archive depuis GitHub.

N’auditez que votre propre site ou un site pour lequel vous disposez d’une autorisation explicite. Même si WP Doctor reste passif, un audit envoie plusieurs requêtes vers des chemins sensibles connus. Sur un site tiers, cette activité peut être considérée comme une reconnaissance non sollicitée. Pour un client, inscrivez le domaine, la date, le créneau et le périmètre dans l’autorisation de test.

Le mode normal vérifie le certificat TLS. L’option --insecure existe pour diagnostiquer un environnement de test avec un certificat autosigné, mais elle ne doit pas devenir la commande habituelle en production. Un certificat invalide est lui-même une information importante. De la même manière, --quick réduit le nombre de requêtes : utilisez-le pour un contrôle fréquent, puis gardez l’audit complet pour les revues planifiées.

Installer WP Doctor sous Linux

Sous Ubuntu, Debian, Fedora ou une autre distribution récente, vérifiez d’abord Python et Git. Le dépôt contient un pyproject.toml, donc l’installation locale suit le mécanisme standard de Python. Un environnement virtuel évite de mélanger l’outil avec les paquets système.

python3 --version
git --version

git clone https://github.com/wpadminlab/wp-doctor.git
cd wp-doctor
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install .

wp-doctor --version
wp-doctor --help

Si votre distribution bloque l’installation globale avec le message « externally-managed-environment », ne forcez pas avec des options risquées. Utilisez l’environnement virtuel montré ci-dessus ou lancez directement le module depuis le dépôt avec python3 -m wpdoctor. Le résultat fonctionnel est le même ; seule la manière d’appeler la commande change.

Installer WP Doctor sous macOS

macOS peut fournir une version ancienne de Python ou ne pas exposer la commande attendue. Installez Python 3 avec l’installeur officiel ou Homebrew, puis vérifiez que python3 pointe vers une version récente. Les Mac Intel et Apple Silicon suivent ensuite les mêmes étapes.

brew install python git

git clone https://github.com/wpadminlab/wp-doctor.git
cd wp-doctor
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install .
wp-doctor exemple.com

Si vous utilisez zsh, l’activation reste source .venv/bin/activate. Pour quitter l’environnement, saisissez deactivate. Conservez le dépôt dans un dossier de travail, car il contient aussi un exemple de rapport HTML et les tests unitaires du projet.

Installer WP Doctor sous Windows

Sous Windows 10 ou 11, installez Python depuis python.org et cochez l’option qui ajoute Python au PATH. Git for Windows fournit la commande git. PowerShell utilise un chemin d’activation différent de Linux.

py --version
git --version

git clone https://github.com/wpadminlab/wp-doctor.git
cd wp-doctor
py -m venv .venv
..venvScriptsActivate.ps1
py -m pip install .
wp-doctor --help

Si PowerShell refuse l’activation, vous pouvez lancer directement .venvScriptspython.exe -m wpdoctor exemple.com sans modifier la politique d’exécution. Cette solution est plus prudente que de désactiver globalement une protection Windows. Dans l’invite de commandes classique, le script d’activation est .venvScriptsactivate.bat.

Lancer son premier audit WordPress

La commande minimale accepte un domaine ou une URL. Si aucun schéma n’est donné, WP Doctor ajoute HTTPS. Un chemin éventuel est retiré afin de repartir de la racine du site : l’audit concerne l’installation WordPress, pas seulement l’article transmis.

wp-doctor exemple.com

# Équivalent sans installation de la commande
python3 -m wpdoctor https://exemple.com

Le rapport terminal commence par la cible normalisée, l’heure UTC et l’empreinte WordPress détectée. Il affiche ensuite le score, la note et le nombre d’observations par gravité. Les résultats sont regroupés par sécurité, performance et SEO. Chaque observation comprend un titre, une explication, une recommandation et, lorsque c’est possible, une preuve : code HTTP, valeur d’en-tête, URL de redirection ou nombre d’éléments.

Ne corrigez pas immédiatement tout ce qui apparaît. Commencez par sauvegarder le rapport et vérifier les éléments critiques ou élevés. Une réponse HTTP 200 ne prouve pas toujours qu’un fichier existe : un WAF peut renvoyer la page d’accueil avec un code 200. WP Doctor filtre plusieurs signatures de soft-404 et compare les titres, mais une validation manuelle reste nécessaire avant une modification.

Comprendre le score sur 100 et la note A à F

Le score part de 100. Une observation critique retire 40 points, une gravité élevée 20 points, une moyenne 10 points et une faible 4 points. Les informations n’abaissent pas le score : elles donnent du contexte. La note traduit le résultat en classes lisibles, de A pour un site bien configuré à F pour une exposition grave.

Ce score sert à prioriser et à comparer un site avec lui-même. Il ne faut pas l’utiliser comme certification universelle. Deux sites notés 80 peuvent présenter des risques très différents : l’un manque de HSTS et de CSP, l’autre expose plusieurs informations faibles. La liste détaillée compte davantage que la note seule.

Pour piloter un chantier, conservez trois colonnes : observation, décision et preuve après correction. Certaines recommandations seront appliquées immédiatement ; d’autres seront acceptées parce qu’une fonction l’exige. Par exemple, XML-RPC peut être nécessaire à une intégration. Une CSP stricte peut casser un thème si elle est copiée sans inventaire des scripts. L’objectif n’est donc pas d’atteindre 100 à n’importe quel prix, mais de documenter chaque écart.

Faire un audit de sécurité WordPress ciblé

Pour isoler la sécurité, utilisez --only security. Le module testera les en-têtes, les chemins sensibles et les surfaces publiques de WordPress sans exécuter de mot de passe, d’exploitation ou de brute-force.

wp-doctor exemple.com --only security
wp-doctor exemple.com --only security --quick
wp-doctor exemple.com --only security --format html -o securite.html

Traitez d’abord les fichiers capables de révéler un secret : .env, sauvegarde de wp-config.php, dump SQL, archive de sauvegarde ou dépôt Git. Une vraie exposition critique justifie de retirer immédiatement le fichier, de bloquer le chemin, puis de renouveler les secrets potentiellement compromis. Masquer seulement l’URL ne suffit pas si le contenu a déjà été téléchargé.

Les en-têtes demandent plus de nuance. HSTS ne doit être activé qu’après avoir confirmé que le domaine et les sous-domaines fonctionnent entièrement en HTTPS. Une Content-Security-Policy doit être observée en mode rapport avant d’être bloquante. À l’inverse, X-Content-Type-Options: nosniff et une Referrer-Policy prudente sont généralement moins risqués. Notre guide sur les en-têtes de sécurité WordPress et la CSP détaille cette mise en œuvre.

Interpréter l’énumération des utilisateurs et XML-RPC

L’endpoint public /wp-json/wp/v2/users peut révéler des slugs d’auteur. La redirection ?author=1 peut produire le même effet. Cette information n’est pas une compromission, mais elle réduit le travail d’un attaquant qui prépare un brute-force : il ne lui reste plus qu’à deviner le mot de passe.

La bonne correction dépend de l’usage éditorial. Vous pouvez dissocier le nom de connexion du nicename public, restreindre l’endpoint utilisateurs pour les visiteurs non authentifiés et bloquer l’énumération par paramètre. Ne cassez pas toute l’API REST : Gutenberg, des applications et des intégrations en dépendent. Ajoutez surtout une authentification multifacteur, une limitation des tentatives et des mots de passe uniques.

XML-RPC n’est pas automatiquement une faille. Il devient une surface inutile si aucune application distante, aucun service compatible ou aucun flux Jetpack ne l’utilise. WP Doctor le signale lorsque le serveur accepte la requête. Si vous n’en avez pas besoin, bloquez xmlrpc.php au niveau du serveur. Sinon, limitez les méthodes et surveillez les appels plutôt que de désactiver une dépendance à l’aveugle.

Auditer les performances WordPress sans navigateur lourd

Le module performance ne remplace pas Lighthouse. Il fournit un contrôle HTTP rapide : temps de réponse, compression, cache visible, volume du HTML et nombre de ressources. Ce périmètre est utile en CI, car il s’exécute rapidement et ne dépend pas d’un navigateur graphique.

wp-doctor exemple.com --only performance
wp-doctor exemple.com --only performance --format json | jq '.meta.final_ttfb_ms'

Le temps mesuré correspond à la requête observée depuis la machine qui lance l’audit. Il inclut le réseau, le TLS et le serveur ; il doit donc être comparé depuis un environnement stable. Un résultat ponctuel n’est pas un SLA. Relancez plusieurs fois et rapprochez-le des données de terrain.

L’absence d’en-tête de cache signifie seulement que WP Doctor n’a pas trouvé les signatures connues comme x-litespeed-cache, x-cache, cf-cache-status, x-proxy-cache ou age. Un serveur peut cacher la page sans exposer ces valeurs. Vérifiez avec votre hébergeur et notre guide pour identifier les différentes couches de cache WordPress avant d’installer un second plugin concurrent.

Auditer le SEO technique de WordPress

Le contrôle SEO cible les erreurs capables de bloquer ou de dégrader la compréhension du site. Lancez-le seul lorsque vous modifiez un plugin SEO, le thème, robots.txt ou le sitemap.

wp-doctor exemple.com --only seo
wp-doctor exemple.com --only seo --format markdown -o audit-seo.md

Une home en noindex ou un Disallow: / appliqué à User-agent: * est critique. Un sitemap absent ou une meta description manquante est moins urgent, mais mérite une correction. La canonical doit pointer vers la version choisie du domaine. Open Graph améliore la présentation lors du partage, tandis que JSON-LD fournit du contexte aux moteurs et aux systèmes de réponse.

WP Doctor vérifie la page d’accueil et les fichiers de crawl, pas chaque article. Pour un audit éditorial complet, il faut ensuite parcourir les URL du sitemap, contrôler les titles dupliqués, les canoniques, le maillage et les statuts d’indexation. Consultez notre diagnostic « Explorée, actuellement non indexée » lorsque la technique est correcte mais que Google refuse encore certaines pages.

Utiliser le mode rapide et combiner plusieurs catégories

L’option --quick limite certains chemins sensibles afin de réduire le nombre de requêtes. Elle convient à une vérification fréquente après déploiement. L’option --only est répétable : vous pouvez combiner sécurité et SEO sans exécuter la performance.

wp-doctor exemple.com --quick
wp-doctor exemple.com --only security --only seo
wp-doctor exemple.com --only performance --quick --no-color

Adaptez le mode au risque. Un contrôle à chaque commit peut être rapide et ciblé. Une revue hebdomadaire peut utiliser les trois catégories. Un audit mensuel peut conserver HTML, JSON et captures, puis être rapproché des journaux, de Search Console et d’un test de restauration.

Exporter un rapport HTML lisible

Le rapport HTML est autonome : il peut être ouvert localement, archivé dans un ticket ou joint à un compte rendu. Il reprend la note, les compteurs, les catégories, les preuves et les recommandations dans une mise en page imprimable.

wp-doctor exemple.com --format html -o rapport-wordpress.html

# Linux
xdg-open rapport-wordpress.html

# macOS
open rapport-wordpress.html

Évitez de publier un rapport brut qui révèle des slugs d’utilisateurs, des chemins ou des détails d’infrastructure. Pour ce tutoriel, nous avons masqué l’identifiant d’auteur dans les captures tout en conservant le résultat original dans notre archive privée. Un rapport destiné à un client doit être partagé par un canal protégé et supprimé selon votre politique de conservation.

Exploiter les formats JSON et Markdown

Le JSON est le meilleur format pour les tableaux de bord et la CI. Le document contient la cible, la date, le score, la note, les compteurs, les métadonnées WordPress et la liste structurée des observations. Chaque finding expose son identifiant de contrôle, sa catégorie, sa gravité, son détail, sa recommandation et sa preuve.

wp-doctor exemple.com --format json -o audit.json
jq '.score, .grade, .counts' audit.json
jq '.findings[] | select(.severity == "critical")' audit.json

wp-doctor exemple.com --format markdown -o audit.md

Markdown s’intègre naturellement à une issue GitHub, une pull request ou une documentation interne. JSON permet d’établir des tendances, mais ne comparez pas seulement le score : stockez aussi les identifiants des findings. La disparition d’une alerte et l’apparition d’une autre peuvent laisser le total inchangé tout en modifiant fortement le risque.

Cas réel : audit de wpadminlab.com avec WP Doctor

Nous avons exécuté WP Doctor le 18 juillet 2026 sur wpadminlab.com. Le site répondait en HTTP 200, WordPress et le thème personnalisé étaient détectés, et le temps de réponse observé était d’environ 114 ms. Le score obtenu était de 52/100, note D : quatre observations moyennes, deux faibles et deux informatives.

Le rapport a signalé l’absence de CSP et de HSTS, l’énumération d’un auteur via l’API REST et ?author=1, l’accès à readme.html et license.txt, l’absence de Permissions-Policy et aucun en-tête de cache reconnu. Aucun problème SEO n’a été remonté sur la home : title, description, canonical, données structurées, H1, langue, robots.txt et sitemap répondaient aux contrôles implémentés.

Ce résultat illustre pourquoi un audit est utile même sur un site fonctionnel. Un temps de réponse rapide ne prouve pas que les en-têtes de sécurité sont complets. Un sitemap correct ne protège pas les slugs d’auteurs. À l’inverse, la note D ne signifie pas que le site est compromis : aucune ressource critique comme .env, sauvegarde de configuration, dépôt Git ou dump SQL n’a été trouvée.

Transformer le rapport en plan de correction

La priorité ne suit pas toujours l’ordre visuel. Commencez par confirmer les expositions critiques et élevées. Ensuite, traitez les observations moyennes qui réduisent réellement la surface d’attaque. Enfin, planifiez les améliorations faibles et informatives.

1. Protéger les secrets. Retirer les sauvegardes, dumps, journaux ou dépôts exposés ; renouveler les clés si nécessaire.
2. Réduire l’énumération. Masquer le login réel, restreindre les endpoints inutiles et ajouter 2FA plus limitation des tentatives.
3. Durcir les en-têtes. Déployer HSTS seulement après validation HTTPS ; tester la CSP en mode rapport.
4. Vérifier le cache. Confirmer la couche active avant d’installer ou de remplacer un plugin.
5. Corriger le crawl. Retirer noindex ou Disallow accidentels, restaurer sitemap et canonical.
6. Relancer l’audit. Archiver le rapport après correction et documenter les risques acceptés.

Pour les erreurs WordPress qui empêchent d’appliquer ces changements, commencez par notre guide de diagnostic de l’erreur 500 WordPress ou celui consacré à un wp-admin inaccessible. Un durcissement doit rester réversible : sauvegarde avant modification, test de santé et procédure de retour arrière.

Intégrer WP Doctor dans GitHub Actions

L’option --fail-on renvoie un code de sortie 2 lorsqu’une observation atteint le seuil demandé ou une gravité supérieure. Elle permet de bloquer une étape CI sans analyser du texte. Le workflow suivant audite un site de staging après déploiement.

name: Audit WordPress
on:
  workflow_dispatch:
  schedule:
    - cron: '15 6 * * 1'

jobs:
  wp-doctor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: python -m pip install .
      - run: wp-doctor https://staging.exemple.com --quick --fail-on high
      - run: wp-doctor https://staging.exemple.com --format json -o audit.json
      - uses: actions/upload-artifact@v4
        with:
          name: rapport-wp-doctor
          path: audit.json

Ne lancez pas un audit agressif sur chaque commit. Le mode rapide et un planning raisonnable réduisent le bruit. Protégez les URL de staging privées et n’utilisez pas --insecure pour masquer une mauvaise configuration TLS. Consultez la documentation officielle de GitHub Actions pour les permissions, secrets et artefacts.

Utiliser WP Doctor dans une procédure de déploiement

Un contrôle de déploiement doit répondre à une question binaire : la mise en production a-t-elle introduit une régression importante ? Conservez un audit de référence, puis testez l’URL après purge du cache. Un finding critique ou élevé doit arrêter la livraison ; une alerte faible peut créer un ticket sans rollback automatique.

set -e
wp-doctor "$SITE_URL" --quick --fail-on high
wp-doctor "$SITE_URL" --format json -o "audit-$(date +%F).json"

# Vérification complémentaire du statut HTTP
curl -fsSIL "$SITE_URL" | head

Ajoutez des contrôles métier indépendants : connexion, panier, formulaire, paiement et tâche cron. WP Doctor ne connaît pas votre tunnel de conversion. Il vérifie l’infrastructure publique, pas le comportement interne de l’application. C’est précisément pour cela qu’il s’intègre bien dans une suite plus large au lieu de prétendre tout remplacer.

WP Doctor, WPScan, Site Health et PageSpeed : quelle différence ?

WP Doctor réalise un audit HTTP généraliste et reproductible sur trois axes. WPScan est plus spécialisé dans l’empreinte de WordPress et les vulnérabilités connues ; certaines fonctions dépendent de sa base de données et de son API. Site Health s’exécute à l’intérieur de WordPress et voit PHP, la base, les modules et les tâches planifiées. PageSpeed Insights mesure le rendu et les Core Web Vitals avec Lighthouse et, lorsque disponibles, les données réelles du Chrome UX Report.

Ces outils ne sont pas concurrents au sens strict. Utilisez WP Doctor pour le contrôle de premier niveau et la CI ; WPScan ou Jetpack Protect pour les CVE ; Site Health et WP-CLI pour l’environnement interne ; PageSpeed pour le rendu ; Search Console pour l’indexation. Un audit professionnel ajoute encore les droits, les sauvegardes, la restauration, les journaux, la configuration serveur et les tests métier.

La différence de WP Doctor tient à sa transparence : pas de compte, pas de plugin, un code court que vous pouvez adapter et des formats exportables. Sa limite est symétrique : il ne possède pas aujourd’hui une base de vulnérabilités de milliers de plugins et ne pilote pas un navigateur complet.

Limites, faux positifs et interprétation responsable

Un scanner externe voit des symptômes. Un en-tête absent peut être compensé ailleurs ; un cache actif peut ne pas annoncer sa signature ; un WAF peut servir une page d’erreur avec un code 200 ; un contenu peut varier selon le pays ou le User-Agent. Confirmez toujours une observation importante avec curl, les outils du navigateur et la configuration du serveur.

WP Doctor ne détecte pas un malware caché dans la base, un compte administrateur compromis, une extension vulnérable non identifiable, une élévation de privilèges, une logique de paiement cassée ou une restauration impossible. Il n’exécute aucun exploit. Il ne doit donc jamais être présenté comme une preuve d’absence de piratage.

La mesure de performance est instantanée et dépend du réseau. Le SEO porte principalement sur la home et les fichiers de crawl. Une page d’accueil parfaite n’implique pas que 400 articles possèdent des titles uniques ou soient indexés. Utilisez le rapport comme porte d’entrée vers des contrôles plus profonds, pas comme une certification marketing.

Méthode d’audit WordPress mensuel reproductible

Une bonne fréquence dépend du rythme de changement. Pour un site éditorial actif, nous recommandons un contrôle rapide après chaque déploiement, un rapport complet hebdomadaire ou mensuel et un audit interne trimestriel. Une boutique ou un site critique mérite une surveillance plus fréquente.

1. Sauvegarder et tester la restauration
2. Lancer WP Doctor et archiver JSON + HTML
3. Contrôler Site Health, mises à jour et comptes admin
4. Vérifier Search Console, sitemap et indexation
5. Tester PageSpeed et les parcours métier
6. Classer les écarts : corriger, accepter ou surveiller
7. Relancer l’audit et joindre les preuves

Donnez un propriétaire et une échéance à chaque correction. Le rapport n’a de valeur que s’il déclenche une décision. Pour éviter la dérive, stockez la date, la version du thème, la version de WP Doctor et l’environnement depuis lequel le test a été lancé.

Comprendre l’architecture de WP Doctor avant de lui faire confiance

Un outil d’audit mérite d’être audité lui aussi. Le point d’entrée de WP Doctor se trouve dans le module de ligne de commande. Il analyse les arguments, choisit les catégories, appelle l’orchestrateur puis confie le rendu au format demandé. Cette séparation évite qu’une modification visuelle du rapport change la logique de détection.

L’orchestrateur normalise d’abord la cible. Une saisie comme exemple.com/article/ devient https://exemple.com/. Il récupère la home, mesure la réponse, détecte les indices WordPress et lance les modules sélectionnés. Les observations sont ensuite triées par gravité décroissante puis par catégorie. Cette architecture rend chaque contrôle indépendant : une nouvelle vérification peut retourner un objet Finding sans réécrire la CLI.

Le client HTTP impose des limites de taille et des délais afin qu’un serveur lent ou un fichier énorme ne bloque pas indéfiniment l’audit. Le module de sécurité compare aussi le contenu suspect à la page d’accueil. Si .env renvoie le même title que la home, l’outil comprend qu’un routeur ou un WAF a probablement servi une page de remplacement. Pour les fichiers qui ne devraient jamais contenir de HTML, une réponse HTML est également considérée comme un fallback possible.

Le projet contient seize tests unitaires qui couvrent notamment les soft-403/404, les faux fichiers sensibles, l’analyse des groupes de robots.txt et le calcul du score. Nous les avons exécutés avant la démonstration : les seize réussissaient. Vous pouvez reproduire ce contrôle avant chaque mise à jour.

cd wp-doctor
python3 -m unittest discover tests -v

# Vérifier précisément la version utilisée
git rev-parse --short HEAD
wp-doctor --version

Cette transparence distingue une méthode reproductible d’une boîte noire. Si vous contestez un seuil ou souhaitez ajouter un en-tête propre à votre infrastructure, vous pouvez lire la condition, écrire un test et proposer une modification. En production, épinglez un commit ou une version afin que deux audits comparés utilisent la même logique.

Confirmer manuellement chaque finding important

Un audit automatisé doit toujours déboucher sur une preuve indépendante. Pour vérifier un en-tête, utilisez curl -I. Pour une redirection, désactivez le suivi automatique. Pour un fichier sensible, téléchargez seulement les premiers octets, sans enregistrer ni diffuser un secret. Si le site ne vous appartient pas, n’effectuez aucune vérification supplémentaire hors du périmètre autorisé.

URL='https://exemple.com/'

# En-têtes de sécurité, cache et compression
curl -sSI "$URL" | tr -d 'r' 
  | grep -iE 'strict-transport|content-security|permissions|cache|age|content-encoding'

# Redirection d’auteur sans la suivre
curl -sSI "${URL}?author=1" | grep -iE 'HTTP/|location:'

# Statut du fichier readme, sans télécharger le corps
curl -sS -o /dev/null -w '%{http_code}n' "${URL}readme.html"

# robots.txt et sitemap
curl -fsS "${URL}robots.txt"
curl -sS -o /dev/null -w '%{http_code}n' "${URL}sitemap.xml"

Une CSP absente se confirme dans les en-têtes de la réponse HTML, pas dans une balise ajoutée par JavaScript. HSTS n’est valable que sur HTTPS. Un en-tête Age ou X-LiteSpeed-Cache peut varier entre la première et la deuxième requête ; comparez plusieurs appels déconnectés. Pour la compression, envoyez explicitement Accept-Encoding: gzip, br, car certains clients n’annoncent pas les algorithmes supportés.

curl -sSI -H 'Accept-Encoding: gzip, br' https://exemple.com/ 
  | grep -iE 'content-encoding|vary|content-length'

curl -sSI https://exemple.com/
sleep 2
curl -sSI https://exemple.com/

Pour l’API REST, ne copiez jamais dans un ticket public la liste complète des utilisateurs. Notez seulement que l’endpoint est accessible, le nombre d’entrées et la correction retenue. Pour un fichier critique réellement exposé, cessez la collecte dès que la preuve est suffisante. Retirez l’accès, examinez les journaux et renouvelez les identifiants susceptibles d’avoir été révélés.

La validation manuelle sert aussi à détecter les limites du scanner. Un CDN peut présenter des en-têtes différents selon le pays. Une extension de sécurité peut autoriser votre IP mais bloquer les visiteurs. Une page de maintenance peut masquer le HTML réel. Consignez donc l’heure, l’adresse testée, les redirections et le contexte d’authentification.

Créer une matrice de priorité adaptée au site

La gravité technique n’est qu’un axe. Ajoutez l’exposition, la facilité d’exploitation, l’impact métier et le coût de correction. Un fichier de configuration contenant des secrets publics cumule tous les critères : traitement immédiat. Une Permissions-Policy absente sur un blog simple peut attendre une fenêtre de maintenance. Une home en noindex est un problème SEO critique même si elle n’affecte pas la sécurité.

• Secret ou sauvegarde accessible — priorité immédiate : confirmer le contenu réel, bloquer l’accès, supprimer la copie et renouveler les secrets.
• Noindex ou robots bloquant — priorité immédiate : vérifier la directive sur la version canonique, la corriger puis demander un nouveau crawl.
• Énumération d’auteur — priorité haute : confirmer le slug révélé, dissocier le login public, limiter les tentatives et activer la 2FA.
• CSP absente — intervention planifiée : inventorier les sources, tester Content-Security-Policy-Report-Only puis déployer progressivement.
• Cache non détecté — priorité selon le trafic : confirmer le comportement avec l’hébergeur et deux requêtes avant de configurer une seule couche de cache.

Après correction, ajoutez la preuve inverse : code 403 ou 404 pour un fichier, endpoint filtré, en-tête présent, sitemap en 200, ou disparition du finding dans le JSON. Cette discipline empêche de fermer un ticket simplement parce qu’un réglage a été modifié dans l’administration.

Construire un rapport d’audit exploitable par une équipe

Un rapport technique devient utile lorsqu’un développeur, un responsable SEO et un décideur peuvent comprendre la même situation. Commencez par un résumé d’une page : cible, date, périmètre, score, changements depuis le rapport précédent et trois priorités. Ajoutez ensuite le rapport WP Doctor, les validations manuelles et les actions assignées.

Ne promettez jamais « site sécurisé à 100 % ». Écrivez plutôt : « aucun fichier critique n’a été détecté dans le périmètre HTTP public testé à cette date ». Cette formulation est plus précise et résiste mieux aux évolutions. Mentionnez les limites : absence d’accès serveur, pas de scan de base, pas d’exploitation, page d’accueil seulement pour plusieurs contrôles SEO.

Pour un client, séparez les preuves sensibles de la synthèse. Le document partagé largement peut masquer les slugs et chemins. L’annexe technique reste dans un espace protégé. Attribuez à chaque finding un état — nouveau, confirmé, faux positif, accepté, corrigé — et une date de revérification. Un risque accepté n’est pas oublié : il possède un motif et un propriétaire.

Enfin, comparez les audits dans le temps. Un score qui progresse de 52 à 80 est encourageant, mais la tendance détaillée est plus importante : disparition de l’énumération, ajout progressif des en-têtes, cache confirmé, absence durable de noindex et stabilité du temps de réponse. WP Doctor fournit la matière structurée ; votre processus transforme ces données en gouvernance technique.

Questions fréquentes sur l’audit WordPress avec WP Doctor

WP Doctor est-il gratuit ?

Oui. Le code est publié sous licence MIT sur GitHub. Vous pouvez l’utiliser, l’auditer et l’adapter dans le respect de la licence et de l’autorisation du site testé.

Faut-il installer un plugin WordPress ?

Non. WP Doctor s’exécute sur votre ordinateur ou dans la CI et interroge uniquement les ressources publiques du site. Il n’a pas besoin d’un compte wp-admin.

WP Doctor peut-il détecter tous les malwares ?

Non. Il peut repérer certaines ressources exposées et mauvaises configurations visibles, mais il ne lit ni les fichiers PHP privés ni la base. Un soupçon de compromission exige une analyse interne et des journaux.

Peut-on auditer plusieurs sites ?

Oui, en appelant la commande pour chaque domaine autorisé et en enregistrant un fichier distinct. Évitez les boucles rapides et adaptez la fréquence à la capacité des serveurs.

Pourquoi mon score change-t-il entre deux exécutions ?

Le cache, le réseau, un CDN, une mise à jour ou une réponse conditionnelle peuvent modifier les observations. Comparez les findings détaillés et relancez depuis un environnement stable avant de conclure.

WP Doctor remplace-t-il WPScan ?

Non. WPScan est plus orienté vulnérabilités WordPress et base de CVE. WP Doctor couvre un diagnostic transversal sécurité, performance et SEO avec exports et seuil CI. Les deux sont complémentaires.

Peut-on utiliser WP Doctor sur un site de client ?

Oui, avec une autorisation explicite définissant la cible et le créneau. Sans autorisation, abstenez-vous, même si l’outil ne tente aucune exploitation.

Télécharger WP Doctor et commencer l’audit

Le projet, les sources, les tests et un exemple de rapport sont disponibles sur le dépôt GitHub WP Doctor. Clonez le dépôt, créez un environnement virtuel et lancez d’abord l’audit sur un site que vous contrôlez. Conservez le JSON initial : il servira de référence à chaque correction.

git clone https://github.com/wpadminlab/wp-doctor.git
cd wp-doctor
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install .
wp-doctor votre-site.fr --format html -o premier-audit.html

Si le rapport révèle une erreur critique ou si votre administration est inaccessible, ne modifiez pas dix paramètres à la fois. Sauvegardez, confirmez l’observation, appliquez une correction réversible et relancez le même test. C’est cette boucle — mesurer, décider, corriger, vérifier — qui transforme un scanner en véritable méthode d’exploitation WordPress.

Sources officielles et références

• WordPress Developer Resources — Hardening WordPress
• WordPress REST API Handbook
• OWASP Secure Headers Project
• MDN — Content-Security-Policy
• Documentation Python — environnements virtuels venv
• Documentation GitHub Actions
• Google Search Central — robots.txt
• WPScan — base et scanner de vulnérabilités WordPress