Comment sécuriser un site web : les mesures essentielles

La plupart des sites piratés sont repérés par des robots qui cherchent une faille connue. Les mesures à prendre par ordre de priorité, les réglages propres à WordPress et la marche à suivre après un piratage.

Pour sécuriser un site web, commencez par les mesures qui bloquent la grande majorité des attaques : mettre à jour le CMS, le thème et les extensions dès qu’un correctif sort, supprimer les extensions inutiles ou abandonnées, protéger chaque compte administrateur par un mot de passe unique et une double authentification, servir le site en HTTPS chez un hébergeur sérieux, et garder des sauvegardes automatiques stockées hors du serveur et testées. Viennent ensuite les protections de second niveau : pare-feu applicatif, en-têtes de sécurité, CAPTCHA sur les formulaires, surveillance et plan de réaction en cas d’incident.

La plupart des sites piratés ne sont pas visés personnellement : ils sont repérés par des robots qui scannent le web à la recherche d’une version vulnérable ou d’un mot de passe faible. On explique ici comment ces attaques fonctionnent, puis on détaille chaque mesure de protection, avec une partie spécifique à WordPress, et la marche à suivre si votre site a déjà été compromis.

Pourquoi un petit site est-il une cible ?
Comment les sites web sont-ils piratés ?
Par quoi commencer pour sécuriser un site web ?
Pourquoi les mises à jour sont-elles la première protection ?
Comment choisir des extensions et des thèmes sûrs ?
Comment protéger les accès au site ?
Pourquoi installer un certificat SSL et passer en HTTPS ?
Comment choisir un hébergement sécurisé ?
Comment protéger les formulaires contre le spam et les injections ?
Quels en-têtes de sécurité HTTP configurer ?
Comment sécuriser un site WordPress en particulier ?
Comment organiser des sauvegardes fiables ?
Comment limiter le risque humain et le phishing ?
Que faire si votre site a été piraté ?
Questions fréquentes
Sources

Pourquoi un petit site est-il une cible ?

« Mon site n’intéresse personne » est la phrase qu’on entend le plus souvent avant un piratage. Les attaquants ne cherchent pas votre site en particulier : ils cherchent une faille connue, et testent automatiquement des millions d’adresses. Un site vitrine sert alors à héberger des pages de spam, rediriger vos visiteurs vers des arnaques, envoyer des e-mails frauduleux depuis votre serveur ou voler les données saisies dans vos formulaires.

Quelques chiffres récents donnent l’échelle du problème :

Selon le rapport Verizon DBIR 2026, qui analyse des incidents survenus entre novembre 2024 et octobre 2025, 31 % des violations de données commencent par l’exploitation d’une faille logicielle, devant le vol de mots de passe.
Selon Patchstack, 11 334 nouvelles vulnérabilités ont été découvertes dans l’écosystème WordPress en 2025, soit 42 % de plus qu’en 2024. 91 % concernaient des extensions, 9 % des thèmes, et seulement 6, toutes peu graves, le cœur de WordPress.
Toujours selon Patchstack, 46 % de ces failles n’avaient pas encore de correctif au moment de leur publication, et le délai médian entre la publication d’une faille et son exploitation massive n’était que de 5 heures.

Les conséquences dépassent la technique : site hors ligne, perte de données clients, blocage par Google qui affiche un avertissement aux visiteurs, perte de positions dans les résultats de recherche, obligation de notifier la CNIL si des données personnelles ont fuité, et surtout atteinte à votre réputation.

Comment les sites web sont-ils piratés ?

sécuriser un site Web — **Sécuriser un site Web**

Comprendre les méthodes d’attaque aide à comprendre pourquoi chaque mesure compte. Les plus fréquentes sur les sites d’entreprise :

Exploitation d’une extension ou d’un thème vulnérable : c’est la porte d’entrée principale sur WordPress. Un robot détecte la version installée et utilise une faille publiée.
Contrôle d’accès défaillant : une fonction réservée aux administrateurs reste accessible à un simple abonné ou à un visiteur anonyme. C’est le premier risque du classement OWASP Top 10 de 2025 et, selon Patchstack, le type de faille le plus exploité sur WordPress en 2025.
Attaque par force brute ou par réutilisation de mots de passe : des robots essaient des milliers de combinaisons, ou des identifiants volés sur un autre service, sur votre page de connexion.
Injection SQL : un champ de formulaire mal contrôlé permet d’envoyer des commandes à la base de données, pour lire ou modifier son contenu.
Cross-site scripting (XSS) : un script malveillant est injecté dans une page et s’exécute dans le navigateur des visiteurs ou d’un administrateur. Selon Patchstack, c’était près de la moitié des failles découvertes dans l’écosystème WordPress en 2024.
Logiciels piratés (« nulled ») : thèmes ou extensions payants téléchargés gratuitement sur des sites douteux, livrés avec une porte dérobée.
Hameçonnage (phishing) : un faux e-mail de votre hébergeur ou de votre registraire pour récupérer vos identifiants.
Déni de service (DoS ou DDoS) : le serveur est saturé de requêtes jusqu’à ne plus répondre.

Une fois entrés, les attaquants installent souvent une porte dérobée (backdoor), un fichier caché qui leur permet de revenir même après un changement de mot de passe. Les symptômes les plus courants d’un site piraté : pages de spam pharmaceutique ou de casino indexées par Google (on parle de « pharma hack »), redirections vers d’autres sites sur mobile uniquement, nouveaux comptes administrateurs inconnus, fichiers PHP étranges dans le dossier des médias, avertissement de Google ou de l’hébergeur.

Pour les applications développées sur mesure, les mêmes familles de failles s’appliquent ; on les détaille dans notre article sur la sécurité des applications web.

Par quoi commencer pour sécuriser un site web ?

Toutes les mesures n’ont pas le même rendement. Voici l’ordre dans lequel on les traite, de la plus efficace à la plus spécialisée.

Priorité	Mesure	Ce qu’elle bloque
1	Mises à jour du CMS, du thème et des extensions	L’exploitation des failles connues
2	Suppression des extensions inutiles ou abandonnées	Les failles qui ne seront jamais corrigées
3	Mots de passe uniques et double authentification	La force brute et la réutilisation d’identifiants
4	Sauvegardes automatiques hors du serveur, testées	La perte définitive du site et des données
5	HTTPS sur tout le site	L’interception des données en transit
6	Hébergement à jour et isolé	La contamination par un autre site, les versions de PHP obsolètes
7	Comptes utilisateurs limités au strict nécessaire	Les dégâts d’un compte compromis
8	Pare-feu applicatif (WAF)	Une partie des attaques automatisées, y compris sur des failles pas encore corrigées
9	Protection des formulaires	Le spam, les injections
10	En-têtes de sécurité HTTP	Le détournement de clics, une partie des attaques XSS
11	Surveillance et alertes	Le piratage qui passe inaperçu pendant des semaines
12	Plan de réaction écrit	La panique et les mauvaises décisions le jour de l’incident

Pourquoi les mises à jour sont-elles la première protection ?

Une mise à jour ne sert pas qu’à ajouter des fonctions : elle corrige des failles. Et dès qu’un correctif est publié, la faille qu’il corrige devient publique. Les robots d’attaque cherchent alors précisément les sites qui ne l’ont pas encore installé. Avec un délai médian de quelques heures entre publication et exploitation, attendre « la maintenance du mois prochain » ne suffit plus pour les failles critiques.

Concrètement :

Mettez à jour le cœur du CMS, le thème, les extensions et la version de PHP du serveur.
Sur WordPress, les mises à jour mineures du cœur (correctifs de sécurité) s’installent automatiquement par défaut, et depuis WordPress 5.5 vous pouvez activer les mises à jour automatiques extension par extension et thème par thème.
Activez l’automatique sur les extensions simples et bien maintenues, gardez un contrôle manuel sur les extensions critiques (boutique, paiement, constructeur de pages) et testez-les d’abord sur un site de préproduction.
Faites une sauvegarde juste avant toute mise à jour importante.
Abonnez-vous à une veille de vulnérabilités (plusieurs services et extensions de sécurité en proposent) pour être alerté d’une faille sur une extension que vous utilisez.

Si vous utilisez un constructeur de site hébergé (Wix, Shopify, Squarespace…), ces mises à jour sont gérées par l’éditeur. Il vous reste la gestion des accès et des applications tierces connectées.

Comment choisir des extensions et des thèmes sûrs ?

Puisque l’immense majorité des failles WordPress se trouve dans les extensions, chaque extension installée est une porte supplémentaire. Avant d’en ajouter une, appliquez toujours la même grille :

La source : le répertoire officiel WordPress.org ou le site de l’éditeur, jamais un site tiers qui propose une version payante gratuitement. Un prix trop alléchant cache souvent une version piratée.
La date de dernière mise à jour et la compatibilité avec votre version de WordPress. Une extension non mise à jour depuis plus d’un an est un signal d’alerte.
La réputation de l’éditeur, le nombre d’installations actives, les avis et la réactivité du support.
L’historique de sécurité : une extension qui a eu des failles n’est pas forcément à éviter, la vraie question est la vitesse à laquelle elles ont été corrigées.
Le besoin réel : si trois lignes de code ou une fonction native suffisent, n’installez pas une extension.

Désinstallez (et pas seulement désactivez) les extensions et thèmes inutilisés : un fichier présent sur le serveur peut être exploité même si l’extension est désactivée. Gardez un seul thème par défaut en secours.

Comment protéger les accès au site ?

Le mot de passe est souvent la seule barrière entre un attaquant et l’administration de votre site. Et il n’y a pas que le compte WordPress : l’espace client de l’hébergeur, le FTP ou SSH, la base de données, le registraire du nom de domaine et la messagerie liée au site sont autant de portes d’entrée.

Des mots de passe robustes et uniques

La CNIL a mis à jour ses recommandations en octobre 2022. Pour un mot de passe utilisé seul, elle donne comme repères équivalents : au moins 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux, ou au moins 14 caractères avec majuscules, minuscules et chiffres, ou une phrase de passe d’au moins 7 mots. Elle ne recommande plus d’imposer un changement périodique pour les comptes ordinaires, jugeant cette mesure peu efficace : notre ancien conseil de changer de mot de passe tous les 90 jours est donc dépassé. En revanche, changez immédiatement un mot de passe dès qu’un doute existe.

La règle la plus importante reste : un mot de passe différent pour chaque service. Si l’un fuit, les autres restent protégés. Le seul moyen réaliste d’y parvenir est un gestionnaire de mots de passe ; on compare les solutions dans notre article sur les meilleurs gestionnaires de mots de passe.

La double authentification

La double authentification (2FA) ajoute un code temporaire, généré par une application sur votre téléphone ou une clé physique, au mot de passe. Même volé, le mot de passe ne suffit plus. Activez-la en priorité sur l’hébergeur, le registraire du domaine, la messagerie et les comptes administrateurs du site. WordPress ne l’intègre pas nativement, mais sa documentation officielle la recommande et plusieurs extensions reconnues l’ajoutent.

Des comptes limités au strict nécessaire

Un compte nominatif par personne, jamais de compte « admin » partagé.
Le rôle le plus bas possible : un rédacteur n’a pas besoin d’être administrateur, et un administrateur non technicien risque de modifier sans le savoir un réglage critique.
Suppression des comptes des anciens salariés et prestataires dès la fin de leur mission.
Changement des identifiants et réglages par défaut dès l’installation.
Limitation des tentatives de connexion, pour ralentir les attaques par force brute.

Pourquoi installer un certificat SSL et passer en HTTPS ?

Le certificat SSL (on devrait dire TLS, le protocole qui a remplacé SSL) chiffre les échanges entre le navigateur du visiteur et votre serveur : c’est le « s » de https et le cadenas dans la barre d’adresse. Sans lui, un mot de passe, un formulaire de contact ou un paiement peuvent être interceptés sur un réseau Wi-Fi public, et les navigateurs affichent la mention « Non sécurisé ». Le HTTPS est aussi un des critères d’expérience de page de Google.

Un certificat gratuit Let’s Encrypt, fourni par la plupart des hébergeurs, suffit pour l’immense majorité des sites, boutiques en ligne comprises : il chiffre exactement de la même façon qu’un certificat payant. Les certificats payants apportent surtout une vérification de l’identité de l’organisation ou une garantie commerciale.

Point à anticiper : la durée de vie maximale des certificats diminue. Selon le calendrier adopté par le CA/Browser Forum en avril 2025, elle est passée à 200 jours le 15 mars 2026, passera à 100 jours le 15 mars 2027 puis à 47 jours le 15 mars 2029. Le renouvellement manuel devient intenable : vérifiez que votre hébergeur renouvelle automatiquement vos certificats.

Une fois le certificat installé, redirigez toutes les adresses http vers https, corrigez les contenus encore appelés en http (images, scripts) et activez l’en-tête HSTS, qui oblige le navigateur à n’utiliser que HTTPS pour votre domaine.

Comment choisir un hébergement sécurisé ?

L’hébergeur est la fondation. Un hébergement bas de gamme mal entretenu peut ruiner tous vos efforts, par exemple si un autre site du même serveur est piraté et contamine le vôtre. Les points à vérifier :

des versions de PHP et de base de données encore maintenues, et la possibilité de choisir la version ;
l’isolation entre les sites d’un même serveur ;
des sauvegardes automatiques quotidiennes, conservées plusieurs jours et restaurables facilement ;
un pare-feu, une protection contre les attaques par déni de service et un antivirus côté serveur ;
des certificats SSL gratuits renouvelés automatiquement ;
des accès SFTP ou SSH plutôt que FTP non chiffré ;
la double authentification sur l’espace client ;
un support réactif, capable d’intervenir en cas d’incident, et des serveurs situés dans l’Union européenne si vous traitez des données personnelles.

Pare-feu applicatif, CDN et extensions de sécurité

Un pare-feu applicatif (WAF, pour Web Application Firewall) filtre les requêtes avant qu’elles n’atteignent votre site : il bloque les signatures d’attaques connues, les robots malveillants, les pics de trafic anormaux. On peut le placer en amont, au niveau d’un CDN qui joue le rôle de proxy (Cloudflare en est l’exemple le plus répandu), ou au niveau du site, via une extension de sécurité (Wordfence, Solid Security, Patchstack…). Certains appliquent des « correctifs virtuels » qui bloquent l’exploitation d’une faille connue en attendant que l’éditeur de l’extension publie sa mise à jour.

Deux limites à connaître. D’abord, les extensions de sécurité qui analysent en permanence les fichiers peuvent ralentir le site : configurez-les avec mesure. Ensuite, un WAF ne remplace pas les mises à jour : Patchstack souligne que les failles de contrôle d’accès, les plus exploitées sur WordPress, ressemblent à des actions légitimes d’utilisateurs connectés et sont difficiles à bloquer pour un pare-feu classique.

Comment protéger les formulaires contre le spam et les injections ?

Formulaires de contact, commentaires, création de compte, recherche : chaque champ qui accepte une saisie est un point d’entrée possible.

Le CAPTCHA et les filtres anti-spam écartent les robots qui soumettent des formulaires ou publient des commentaires chargés de liens malveillants. Les solutions récentes sont souvent invisibles pour les vrais visiteurs.
La modération des commentaires : ne publiez pas automatiquement les commentaires, surtout s’ils contiennent des liens. Un lien piégé laissé en commentaire expose directement vos visiteurs. Si les commentaires ne vous apportent rien, désactivez-les.
Contre l’injection SQL, côté développement, toutes les requêtes à la base de données doivent être paramétrées (requêtes préparées) : la saisie de l’utilisateur est alors traitée comme une donnée, jamais comme une commande. Les champs doivent aussi être validés (format attendu, longueur).
Contre le XSS, toute donnée affichée dans une page doit être échappée, et les visiteurs ne doivent jamais pouvoir insérer du HTML ou du JavaScript. Une politique de sécurité du contenu (CSP) limite les dégâts si une faille subsiste.
Contre les envois de fichiers malveillants : limitez les types de fichiers acceptés et empêchez l’exécution de scripts dans le dossier des téléversements.

Quels en-têtes de sécurité HTTP configurer ?

Le certificat SSL ne suffit pas. Les en-têtes HTTP de sécurité donnent au navigateur des consignes qui ferment plusieurs types d’attaques. Ils se configurent au niveau du serveur (Apache, Nginx), du CDN ou via une extension.

En-tête	Rôle
Strict-Transport-Security (HSTS)	Force l’utilisation de HTTPS pour le domaine
Content-Security-Policy (CSP)	Liste les sources autorisées pour les scripts, styles, images et cadres ; principal rempart contre le XSS
X-Content-Type-Options: nosniff	Empêche le navigateur d’interpréter un fichier autrement que selon son type déclaré
X-Frame-Options ou CSP frame-ancestors	Empêche l’affichage du site dans un cadre sur un autre site (détournement de clic)
Referrer-Policy	Limite les informations transmises aux sites vers lesquels vous faites un lien
Permissions-Policy	Désactive les fonctions du navigateur dont le site n’a pas besoin (caméra, micro, géolocalisation)

Exemple de configuration de base pour Nginx :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Deux précautions. La CSP est la plus puissante mais aussi la plus délicate : elle bloque toute source non déclarée, il faut donc la tester en mode « rapport seulement » puis la mettre à jour à chaque nouvel outil ajouté au site (outil d’analyse, vidéo, chat). Et l’ancien en-tête X-XSS-Protection, souvent encore recommandé, est aujourd’hui déprécié : la documentation MDN déconseille de l’utiliser et recommande une CSP à la place.

Comment sécuriser un site WordPress en particulier ?

WordPress n’est pas moins sûr qu’un autre CMS : son cœur a très peu de failles. Sa popularité en fait simplement la cible la plus scannée, et son écosystème d’extensions multiplie les risques. En plus des mesures précédentes, voici les réglages recommandés, pour la plupart issus de la documentation officielle de WordPress :

Désactiver l’éditeur de fichiers du tableau de bord, pour qu’un attaquant connecté ne puisse pas modifier le code du thème ou des extensions. Dans le fichier wp-config.php : define( 'DISALLOW_FILE_EDIT', true );
Protéger wp-config.php, qui contient les accès à la base de données : bloquez son accès depuis le web, et placez-le si possible hors du dossier public.
Régler les droits des fichiers : seuls les dossiers qui en ont besoin (téléversements, cache) doivent être modifiables par le serveur web.
Limiter les droits de l’utilisateur de la base de données aux opérations nécessaires au fonctionnement courant.
Limiter l’exposition de l’API REST : par défaut, WordPress publie la liste des auteurs via l’adresse /wp-json/wp/v2/users, ce qui donne aux attaquants des identifiants à tester. Restreignez cette route aux utilisateurs connectés, sans désactiver toute l’API, dont l’éditeur de blocs et de nombreuses extensions ont besoin.
Désactiver XML-RPC si aucun service ne l’utilise (anciennes applications mobiles, certains outils de publication) : c’est une cible classique des attaques par force brute.
Limiter les tentatives de connexion et activer la double authentification pour tous les administrateurs.
Tenir une liste des extensions avec leur rôle, et la revoir tous les trimestres.

Changer l’adresse de la page de connexion ou le préfixe des tables de la base de données (wp_) réduit le bruit des attaques automatisées, mais ne protège pas contre un attaquant déterminé : ce sont des compléments, jamais des substituts aux mises à jour et aux mots de passe.

Tout ce travail doit être répété dans le temps. C’est le rôle d’un contrat de maintenance, et l’objet de nos formules d’hébergement et maintenance, détaillées dans nos tarifs indicatifs. Notre article sur la maintenance des sites WordPress détaille les tâches à prévoir si vous la gérez vous-même.

Comment organiser des sauvegardes fiables ?

Aucune protection n’est infaillible. La sauvegarde est ce qui transforme un piratage en mauvaise journée plutôt qu’en catastrophe. Une sauvegarde complète comprend les fichiers (thème, extensions, médias) et la base de données. Les bonnes pratiques, conformes aux recommandations de Cybermalveillance.gouv.fr :

Automatisées : une sauvegarde qui dépend de la mémoire de quelqu’un finit par ne plus être faite.
Régulières : quotidiennes pour un site qui change souvent (boutique, blog actif), au minimum hebdomadaires pour un site vitrine.
Hors du serveur : une copie stockée sur le même serveur disparaît avec lui, et un attaquant qui a pris la main peut la supprimer ou la chiffrer.
Multiples : plusieurs copies, sur des supports ou chez des prestataires différents, dont au moins une déconnectée ou non modifiable.
Conservées sur plusieurs semaines : un piratage est souvent découvert tard, il faut pouvoir revenir à une version saine antérieure.
Testées : restaurez régulièrement une sauvegarde sur un site de test. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

Les sauvegardes de l’hébergeur sont un bon premier niveau, mais leur durée de conservation est souvent courte : complétez-les par une sauvegarde externe, via une extension ou un service dédié.

Surveiller pour réagir vite

Un site piraté peut le rester des semaines sans que personne ne le remarque, en particulier quand les pages de spam ne s’affichent qu’aux robots de Google. Mettez en place une surveillance de disponibilité, des alertes sur les nouveaux comptes administrateurs et les modifications de fichiers, et suivez les messages de sécurité dans la Google Search Console. On présente les outils dans notre article sur le monitoring de site web.

Comment limiter le risque humain et le phishing ?

La meilleure configuration technique ne résiste pas à un administrateur qui saisit son mot de passe sur une fausse page. Les attaquants imitent de plus en plus finement les e-mails d’hébergeurs, de registraires ou d’éditeurs d’extensions, et le rapport Verizon DBIR 2026 note que l’hameçonnage passe de plus en plus par SMS et appels téléphoniques. Quelques règles à partager avec toutes les personnes qui ont un accès au site :

Ne jamais cliquer sur un lien de connexion reçu par e-mail ou SMS : allez directement sur le site du service.
Se méfier des messages urgents (« votre domaine expire aujourd’hui », « votre site va être suspendu »).
Ne jamais donner la main sur son écran ni ses identifiants à un interlocuteur qui vous a contacté spontanément pour « résoudre un problème technique ».
Éviter d’administrer le site depuis un Wi-Fi public non protégé.
Ne confier les accès qu’à des prestataires identifiés, avec un compte dédié que vous pourrez supprimer.
Protéger l’adresse e-mail qui sert à récupérer les mots de passe du site : qui contrôle cette boîte contrôle le site.

Que faire si votre site a été piraté ?

Gardez votre calme et documentez : captures d’écran, date de découverte, symptômes observés.
Prévenez votre hébergeur, qui peut isoler le site et fournir les journaux de connexion.
Changez tous les mots de passe : administrateurs du site, hébergeur, FTP ou SSH, base de données, messagerie. Régénérez les clés de sécurité de WordPress dans wp-config.php pour déconnecter toutes les sessions.
Supprimez les comptes inconnus et vérifiez les rôles des comptes existants.
Restaurez une sauvegarde saine, antérieure à l’intrusion, ou à défaut réinstallez le cœur, le thème et les extensions depuis leurs sources officielles, puis nettoyez les fichiers et la base de données.
Corrigez la cause : sans cela, le site sera de nouveau piraté. Mettez à jour ou supprimez l’extension vulnérable.
Nettoyez la présence dans Google : supprimez les pages de spam, mettez à jour le sitemap et demandez un réexamen dans la Search Console si un avertissement de sécurité s’affiche.
Notifiez la CNIL si des données personnelles ont fuité : le RGPD impose une notification dans les 72 heures après la découverte lorsque la violation présente un risque pour les personnes, et une information des personnes concernées si ce risque est élevé.

Pour vous faire aider, le dispositif public Cybermalveillance.gouv.fr oriente les entreprises victimes vers des prestataires de proximité. Et une fois le site remis en état, reprenez la liste de priorités ci-dessus : c’est elle qui évite de revivre la même situation.

Questions fréquentes

Un certificat SSL suffit-il à sécuriser un site ?

Non. Le HTTPS protège les données pendant leur trajet entre le visiteur et le serveur, mais il n’empêche ni l’exploitation d’une extension vulnérable, ni la connexion avec un mot de passe volé. C’est une base, pas une protection complète.

WordPress est-il moins sécurisé que les autres CMS ?

Son cœur est très solide : selon Patchstack, seules 6 failles, toutes peu graves, y ont été trouvées en 2025. Le risque vient des extensions et des thèmes, et du manque de mises à jour. Un WordPress bien maintenu avec peu d’extensions est un site sûr.

Faut-il installer une extension de sécurité ?

C’est utile pour le pare-feu, la limitation des tentatives de connexion, la double authentification et les alertes de vulnérabilités. Mais une seule suffit, bien configurée, et elle ne dispense pas des mises à jour. Si votre site passe déjà par un pare-feu en amont (CDN ou hébergeur), évitez les doublons.

À quelle fréquence sauvegarder un site ?

Au rythme de ses modifications : tous les jours pour une boutique ou un site qui reçoit des commandes, au moins une fois par semaine pour un site vitrine, et systématiquement avant chaque mise à jour importante.

Faut-il changer régulièrement ses mots de passe ?

La CNIL ne le recommande plus pour les comptes ordinaires. Mieux vaut un mot de passe long et unique, associé à la double authentification, et un changement immédiat en cas de doute ou de départ d’une personne qui y avait accès.

Combien coûte la sécurisation d’un site ?

La plupart des mesures de base sont gratuites (certificat Let’s Encrypt, mises à jour, gestionnaire de mots de passe, double authentification). Le coût réel est le temps de suivi : c’est ce que couvre un contrat de maintenance, qui démarre chez nous à 40 € par mois.