En bref : Un test de relance informatique (ou test DR) est un exercice de reprise après sinistre chronométré qui vérifie qu’un plan de relance fonctionne vraiment : les personnes, les procédures et les dépendances technologiques, pas seulement la restauration d’un fichier. Le test mesure les délais réels contre le RTO et le RPO fixés par la direction, et se conclut par un rapport écrit.
Si vous êtes responsable TI ou dirigeant et qu’un auditeur, un client ou votre propre conseil d’administration vous a demandé si votre plan de relance a déjà été testé, ce guide décrit comment mener ce test sérieusement, du choix du scénario jusqu’au rapport final.
Un premier test imparfait vaut mieux qu’un plan parfait jamais essayé.
Dans cet article
Qu’est-ce qu’un test de relance informatique ?
Un test de relance ne se limite pas à restaurer un fichier ou relancer un serveur depuis une sauvegarde. Il vérifie le plan complet : qui décide de déclencher la relance, qui l’exécute, dans quel ordre, avec quelles dépendances externes comme un fournisseur infonuagique, un lien Internet ou une licence logicielle. Une sauvegarde qui restaure correctement un fichier isolé ne dit rien sur la capacité réelle de relancer l’ensemble des systèmes en cascade.
C’est la distinction que nous détaillons dans Une sauvegarde non testée n’est pas une sauvegarde : un test de restauration valide une copie, un test de relance valide un plan. Le second inclut le premier, jamais l’inverse.
Ce guide fait partie de notre pilier continuité, sur les sauvegardes, le plan de relance et les tests, qui couvre l’ensemble de la démarche. Ici, on reste sur une seule question : comment mener un test de relance et quoi documenter.
Comment choisir le scénario de sinistre et le périmètre ?
Un test de relance commence par deux décisions écrites avant le premier chronomètre : le scénario et le périmètre.
Le scénario de sinistre précise ce qu’on simule. Chaque scénario mobilise des dépendances différentes et teste des réflexes différents :
- Perte d’un serveur physique.
- Panne du site principal.
- Indisponibilité d’un fournisseur infonuagique.
- Chiffrement par rançongiciel.
- Simulation de panne informatique localisée à un seul système.
Un scénario vague, du genre « un problème informatique majeur », ne mène nulle part : personne ne sait par où commencer le chronomètre.
Le périmètre borne ce qu’on restaure réellement pendant l’exercice. Restaurer l’ensemble de l’environnement de production un mardi après-midi n’est ni réaliste ni souhaitable pour la plupart des PME. Le périmètre courant restaure, dans un environnement isolé, un système ou un groupe de systèmes jugé critique, sans toucher à la production réelle.
Le choix du scénario et du périmètre n’est pas une décision technique seule. La direction doit trancher quels systèmes sont critiques et quelle indisponibilité est tolérable : c’est elle qui fixe le RTO (temps de relance cible) et le RPO (perte de données maximale tolérable) dont il sera question plus loin.
Qui joue quel rôle ?
Un test de relance mobilise plusieurs personnes, chacune avec un rôle précis, nommé avant le début de l’exercice, pas improvisé en cours de route.
| Rôle | Responsabilité pendant le test |
|---|---|
| Répondant décisionnel | Déclenche le test, tranche les questions imprévues, décide d’arrêter l’exercice au besoin |
| Exécutant technique | Applique les procédures de relance, restaure les systèmes selon le scénario retenu |
| Chronométreur | Mesure le temps écoulé à chaque étape, sans intervenir dans l’exécution |
| Observateur | Note les écarts, les improvisations et les étapes non documentées |
| Contact fournisseurs | Coordonne avec l’hébergeur ou le fournisseur infonuagique si le scénario l’exige |
Un même employé peut cumuler deux rôles dans une petite équipe, sauf le chronométrage et l’exécution. Celui qui exécute sous pression a rarement le réflexe de noter l’heure exacte de chaque étape. Séparer ces deux rôles, même dans une équipe de trois personnes, change la qualité du rapport final.
Comment chronomètre-t-on contre le RTO et le RPO ?
Le chronométrage est ce qui transforme un exercice en mesure. Sans lui, un test de relance informatique n’est qu’une démonstration qu’on sait où sont les sauvegardes.
Le RTO et le RPO sont deux chiffres fixés par la direction, pas devinés par l’équipe technique le jour du test. Nous les expliquons en détail dans RTO, RPO : les deux chiffres que votre direction doit connaître.
Pendant le test, le chronométreur note l’heure de déclenchement, l’heure où chaque système critique redevient utilisable, et l’ancienneté des données restaurées comparée au moment du sinistre simulé. Trois chiffres, à comparer directement aux cibles fixées d’avance.
Un écart entre le temps mesuré et le RTO cible n’est pas une anomalie à cacher, c’est exactement ce que le test devait révéler. Si votre RTO cible est de quatre heures et que la relance en a pris neuf, mieux vaut le savoir un mardi de test qu’un dimanche de vrai sinistre.
Que contient le rapport de test de relance ?
Le rapport de test de relance est le livrable qui reste après l’exercice. C’est aussi ce que demandent certains référentiels et certains auditeurs comme preuve que la continuité n’est pas qu’une politique sur papier, mais une capacité vérifiée.
Un rapport complet couvre, dans l’ordre :
- Le scénario et le périmètre retenus, avec la date et la durée de l’exercice.
- La liste des participants et leur rôle.
- Le déroulé chronologique, étape par étape, avec l’heure de chacune.
- Les temps mesurés, comparés aux cibles RTO et RPO.
- Les constats : ce qui a fonctionné, ce qui a dévié de la procédure écrite, ce qui manquait.
- Le plan de correction, avec un responsable et une échéance pour chaque action.
Le détail exact de ce qu’un référentiel donné exige d’un rapport de test varie d’une norme à l’autre. Nous comparons ces exigences dans Ce que les normes exigent : sauvegardes, relance et tests plutôt que de les reprendre une à une ici.
Que faire des constats ?
Un constat d’écart n’est pas un échec du test, c’est sa raison d’être. Un test qui ne révèle rien à corriger est suspect, pas rassurant : soit le scénario était trop facile, soit personne n’a vraiment cherché les problèmes.
Chaque constat devient une action dans le plan de correction, avec un nom et une date, pas une note vague du genre « à améliorer ». Une procédure manquante se rédige. Une dépendance oubliée se documente. Un délai trop long par rapport au RTO se creuse : est-ce un problème d’outil, de procédure ou de formation de l’équipe ?
Le prochain test de relance vérifie, entre autres, si les constats du précédent ont été corrigés. Un plan de correction jamais suivi vaut à peu près autant qu’un test jamais fait.
Beaucoup des questions qui reviennent après un premier test, sur la fréquence à respecter ou sur qui doit approuver le rapport, sont traitées dans Continuité et relance : les questions qu’on nous pose.
Qui exige ce genre de test ?
Un test de relance informatique documenté n’est plus seulement une bonne pratique interne. Plusieurs référentiels l’exigent ou l’encadrent, chacun avec ses propres modalités :
- ISO 22301:2019 (continuité d’activité) : impose un programme régulier d’exercices et de tests du plan de continuité.
- Trust Services Criteria (SOC 2, AICPA) : le critère de disponibilité exige la mise à l’essai des procédures de reprise qui appuient la récupération des systèmes.
- Certification TGV (MSSS, réseau de la santé du Québec) : porte notamment sur la sécurité de l’information des fournisseurs certifiés, un chapitre où un plan de relance testé trouve sa place.
- Norme CAN/DGSI 104 (Digital Governance Standards Institute) : comprend des contrôles de sauvegarde et de mise à l’essai des procédures de récupération.
- ITSP.10.171 (Centre canadien pour la cybersécurité) : encadre la protection de l’information désignée et sert de fondement au CPCSC pour les fournisseurs du secteur de la défense.
Nous ne reprenons pas ici le détail article par article de chacun de ces référentiels. Notre comparatif Ce que les normes exigent fait ce travail. Si votre organisation vise l’une de ces certifications, ou fait affaire avec un client qui l’exige contractuellement, un rapport de test de relance daté et signé n’est pas facultatif : c’est une pièce du dossier.
Le Centre canadien pour la cybersécurité publie aussi des guides destinés aux PME sur la préparation aux incidents, utiles même hors de tout contexte de certification.
Pour une PME sans obligation normative directe, la question reste la même. Un sinistre qui prive vos clients de vos services pendant quelques jours déclenche vite d’autres obligations, dont celles de la Loi 25 si des renseignements personnels sont touchés. Le test de relance ne règle pas ces obligations, il réduit le temps pendant lequel elles s’accumulent.
Votre dernier test de relance a-t-il produit un rapport écrit, ou seulement un compte rendu verbal le lendemain ? La différence compte le jour où un auditeur, un assureur ou un client vous la demande. Un audit TI indépendant vérifie où en est réellement votre plan de continuité, sans rien vous vendre d’autre que le constat.
Pour aller plus loin avec Factero :
- test de sauvegardes et préparation à la relève
- exercice de crise tabletop en présentiel
- audit informatique indépendant pour vérifier votre test
Foire aux questions
Un test de relance informatique est-il obligatoire ?
Aucune loi générale québécoise n’impose un test de relance à toute entreprise. Plusieurs référentiels et plusieurs clients l’exigent par contrat, et un sinistre mal maîtrisé déclenche souvent d’autres obligations, notamment celles de la Loi 25 si des renseignements personnels sont touchés.
Quelle est la différence entre un test de restauration et un test de relance ?
Un test de restauration vérifie qu’une sauvegarde se restaure correctement, un fichier ou une base de données isolée. Un test de relance couvre le plan complet : les personnes, les procédures et les dépendances technologiques, chronométré contre des cibles fixées d’avance. Le second inclut le premier, jamais l’inverse.
À quelle fréquence faut-il refaire un test de relance ?
Il n’existe pas de fréquence légale unique au Québec. Un rythme annuel est une base courante : le Centre canadien pour la cybersécurité recommande de tester périodiquement un plan de reprise informatique. À resserrer si l’environnement change souvent, nouveaux systèmes ou nouveaux fournisseurs, ou si un test précédent a révélé des écarts encore non corrigés.
Un test de relance interrompt-il la production ?
Non, pas s’il est bien cadré. Le test se déroule dans un environnement isolé, sur un système ou un groupe de systèmes jugé critique, sans toucher à la production réelle. C’est justement le rôle du périmètre défini avant l’exercice : borner ce qui est restauré pour éviter tout risque sur les opérations en cours.
Que se passe-t-il si un test de relance échoue ?
Rien de dramatique, à condition d’agir sur les constats. Un test qui révèle un plan non fonctionnel avant un vrai sinistre a rempli son rôle : c’est la raison la plus fréquente pour laquelle des plans de reprise échouent en situation réelle, faute d’avoir été testés sérieusement. Le seul vrai échec serait de ne rien corriger.
