Plan de reprise après sinistre (PRA) : la checklist

Sauvegarde n'est pas reprise

Première confusion à lever : une sauvegarde copie vos données, un plan de reprise organise le redémarrage complet de votre activité. Avoir des sauvegardes ne suffit pas si vous ne savez ni dans quel ordre redémarrer les systèmes, ni combien de temps cela prendra, ni qui doit faire quoi.

Le PRA répond à ces questions à l'avance. Il transforme une situation de panique en une procédure connue, répétée et chronométrée. La différence se mesure en heures ou en semaines d'arrêt, et parfois en survie de l'entreprise.

Penser reprise plutôt que seulement sauvegarde change la perspective : on ne se demande plus seulement "ai-je une copie ?", mais "suis-je capable de redémarrer, et en combien de temps ?". C'est cette seconde question qui compte vraiment le jour J.

Définir le RTO et le RPO

Deux indicateurs structurent tout le plan. Le RTO (Recovery Time Objective) est le temps d'arrêt maximal tolérable : combien de temps pouvez-vous fonctionner sans ce système avant que les conséquences ne deviennent graves ? Le RPO (Recovery Point Objective) est la perte de données acceptable : jusqu'à quel point pouvez-vous revenir en arrière sans dommage ?

Une application critique vise un RTO court (quelques heures) et un RPO proche de zéro (quelques minutes de données perdues au maximum). Une application secondaire tolère des objectifs plus souples. Tout l'art consiste à fixer ces cibles système par système.

Ces deux chiffres déterminent l'architecture et le budget : plus ils sont exigeants, plus la redondance et la fréquence de sauvegarde nécessaires sont coûteuses. Les définir lucidement évite à la fois le sous-investissement dangereux et la surenchère inutile.

Des sauvegardes testées, pas seulement planifiées

Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Trop d'entreprises découvrent au pire moment que leurs sauvegardes étaient corrompues, incomplètes, ou impossibles à restaurer dans un délai acceptable. La planification ne suffit pas ; seule la restauration prouve quelque chose.

Adoptez une stratégie 3-2-1 et, surtout, testez régulièrement les restaurations. Un test trimestriel sur un échantillon représentatif révèle les problèmes pendant qu'ils sont encore réparables, et non en pleine crise.

Profitez de ces tests pour mesurer le temps réel de restauration. C'est lui, et non la promesse théorique, qui détermine votre temps d'arrêt effectif. Beaucoup d'entreprises découvrent que restaurer plusieurs téraoctets prend bien plus longtemps qu'imaginé.

Se protéger des rançongiciels avec l'immuabilité

Les rançongiciels modernes cherchent activement à chiffrer aussi vos sauvegardes, car ils savent que c'est votre filet de sécurité. Une sauvegarde immuable, c'est-à-dire non modifiable ni supprimable pendant une période définie, garantit qu'il restera toujours une copie propre à restaurer, sans céder au chantage.

Couplée à une copie hors ligne ou hors site, l'immuabilité est aujourd'hui un standard, pas un luxe. Elle transforme une attaque potentiellement fatale en incident gérable : on restaure, on repart, on n'a rien payé.

Notre page cybersécurité et conformité intègre cette protection dans une défense plus large. L'immuabilité des sauvegardes est l'un des investissements au meilleur rapport coût/bénéfice contre la menace dominante du moment.

Redondance et procédure de bascule

Pour les systèmes critiques, prévoyez un environnement de secours capable de prendre le relais. La bascule, c'est-à-dire le basculement de la production vers ce secours, doit être documentée pas à pas et non improvisée le jour de l'incident, quand le stress fait commettre des erreurs.

Notre hébergement infogéré peut intégrer cette haute disponibilité, dimensionnée selon la criticité. Toutes les applications n'en ont pas besoin ; il s'agit de protéger en priorité ce dont l'arrêt coûterait le plus cher.

Précisez aussi la procédure de retour à la normale : une fois l'incident réglé, comment revient-on à l'environnement principal sans provoquer une nouvelle interruption ? Ce volet est fréquemment oublié et cause une seconde panne, parfois pire que la première.

Rôles, contacts et ordre de priorité

En situation de crise, l'improvisation coûte cher. Documentez qui décide, qui exécute, et dans quel ordre les services doivent être rétablis. Certains systèmes doivent revenir avant d'autres, par exemple l'authentification avant les applications qui en dépendent.

Listez les contacts clés avec leurs coordonnées à jour : fournisseurs, hébergeur, assurance, personnes-ressources internes. Gardez cette liste accessible même si votre réseau est tombé, par exemple sous forme imprimée ou hors ligne, car un PRA stocké uniquement sur le système en panne ne sert à rien.

La Loi 25 exige d'ailleurs un plan de réponse aux incidents : votre PRA en est le prolongement naturel et couvre un périmètre plus large que le seul volet des renseignements personnels.

Communiquer pendant la crise

Un sinistre informatique n'est pas qu'un problème technique, c'est aussi un enjeu de communication. Vos clients, vos employés et parfois les autorités attendent des informations claires. L'absence de communication alimente l'inquiétude et abîme la confiance plus encore que la panne elle-même.

Préparez à l'avance des modèles de messages et identifiez qui communique, à qui et par quel canal. En cas d'atteinte à des renseignements personnels, la Loi 25 impose d'ailleurs d'informer les personnes concernées dans certaines situations.

Une communication maîtrisée, honnête et rapide limite les dégâts réputationnels. Elle montre que l'entreprise tient la situation, ce qui rassure bien plus qu'un silence gêné suivi d'explications tardives.

Les erreurs qui ruinent un plan de reprise

Le piège classique est le plan écrit une fois puis oublié dans un tiroir. Les environnements évoluent : un plan qui n'est pas mis à jour devient vite inexact, et donc inutile au moment critique. La revue régulière n'est pas optionnelle.

Autre erreur fréquente : stocker le plan et les contacts uniquement sur les systèmes susceptibles de tomber. Si votre plan de reprise n'est accessible que sur le serveur en panne, il ne sert à rien. Gardez-en une copie hors ligne.

Enfin, beaucoup négligent de tester la restauration complète, se contentant de vérifier que les sauvegardes tournent. Or seul un test de bout en bout révèle le temps réel de reprise et les dépendances oubliées. Sans test, vous avez un espoir, pas un plan.

Adapter le plan à la taille de l'entreprise

Un plan de reprise n'a pas à être un pavé de procédures dignes d'une multinationale. Pour une PME, l'enjeu est d'avoir un document court, clair et à jour, qui couvre les scénarios réellement probables plutôt qu'une liste exhaustive de catastrophes improbables. Mieux vaut deux pages réalistes et testées qu'un manuel de cent pages que personne n'ouvrira jamais le jour venu.

Concentrez-vous sur vos systèmes vitaux : ceux dont l'arrêt stoppe l'activité ou la facturation. Pour ces systèmes, définissez précisément le RTO, le RPO, l'ordre de redémarrage et les responsables. Le reste peut suivre un traitement plus léger, ce qui maintient le plan gérable et donc réellement utilisé.

L'accompagnement par une infogérance aide à calibrer cet effort. Un partenaire expérimenté sait distinguer ce qui est indispensable de ce qui relève du superflu rassurant, et adapte le dispositif à vos moyens sans vous vendre une usine à gaz dont vous n'avez pas besoin.

Tester le plan, sinon il n'existe pas

Un PRA sur papier n'a de valeur que testé. Un exercice annuel, au minimum, simule un scénario réaliste et révèle les angles morts : un mot de passe oublié, une dépendance ignorée, une étape bien plus longue que prévu, une sauvegarde inexploitable.

Chaque test améliore le plan et entraîne l'équipe. Le jour d'un vrai sinistre, ce sont ces réflexes répétés qui font la différence entre une reprise maîtrisée et une catastrophe désordonnée. On ne s'improvise pas calme sous pression ; on s'y prépare.

Idéalement, variez les scénarios testés : perte d'un serveur, attaque par rançongiciel, indisponibilité du datacenter. Chaque type de sinistre mobilise des réponses différentes, et un plan robuste les a toutes anticipées au moins une fois.

FAQ