Aller au contenu
IT White GloveConseil TI · Canada
Menu

Guide de continuité et reprise · Canada · EN / FR

Décider ce qui doit survivre — avant de décider comment.

This guide is maintained in English as well. DR and continuity planning →

Un calendrier de sauvegarde n’est pas un plan de reprise, et un plan de reprise jamais testé est une hypothèse, pas une capacité. La direction doit décider ce qui doit revenir, à quelle vitesse et qui est responsable de le faire — avant qu’un incident n’impose la réponse.

La décision à rendre possible

Décider quels systèmes doivent être rétablis, dans quel ordre, dans quel délai, et qui porte la reprise — confirmé avant un incident, pas pendant.

Nommer ce qui doit revenir, et dans quel ordre

Tous les systèmes n’ont pas la même importance pendant une interruption. Repérez les systèmes requis pour servir la clientèle, payer le personnel et protéger les accès, et ceux qui peuvent attendre — puis séquencez la reprise selon cette priorité plutôt que la commodité technique.

  • Systèmes requis en heures plutôt qu’en jours
  • Dépendances entre systèmes qui influencent l’ordre de reprise
  • Qui confirme qu’un système est vraiment utilisable, pas seulement en fonction

Fixer un délai de reprise et une tolérance de perte de données par palier

La vitesse à laquelle un système doit revenir, et la quantité de données récentes que l’organisation peut se permettre de perdre, sont des décisions d’affaires — pas des valeurs techniques par défaut. Précisez les deux explicitement pour chaque palier afin que la conception des sauvegardes et les essais de reprise aient une vraie cible.

Séparer la sauvegarde de la capacité réelle de restaurer

Une sauvegarde jamais restaurée n’est pas vérifiée. Confirmez que la restauration est réellement testée selon un calendrier connu, que les personnes qui l’exécuteraient savent comment faire, et que le processus fonctionne sans dépendre de la disponibilité d’une seule personne.

Décider qui est responsable pendant une interruption réelle

Nommez qui déclare un incident, qui autorise la séquence de reprise, qui communique avec le personnel et la clientèle, et qui confirme la fin de l’incident. Un plan sans responsabilité nommée devient de l’improvisation au moment où il est vraiment nécessaire.

Cadre de décision

Ce que la direction devrait pouvoir vérifier.

Ces critères ne produisent pas une note. Ils rendent visibles les questions qui doivent être résolues avant une décision responsable.

CritèreSignal utileQuestion de direction
PrioritéLes systèmes sont classés selon la conséquence d’affaires, pas la commodité technique.Qu’est-ce qui ne peut vraiment pas attendre si ce système est indisponible?
CiblesDélai de reprise et perte de données acceptable sont précisés pour chaque palier.À quelle vitesse ce système doit-il revenir, et combien de données récentes peuvent être perdues?
Restauration vérifiéeLa restauration est réellement testée selon un calendrier connu, pas présumée fonctionnelle.Quand la restauration a-t-elle été testée pour la dernière fois, et qui l’a confirmé?
ResponsabilitéDes personnes nommées portent la déclaration, l’exécution et la communication durant un incident.Qui est autorisé à déclarer un incident et à diriger la réponse?

Scénarios pratiques

Le même cadre, appliqué à des décisions différentes.

Un incident de rançongiciel touche le stockage de fichiers et le courriel

Situation : Des systèmes deviennent indisponibles ou non fiables, et la direction doit décider quoi restaurer en premier et comment communiquer avec le personnel et la clientèle pendant l’interruption.

Réponse utile : Suivez l’ordre de priorité et le plan de communication convenus d’avance plutôt que d’improviser la séquence sous pression, et confirmez que les systèmes restaurés sont réellement propres avant de les remettre en service.

Limite : Ce guide n’offre aucun service de réponse à incident ni d’enquête judiciaire.

Un seul administrateur détient un savoir de reprise non documenté

Situation : La personne qui comprend réellement le fonctionnement des sauvegardes et de la reprise est indisponible lorsqu’un incident survient.

Réponse utile : Traitez ceci comme une lacune de gouvernance à corriger avant le prochain incident : documentez le processus de reprise, désignez une personne de relève et vérifiez qu’elle peut l’exécuter.

Limite : Ce guide ne remplace pas un plan documenté et testé par des conseils génériques.