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.
Your server catches fire tomorrow morning at 3 AM. Your accountant arrives at the office at 8 AM and nothing works. Your emails are dead, your ERP isn't responding, your website shows an error. What happens next?
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.
The problem is that most people confuse "having backups" with "having a recovery plan." It's like saying "I have a fire extinguisher, so I have an evacuation plan." Backups are an ingredient. The DRP is the complete recipe.
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?
A DRP is not a theoretical document you write once and file away in a drawer. It's a living tool that needs to be tested, updated, and known by the people who will execute it. If the only person who knows how to restore backups is on vacation in Mexico when the server crashes, your DRP is worthless.
Scenarios that actually happen
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 and Microsoft don't guarantee your data.
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)?
The thing is, RPO and RTO aren't the same for all your systems. Your brochure website can probably be down for 24 hours without catastrophe. Your billing system or your email is a different story.
How much does downtime cost?
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 |
|---|---|
| Lost productivity | Number of affected employees x average hourly wage x duration of outage |
| Lost direct revenue | Daily revenue / business hours x duration of outage |
| Restoration costs | Hours of technical work (internal + external consultants) |
| Lost clients | Difficile à quantifier, mais réel : un client qui ne peut pas vous joindre appelle un concurrent |
| Reputation damage | Long-term impact on client and partner trust |
| Contractual penalties | If you have service level agreements (SLA) with your 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.
The minimum viable DRP for an SMB
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?
A DRP without a designated owner is an orphan document. For each step of the plan, someone must be named. And there needs to be a backup person, because the primary one could be unavailable when disaster strikes.
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.
Each of these roles must have a clearly identified backup, with the same access and the same knowledge.
Tester le plan : le point faible de tout le monde
On va se le dire : 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 Law 25 vous impose des obligations légales.
If the incident presents a risk of serious harm to affected individuals, you must notify the Commission d'accès à l'information (CAI) as soon as possible, and notify the affected individuals. You must also maintain a register of all confidentiality incidents and keep it for 5 years.
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.
Open source tools that help
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.
What a DRP doesn't solve
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 hardening your systems, un bon antimalware, and training your employees.
A DRP on paper that's never been tested gives a false sense of security. A simple, tested DRP is better than a comprehensive document that nobody has validated.
A DRP doesn't compensate for inadequate backups. If your backups don't contain the right data, or if they're not tested regularly, the best plan in the world won't save you.
Finally, a DRP is only as good as its last update. If you've changed servers, providers, or software since the last version, it's probably already obsolete.
Checklist PRA minimum pour une PME :
- Inventory of all your critical systems with RPO/RTO
- Automated backups following the 3-2-1 rule (3 copies, 2 media types, 1 offsite)
- Documented and tested restoration procedures
- Emergency contact list accessible offline (printed)
- Clearly assigned roles and backups
- Communication plan (employees, clients, CAI if personal data is involved)
- Full restoration test at least once a year
- DRP review and update after every major change
Ce qu'on met en place pour nos clients
At Blue Fox, when we deploy infrastructure for a client, the DRP is part of the project from the start. We use Proxmox for virtualization, BorgBackup or Restic for encrypted offsite backups, and Ansible for configuration automation. Every deployment includes a tested and documented offsite backup.
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é. Let's talk about it.
In summary
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? Let's talk about your situation.