TL;DR : Un plan de reprise après sinistre (PRA) définit comment votre organisation redémarre après un incident majeur. Pas besoin d'un document de 200 pages : identifiez vos systèmes critiques, fixez vos objectifs de récupération (RPO/RTO), documentez les procédures de restauration, et testez le tout au moins une fois par année. Si votre PRA est "on appellera le gars de l'informatique", vous n'avez pas de PRA.
Votre serveur prend feu demain matin à 3h. Votre comptable arrive au bureau à 8h et rien ne fonctionne. Vos courriels sont morts, votre ERP ne répond pas, votre site web affiche une erreur. Qu'est-ce qui se passe ensuite?
Si la réponse c'est "je sais pas", vous n'êtes pas seul. Près d'une PME sur deux n'a aucun plan formel pour ce genre de situation. Et le feu, c'est même pas le scénario le plus probable : un rançongiciel qui chiffre tout, un disque dur qui lâche, une mise à jour qui tourne mal, ou simplement quelqu'un qui supprime le mauvais dossier par accident. Ça arrive tous les jours.
Le problème, c'est que la plupart des gens confondent "avoir des sauvegardes" avec "avoir un plan de reprise". C'est comme dire "j'ai un extincteur, donc j'ai un plan d'évacuation". Les sauvegardes, c'est un ingrédient. Le PRA, c'est la recette complète.
Un PRA, en version courte
Un plan de reprise après sinistre (PRA), c'est un document qui répond à une question simple : si tout tombe, qui fait quoi, dans quel ordre, pour que l'organisation recommence à fonctionner?
Ça inclut les sauvegardes, oui. Mais aussi : qui a les accès pour restaurer? Sur quelle machine on restaure si le serveur est mort? Combien de temps ça prend? Est-ce qu'on perd des données, et combien? Qui appelle les clients pour les prévenir? Qui contacte le fournisseur d'hébergement?
Un PRA, ce n'est pas un document théorique qu'on écrit une fois et qu'on range dans un tiroir. C'est un outil vivant qui doit être testé, mis à jour, et connu des personnes qui vont l'exécuter. Si la seule personne qui sait comment restaurer les sauvegardes est en vacances au Mexique quand le serveur plante, votre PRA ne vaut rien.
Les scénarios qui arrivent vraiment
On a tendance à penser "sinistre" comme un incendie ou une inondation. C'est possible, mais c'est loin d'être le plus fréquent. Voici ce qu'on voit sur le terrain :
Rançongiciel (ransomware) : un employé clique sur la mauvaise pièce jointe, et en quelques heures tous vos fichiers sont chiffrés. L'attaquant demande une rançon. Même si vous payez (ce qu'on ne recommande pas), rien ne garantit que vous récupérerez vos données. C'est le scénario le plus courant et le plus dévastateur pour les PME. Si vos sauvegardes sont sur le même réseau, elles sont probablement chiffrées aussi.
Panne matérielle : un disque dur qui lâche, un contrôleur RAID qui fait défaut, une alimentation qui grille. Ça arrive sans prévenir. Si votre serveur a 5 ans et n'a jamais été remplacé, c'est une question de quand, pas de si.
Erreur humaine : quelqu'un supprime la mauvaise base de données, écrase un fichier critique, ou lance une mise à jour qui casse tout. C'est plus fréquent qu'on pense, et c'est souvent le plus difficile à détecter rapidement.
Panne de fournisseur cloud : votre hébergeur a un problème, votre fournisseur SaaS est en panne, ou votre fournisseur de courriel tombe. Vous n'avez aucun contrôle dessus, mais vous subissez quand même l'impact. Et non, Google et Microsoft ne garantissent pas vos données.
Sinistre physique : incendie, inondation, dégât d'eau, vol d'équipement. Moins fréquent, mais quand ça arrive, c'est total. Si votre seule sauvegarde est sur un disque dur dans le même bureau que votre serveur, vous perdez tout.
RPO et RTO : les deux chiffres à connaître
Avant de planifier quoi que ce soit, il faut répondre à deux questions fondamentales :
RPO (Recovery Point Objective) : combien de données pouvez-vous vous permettre de perdre? Si votre dernière sauvegarde date de hier soir et que le serveur tombe à 16h, vous perdez une journée complète de travail. Pour certaines organisations, c'est acceptable. Pour d'autres, perdre une heure de transactions est catastrophique. Le RPO dicte la fréquence de vos sauvegardes.
RTO (Recovery Time Objective) : combien de temps pouvez-vous vous permettre d'être en panne? Si ça prend 4 heures pour tout restaurer, est-ce que votre organisation survit? Est-ce que vos clients acceptent 4 heures sans service? Le RTO dicte votre stratégie de reprise : est-ce qu'on restaure sur le même serveur (plus long), on bascule vers un serveur de secours (plus rapide), ou on a un système de réplication en temps réel (le plus rapide, mais le plus cher)?
Le truc, c'est que le RPO et le RTO ne sont pas les mêmes pour tous vos systèmes. Votre site web vitrine peut probablement être en panne 24 heures sans catastrophe. Votre système de facturation ou votre courriel, c'est une autre histoire.
Combien ça coûte, une panne?
Les études récentes estiment que le temps d'arrêt coûte entre 8 000 $ et 25 000 $ de l'heure pour une PME typique. Mais ce chiffre cache beaucoup de nuances.
Pour calculer votre propre coût, pensez à :
| Facteur | Comment le calculer |
|---|---|
| Perte de productivité | Nombre d'employés affectés x salaire horaire moyen x durée de la panne |
| Perte de revenus directs | Revenus quotidiens / heures ouvrables x durée de la panne |
| Coûts de restauration | Heures de travail technique (interne + consultants externes) |
| Perte de clients | Difficile à quantifier, mais réel : un client qui ne peut pas vous joindre appelle un concurrent |
| Atteinte à la réputation | Impact à long terme sur la confiance des clients et partenaires |
| Pénalités contractuelles | Si vous avez des engagements de niveau de service (SLA) avec vos clients |
Pour une PME de 20 personnes avec un salaire moyen de 30 $/h, la perte de productivité seule représente 600 $/h. Ajoutez les revenus perdus et les coûts de restauration, et une journée complète de panne peut facilement dépasser 10 000 $. C'est souvent plus que le coût d'un PRA complet.
Le PRA minimum viable pour une PME
Une PME de 20 personnes n'a pas besoin du même PRA qu'une banque. Mais elle a besoin d'un PRA. Voici le strict minimum :
1. Inventaire des systèmes critiques. Faites la liste de tout ce dont votre organisation a besoin pour fonctionner : courriel, ERP, comptabilité, partage de fichiers, site web, téléphonie. Classez-les par ordre de priorité. Qu'est-ce qui doit revenir en premier?
2. Objectifs de récupération. Pour chaque système critique, définissez votre RPO et votre RTO. Soyez réaliste : un RTO de 15 minutes quand votre seule stratégie c'est de restaurer un backup sur un nouveau serveur, c'est de la fiction.
3. Stratégie de sauvegarde qui suit la règle 3-2-1. Trois copies de vos données, sur deux types de supports différents, dont une copie hors site. Si toutes vos sauvegardes sont sur le même serveur, ou dans le même bureau, ce n'est pas un plan, c'est un voeu pieux. On va couvrir la règle 3-2-1 en détail dans un prochain article.
4. Procédures de restauration documentées. Pas "on va restaurer le backup". Des vraies étapes : sur quel serveur, avec quel compte, quelle commande, dans quel ordre. Assez détaillé pour que quelqu'un d'autre que votre technicien principal puisse le faire.
5. Liste de contacts d'urgence. Qui appeler en premier? Le responsable TI, le fournisseur d'hébergement, le fournisseur de sauvegardes, la direction. Avec les numéros de téléphone, pas juste les courriels (parce que si le serveur de courriel est en panne...).
6. Plan de communication. Comment informez-vous vos employés que les systèmes sont en panne? Comment prévenez-vous vos clients? Avoir un modèle de message préparé d'avance évite de paniquer et d'envoyer un courriel maladroit en pleine crise.
Rôles et responsabilités : qui fait quoi?
Un PRA sans responsable désigné, c'est un document orphelin. Pour chaque étape du plan, quelqu'un doit être nommé. Et il faut un substitut, parce que la personne principale pourrait être indisponible au moment du sinistre.
Au minimum, vous avez besoin de :
Un responsable de la décision : la personne qui déclare que oui, on est en situation de sinistre, et qui autorise l'exécution du PRA. Généralement la direction générale ou le responsable TI.
Un responsable technique : la personne qui exécute les restaurations, bascule les systèmes, et coordonne les aspects techniques. C'est souvent votre personne TI interne ou votre fournisseur de services gérés.
Un responsable des communications : la personne qui informe les employés, les clients, les partenaires. C'est un rôle qu'on oublie souvent, mais en pleine crise, la communication fait toute la différence.
Chacun de ces rôles doit avoir un substitut clairement identifié, avec les mêmes accès et les mêmes connaissances.
Tester le plan : le point faible de tout le monde
La réalité, c'est que la majorité des PME qui ont un PRA ne l'ont jamais testé. C'est comme avoir un extincteur qu'on n'a jamais vérifié. Peut-être qu'il fonctionne. Peut-être pas.
Tester un PRA, ça veut dire simuler un sinistre et suivre les procédures pour vrai. Pas lire le document en réunion : réellement restaurer une sauvegarde, vérifier que les données sont là, mesurer combien de temps ça prend.
Idéalement, vous testez au moins une fois par année. Chaque test va révéler des problèmes : une sauvegarde qui ne contenait pas ce qu'on pensait, une procédure qui ne fonctionne plus parce que le système a changé, un mot de passe qui a été modifié depuis la dernière version du document.
Après chaque test, mettez le PRA à jour. Un PRA qui date de 2 ans et qui n'a jamais été testé donne un faux sentiment de sécurité : c'est presque pire que de ne pas en avoir du tout.
La documentation : quoi écrire, où la mettre
Le contenu du PRA doit être concis et pratique. Pas un roman : un guide de procédures. Voici ce qu'il devrait contenir :
Inventaire des systèmes avec les informations de connexion, l'emplacement des serveurs, les versions des logiciels. Pour chaque système : RPO, RTO, responsable, procédure de restauration.
Procédures de restauration étape par étape, avec les commandes exactes si c'est technique. Quelqu'un qui n'a jamais fait la procédure devrait pouvoir la suivre.
Contacts d'urgence avec numéros de téléphone (pas juste courriel), disponibilités, et alternatives.
Modèles de communication prêts à envoyer aux employés, aux clients, aux partenaires.
Et le point crucial : ne stockez pas le PRA uniquement sur le serveur qu'il est censé protéger. Si votre PRA est sur le serveur qui vient de prendre feu, il ne vous aide pas beaucoup. Gardez une copie imprimée accessible, une copie dans le cloud (différent de votre infrastructure principale), et idéalement une copie chez le dirigeant ou le responsable TI.
Loi 25 : vos obligations en cas d'incident
Si votre sinistre implique une fuite de données personnelles (un rançongiciel qui exfiltre des données avant de les chiffrer, un vol de serveur, etc.), la Loi 25 vous impose des obligations légales.
Si l'incident présente un risque de préjudice sérieux pour les personnes touchées, vous devez aviser la Commission d'accès à l'information (CAI) dans les plus brefs délais, et notifier les personnes touchées. Vous devez aussi tenir un registre de tous les incidents de confidentialité et le conserver pendant 5 ans.
Les amendes sont significatives : jusqu'à 10 millions de dollars ou 2 % du chiffre d'affaires mondial pour les manquements administratifs. C'est pas rien pour une PME.
Le lien avec le PRA? Votre plan devrait inclure une procédure spécifique pour les incidents impliquant des données personnelles : qui évalue si c'est un incident à signaler, qui rédige l'avis à la CAI, qui contacte les personnes touchées. En pleine crise, vous n'avez pas le temps de chercher comment faire.
Les outils libres qui aident
Vous n'avez pas besoin d'un logiciel à 50 000 $ pour mettre en place un PRA solide. Plusieurs outils libres font très bien le travail :
BorgBackup : sauvegarde avec déduplication et chiffrement. Extrêmement efficace pour les sauvegardes incrémentales. Si vous sauvegardez 500 Go de données mais que seulement 2 Go changent par jour, Borg ne sauvegarde que les 2 Go qui ont changé. Idéal pour les sauvegardes locales et via SSH.
Restic : similaire à Borg, mais avec un support natif pour le stockage cloud (S3, Backblaze B2, Azure, SFTP). Plus simple à déployer dans un contexte multi-sites. Un bon choix si votre sauvegarde hors site va dans le cloud.
Proxmox VE : virtualisation libre qui permet de prendre des snapshots de vos machines virtuelles. Si votre serveur est virtualisé, un snapshot avant une mise à jour vous permet de revenir en arrière en quelques minutes si ça tourne mal. Proxmox Backup Server (PBS) complète le tout avec des sauvegardes incrémentales des VMs.
Ansible : automatisation de la configuration des serveurs. Si votre serveur est configuré avec Ansible, vous pouvez reconstruire un serveur identique à partir de zéro en lançant un script. Au lieu de passer 8 heures à tout réinstaller manuellement, c'est fait en 30 minutes. C'est un investissement initial, mais en cas de sinistre, ça change tout.
Ces outils ne remplacent pas le PRA : ils sont les briques avec lesquelles vous le construisez.
Ce qu'un PRA ne règle pas
Un PRA bien fait, c'est essentiel. Mais il faut être honnête sur ses limites :
Un PRA ne prévient pas les sinistres. Il vous prépare à y répondre. La prévention passe par le durcissement de vos systèmes, un bon antimalware, et la formation de vos employés.
Un PRA sur papier qui n'a jamais été testé donne un faux sentiment de sécurité. Mieux vaut un PRA simple et testé qu'un document exhaustif que personne n'a validé.
Un PRA ne compense pas des sauvegardes inadéquates. Si vos sauvegardes ne contiennent pas les bonnes données, ou si elles ne sont pas testées régulièrement, le meilleur plan du monde ne vous sauvera pas.
Finalement, un PRA est aussi bon que sa dernière mise à jour. Si vous avez changé de serveur, de fournisseur, ou de logiciel depuis la dernière version, il est probablement déjà obsolète.
Checklist PRA minimum pour une PME :
- Inventaire de tous vos systèmes critiques avec RPO/RTO
- Sauvegardes automatisées suivant la règle 3-2-1 (3 copies, 2 supports, 1 hors site)
- Procédures de restauration documentées et testées
- Liste de contacts d'urgence accessible hors ligne (imprimée)
- Rôles et substituts clairement assignés
- Plan de communication (employés, clients, CAI si données personnelles)
- Test de restauration complet au moins 1 fois par année
- Revue et mise à jour du PRA après chaque changement majeur
Ce qu'on met en place pour nos clients
Chez Blue Fox, quand on déploie une infrastructure pour un client, le PRA fait partie du projet dès le départ. On utilise Proxmox pour la virtualisation, BorgBackup ou Restic pour les sauvegardes chiffrées hors site, et Ansible pour l'automatisation des configurations. Chaque déploiement inclut une sauvegarde hors site testée et documentée.
On ne promet pas le zéro temps d'arrêt : ça n'existe pas, sauf à des coûts qui n'ont aucun sens pour une PME. Ce qu'on promet, c'est un RPO et un RTO clairs, documentés, et testés. Quand quelque chose tombe, on sait exactement quoi faire et combien de temps ça va prendre.
Votre infrastructure actuelle n'a pas de PRA? On peut faire un état des lieux et monter un plan adapté à votre réalité. On en jase.
En résumé
Un PRA, c'est pas un luxe et c'est pas un projet de 6 mois. C'est un document vivant qui répond à la question : "si tout tombe demain, on fait quoi?" Si vous ne pouvez pas répondre à cette question en moins de 5 minutes, c'est le signe qu'il est temps de s'y mettre.
Commencez simple : identifiez vos 3 systèmes les plus critiques, vérifiez que vos sauvegardes fonctionnent (vraiment, en les testant), et écrivez les grandes lignes de votre procédure de restauration. Vous pouvez raffiner ensuite. L'important, c'est de commencer.
Besoin d'un coup de main pour monter votre PRA? On jase de votre situation.