Sécurité et continuité
Sécuriser un site internet et préparer la réponse à un incident
Attribuer les responsabilités, limiter les accès et organiser une réaction utile quand le site ne fonctionne plus comme prévu.

Illustration photographique générée par IA : scène fictive, sans représentation d’un client ou d’une équipe réelle.
La réponse en bref
Un plan de sécurité exploitable et une procédure d’alerte.
Commencez par identifier qui administre le site, quelles dépendances sont utilisées et comment signaler un incident. Réduisez les privilèges, appliquez les mises à jour avec possibilité de retour arrière, contrôlez les sauvegardes et vérifiez les alertes. Le cadenas HTTPS protège le transport ; il ne démontre pas à lui seul que le site est sûr.
La sécurité se joue aussi dans l’organisation : un ancien prestataire encore administrateur, une extension abandonnée ou une alerte sans destinataire peuvent compromettre un site pourtant récent. Fixez un responsable et un relais pour chaque action essentielle.
Ce cadre prépare les échanges avec votre support informatique. Il ne remplace pas un audit technique ciblé : les tests intrusifs doivent être autorisés, délimités et réalisés par des personnes compétentes.
Méthode en 6 étapes
Passer d’une intention générale à des décisions vérifiables.
Chaque étape produit une information qui peut être relue, attribuée et utilisée dans la suivante.
Recenser les dépendances
Listez CMS, extensions, hébergeur, DNS, messagerie, tâches planifiées et intégrations. Notez versions, responsable et mode de mise à jour, sans recopier de secrets dans le document.
Revoir les accès
Attribuez des comptes nominatifs, retirez les comptes inutiles et séparez publication et administration. Activez une authentification multifacteur quand elle est disponible ; prévoyez la récupération dans un coffre adapté.
Maintenir avec retour arrière
Vérifiez la provenance et le suivi des extensions. Testez les mises à jour sensibles, contrôlez les parcours métier ensuite et gardez une sauvegarde restaurable antérieure.
Définir les alertes
Surveillez disponibilité, expiration de certificat, erreurs et changements anormaux. Testez la réception de l’alerte, son escalade et l’accès au support hors du site.
Préparer la réponse
En cas d’incident, notez heure, symptômes et actions. Contactez le support, préservez les éléments utiles et décidez avec lui de l’isolement. Une restauration ne suffit pas si la cause reste présente.
Valider la reprise
Corrigez la cause, rétablissez les accès nécessaires puis testez formulaires, commandes, contenus et indexation. Consignez la décision de remise en ligne et les actions de prévention.
Référentiel opérationnel
Responsabilités et preuves de sécurité.
Utilisez ce tableau comme base d’entretien, de brief ou de revue. Adaptez la fréquence et le niveau de preuve au risque réel du projet.
| Chantier | Responsable à désigner | Preuve utile |
|---|---|---|
| Accès | Administrateur des comptes | Revue datée des rôles et anciens comptes |
| Logiciels | Responsable de maintenance | Inventaire des versions et suivi des mises à jour |
| Sauvegardes | Hébergeur ou prestataire selon contrat | Compte rendu de restauration isolée |
| Alertes | Pilote du site et relais | Essai de notification reçu et traité |
| Incident | Interlocuteur technique et direction | Chronologie, périmètre et décision de reprise |
| Formulaires | Responsable du parcours | Données minimisées et erreurs vérifiées |
Avant de valider
6 points de contrôle.
Une vérification courte vaut mieux qu’une intention implicite. Conservez une preuve proportionnée : document, capture, résultat de test ou décision datée.
- ContrôlerLes comptes n’ont que les droits nécessaires.
- ContrôlerLes composants non utilisés sont retirés après contrôle de dépendance.
- ContrôlerUne personne reçoit et traite les alertes.
- ContrôlerLa restauration a été testée hors production.
- ContrôlerLe contact de secours reste disponible si le site est indisponible.
- ContrôlerUne reprise inclut la correction de la cause de l’incident.
Questions fréquentes
Réponses directes avant de décider.
Ces repères restent généraux. Le contexte, les outils, l’organisation et les obligations applicables peuvent modifier la réponse.
Le HTTPS suffit-il à sécuriser le site ?
Non. Il protège les échanges entre navigateur et serveur, mais ne corrige ni un logiciel vulnérable ni un compte compromis. Vérifiez aussi les mises à jour, les accès, les sauvegardes et les responsabilités.
Que préparer avant de contacter le support ?
L’adresse du site, l’heure de découverte, les symptômes, les changements récents et un moyen de rappel. Ne transmettez pas de mots de passe par un formulaire public ; utilisez le canal sécurisé convenu.
Peut-on effacer immédiatement les fichiers suspects ?
Évitez une suppression improvisée qui efface les éléments utiles au diagnostic. Le support doit déterminer comment préserver les preuves, isoler le service et corriger la cause.
Sources et prolongements




