Article 32 du RGPD et WordPress : une sécurité « appropriée »

L’article 32 du RGPD ne cite aucune extension, aucun réglage serveur, aucune longueur minimale de mot de passe. Il exige une sécurité adaptée au risque, et pour la plupart des sites WordPress cela se traduit par une liste courte et concrète : HTTPS partout, des logiciels à jour, des comptes personnels protégés par l’authentification à deux facteurs, des sauvegardes que vous avez réellement restaurées et des contrôles réguliers. Si vous faites tout cela et pouvez le démontrer, vous couvrez déjà l’essentiel de ce que l’article 32 attend d’un site WordPress ordinaire.

Ce guide traduit l’article 32, paragraphe 1, points a) à d), en mesures WordPress, point par point. Il aborde aussi les deux obligations qui l’entourent : documenter vos mesures (principe de responsabilité, ou « accountability ») et vous assurer que votre hébergeur et votre agence font leur part.

RGPD et sécurité WordPress : ce que dit l’article 32

L’article 32 du RGPD impose au responsable du traitement (votre entreprise) comme à tout sous-traitant (votre hébergeur, par exemple) de mettre en œuvre des mesures techniques et organisationnelles appropriées. Ce qui est approprié dépend de l’état des connaissances, des coûts de mise en œuvre, de la nature, de la portée, du contexte et des finalités du traitement, ainsi que du risque pour les personnes dont vous traitez les données.

L’article énumère ensuite quatre éléments que ces mesures comprennent, « entre autres, selon les besoins » :

• a) la pseudonymisation et le chiffrement des données à caractère personnel ;
• b) des moyens permettant de garantir la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes et des services ;
• c) des moyens permettant de rétablir la disponibilité des données à caractère personnel et l’accès à celles-ci dans des délais appropriés après un incident ;
• d) une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité de ces mesures.

En toile de fond, il y a l’article 5, paragraphe 1, point f) : les données personnelles doivent être traitées de façon à garantir une sécurité appropriée. Or un site WordPress ordinaire traite davantage de données personnelles que son propriétaire ne l’imagine : comptes utilisateurs, commentaires avec nom, adresse e-mail et adresse IP, saisies de formulaires de contact, inscriptions à la newsletter, commandes WooCommerce et journaux du serveur.

Une approche par les risques : état de l’art contre coûts

L’article 32 repose délibérément sur le risque. Un site d’entreprise doté d’un seul formulaire de contact, une boutique qui compte des milliers de comptes clients et un espace membres qui stocke des données de santé n’exigent pas le même effort, mais chacun a besoin d’un niveau à la mesure de ce qui pourrait mal tourner. L’article 32, paragraphe 2, nomme les risques à prendre en compte : destruction, perte, altération, divulgation non autorisée de données personnelles ou accès non autorisé à celles-ci, de manière accidentelle ou illicite.

L’« état des connaissances », souvent appelé « état de l’art », se comprend mieux comme « ce qui est éprouvé et largement disponible » que comme « le produit le plus cher du marché ». HTTPS, des versions logicielles maintenues et la connexion à deux facteurs pour les administrateurs relèvent aujourd’hui de l’état de l’art, et coûtent peu. Les coûts peuvent justifier qu’un petit blog tourne sans pare-feu applicatif web de niveau entreprise. Ils justifient rarement de faire l’impasse sur les fondamentaux.

L’article 32, paragraphe 1, points a) à d), en mesures WordPress

Le tableau associe chaque point à des mesures WordPress courantes et aux preuves à conserver.

a) Chiffrement et pseudonymisation

Servez l’intégralité du site en HTTPS uniquement, y compris /wp-admin/ et chaque formulaire, et ajoutez HSTS dès que cela fonctionne de manière fiable. Les mots de passe, eux, ne sont pas chiffrés mais hachés, ce qui est la bonne approche : depuis WordPress 6.8, les mots de passe des utilisateurs sont hachés avec bcrypt.

Les sauvegardes sont la copie de vos données personnelles la plus souvent oubliée. Chiffrez-les et stockez-les à l’écart du serveur web. Une véritable pseudonymisation est rare sur un site WordPress ordinaire, mais des mesures voisines réduisent le risque : tronquez les adresses IP dans vos outils de mesure d’audience et vos journaux, et ne conservez pas les saisies des formulaires de contact dans la base de données plus longtemps que nécessaire. Une donnée que vous ne stockez plus ne peut pas fuiter.

b) Confidentialité, intégrité, disponibilité et résilience

Les mises à jour passent en premier. Patchstack, un éditeur de solutions de sécurité, a recensé 11 334 nouvelles vulnérabilités dans l’écosystème WordPress en 2025, dont 91 % dans des extensions. Pour les plus massivement exploitées, le délai médian pondéré avant l’exploitation de masse était de cinq heures (rapport Patchstack). Activez les mises à jour automatiques là où elles conviennent (le cœur les propose pour les extensions et les thèmes depuis WordPress 5.5) et supprimez les extensions inutilisées. Notre guide sur les extensions vulnérables explique comment les auditer.

Le contrôle d’accès constitue le deuxième pilier : un compte personnel par personne, le rôle le plus bas qui suffit (Éditeur, Auteur ou Contributeur plutôt qu’Administrateur) et l’authentification à deux facteurs pour chaque administrateur. Le cœur de WordPress ne la propose pas. Pour protéger l’intégrité, supprimez les éditeurs de fichiers du tableau de bord dans wp-config.php :

define( 'DISALLOW_FILE_EDIT', true );

Comparez de temps en temps les fichiers du cœur avec les sommes de contrôle officielles (wp core verify-checksums avec WP-CLI). Pour la disponibilité et la résilience, choisissez un hébergement doté de ressources suffisantes et d’une supervision. Aucune extension ne peut absorber une attaque DDoS d’envergure : c’est le rôle d’un CDN ou d’un pare-feu en périphérie de réseau. Le guide officiel de durcissement de WordPress détaille d’autres réglages côté serveur.

c) Rétablir la disponibilité après un incident

Une sauvegarde ne compte que si vous savez la restaurer. Sauvegardez les fichiers et la base de données, gardez au moins une copie hors site et hors de portée du compte administrateur WordPress, et testez une restauration complète sur un site de préproduction. Notez le temps qu’elle a pris : il est bien plus facile de défendre des « délais appropriés » avec une durée de restauration mesurée qu’avec un espoir.

d) Tester, analyser et évaluer régulièrement

Le RGPD ne fixe aucune fréquence : fixez la vôtre et tenez-vous-y. Pour une petite entreprise, voici un point de départ raisonnable : une analyse automatisée chaque semaine, une revue des comptes utilisateurs et des extensions chaque trimestre, un test de restauration deux fois par an, et une revue supplémentaire après chaque incident ou changement majeur. Consignez ce que vous avez trouvé et corrigé, avec les dates.

L’extension Security Audit & Compliance de secaudit.eu peut prendre en charge une partie de ces tests : elle recherche les logiciels malveillants, les fichiers du cœur modifiés, les extensions obsolètes et les mots de passe faibles, rattache ses constats à l’article 32 du RGPD et affiche un récapitulatif de conformité à l’écran ; les rapports signés (PDF, CSV) sont inclus dans secaudit.eu Pro. Une analyse étaye votre documentation ; elle ne rend pas un site conforme à elle seule.

Principe de responsabilité : documentez ce que vous faites (art. 5, § 2)

Selon l’article 5, paragraphe 2, le responsable du traitement doit être en mesure de démontrer sa conformité. Concrètement, il vous faut un document de sécurité court et vivant plutôt qu’un classeur que personne ne lit. Il devrait couvrir :

• Un inventaire : hébergement, version de WordPress, extensions, thèmes, services externes
• Qui a accès, avec quel rôle, et qui approuve les nouveaux comptes
• Vos mesures pour les points a) à d), avec la note de risque qui les justifie
• Un journal des mises à jour et les dates des analyses, des revues d’accès et des tests de restauration
• Votre procédure en cas d’incident, y compris la notification des violations sous 72 heures
• Les contrats de sous-traitance conclus avec vos sous-traitants

Revoyez ce document une fois par an et chaque fois que le site évolue de façon significative. Notre checklist sécurité WordPress constitue un bon point de départ pour l’inventaire.

Hébergeurs et agences : des sous-traitants au sens de l’article 28

Votre hébergeur stocke la base de données et les sauvegardes. Une agence ou un freelance disposant d’un accès administrateur peut consulter chaque fiche client. Tous deux agissent généralement en qualité de sous-traitants, et vous devez alors conclure avec chacun un contrat de sous-traitance au titre de l’article 28. Ce même article précise que vous ne pouvez faire appel qu’à des sous-traitants présentant des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées, et le contrat doit les obliger à prendre les mesures requises par l’article 32.

Posez des questions concrètes au lieu de vous fier à un modèle. Où les sauvegardes sont-elles stockées, et pendant combien de temps ? La connexion à deux facteurs est-elle imposée sur le panneau d’hébergement et sur les comptes de l’agence ? Dans quel délai serez-vous informé d’un incident de sécurité ? Lorsqu’un contrat d’agence prend fin, supprimez ses comptes et changez les identifiants partagés le jour même.

L’article 83, paragraphe 4, point a), prévoit pour les manquements aux articles 25 à 39, dont l’article 32, des amendes pouvant atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Mais c’est surtout après un incident que vous aurez besoin de votre documentation, lorsqu’une autorité de contrôle comme la CNIL vous demandera quelles mesures étaient en place.

FAQ

L’article 32 impose-t-il une extension de sécurité précise ?

Non. Il exige des mesures appropriées, pas des produits. Une extension peut vous aider pour certaines d’entre elles, comme la connexion à deux facteurs ou les analyses, mais les mises à jour, les sauvegardes, les revues d’accès et les contrats en font tout autant partie.

L’article 32 s’applique-t-il à un petit site sans comptes utilisateurs ?

Oui, dès que le site traite des données personnelles, par exemple des saisies de formulaire de contact, des commentaires ou des journaux serveur contenant des adresses IP. Les mesures sont proportionnées au risque.

HTTPS suffit-il pour le point a) ?

Non. HTTPS protège les données en transit. Les sauvegardes, les exports et la base de données sur le serveur ont besoin de leur propre protection.

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