Plan de relance informatique : le guide en 3 étapes

En bref : Un plan de relance informatique décrit comment une entreprise redémarre après un incident, appuyé sur des sauvegardes vérifiées et un test qui confirme que la relance fonctionne. La continuité tient en trois maillons : sauvegarder les données, planifier la relance, puis la tester avant d’en avoir besoin. Un maillon manquant annule les deux autres. Ce guide s’adresse aux PME québécoises.

Dans cet article

Pourquoi la continuité est-elle l’angle mort classique des PME québécoises ?

La plupart des dirigeants de PME savent qu’ils font des copies de leurs données. Peu savent combien de temps il leur faudrait pour redémarrer si ces données devenaient inaccessibles demain matin.

C’est l’angle mort classique. La sauvegarde se configure une fois, tourne en silence, et personne n’y repense jusqu’au jour où elle doit servir. Le plan de relance, lui, ne se configure pas : il se rédige, se révise et, surtout, se teste. Sans test, un plan de relance est une hypothèse, pas une capacité.

Le coût d’une heure d’arrêt se calcule en dollars canadiens, mais la vraie question n’est pas le chiffre. C’est de savoir combien d’heures votre entreprise peut réellement encaisser avant que les conséquences deviennent sérieuses, pour vos clients comme pour votre trésorerie.

Le rançongiciel a changé la donne. Une attaque ne détruit pas seulement vos systèmes en production, elle vise souvent vos sauvegardes en même temps, précisément parce qu’une sauvegarde intacte est ce qui vous permettrait de refuser de payer. Nous détaillons ce mécanisme dans Rançongiciel : votre vraie défense, c’est votre capacité de relance. La question n’est plus « avez-vous une sauvegarde ? », c’est « pouvez-vous redémarrer si votre sauvegarde est elle aussi touchée ? »

Quelle est la différence entre une sauvegarde, un plan de relance informatique et un test ?

Une sauvegarde, un plan de relance informatique et un test répondent chacun à une question distincte. Les trois mots se confondent pourtant dans la conversation courante.

La sauvegarde répond à « où sont mes données ? ». C’est la copie elle-même : ce qui est copié, où, à quelle fréquence, combien de versions sont conservées.
Le plan de relance, aussi appelé PRA (plan de reprise après sinistre) ou DRP (disaster recovery plan) en anglais, répond à « comment et en combien de temps je redémarre ? ». C’est la procédure : qui fait quoi, dans quel ordre, avec quels systèmes en priorité.
Le test vérifie que les deux premiers fonctionnent ensemble, dans la pratique, pas seulement sur papier.

Une sauvegarde sans plan de relance vous laisse des données intactes et personne pour les remettre en service dans un délai raisonnable. Un plan de relance sans sauvegarde à jour est un document bien écrit qui ne redémarre rien. Les deux sans test restent des suppositions.

La règle 3-2-1 est le standard minimal pour la première étape : trois copies de vos données, sur deux types de support différents, dont une copie hors site. Nous l’expliquons dans La règle 3-2-1 : pourquoi vos sauvegardes ne suffisent pas. Pour la troisième étape, l’erreur la plus fréquente que nous observons est de ne jamais la faire : une sauvegarde non testée n’est pas une sauvegarde, c’est un acte de foi.

C’est quoi, un RTO et un RPO, en langage de direction ?

RTO et RPO sont deux acronymes techniques qui cachent en réalité deux décisions d’affaires.

Le RTO (recovery time objective, ou durée d’arrêt maximale tolérable) répond à une question : combien de temps votre entreprise peut-elle fonctionner sans tel système avant que les conséquences deviennent sérieuses ? Le RPO (recovery point objective, ou ancienneté maximale de la dernière copie utilisable) répond à une autre : combien de données pouvez-vous vous permettre de reperdre, mesuré en temps depuis la dernière sauvegarde valide ?

Question	Ce qu’elle mesure	Qui devrait la fixer
RTO : en combien de temps redémarre-t-on ?	La durée d’arrêt tolérable	La direction, pas l’équipe TI seule
RPO : jusqu’où peut-on reculer dans le temps ?	La quantité de données qu’on accepte de reperdre	La direction, en fonction du risque d’affaires

Ces deux chiffres ne se déduisent pas d’un manuel technique. Ils dépendent de ce que votre entreprise peut encaisser : un cabinet comptable en pleine période de déclaration n’a pas le même RTO qu’une entreprise de services entre deux contrats. Nous consacrons un article complet à cette distinction : RTO, RPO : les deux chiffres que votre direction doit connaître.

Une fois ces deux chiffres fixés, encore faut-il vérifier que votre infrastructure actuelle peut réellement les respecter. C’est exactement ce que mesure un test de relance, mené dans des conditions proches du réel plutôt que sur papier. Nous décrivons la méthode dans Le test de relance (test DR) : comment on le mène, ce qu’on documente.

Que demandent les normes et les certifications ?

Les grands référentiels de continuité, dont ISO 22301, SOC 2, CAN/DGSI 104, la TGV et ITSP.10.171, exigent des preuves, pas des intentions. La continuité restait jusqu’ici une bonne pratique surtout interne ; une part croissante des contrats, des appels d’offres et des certifications l’exige désormais.

ISO 22301 est la norme internationale de référence en gestion de la continuité d’activité ; elle encadre la démarche complète, de l’analyse d’impact jusqu’au test périodique.
Le Trust Services Criteria, utilisé pour les rapports SOC 2, examine notamment la disponibilité des systèmes qu’un fournisseur héberge pour ses clients.
CAN/DGSI 104, du Digital Governance Standards Institute, pose des exigences comparables pour les organisations canadiennes, avec un contrôle dédié à la sauvegarde et à la récupération des données.

Dans le réseau de la santé du Québec, la certification TGV (Trousse globale de vérification) exige des fournisseurs de technologies qu’ils démontrent leur capacité de sauvegarde et de relance parmi ses critères de vérification. Le cadre est décrit dans l’orientation officielle du MSSS (publication 24-715-38W). Pour les entreprises qui traitent de l’information désignée pour le compte du gouvernement fédéral ou qui vendent à la défense, la norme technique ITSP.10.171 du Centre canadien pour la cybersécurité pose des exigences similaires, reprises par le programme canadien de certification en cybersécurité, le CPCSC, aussi désigné PCCC. Nous détaillons ce programme dans CPCSC / PCCC : guide complet de la certification cyberdéfense.

Au Québec, la Loi 25 n’impose pas explicitement un plan de relance, mais elle impose la protection des renseignements personnels et une obligation de déclaration quand un incident y porte atteinte. Un plan de relance qui fonctionne mal prolonge l’incident, il ne l’excuse pas.

Le fil commun entre tous ces référentiels : aucun ne se satisfait d’un plan rédigé et jamais éprouvé. Tous demandent un journal de sauvegardes, un plan à jour et, la plupart du temps, un rapport de test daté. Nous comparons ces exigences référentiel par référentiel dans Ce que les normes exigent : sauvegardes, relance et tests.

Comment un audit indépendant vérifie-t-il votre capacité de relance ?

Un audit de continuité vérifie trois choses concrètes, pas seulement la lecture de votre plan.

que vos sauvegardes existent réellement et respectent la fréquence annoncée ;
que votre plan de relance correspond à votre infrastructure actuelle, non à celle d’il y a deux ans ;
qu’un test de relance a été mené dans un délai raisonnable, avec un rapport qui en garde la trace.

C’est un exercice de vérification, pas de mise en œuvre. Un auditeur indépendant qui n’a rien à vous vendre en amont n’a aucun intérêt à gonfler ses constats ni à les minimiser : son rôle s’arrête au rapport, la décision d’agir vous revient entièrement. La différence est simple à énoncer : se faire dire par son propre fournisseur infonuagique que tout fonctionne n’est pas la même chose que se le faire confirmer par un tiers qui n’a rien à vendre derrière le constat.

Cette logique de vérification indépendante s’applique à l’ensemble de votre environnement TI, pas seulement à la continuité. Nous en détaillons la portée dans L’audit informatique : le guide complet du dirigeant québécois.

Par où commencer ?

Trois gestes concrets, dans l’ordre.

Vérifiez ce qui existe réellement aujourd’hui : quelles sauvegardes tournent, sur quels systèmes, avec quelle fréquence, et depuis combien de temps personne n’a vérifié qu’elles fonctionnent.
Fixez vos RTO et vos RPO par système, en fonction de ce que votre entreprise peut réellement encaisser, pas de ce que la technologie permet en théorie.
Planifiez un test de relance, même partiel, sur le système le plus critique. Un test partiel bien documenté vaut mieux qu’un plan complet jamais éprouvé.

Un plan de relance informatique jamais testé ressemble à un extincteur jamais vérifié.

Personne ne sait s’il fonctionne avant d’en avoir besoin, et ce moment-là n’est pas le bon pour l’apprendre. Les questions les plus fréquentes que les dirigeants nous posent sur ce sujet sont réunies dans Continuité et relance : les questions qu’on nous pose.

Si vous n’avez jamais fait vérifier cette chaîne par un tiers, un audit TI indépendant vous donne un portrait exact de ce qui fonctionne et de ce qui ne fonctionne pas, sans rien à vendre derrière le constat.

Planifier un appel exploratoire

Pour aller plus loin avec Factero :

Foire aux questions

Combien coûte un plan de relance informatique pour une PME ?

Il n’existe pas de fourchette universelle : le coût dépend du nombre de systèmes couverts, du RTO et du RPO retenus, et de l’état de l’infrastructure de départ. Un système au RTO serré coûte plus cher à protéger qu’un système que l’entreprise peut se permettre de perdre une journée. La vraie question à se poser d’abord n’est pas le prix du plan, c’est le coût d’une heure d’arrêt pour votre entreprise : c’est ce chiffre qui justifie l’investissement, pas l’inverse.

Une sauvegarde infonuagique suffit-elle comme plan de relance ?

Non. Une sauvegarde infonuagique, même un « backup » automatique chez un fournisseur reconnu, répond à la question de la copie des données. Elle ne répond pas à la question du temps de redémarrage ni de l’ordre dans lequel vos systèmes doivent revenir en ligne. C’est la différence entre avoir une copie et savoir s’en servir sous pression.

À quelle fréquence faut-il tester un plan de relance ?

Il n’existe pas de fréquence universelle imposée par une loi générale au Québec. Les référentiels sérieux, dont ISO 22301, exigent un calendrier de test défini selon les risques de l’organisation, sans imposer un chiffre unique ; un test annuel reste la pratique de base la plus répandue, plus fréquente pour les systèmes critiques. La bonne fréquence dépend de la vitesse à laquelle votre infrastructure change : plus elle change vite, plus le test doit se répéter.

Qui, dans une PME, devrait être responsable du plan de relance ?

La direction en fixe les objectifs, RTO et RPO en tête, parce que ce sont des décisions d’affaires. L’équipe TI ou un fournisseur en assure l’exécution technique. Confier tout le dossier à la seule équipe technique, sans que la direction ait tranché ce qu’elle peut réellement tolérer comme arrêt, est une des erreurs les plus fréquentes que nous observons.

Un incident qui empêche de récupérer des renseignements personnels doit-il être déclaré ?

Si l’incident touche des renseignements personnels et présente un risque de préjudice sérieux, la Loi 25 impose une déclaration à la Commission d’accès à l’information du Québec, indépendamment de la cause technique. Un plan de relance qui fonctionne mal n’excuse pas un retard de déclaration. C’est une raison de plus de savoir, avant l’incident, combien de temps votre relance prend réellement.

Sauvegardes, plan de relance informatique et tests : le guide complet

Besoin d’aide sur ce sujet ?