Sécurité serveur : ce que vous êtes en droit d’attendre de votre hébergement infogéré

Pourquoi la sécurité de votre serveur est l’affaire du dirigeant

La sécurité informatique est souvent perçue comme un sujet purement technique, relégué au service IT ou à l’hébergeur. C’est une erreur qui peut coûter très cher. En réalité, la sécurité de vos serveurs est un enjeu de direction générale, au même titre que la gestion financière ou la conformité réglementaire.

Depuis l’entrée en vigueur du RGPD en 2018, le responsable du traitement des données — c’est-à-dire vous, en tant que dirigeant — est juridiquement responsable de la protection des données personnelles que votre entreprise collecte et stocke. Ce n’est pas votre hébergeur qui sera en première ligne en cas de fuite : c’est vous. Les sanctions peuvent atteindre 4 % de votre chiffre d’affaires annuel mondial, ou 20 millions d’euros — le montant le plus élevé étant retenu.

Mais au-delà du cadre juridique, les conséquences opérationnelles d’un serveur compromis sont immédiates et concrètes. Un rançongiciel qui chiffre vos données, c’est votre activité à l’arrêt : plus d’accès aux emails, au site web, au CRM, aux fichiers partagés. Pour une PME, chaque jour d’interruption représente des dizaines de milliers d’euros de perte — sans compter la perte de confiance de vos clients et partenaires.

En 2024, l’ANSSI (Agence nationale de la sécurité des systèmes d’information) rapportait que les PME et TPE représentent 40 % des victimes de rançongiciels en France. La raison est simple : elles sont souvent moins bien protégées que les grandes entreprises, tout en manipulant des données sensibles — fiches clients, coordonnées bancaires, contrats, données de santé.

Le problème n’est pas que les dirigeants ne s’intéressent pas à la sécurité. C’est qu’ils n’ont pas les repères pour évaluer ce qui est fait — ou ce qui ne l’est pas. Quand votre infogérant vous dit que « tout est en ordre », comment le vérifier ? Quand il vous facture un service de sécurité, comment savoir si c’est le minimum vital ou une prestation solide ?

C’est exactement l’objet de cet article : vous donner une grille de lecture claire, concrète et applicable, pour reprendre le contrôle sur un sujet qui engage votre responsabilité personnelle de dirigeant.

Hébergement infogéré : ce que ça couvre réellement (et ce que ça ne couvre pas)

Quand une entreprise souscrit un hébergement infogéré, elle part souvent du principe que tout est pris en charge : le serveur, sa maintenance, et sa sécurité. C’est rarement aussi simple. Comprendre les contours exacts de la prestation est indispensable pour éviter les mauvaises surprises.

L’infogérance, dans sa définition la plus courante, désigne la délégation de la gestion technique d’un serveur ou d’une infrastructure à un prestataire externe. Cela peut aller du simple hébergement avec surveillance basique jusqu’à une prise en charge complète incluant sécurité, sauvegardes, mises à jour et support 24/7. Le problème, c’est que le périmètre exact varie énormément d’un prestataire à l’autre — et que les contrats ne sont pas toujours limpides.

Beaucoup de dirigeants confondent deux choses fondamentalement différentes : « l’hébergeur gère mon serveur » et « l’hébergeur sécurise mon serveur ». La gestion peut se limiter à s’assurer que la machine tourne, que l’espace disque ne sature pas, et que le réseau fonctionne. La sécurité, elle, suppose des actions actives : durcir la configuration, appliquer les correctifs, surveiller les intrusions, tester les sauvegardes.

Si votre contrat mentionne uniquement « maintenance de l’infrastructure » sans détailler les actions de sécurité, il y a de fortes chances que la sécurité proactive ne soit pas incluse. Et dans ce cas, vous pensez être protégé… mais vous ne l’êtes pas.

Le modèle de responsabilité partagée en infogérance

Il existe un concept clé à comprendre quand on externalise son hébergement : la responsabilité partagée. Ce modèle, popularisé par les fournisseurs cloud comme AWS ou Azure, définit clairement ce qui relève du prestataire et ce qui relève du client. En infogérance classique, ce partage existe aussi, même s’il est rarement formalisé.

En général, voici comment les responsabilités se répartissent :

Domaine	Infogérant	Client
Infrastructure physique (réseau, alimentation, refroidissement)	✅ Oui	Non
Système d’exploitation (installation, mises à jour)	✅ Oui (si inclus)	À vérifier
Pare-feu et règles réseau	Souvent	Validation
Sauvegardes	Souvent (exécution)	Validation et test
Sécurité applicative (code, CMS, plugins)	Rarement	✅ Oui
Gestion des accès utilisateurs	Rarement	✅ Oui
Conformité RGPD	Partiellement (sous-traitant)	✅ Oui (responsable)
Plan de reprise d’activité	Rarement inclus de base	✅ À demander

Ce tableau illustre un point essentiel : même avec une infogérance « complète », la sécurité applicative et la conformité restent sous votre responsabilité. Si votre site tourne sous WordPress avec des plugins non mis à jour, ce n’est généralement pas votre hébergeur qui va s’en occuper — sauf si vous avez spécifiquement contractualisé ce service.

Pour aller plus loin sur le choix de votre solution d’hébergement, consultez notre guide pour choisir son hébergement web.

La clé, c’est de formaliser le périmètre de sécurité dans le contrat. Demandez un document qui liste explicitement ce que le prestataire fait, ce qu’il ne fait pas, et ce qui est optionnel. Si cette liste n’existe pas, c’est le premier signal d’alerte.

Les fondamentaux que tout serveur infogéré doit respecter

Quel que soit votre secteur d’activité ou la taille de votre entreprise, il existe un socle de sécurité minimum que tout serveur infogéré doit respecter. Ce ne sont pas des options premium ou des extras facturés en supplément : ce sont les bases. Si votre prestataire ne les met pas en œuvre, votre serveur est vulnérable.

Passons en revue ces fondamentaux un par un, en expliquant pourquoi chacun compte et ce que vous devez exiger concrètement.

Mises à jour système et correctifs de sécurité

Un serveur dont le système d’exploitation n’est pas à jour est une porte ouverte. Chaque mois, des vulnérabilités sont découvertes dans Linux, dans les services réseau, dans les bases de données. Les éditeurs publient des correctifs (patches) pour les combler. Si ces correctifs ne sont pas appliqués, les failles restent exploitables — et les attaquants le savent.

Votre infogérant doit appliquer les mises à jour de sécurité dans un délai raisonnable : idéalement sous 48 heures pour les failles critiques, sous deux semaines pour les autres. Il doit aussi être en mesure de vous fournir un historique des mises à jour appliquées. Pour approfondir ce sujet, consultez nos bonnes pratiques de gestion des mises à jour.

Pare-feu configuré et maintenu

Le pare-feu (firewall) est la première ligne de défense de votre serveur. Il filtre le trafic réseau entrant et sortant selon des règles définies. Un pare-feu correctement configuré n’autorise que les connexions strictement nécessaires : le port 443 pour le HTTPS, le port 22 pour l’administration SSH (idéalement restreint à certaines adresses IP), et les ports spécifiques à vos applications.

Un serveur livré avec un pare-feu « ouvert » — c’est-à-dire qui laisse passer tout le trafic — n’est pas un serveur sécurisé. C’est un serveur en attente d’être compromis. Pour aller plus loin, notre article sur les bonnes pratiques firewall détaille les règles essentielles.

Accès SSH sécurisé

SSH (Secure Shell) est le protocole utilisé pour administrer un serveur à distance. C’est la porte d’entrée technique principale. Si cette porte est mal protégée, tout le reste s’effondre. Voici les exigences minimales :

• Authentification par clé, pas par mot de passe. Les clés SSH sont considérablement plus sûres que les mots de passe, même complexes. L’authentification par mot de passe devrait être désactivée sur tout serveur de production.
• Pas de connexion root directe. Le compte root (administrateur suprême) ne doit jamais être accessible directement en SSH. On se connecte avec un compte utilisateur, puis on élève les privilèges si nécessaire.
• Port SSH non standard. Par défaut, SSH écoute sur le port 22. Le changer réduit drastiquement les tentatives d’intrusion automatisées — même si ce n’est pas une protection suffisante en soi, c’est un filtre utile.
• Restriction par adresse IP. Idéalement, seules les adresses IP identifiées peuvent se connecter en SSH. Cela limite le risque même si une clé venait à être compromise.

Gestion des accès et politique de mots de passe

Qui a accès à votre serveur ? Combien de personnes disposent d’identifiants ? Sont-elles toutes encore en poste ? Ces questions paraissent évidentes, mais dans la réalité, beaucoup de serveurs cumulent des comptes obsolètes, des mots de passe partagés entre plusieurs personnes, ou des accès jamais révoqués après le départ d’un collaborateur ou d’un prestataire.

Votre infogérant doit mettre en place une politique de gestion des accès stricte : un compte par personne, des droits limités au strict nécessaire (principe du moindre privilège), et une procédure de révocation systématique lors de tout changement d’équipe.

Certificats TLS/SSL actifs et renouvelés

Le certificat TLS (souvent appelé « certificat SSL » par abus de langage) est ce qui permet la connexion chiffrée entre vos utilisateurs et votre site — le fameux cadenas dans la barre d’adresse. Sans lui, les données transitent en clair sur le réseau : mots de passe, formulaires de contact, données de paiement.

Votre infogérant doit s’assurer que les certificats sont en place, valides, et renouvelés automatiquement avant expiration. Un certificat expiré provoque une alerte de sécurité dans le navigateur de vos visiteurs — ce qui détruit immédiatement la confiance et nuit à votre référencement.

Checklist des basiques non négociables

Voici un récapitulatif synthétique des éléments que vous pouvez exiger de votre infogérant dès aujourd’hui :

Élément	Ce que vous devez exiger	Fréquence
Mises à jour système	Correctifs critiques sous 48h, autres sous 15 jours	Continue
Pare-feu	Règles restrictives, seuls les ports nécessaires ouverts	Revue trimestrielle
Accès SSH	Clés SSH, pas de root, port modifié, IP restreintes	Revue à chaque changement
Gestion des accès	1 compte/personne, révocation systématique	Revue trimestrielle
Certificats TLS	Renouvellement automatique, redirection HTTP → HTTPS forcée	Continue
Logs d’accès	Conservation 6 mois minimum, consultables sur demande	Continue

Si un seul de ces points n’est pas couvert, il est urgent d’ouvrir la discussion avec votre prestataire. Ce ne sont pas des options : ce sont les fondations de toute sécurité serveur.

Sauvegardes : la garantie que personne ne vérifie (jusqu’au jour où)

Les sauvegardes sont le filet de sécurité ultime. Quand tout le reste échoue — intrusion, erreur humaine, panne matérielle, rançongiciel — la capacité à restaurer vos données rapidement est ce qui sépare un incident gérable d’une catastrophe. Et pourtant, les sauvegardes sont le point le plus souvent négligé dans les contrats d’infogérance.

Le problème n’est pas que les sauvegardes n’existent pas. C’est qu’elles ne sont pas vérifiées. « On a des sauvegardes » est une phrase rassurante. « On a testé la restauration complète le mois dernier et ça a fonctionné en 45 minutes » est une phrase qui vaut quelque chose.

La stratégie 3-2-1 expliquée simplement

La règle 3-2-1 est le standard reconnu en matière de sauvegarde. Elle est simple à comprendre et redoutablement efficace :

• 3 copies de vos données : l’original + 2 sauvegardes. Si une copie est corrompue, il en reste une autre.
• 2 supports différents : par exemple, un disque local et un stockage distant. Cela protège contre les pannes matérielles.
• 1 copie hors site : dans un autre datacenter, un autre prestataire, ou un stockage cloud dédié. C’est la protection contre les sinistres majeurs (incendie, inondation, attaque ciblée).

Si vos sauvegardes sont toutes stockées sur le même serveur que vos données de production, vous n’avez pas de sauvegardes. Vous avez une copie qui sera détruite en même temps que l’original.

Fréquence, rétention et externalisation

La fréquence de sauvegarde dépend de votre activité. Un site e-commerce qui traite des commandes en continu a besoin de sauvegardes beaucoup plus fréquentes qu’un site vitrine mis à jour une fois par mois. Voici les repères courants :

• Sauvegarde quotidienne : le minimum pour toute entreprise avec de l’activité régulière. Elle capture les changements de la journée.
• Sauvegarde hebdomadaire complète : une image complète du serveur, permettant une restauration intégrale.
• Rétention de 30 jours minimum : pouvoir revenir à un état antérieur est crucial, notamment quand une compromission est détectée tardivement.

La rétention est un point souvent oublié. Si votre infogérant ne conserve que les 3 derniers jours de sauvegardes, et qu’un malware est actif depuis une semaine, toutes vos sauvegardes sont potentiellement compromises. Une rétention de 30 à 90 jours offre une marge de manœuvre indispensable.

Le vrai test : la restauration

Une sauvegarde qui n’a jamais été testée n’est qu’une promesse. Le seul moyen de garantir que vos sauvegardes fonctionnent, c’est de simuler une restauration régulièrement — au minimum une fois par trimestre. Cela implique de restaurer les données sur un environnement de test et de vérifier l’intégrité des fichiers, des bases de données et des configurations.

Demandez à votre infogérant un rapport de test de restauration. S’il ne peut pas vous le fournir, c’est qu’il ne teste pas. Et s’il ne teste pas, vous n’avez aucune garantie que vos données sont récupérables le jour où vous en aurez besoin.

Cas client — E-commerce alimentaire, 12 collaborateurs Situation : Après une corruption de base de données suite à une mise à jour applicative ratée, le client demande une restauration. L’infogérant découvre que les sauvegardes automatiques étaient en échec silencieux depuis 3 semaines. Action : Reconstruction partielle à partir de données fragmentaires. Mise en place d’un système de sauvegarde avec alertes en cas d’échec, tests de restauration mensuels automatisés, externalisation vers un second datacenter. Résultat : Perte de 72 heures de commandes (irrécupérables). Après la refonte du dispositif : restauration testée et fonctionnelle en moins de 30 minutes lors du trimestre suivant.

Ce que vous devez exiger de votre prestataire sur les sauvegardes

• Sauvegarde quotidienne des données et configurations, avec horodatage vérifiable.
• Externalisation d’au moins une copie hors du datacenter principal.
• Rétention minimum de 30 jours, idéalement 90 jours pour les environnements critiques.
• Tests de restauration trimestriels, documentés et partagés avec vous.
• Alertes en cas d’échec de sauvegarde — vous devez être informé, pas le découvrir après un sinistre.
• Temps de restauration garanti (RTO) inscrit dans le contrat : en combien de temps votre serveur est-il de nouveau opérationnel ?

Monitoring et surveillance : savoir avant que ça tombe

Un serveur peut fonctionner parfaitement pendant des mois puis tomber en quelques minutes. Un disque qui se remplit, une fuite mémoire, une attaque par déni de service, un processus qui s’emballe — les causes sont multiples. Sans surveillance active, vous ne découvrez le problème qu’au moment où vos clients vous appellent pour dire que le site est hors ligne. C’est trop tard.

Le monitoring (ou supervision) est l’ensemble des outils et pratiques qui permettent de surveiller l’état de santé de votre serveur en temps réel et d’être alerté avant qu’un problème ne devienne critique. C’est la vigie de votre infrastructure.

Supervision système : les indicateurs vitaux

Votre infogérant doit surveiller en permanence les indicateurs fondamentaux du serveur. Ce sont les constantes vitales de votre infrastructure :

• Utilisation CPU : un processeur constamment saturé ralentit tout et peut indiquer un problème applicatif, un script en boucle, ou une attaque en cours.
• Mémoire RAM : quand la mémoire est pleine, le serveur commence à utiliser l’espace disque comme tampon (swap), ce qui dégrade drastiquement les performances.
• Espace disque : un disque plein bloque les applications, les bases de données, et peut corrompre des fichiers. C’est l’une des causes de panne les plus fréquentes — et les plus faciles à anticiper.
• Trafic réseau : une augmentation soudaine peut signaler une attaque DDoS ou un usage abusif de vos ressources.
• Disponibilité des services : le serveur web, la base de données, le serveur de mail — chaque service critique doit être vérifié individuellement.

Détection d’intrusion et alertes

Au-delà de la supervision système, un bon infogérant met en place des mécanismes de détection d’intrusion. L’outil le plus courant sur les serveurs Linux est Fail2ban, qui surveille les tentatives de connexion échouées et bloque automatiquement les adresses IP suspectes. C’est une protection efficace contre les attaques par force brute.

D’autres outils complémentaires existent : les IDS (Intrusion Detection Systems) comme OSSEC ou Wazuh analysent les logs en temps réel et alertent en cas de comportement suspect — modification de fichiers critiques, élévation de privilèges non prévue, connexion depuis un pays inhabituel.

Mais la détection ne suffit pas sans un système d’alerte efficace. Votre infogérant doit être notifié immédiatement en cas d’anomalie, et vous devez savoir comment il réagit. Un monitoring sans procédure de réaction, c’est comme une alarme incendie sans pompier.

Logs centralisés et exploitables

Les logs (journaux d’événements) sont la boîte noire de votre serveur. Ils enregistrent tout : les connexions, les erreurs, les modifications de fichiers, les tentatives d’accès. En cas d’incident, ce sont les logs qui permettent de comprendre ce qui s’est passé, quand, et comment.

Votre infogérant doit centraliser ces logs, les conserver sur une durée suffisante (6 mois minimum, souvent exigé par la réglementation), et être capable de les exploiter rapidement en cas de besoin. Des logs éparpillés sur différents serveurs sans outil de consultation sont quasi inutiles en situation de crise.

Temps de réaction attendu (SLA)

Le SLA (Service Level Agreement), ou accord de niveau de service, est le document qui formalise les engagements de votre infogérant en termes de réactivité. Il doit répondre à ces questions :

• En combien de temps le prestataire détecte-t-il un incident ? (Temps de détection)
• En combien de temps intervient-il ? (Temps de prise en charge — GTI, Garantie de Temps d’Intervention)
• En combien de temps le service est-il rétabli ? (Temps de rétablissement — GTR, Garantie de Temps de Rétablissement)
• Quels sont les horaires de couverture ? (24/7, heures ouvrées uniquement ?)

Un SLA sérieux pour un serveur critique prévoit une détection en quelques minutes, une prise en charge sous 30 minutes, et un rétablissement sous 4 heures. Si votre contrat ne mentionne aucun SLA, vous n’avez aucun engagement — et donc aucun recours en cas de défaillance. Pour approfondir ce sujet, notre article sur la sécurité et fiabilité des systèmes IT détaille les niveaux de service à exiger.

Les indicateurs à suivre même sans être technique

Vous n’avez pas besoin de lire des logs pour suivre la santé de votre infrastructure. Demandez à votre infogérant un rapport mensuel synthétique qui inclut :

• Le taux de disponibilité du mois (objectif : 99,9 % minimum, soit moins de 44 minutes d’interruption par mois).
• Le nombre d’incidents détectés et leur temps de résolution.
• L’état des sauvegardes (succès / échecs).
• Les mises à jour de sécurité appliquées.
• Les éventuelles alertes de sécurité et les actions correctives.

Ce rapport est votre tableau de bord. S’il n’existe pas, proposez-le — un infogérant sérieux n’aura aucun mal à le produire. S’il refuse, posez-vous la question de la raison.

Les normes et référentiels de sécurité à connaître

Quand on parle de sécurité serveur, les normes et référentiels sont vos repères objectifs. Ils permettent de dépasser le « faites-nous confiance » et d’évaluer un prestataire sur des critères concrets et vérifiables. Vous n’avez pas besoin de les maîtriser dans le détail, mais vous devez savoir lesquels sont pertinents pour votre situation.

ISO 27001 : le standard international de la sécurité de l’information

L’ISO 27001 est la norme internationale de référence pour la gestion de la sécurité de l’information. Elle certifie qu’une organisation a mis en place un Système de Management de la Sécurité de l’Information (SMSI) structuré : identification des risques, politiques de sécurité, contrôles techniques et organisationnels, amélioration continue.

Pour un dirigeant, un infogérant certifié ISO 27001, c’est un gage de sérieux. Cela signifie que ses processus ont été audités par un organisme indépendant, et qu’il ne se contente pas de promettre une bonne sécurité — il la prouve par une démarche documentée et régulièrement vérifiée.

Attention cependant : la certification ISO 27001 du prestataire ne garantit pas automatiquement la sécurité de votre serveur. Elle garantit que le prestataire a les processus en place. C’est une condition nécessaire, pas suffisante.

HDS : l’hébergement de données de santé

Si votre entreprise manipule des données de santé — que vous soyez professionnel de santé, éditeur de logiciel médical, laboratoire, ou même prestataire IT d’un acteur de santé — votre hébergeur doit être certifié HDS (Hébergeur de Données de Santé). Ce n’est pas une recommandation : c’est une obligation légale en France, encadrée par le Code de la santé publique.

La certification HDS impose des exigences renforcées en matière de sécurité physique, de chiffrement, de traçabilité et de disponibilité. Elle est délivrée par des organismes accrédités et fait l’objet d’audits réguliers. Deux niveaux existent : « hébergeur d’infrastructure physique » et « hébergeur infogérant » — le second étant plus exigeant.

RGPD et ses implications sur l’hébergement

Le RGPD (Règlement Général sur la Protection des Données) n’est pas une norme technique à proprement parler, mais il a des implications directes et concrètes sur votre hébergement. En tant que responsable de traitement, vous devez vous assurer que votre hébergeur :

• Héberge vos données dans l’Union européenne (ou dans un pays reconnu comme offrant un niveau de protection adéquat).
• A signé un contrat de sous-traitance conforme à l’article 28 du RGPD, qui détaille les mesures de sécurité mises en œuvre.
• Met en œuvre des mesures techniques et organisationnelles appropriées pour protéger les données (chiffrement, contrôle d’accès, pseudonymisation le cas échéant).
• Vous notifie en cas de violation de données dans les 72 heures.

Si votre infogérant héberge vos données hors UE sans encadrement contractuel adéquat, vous êtes en infraction. Ce point est souvent sous-estimé, notamment quand des services annexes (sauvegardes, CDN, outils d’analyse) transitent par des serveurs américains sans que le dirigeant en soit conscient.

SecNumCloud : le label de confiance de l’ANSSI

SecNumCloud est un référentiel de sécurité développé par l’ANSSI, destiné aux prestataires de services cloud. Il impose des exigences très élevées en matière de sécurité technique, de gouvernance, et de souveraineté des données. Un prestataire qualifié SecNumCloud garantit un niveau de protection particulièrement robuste.

Ce label est surtout pertinent pour les entreprises qui traitent des données sensibles (défense, secteur public, opérateurs d’importance vitale). Mais connaître son existence vous permet d’évaluer le niveau de maturité de votre prestataire : s’il est qualifié SecNumCloud, vous êtes entre de très bonnes mains. S’il ne l’est pas, ce n’est pas rédhibitoire — mais vous pouvez lui demander quels référentiels il suit.

NIS2 : la directive européenne qui change la donne

La directive NIS2 (Network and Information Systems Directive), entrée en application en 2024, élargit considérablement le périmètre des entreprises soumises à des obligations de cybersécurité. Elle ne concerne plus seulement les opérateurs d’infrastructures critiques : de nombreuses PME dans des secteurs comme la santé, l’énergie, les transports, l’agroalimentaire, ou les services numériques sont désormais concernées.

Si votre entreprise entre dans le périmètre NIS2, vous avez des obligations légales en matière de sécurité des systèmes d’information — et votre hébergeur doit être en mesure de vous accompagner dans cette mise en conformité. C’est un point à aborder explicitement avec votre infogérant.

Tableau récapitulatif — quelle norme pour quel besoin

Norme / Référentiel	Qui est concerné ?	Obligatoire ?	Ce que ça garantit
ISO 27001	Toute entreprise	Non (volontaire)	Processus de sécurité structuré et audité
HDS	Acteurs manipulant des données de santé	Oui (légal)	Hébergement conforme aux exigences de santé
RGPD	Toute entreprise traitant des données personnelles	Oui (légal)	Protection des données personnelles
SecNumCloud	Données sensibles, secteur public	Selon contexte	Niveau de sécurité et souveraineté très élevé
NIS2	Secteurs essentiels et importants	Oui (directive UE)	Obligations de cybersécurité renforcées

Pour une vue d’ensemble de nos prestations en la matière, consultez notre page sécurité et conformité.

Les erreurs courantes qui exposent votre serveur

Après des années d’accompagnement de PME sur leurs infrastructures, certaines erreurs reviennent systématiquement. Elles ne sont pas dues à de la négligence — elles sont dues à un manque de visibilité et de repères. Voici les plus fréquentes, et comment les éviter.

Un serveur jamais mis à jour

C’est l’erreur numéro un. Par peur de « casser quelque chose », les mises à jour sont repoussées indéfiniment. Résultat : le serveur tourne avec des versions obsolètes de l’OS, du serveur web, de PHP, de la base de données. Chaque vulnérabilité non corrigée est une porte ouverte.

La règle : les mises à jour de sécurité ne sont pas optionnelles. Votre infogérant doit les appliquer régulièrement et de manière encadrée (avec un environnement de test si nécessaire), pas les ignorer.

Des sauvegardes jamais testées

On en a parlé en détail plus haut, mais l’erreur mérite d’être répétée tant elle est fréquente. La sauvegarde existe sur le papier, mais personne n’a jamais vérifié qu’elle était exploitable. Le jour J, on découvre que les fichiers sont corrompus, que la procédure de restauration est incomplète, ou que le temps de restauration dépasse largement ce qui est acceptable.

La règle : un test de restauration par trimestre, documenté, avec mesure du temps de rétablissement.

Aucun plan de reprise d’activité

Le PRA (Plan de Reprise d’Activité) est le document qui décrit ce qu’on fait quand tout tombe : panne serveur, cyberattaque, sinistre. Qui appelle qui ? Quel est le serveur de secours ? Combien de temps avant la reprise ? Sans PRA, la réponse à un incident est improvisée — et une réponse improvisée est toujours plus lente, plus coûteuse et plus risquée.

La règle : un PRA écrit, connu des personnes clés, et testé au moins une fois par an.

Confondre hébergement mutualisé et infogérance

L’hébergement mutualisé (type hébergement à quelques euros par mois) n’est pas de l’infogérance. Sur un mutualisé, vous partagez un serveur avec des dizaines voire des centaines d’autres sites. La sécurité dépend largement de l’hébergeur, mais vous n’avez aucun contrôle sur la configuration et aucun SLA personnalisé. C’est adapté à un petit site vitrine avec peu d’enjeux, pas à une application métier ou un site e-commerce.

La règle : évaluer son besoin en fonction des enjeux. Si votre site ou application est critique pour votre activité, un hébergement dédié ou VPS avec une vraie infogérance de sécurité s’impose. Notre guide pour choisir son hébergement vous aide à y voir clair.

Besoin d’un accompagnement ?

Si cet article a soulevé des questions — ou confirmé des inquiétudes — je propose un diagnostic sécurité serveur : analyse de votre configuration actuelle, identification des vulnérabilités critiques, et plan d’action priorisé avec les premières recommandations à mettre en œuvre immédiatement.

Aucun jargon, un livrable clair, et une vision honnête de votre situation, contactez-nous pour en discuter

Sécurité serveur et hébergement infogéré