Plan DR : Services critiques et points de défaillance

Élaboration d’un plan de reprise après sinistre : identifier les services critiques et points de défaillance

Un plan de reprise après sinistre (PRS, ou DR en anglais) commence par se concentrer sur les services destinés aux utilisateurs finaux. L’objectif est de minimiser l’arrêt des processus métier, pas seulement des composants d’infrastructure individuels. Les utilisateurs remarquent les pannes au niveau des services : impossibilité d’accéder aux e-mails ou au système ERP, pas un disque défaillant sur un serveur.

D’abord, listez vos services IT critiques — les outils sans lesquels l’entreprise perd du chiffre d’affaires ou en efficacité :

• Messagerie électronique
• Systèmes téléphoniques d’entreprise
• Progiciel de gestion intégrée (PGI, comme 1C ou SAP)
• Plateformes de collaboration documentaire
• Impression en réseau
• Accès Internet
• CRM d’entreprise et bases de données

Écartez les éléments non critiques comme les serveurs de jeux — ils n’impactent pas les opérations quotidiennes.

Identifier les points de défaillance dans l’infrastructure

Pour chaque service, repérez tous les points de défaillance potentiels — les composants d’infrastructure dont la panne rend le service indisponible. Un point de défaillance est toute unité où le dépannage s’arrête à « c’est en panne ».

Dans les appareils modulaires (comme les routeurs), considérez les modules individuels et le châssis séparément. Si vous pouvez isoler et remplacer des sous-composants, chacun est un point de défaillance à part entière.

Exemple pour le service « Messagerie électronique » :

• Système d’exploitation du serveur (Linux/Windows Server)
• Logiciel de messagerie (Postfix, Exchange)
• Commutateur réseau principal
• Alimentation électrique (onduleur, PDU)
• Serveurs DNS externes
• Filtres de listes noires (RBL)
• Climatisation de la salle serveur
• Stockage des données (SAN/NAS)

N’oubliez pas les équipements « fiables » : même un tableau de stockage avec RAID et réplication aura besoin d’un plan de reprise en cas de panne.

Analyser les dépendances entre points de défaillance

Les points de défaillance forment un graphe de dépendances : une panne peut en déclencher une cascade chez les autres. Par exemple, une défaillance d’onduleur arrête les serveurs, et au redémarrage de l’hyperviseur, les machines virtuelles ne se relancent pas correctement. Un commutateur côté client, en revanche, est indépendant.

Pour la « Messagerie électronique », les dépendances forment une chaîne : alimentation → serveurs → applications → réseau → services externes. Étendez ce modèle à tous les services critiques via un diagramme d’influence.

Cette analyse est cruciale pour la priorisation : elle dicte l’ordre de dépannage, les objectifs RTO/RPO et les risques. Les sections suivantes aborderont les procédures de reprise et les métriques.

Points clés à retenir

• Concentrez-vous sur les services visibles par les utilisateurs, pas le matériel : les entreprises mesurent l’arrêt en minutes de perte d’outils essentiels.
• Listez tous les points de défaillance, sans sauter les équipements « infaillibles » — la loi de Murphy frappe toujours.
• Les graphes de dépendances révèlent les pannes en cascade et accélèrent le MTTR (temps moyen de reprise).
• Un plan de PRS transforme la lutte contre les incendies en stratégies proactives avec budgets et SLA.
• Intégrez-le à une CMDB ou un outil ITSM pour une découverte automatisée.

— Editorial Team