Analyse de risques WordPress : une méthode simple

Une analyse de risques pour un site WordPress tient sur une page. Elle recense ce que vous possédez, ce qui peut réellement mal tourner, la gravité des conséquences, et qui corrige quoi, pour quand. Vous pouvez en rédiger une première version cet après-midi avec la méthode en cinq étapes ci-dessous. Vous obtenez un document concret à présenter quand un questionnaire client, un assureur ou une autorité de contrôle vous demande comment vous avez choisi vos mesures de sécurité.

Pourquoi l'analyse de risques passe en premier avec le RGPD et NIS 2

L'article 32, paragraphe 1, du RGPD exige des mesures techniques et organisationnelles appropriées au risque, compte tenu de l'état des connaissances et des coûts de mise en œuvre. Impossible de démontrer qu'une mesure est appropriée sans avoir dit quel est le risque. L'article 5, paragraphe 2, ajoute que vous devez pouvoir démontrer votre conformité : l'analyse doit donc être écrite. Notre article sur l'article 32 du RGPD appliqué à WordPress traite des mesures elles-mêmes.

Si votre entreprise entre dans le champ de la directive NIS 2, la liste des mesures minimales de l'article 21, paragraphe 2, commence par le point a) : l'analyse des risques et la politique de sécurité des systèmes d'information. Les obligations contraignantes découlent du droit national : vérifiez la loi de transposition de NIS 2 dans votre pays. Vous pouvez d'abord vérifier si NIS 2 vous concerne.

Cette méthode est un point de départ pragmatique. Ce n'est pas une mise en œuvre de l'ISO 27001, ni un audit externe formel.

Étape 1 : recenser vos actifs (sites, données, comptes, fournisseurs)

Un actif est tout ce dont la perte ou le détournement vous nuirait. Pour une petite entreprise type, quatre groupes couvrent presque tout. Placez les données personnelles en premier : c'est là que le RGPD s'applique et que l'impact est le plus élevé.

Soyez précis. « Site web » est trop vague. « boutique.exemple.fr, WooCommerce avec environ 40 extensions, commandes depuis 2021 » est exploitable. Si vous retrouvez en dressant la liste une préproduction oubliée ou le compte administrateur d'un ancien prestataire, notez-le. Cette seule découverte justifie l'exercice.

Étape 2 : nommer les menaces réalistes pour chaque actif

Inutile de dresser un catalogue de toutes les attaques possibles. Pour des sites WordPress, quatre familles de menaces couvrent la plupart des incidents réels :

• Extensions et thèmes vulnérables ou abandonnés. Quelqu'un exploite une faille connue avant votre mise à jour, ou une faille qui ne sera jamais corrigée.
• Identifiants volés ou partagés. Un mot de passe réutilisé, un compte « admin » partagé, ou l'accès d'une agence que personne n'a supprimé.
• Défaillance de l'hébergeur ou du serveur. Une panne, une perte de données chez l'hébergeur, ou une faille dans le logiciel serveur lui-même. Les failles PHP2Shell en sont un exemple : elles se trouvaient dans l'environnement d'exécution PHP, de sorte qu'un WordPress entièrement à jour restait exposé.
• Erreur humaine. Une mise à jour qui casse le paiement, une page supprimée, ou un rédacteur qui reçoit le rôle Administrateur « juste un instant ».

La menace liée aux extensions mérite une cotation honnête. L'éditeur Patchstack a recensé, dans son rapport State of WordPress Security in 2026, 11 334 nouvelles vulnérabilités dans l'écosystème WordPress en 2025. 91 % concernaient des extensions, et 46 % n'avaient aucun correctif disponible auprès du développeur au moment de la divulgation publique. Pour les vulnérabilités massivement exploitées, le délai médian pondéré avant exploitation de masse était de 5 heures. Ces chiffres viennent d'un éditeur, mais ils expliquent pourquoi « extension vulnérable » arrive généralement en tête d'un registre WordPress.

Étape 3 : coter la probabilité et l'impact sur une échelle de 1 à 3

Utilisez trois niveaux et définissez-les en termes simples, pour que deux personnes qui cotent le même risque arrivent au même résultat.

Probabilité

1. Improbable dans l'année
2. Possible dans l'année
3. Attendue, ou déjà arrivée chez vous ou sur un site comparable

Impact

1. Désagrément : une heure pour corriger, aucune donnée touchée
2. Indisponibilité, ou quantité limitée de données non sensibles touchées
3. Données personnelles exposées, paiements affectés, ou arrêt de l'activité

Multipliez les deux valeurs. Un score de 1–2 signifie accepter, 3–4 planifier une mesure, 6–9 agir tout de suite. Les scores 5, 7 et 8 ne peuvent pas apparaître sur cette échelle, ce qui garde les seuils nets.

Cotez le risque tel qu'il est aujourd'hui. Un contrôle qui existe et fonctionne réduit la probabilité. « Nous avons des sauvegardes » ne compte que si quelqu'un en a déjà restauré une. N'ajoutez ni décimales ni coefficients. Une échelle de 1 à 3 est volontairement grossière : une fausse précision donne au registre un air plus scientifique que les connaissances sur lesquelles il repose.

Étape 4 : choisir mesures, responsables et dates de revue

Pour chaque risque dont le score atteint 3 ou plus, choisissez une ou deux mesures concrètes. « Améliorer la sécurité » n'est pas une mesure. « Activer l'authentification à deux facteurs pour les quatre administrateurs avant le 17 novembre » en est une. Désignez une personne comme responsable, pas « l'informatique » ni « l'agence », et fixez une date.

Les articles de fond détaillent les mesures elles-mêmes : voir la gestion des extensions vulnérables et des sauvegardes WordPress qui se restaurent vraiment. Votre registre de risques n'a qu'à consigner la décision et renvoyer aux preuves.

Deux autres éléments appartiennent à chaque ligne. D'abord, « accepter » est une décision valable pour les scores faibles, à condition d'en noter la raison. Ensuite, indiquez le risque résiduel, c'est-à-dire le score attendu une fois la mesure en place. Si une mesure ne fait pas baisser le score, c'est probablement la mauvaise mesure.

Exemple concret : registre de risques d'une petite boutique WooCommerce

L'exemple ci-dessous concerne une boutique fictive. Elle a un site WooCommerce, une copie de préproduction, deux salariés, une agence externe et un hébergement mutualisé. « P » désigne la probabilité, « I » l'impact, et « Après » le score résiduel attendu.

Lisez-le de haut en bas. Cette semaine, la boutique supprime le compte de l'agence et interroge l'hébergeur sur PHP. Les deux actions sont peu coûteuses et prennent moins d'une heure. Le nettoyage des extensions suit la semaine prochaine, car c'est le score le plus élevé. La 2FA et le test de restauration sont planifiés dans le mois.

Les lignes sur l'erreur du personnel et sur les formulaires de contact peuvent attendre décembre. Leurs scores sont plus bas, et pour les erreurs du personnel, le travail sur les sauvegardes de la quatrième ligne offre déjà une solution de repli. La panne de la newsletter est acceptée, avec une raison et une date de revue. Chaque ligne se termine à 3 ou moins. Cela ne signifie pas que rien ne peut arriver : c'est un niveau de risque documenté et motivé.

Garder l'analyse de risques vivante

Une analyse de risques que personne ne rouvre devient la preuve que vous avez cessé de regarder. Reprenez-la quand l'un de ces déclencheurs se produit :

• Après tout incident ou quasi-incident, y compris une vague de connexions échouées ou une extension que vous avez dû annuler
• Après des changements importants : nouvelle extension traitant des données personnelles, nouvel hébergeur, nouvelle agence, lancement d'une boutique
• Quand un fournisseur ou un client soumis à NIS 2 vous envoie un questionnaire de sécurité
• À un intervalle fixe de votre choix, par exemple chaque trimestre ou chaque année. C'est votre décision, pas une règle légale

Donnez au document un numéro de version et une date, et conservez les anciennes versions. Un historique montrant qu'un score de 9 est tombé à 3 après une mesure constitue une bonne preuve de responsabilisation. Notre guide sur la documentation d'audit de sécurité montre comment le registre s'articule avec vos autres documents.

L'extension d'audit « Security Audit & Compliance » de secaudit.eu peut vous aider pour l'étape 2 et pour chaque revue. Elle associe ses constats à l'art. 32 du RGPD et à l'art. 21 de NIS 2 et les exporte sous forme de rapport ou de CSV, que vous pouvez comparer à votre registre. Les décisions du registre restent les vôtres ; l'extension vous fournit des éléments à jour pour les prendre. → secaudit.eu

Votre prochaine étape : copiez le tableau d'exemple, remplacez les lignes par vos propres actifs et planifiez la date de la première revue avant de fermer le fichier.

FAQ

Ai-je besoin de l'ISO 27001 pour cela ?

Non. Cette méthode est un point de départ pratique que vous pouvez mener avec votre propre équipe. L'ISO 27001 est une norme complète de système de management ; l'adopter plus tard relève d'une décision d'entreprise distincte, souvent motivée par de grands clients.

Combien de temps faut-il pour un site ?

Pour un site unique dont la configuration est connue, une première version tient dans une séance de travail. L'essentiel du temps passe dans l'étape 1, à retrouver les comptes et les fournisseurs. Les revues suivantes sont bien plus rapides, car vous ne mettez à jour que ce qui a changé.

Une agence la réalise-t-elle une fois ou pour chaque client ?

Chaque client est le responsable du traitement de son propre site et détient son analyse de risques. L'agence peut préparer un projet que le client valide. Elle doit aussi tenir un registre distinct pour ses propres systèmes, comme ses ordinateurs portables, son coffre de mots de passe et ses accès aux hébergements de ses clients. Votre contrat de sous-traitance doit préciser qui fait quoi.

Cet article est une information générale et ne constitue pas un conseil juridique.