En bref : La continuité informatique PME dépend de tests de relance réguliers, d’une participation qui dépasse l’équipe TI et de preuves conservées dans la durée. La fréquence se calibre sur la criticité des systèmes, un test peut se faire sans arrêter la production, et un test qui révèle des écarts a rempli sa mission.
Voici les questions que les dirigeants nous posent le plus souvent sur la continuité informatique PME, avec des réponses qui restent vraies même sorties de leur contexte.
Dans cet article
En continuité informatique PME, quelle est la fréquence recommandée pour un test de relance ?
La fréquence se calibre sur la criticité de vos systèmes, pas sur un chiffre universel. Un système qui traite des transactions en continu se teste plus souvent qu’un système de support interne, et tout changement majeur d’infrastructure, migration infonuagique, nouveau fournisseur, refonte applicative, justifie un nouveau test, peu importe la date du précédent.
Le principe derrière ce calibrage est simple. Un plan de relance non testé depuis longtemps peut très bien décrire une infrastructure qui n’existe plus : nouveaux serveurs, nouveau fournisseur infonuagique, application critique ajoutée en cours d’année. Le test ne valide pas seulement vos sauvegardes, il valide que le plan lui-même correspond encore à la réalité.
Trois facteurs font généralement monter la fréquence requise :
- La criticité du système pour la continuité des revenus ou des opérations quotidiennes.
- Le rythme des changements dans l’infrastructure, les fournisseurs ou les applications qui en dépendent.
- Les exigences d’un client, d’un assureur ou d’un programme de certification auquel l’entreprise est soumise.
Aucun de ces trois facteurs ne se mesure une fois pour toutes. Une entreprise qui change de fournisseur infonuagique ou qui ajoute un système critique change du même coup son propre calendrier de tests, que quelqu’un y pense ou non.
Un plan de relance jamais testé, c’est un extincteur jamais vérifié : personne ne sait s’il fonctionne avant l’incendie.
Plusieurs référentiels traitent de la continuité informatique, chacun avec ses propres exigences précises :
- La norme ISO 22301:2019 sur la continuité d’activité.
- Les Trust Services Criteria (SOC 2) de l’AICPA.
- La norme CAN/DGSI 104 du Digital Governance Standards Institute.
- Le guide ITSP.10.171 du Centre canadien pour la cybersécurité, sur la protection de l’information désignée.
- Les guides destinés aux PME du même centre.
Aucun ne fixe un chiffre qui s’applique à toutes les entreprises : c’est pourquoi ce guide donne des principes, pas des seuils. Si votre organisation doit démontrer sa conformité à un cadre précis, notre article Ce que les normes exigent : sauvegardes, relance et tests détaille les exigences chiffrées référentiel par référentiel.
Notre guide complet sur les sauvegardes, le plan de relance et les tests explique comment bâtir ce calendrier à partir de votre propre cartographie de systèmes, plutôt qu’à partir d’un chiffre emprunté à une autre entreprise.
Qui participe à un test de relance (test DR) ?
Un test de relance implique plus que l’équipe TI. Il faut au minimum un responsable d’affaires capable de juger si les données restaurées sont utilisables, pas seulement si elles existent.
La distinction compte. L’équipe TI peut confirmer qu’un serveur redémarre et qu’un fichier se restaure. Elle ne peut pas toujours confirmer que la version restaurée du système de facturation contient les bonnes données au bon état, ou que le registre comptable correspond à la dernière transaction connue. Cette validation appartient au responsable des finances, des opérations ou du service concerné par le système testé.
Un test DR (disaster recovery, reprise après sinistre) mené uniquement par les TI répond à une question technique. Il ne répond pas à la question qui compte pour l’entreprise : si l’incident survenait ce soir, pourrait-on rouvrir demain avec des données sur lesquelles on peut se fier ? Une sauvegarde non testée n’est pas une sauvegarde, et une sauvegarde validée par la seule équipe technique n’est qu’à moitié validée.
Selon la taille de l’organisation, la liste des participants peut inclure :
- La direction, pour trancher les décisions qui dépassent le mandat de l’équipe technique.
- Un représentant du service touché par le système restauré, pour juger si les données restaurées sont réellement utilisables.
- Une ressource indépendante, pour documenter objectivement ce qui a fonctionné et ce qui n’a pas fonctionné.
Cette dernière présence n’est pas un luxe : un test noté par les mêmes personnes qui l’ont exécuté tend à paraître mieux réussi qu’il ne l’était.
Une organisation oublie souvent un rôle : celui qui déciderait quoi communiquer aux clients ou aux partenaires si l’incident était réel. Un test de relance qui ne se pose jamais cette question laisse un angle mort entier, découvert seulement le jour où quelqu’un doit vraiment décrocher le téléphone.
Peut-on faire un test de reprise sans interruption de production en continuité informatique PME ?
Oui. Trois formules permettent de tester sans interrompre les opérations, chacune avec ses limites propres, à documenter au moment de choisir.
| Formule | Ce qu’elle vérifie | Sa limite |
|---|---|---|
| Restauration en environnement isolé | Que les sauvegardes sont lisibles et que les données restaurées sont cohérentes | Ne teste pas la bascule réelle des utilisateurs vers le système restauré |
| Exercice sur table | Que les rôles, les décisions et l’ordre des étapes sont clairs pour les personnes impliquées | Ne teste aucune donnée ni aucun système réel |
| Périmètre restreint | Qu’un sous-ensemble représentatif du plan fonctionne dans des conditions proches du réel | Laisse dans l’ombre les systèmes non couverts par le test |
Aucune des trois formules ne remplace un test complet en conditions réelles, mais peu d’entreprises peuvent se permettre d’arrêter leur production à répétition pour vérifier leur relance. Le choix raisonnable alterne : un exercice sur table ou une restauration isolée la plupart du temps, un test à périmètre plus large à intervalle plus espacé, selon la criticité établie plus haut.
Ce qui compte, c’est de documenter pourquoi une formule a été choisie plutôt qu’une autre, et ce qu’elle ne couvre pas. Un auditeur, un assureur ou un client qui pose la question s’attend à cette réponse, pas à une case cochée sans explication.
Conservation des preuves de sauvegarde : combien de temps faut-il les garder ?
Les preuves, rapports de test, journaux de sauvegarde, comptes rendus d’exercice, se conservent au minimum d’un cycle d’audit ou de certification à l’autre.
En continuité informatique PME, la preuve n’est pas le test lui-même : c’est ce qui en reste après. Un test de relance réalisé sans rapport écrit n’a de valeur que pour les personnes qui y ont assisté, et leur mémoire n’est pas une preuve devant un auditeur, un assureur ou un tribunal.
Un rapport de test utile répond à des questions simples :
- Quel système a été testé.
- Avec quelle formule (environnement isolé, exercice sur table, périmètre restreint).
- Par qui, et avec quel niveau de responsabilité.
- À quelle date.
- Combien de temps la restauration a pris.
- Quels écarts ont été relevés.
Un rapport qui se contente de conclure « test réussi » sans ces détails ne convainc personne d’extérieur à l’exercice, et n’aide pas non plus la prochaine équipe qui devra refaire le même test dans un an.
Certains programmes précisent des durées de conservation plus strictes que ce principe général. C’est le cas de plusieurs cadres normatifs pertinents pour le Québec, dont la TGV du réseau de la santé pour les fournisseurs technologiques visés, ou la norme CAN/DGSI 104 pour les organisations qui visent la certification CyberSécuritaire Canada. Notre article Ce que les normes exigent détaille ces durées référentiel par référentiel, plutôt que de les résumer ici en un chiffre unique qui ne s’appliquerait exactement à personne.
En pratique, la question à se poser n’est pas « combien de temps » dans l’absolu, mais « jusqu’à quand un auditeur, un assureur ou un client pourrait légitimement redemander cette preuve ». Tant que le cycle de vérification suivant n’est pas complété, l’ancien dossier reste pertinent.
Dans la continuité informatique PME, un test qui révèle des écarts est-il un échec ?
Non. Un test qui révèle des écarts a rempli sa mission : il a trouvé le problème avant l’incident réel. Le véritable échec, c’est de ne jamais tester.
C’est la question la plus mal comprise de toutes, et souvent celle qui décourage les dirigeants de tester. Un test qui se déroule sans accroc peut vouloir dire deux choses : que tout fonctionne réellement, ou que le test n’était pas assez exigeant pour révéler quoi que ce soit. Un test qui révèle des écarts, un délai de restauration plus long que prévu, une donnée manquante, une étape mal documentée, donne une information qu’aucun document théorique ne peut donner.
La bonne réaction devant des écarts n’est pas de les enterrer dans un rapport optimiste. C’est de les corriger, puis de retester ce qui a été corrigé. Une entreprise qui documente ses écarts et les ferme méthodiquement construit une capacité de relance qui se renforce à chaque cycle. Une entreprise qui ne teste jamais découvre ses écarts au pire moment possible, pendant l’incident, devant ses clients.
Si vous n’êtes pas certain que votre continuité informatique PME tiendrait le jour où elle compterait vraiment, la question se vérifie de l’extérieur. Un audit TI indépendant regarde vos sauvegardes, vos tests et vos preuves tels qu’ils sont, pas tels qu’on les présente en interne, et vous dit où vous en êtes réellement.
Pour aller plus loin avec Factero :
- vérifier vos sauvegardes par un test de restauration
- exercice de crise tabletop pour votre équipe
- bilan de continuité par audit informatique indépendant
Foire aux questions
Faut-il un rapport écrit après chaque test de relance ?
Oui. Sans rapport, le test ne laisse aucune preuve exploitable pour un auditeur, un assureur ou un client, et l’organisation ne peut pas comparer ses résultats d’une année à l’autre. Le rapport devrait nommer le système testé, la méthode utilisée, la date et les écarts relevés, pour rester utile à la prochaine équipe qui refera le test.
Un plan de continuité et un plan de relance informatique, est-ce la même chose ?
Non, mais les deux sont complémentaires. Le plan de continuité vise à garder les opérations essentielles en marche pendant une perturbation, parfois en mode réduit. Le plan de relance intervient après l’interruption pour restaurer les systèmes et les données. Une PME qui n’a que le second se retrouve sans réponse pendant l’incident lui-même, avant même que la restauration commence.
Faut-il tester tous les systèmes en même temps ?
Non. La plupart des organisations testent par lot, en commençant par les systèmes les plus critiques pour la continuité des opérations, plutôt que d’attendre un exercice unique censé tout couvrir à la fois et qui, en pratique, ne se produit jamais faute de temps et de ressources.
Le test doit-il couvrir les fournisseurs externes critiques ?
Oui, dans la mesure où la relance en dépend. Si un fournisseur infonuagique, un sous-traitant ou un partenaire technologique fait partie de la chaîne qui permet de rouvrir, le plan de relance doit prévoir comment vérifier sa propre capacité de relance, pas seulement présumer qu’elle existe.
