GUIDE ENTREPRISE · RÉSILIENCE
Tester la reprise du réseau avant la vraie panne.
Un plan de reprise qui n’a jamais été exercé reste une hypothèse. Cette méthode relie les besoins métier aux scénarios de rupture, aux procédures techniques et aux preuves collectées pendant un essai contrôlé.
Quel est le premier test à organiser ?
Choisissez un service métier prioritaire et une panne plausible, par exemple la perte du lien Internet principal d’un site. Définissez à l’avance les critères de succès, les personnes présentes et les conditions d’arrêt. Simulez la rupture dans une fenêtre maîtrisée, mesurez la reprise de l’application, puis testez aussi le retour au fonctionnement normal.
- Unité de test
- Service métier de bout en bout
- Panne initiale
- Scénario plausible et contrôlé
- Mesure
- Horodatage, disponibilité et mode dégradé
- Fin de l’exercice
- Retour nominal et actions correctives
Scénarios à inscrire dans un programme de reprise réseau
| Scénario | Ce qui peut rester en panne | Essai utile | Preuve à conserver |
|---|---|---|---|
| Lien principal interrompu | VPN, appels IP ou applications cloud. | Basculer sur le secours et ouvrir les applications prioritaires. | Chronologie et résultats par application. |
| DNS ou DHCP indisponible | Nouveaux accès malgré un lien encore actif. | Tester résolution, attribution d’adresse et redondance. | Résultats des requêtes et des postes témoins. |
| Alimentation du local perdue | Routeur, commutateur, borne et téléphonie. | Vérifier autonomie et séquence de redémarrage. | Durée observée et ordre de reprise. |
| Retour du réseau principal | Sessions, routes ou services restés sur le secours. | Réintroduire le lien et surveiller les bascules. | État final et anomalies résiduelles. |
1. Fixer les objectifs avec les métiers
Demandez quelles applications doivent rester accessibles, combien de temps une interruption est supportable et quelles fonctions peuvent fonctionner en mode dégradé. L’objectif de reprise doit être relié à un usage observable : un terminal de paiement qui valide une transaction, une équipe qui passe un appel, ou une application qui enregistre une opération.
Distinguez la remise en service du réseau et celle de l’application. Une sonde qui répond ne prouve pas que les utilisateurs peuvent se connecter, résoudre les noms, s’authentifier et terminer leur tâche.
- Service et utilisateurs témoins
- Délai de reprise attendu
- Fonctions admises en mode dégradé
- Critère de succès observable
2. Préparer un exercice sans créer un incident incontrôlé
Définissez une fenêtre, les responsables, un moyen de communication indépendant et la procédure d’arrêt. Vérifiez que les équipes savent remettre la configuration initiale et que les applications critiques disposent d’une sauvegarde ou d’une solution de contournement adaptée.
Commencez par une revue sur table si la coupure réelle n’est pas encore acceptable. Passez ensuite à un essai technique ciblé, puis à un scénario plus complet lorsque les dépendances et les rôles sont compris.
- Autorisation et fenêtre de test
- Personnes d’astreinte et canal hors bande
- Point de retour arrière
- Critères d’interruption immédiate
3. Mesurer la reprise de bout en bout
Notez l’heure de la rupture, celle de la détection, du basculement, du rétablissement de chaque application et de la communication aux utilisateurs. Testez depuis les lieux réellement concernés : un poste câblé, le Wi-Fi, un site distant et, si nécessaire, un terminal mobile.
Consignez les symptômes de panne partielle. Un lien peut rester techniquement actif tout en perdant des paquets ou en laissant échouer DNS et VPN. Les scénarios doivent couvrir ces dégradations autant que la coupure franche.
- Horodatage des étapes
- Tests applicatifs réels
- Contrôle du DNS, VPN et téléphonie
- Observations depuis plusieurs points du site
4. Tester le retour et corriger le plan
Le retour au lien principal peut provoquer une deuxième interruption. Vérifiez les routes, les sessions, les appels et les services qui auraient pu rester sur le secours. La fin de l’exercice exige un état nominal confirmé par les utilisateurs témoins.
Transformez chaque écart en action datée avec un responsable. Mettez à jour les schémas, les contacts et les procédures, puis rejouez les étapes qui ont échoué. Le compte rendu doit permettre de comparer les exercices suivants sans masquer les limites.
- Retour du trafic sur le chemin nominal
- Confirmation par les utilisateurs
- Écarts, causes et propriétaires
- Nouvelle vérification après correction
Checklist avant décision
- Choisir un service métier prioritaire
- Définir une panne et un résultat attendu
- Valider la fenêtre et les responsables
- Préparer le retour arrière
- Tester depuis les points d’usage réels
- Horodater détection, bascule et reprise
- Vérifier le retour au lien principal
- Attribuer et retester les corrections
Réponses complémentaires
Une bascule automatique dispense-t-elle d’exercice ?
Non. Elle peut fonctionner pour le routeur mais laisser une application, un VPN, un appel ou le DNS indisponible.
Faut-il provoquer une vraie coupure ?
Une revue sur table est un premier pas. Un essai technique contrôlé donne ensuite une preuve plus forte, sous réserve d’une fenêtre et d’un retour arrière préparés.
Que mesurer pendant le test ?
La détection, le délai de bascule, la reprise des usages prioritaires, les fonctions dégradées et le retour au fonctionnement normal.
Quand refaire un exercice ?
Après un changement majeur ou la correction d’un échec, et selon un rythme adapté à la criticité du site et aux obligations de l’organisation.
Sources et limites
Ces ressources publiques complètent l’étude. Elles ne remplacent ni un test sur place, ni l’éligibilité opérateur, ni les conditions contractuelles applicables au service concerné.
- ANSSI — Anticiper et gérer une crise cyberPlans de continuité, de reprise et exercices de crise.
- ANSSI — Sauvegarde des systèmes d’informationBonnes pratiques pour rendre une restauration possible.
Guide préparé par l’équipe éditoriale de Nicholas Owen Global Telecom et mis à jour le . Les prix, couvertures, délais et performances doivent être confirmés par écrit.
Guides complémentaires
Ces sujets prolongent les vérifications présentées dans ce guide.
GUIDE ENTREPRISE · CONTINUITÉConcevoir un accès Internet de secours qui fonctionne vraiment.Dimensionnez un accès Internet de secours selon les applications critiques, les dépendances physiques, le basculement et les tests de reprise.
GUIDE RÉSEAU · RÉSILIENCEContinuité réseau : un accès de secours doit être indépendant et testé.Concevez une continuité Internet réaliste : dépendances, double accès, routeur, énergie, bascule, supervision et tests de reprise.