Une panne de serveur peut rendre un site inaccessible, interrompre des commandes et fragiliser la confiance des clients. Pour un hébergeur web, la redondance des serveurs est donc un moyen concret de préserver la continuité de service.
Elle consiste à prévoir des composants capables de prendre le relais, mais ne remplace ni les sauvegardes ni une organisation de crise. Le choix des équipements dépend d’abord des services à protéger et du temps d’arrêt acceptable.
A retenir :
- Disponibilité accrue des sites et applications hébergés
- Services critiques classés selon leur impact métier
- Réplication des données associée à des sauvegardes vérifiées
- Exercices réguliers pour éprouver la reprise après sinistre
Redondance des serveurs et continuité de service
Cette priorité de disponibilité commence par une question pratique : quels services doivent rester accessibles lors d’une panne ? Un hébergeur peut devoir protéger à la fois les sites clients, les bases de données et les outils d’administration.
Définir les besoins de haute disponibilité
Pour répondre à cette question, il faut hiérarchiser les applications selon les conséquences de leur interruption. Une boutique en ligne peut perdre des ventes, tandis qu’un service administratif peut parfois fonctionner temporairement avec des procédures manuelles.
Le SGDSN recommande de construire le plan de continuité à partir des activités essentielles et de scénarios d’indisponibilité. Cette démarche évite d’investir dans le même niveau de haute disponibilité pour chaque composant.
Priorités des services hébergés :
- Sites marchands : limiter les interruptions de commande
- Bases de données : protéger les transactions et leur cohérence
- Messagerie : maintenir les échanges avec les clients
- Administration : conserver un accès contrôlé aux outils de gestion
Un diagnostic utile précise aussi les délais de reprise acceptables et la quantité de données qu’une organisation peut perdre. Ces repères orientent la réplication des données et la fréquence des sauvegardes.
Comparer les architectures de serveurs redondants
Une fois les priorités définies, l’architecture doit répondre aux défaillances réellement envisagées. Un serveur secondaire peut suffire à certains usages, alors qu’un cluster convient mieux aux services exigeant une disponibilité plus constante.
Architecture
Principe
Usage adapté
Serveur de secours
Une machine prend le relais après une panne
Services pouvant tolérer une reprise planifiée
Cluster actif-passif
Un nœud secondaire attend la défaillance du principal
Applications nécessitant une reprise encadrée
Cluster actif-actif
Plusieurs nœuds traitent les requêtes en parallèle
Charges réparties entre plusieurs serveurs
Redondance géographique
Des ressources sont réparties entre plusieurs sites
Risques affectant un centre d’hébergement entier
« Nous pensions tenir deux jours sans base de données, puis le BIA a révélé une rupture d’activité au bout de six heures. »
Claire M.
Selon ISO 22301, la continuité d’activité se prépare et se maintient dans le temps, plutôt que de reposer sur un équipement isolé. Le choix architectural doit donc inclure les réseaux, le stockage et les procédures humaines.
Basculement automatique et tolérance aux pannes
Après la sélection d’une architecture, la continuité dépend de la manière dont ses composants réagissent à une défaillance. La tolérance aux pannes suppose que le relais soit conçu, surveillé et compréhensible par les équipes.
Organiser le basculement et la réplication des données
Le basculement automatique peut rediriger les requêtes vers un serveur disponible lorsque le principal ne répond plus. Il faut toutefois vérifier que les applications, les connexions réseau et les données suivent correctement ce changement.
Selon l’ANSSI, les mesures de sécurité doivent être adaptées aux risques et intégrées aux pratiques de l’organisation. Une réplication seule ne constitue pas une sauvegarde indépendante : une suppression ou une attaque peut aussi se propager.
Contrôles de l’infrastructure redondante :
- Vérifier les alertes de santé des serveurs
- Tester les chemins réseau de secours
- Contrôler la cohérence des copies répliquées
- Conserver des sauvegardes isolées et restaurables
Éviter les points uniques de défaillance
Un serveur doublé n’élimine pas tous les risques si les deux machines dépendent de la même alimentation ou du même équipement réseau. L’analyse doit rechercher ces dépendances communes avant qu’une panne locale ne touche l’ensemble du service.
Composant
Risque commun
Mesure de continuité
Alimentation
Coupure électrique partagée
Alimentations et sources distinctes
Réseau
Rupture d’un chemin unique
Routes et équipements alternatifs
Stockage
Défaillance ou altération des données
Copies séparées et restauration testée
Centre de données
Incident touchant un site entier
Ressources de secours sur un autre site
« Pendant l’exercice, nous avons compris que l’adresse de contact d’urgence était stockée uniquement sur le serveur principal. »
Marc D.
Ces contrôles réduisent les défaillances en chaîne, mais une architecture fiable doit également être éprouvée en conditions réalistes. Les tests révèlent si les équipes peuvent réellement restaurer les services.
Reprise après sinistre et fiabilité des serveurs
Une architecture bien conçue ne suffit pas si personne ne sait l’activer ou restaurer les données. Les exercices transforment les procédures de reprise après sinistre en gestes connus, plutôt qu’en consignes découvertes pendant l’incident.
Tester la continuité de l’hébergement web
Un test peut commencer par la restauration d’un fichier, puis simuler l’arrêt d’un serveur ou d’un service complet. Il permet de mesurer les délais réels et de repérer les accès, contacts ou dépendances manquants.
Selon le SGDSN, les exercices doivent alimenter des corrections concrètes du plan. Une entreprise qui découvre une sauvegarde inutilisable lors d’un test peut la remplacer avant qu’une panne réelle ne compromette son activité.
Exercices utiles pour la reprise :
- Restaurer régulièrement des données sauvegardées
- Simuler la perte d’un serveur ou d’un lien réseau
- Confirmer les rôles de la cellule de crise
- Documenter les écarts et les mesures correctives
Relier la technique aux procédures humaines
Quand les outils habituels sont indisponibles, des contacts hors ligne et des consignes accessibles facilitent la coordination. Les équipes métier doivent savoir quels services passent en premier et comment poursuivre temporairement leurs opérations.
« Nous avons lancé une restauration trimestrielle, puis réduit de moitié le temps de reprise au fil des exercices. »
Sophie R.
« Le régulateur nous a demandé des preuves d’exercice, pas seulement une politique écrite. »
Julien P.
La fiabilité des serveurs se juge ainsi à la fois par leur architecture et par la capacité des équipes à maintenir ou rétablir les services. Un dispositif testé régulièrement protège mieux les clients qu’une redondance jamais mise à l’épreuve.
Source : SGDSN, « Guide pour réaliser un plan de continuité d’activité », SGDSN, 2013 ; ISO, « ISO 22301, systèmes de management de la continuité d’activité », ISO, 2019 ; ANSSI, « Guide d’hygiène informatique », ANSSI, 2022.
