Erreur 1 : Confondre sauvegarde et continuité
La sauvegarde protège les données. La continuité protège l'activité. Ce ne sont pas les mêmes métiers, ni les mêmes budgets, ni les mêmes contrats.
- Sauvegarde : duplication périodique de données vers un dépôt secondaire. Mesurée par le RPO (quantité de données qu'on accepte de perdre).
- PRA (Plan de Reprise d'Activité) : dispositif technique et organisationnel qui permet de redémarrer les services métier après sinistre. Mesuré par le RTO (durée d'indisponibilité acceptable).
- PCA (Plan de Continuité d'Activité) : stratégie globale qui intègre le PRA, les procédures dégradées, les contournements métier, la communication de crise.
Une sauvegarde qu'on peut restaurer sous 24 h n'est pas un PRA quand l'ERP doit être opérationnel en 4 h. La différence se joue sur trois leviers : l'infrastructure cible de reprise (préprovisionnée ou à redéployer), la stratégie de copie des données (réplication synchrone, réplication asynchrone, ou sauvegarde périodique), et l'organisation humaine (qui redémarre, dans quel ordre, avec quelles procédures).
Ordre de grandeur à connaître. Pour une PME de 50 salariés au CA de 10 M€, le CA horaire ouvré ressort à ~5 500 €/h (10 M€ ÷ 1 800 h). Ajusté d'un coefficient d'impact indirect de 1,2 à 1,5 (pénalités, personnel immobilisé, image), le coût d'arrêt s'établit autour de 6 à 8 k€/h ouvrée. Un arrêt ransomware typique, non préparé, dure 5 jours ouvrés, soit 40 h de paralysie effective : 240 à 320 k€ de coût brut, avant pénalités juridiques et réputationnelles. Un dispositif de réduction à RTO 4 h coûte typiquement 18 à 25 k€/an. Ratio de couverture ≥ 10 à 1. L'arbitrage CODIR tient en une phrase.
Erreur 2 : Ne jamais tester les restaurations
« Les sauvegardes tournent. » Cette phrase ne porte aucune information opérationnelle. Ce qui compte, c'est la capacité à redémarrer un service métier sur une infrastructure de reprise, chronomètre en main, dans des conditions proches du sinistre.
Le socle méthodologique, c'est la règle 3-2-1-0 : 3 copies, 2 supports différents, 1 copie hors site, 0 erreur au test de restauration annuel. Le zéro est l'ajout moderne, et c'est, en audit, celui qui manque le plus souvent.
Un protocole de test réaliste se décline en trois rythmes :
- Test trimestriel : restauration granulaire : un fichier, une boîte mail, un dossier SharePoint. Objectif : valider que les sauvegardes sont lisibles et que les comptes d'accès fonctionnent. Durée : 30 minutes.
- Test semestriel : restauration d'une VM ou d'un service applicatif non critique sur infrastructure de reprise. Objectif : mesurer le MTTR réel. Durée : 2 à 4 heures.
- Test annuel : exercice PRA complet avec bascule d'un service critique (ERP, messagerie, fichiers). Objectif : valider runbook, dépendances, ordre de redémarrage, communication de crise. Durée : 1 à 2 journées.
Un PRA non testé n'est pas un PRA. C'est une hypothèse, et les hypothèses non vérifiées se paient toujours au moment où on en a le plus besoin. Les équipes qui pratiquent le test annuel détectent en moyenne deux à trois anomalies silencieuses à corriger (droits d'accès expirés, dépendances oubliées, documentation obsolète, licences expirées).
Erreur 3 : Pas de copie hors-site ou immuable
Les rançongiciels actuels (LockBit 3.0, BlackCat/ALPHV, Royal, Play) ne se contentent plus de chiffrer les postes et serveurs de production. Ils effectuent une reconnaissance préalable de plusieurs jours à plusieurs semaines pour identifier les dépôts de sauvegarde, élever les privilèges, exfiltrer des données, puis lancer le chiffrement en dernier, généralement un week-end, entre 2 h et 5 h du matin.
Trois niveaux de protection existent contre cette logique d'attaque, du plus simple au plus robuste :
- Anti-malware sur les dépôts de sauvegarde : détection comportementale, alertes sur suppressions massives. Nécessaire mais insuffisant : un attaquant avec privilèges admin désactive la supervision avant d'agir.
- Immuabilité logique : WORM (Write Once Read Many), verrou cryptographique, rétention obligatoire côté stockage objet (S3 Object Lock, Azure Blob immutability, Wasabi Object Lock). Protection forte si l'immuabilité est appliquée par la plateforme de stockage elle-même, pas seulement par l'agent de sauvegarde.
- Air-gap physique ou logique : copie sur bande LTO déconnectée, ou copie cloud sur compte séparé (tenant distinct, identifiants non accessibles depuis la production). Protection maximale, mais RTO plus long.
Les plateformes BCDR récentes ajoutent des contrôles automatisés complémentaires à l'immuabilité. Datto SIRIS démarre chaque sauvegarde dans un sandbox isolé et envoie une capture d'écran d'amorçage quotidienne (Screenshot Verification). Veeam SureBackup monte un laboratoire virtuel et valide le boot, les services et les ports applicatifs sans impacter la production. Acronis Active Protection surveille, côté production, les schémas de chiffrement suspects (hausse brutale d'écritures chiffrées, entropie anormale) pour alerter avant que l'attaquant n'atteigne les dépôts. Ces mécanismes ne remplacent pas l'immuabilité, ils la complètent en ajoutant une barrière de détection en profondeur.
La bonne combinaison pour une PME de 20-200 salariés est généralement : sauvegarde locale rapide (appliance ou NAS) pour les restaurations granulaires + copie cloud immuable sur compte séparé pour la résilience ransomware + test annuel de restauration complète. Le coût incrémental de l'immuabilité cloud est modéré (quelques centaines d'euros par mois selon volumétrie) au regard de l'impact d'une attaque réussie.
Erreur 4 : Aucun runbook de reprise documenté
Le jour du sinistre, personne n'improvise bien. Le redémarrage d'une infrastructure suit un ordre technique précis, dicté par les dépendances entre services. Sans document à jour, chaque étape devient une recherche, et chaque dépendance oubliée ajoute 20 à 40 minutes de retard.
La séquence AD → DNS → DHCP est non négociable : aucun service applicatif ne peut fonctionner sans résolution d'identité et de nom. Sauter une étape force un rollback.
Un runbook minimum tient sur 3 à 5 pages par service critique. Il contient :
- la liste des dépendances amont (services dont dépend le redémarrage) ;
- l'ordre technique de redémarrage : étape par étape ;
- les comptes de service : avec mots de passe stockés hors ligne ;
- les commandes ou scripts à exécuter, copiables tels quels ;
- les points de vérification (tel service doit répondre, tel endpoint doit retourner 200 OK) ;
- la liste des personnes à prévenir : avec numéros de téléphone personnels, pas uniquement professionnels.
Ce document doit être imprimé, stocké hors site et relu chaque année. Un runbook à jour dans OneDrive quand OneDrive est inaccessible n'est d'aucun secours.
Erreur 5 : Ignorer Microsoft 365
« C'est dans le cloud, Microsoft s'en occupe. » Cette phrase est techniquement inexacte. Microsoft applique explicitement un modèle de responsabilité partagée (Shared Responsibility Model) dans lequel l'éditeur garantit la disponibilité de la plateforme, mais pas la protection des données métier contre suppression, corruption ou exfiltration.
Les limites de la rétention native M365 sont documentées par Microsoft :
- Exchange Online : suppression récupérable 14 jours par défaut (30 jours maximum via rétention configurable). Au-delà, perte définitive.
- OneDrive / SharePoint : corbeille utilisateur 93 jours, corbeille administrateur supplémentaire limitée. Un ransomware qui chiffre via un client synchronisé se propage aux copies cloud en quelques minutes.
- Teams : messages de chat non restaurables après suppression, sauf rétention Purview activée et couverte par une licence E3/E5 complétée des add-ons appropriés.
- Après retrait de licence : 30 jours de rétention des données utilisateur, puis suppression définitive.
Un backup tiers M365 (voir notre observatoire Microsoft 365) n'est plus une option pour les organisations exposées au ransomware ou soumises à NIS2 par ricochet, au RGPD article 32, ou à des exigences d'assureur. Les acteurs matures du marché (Veeam Backup for Microsoft 365, Acronis Cyber Protect Cloud, Datto SaaS Protection, Keepit) proposent des RPO de quelques heures et une restauration granulaire jusqu'au message ou au fichier individuel.
Erreur bonus, Confondre « bon plan » et « bon budget »
Le PRA se négocie trop souvent au feeling : « on prend la formule intermédiaire, ça a l'air raisonnable ». C'est le meilleur moyen d'être soit surdimensionné (et de payer pour une résilience qu'on n'utilise pas), soit sous-dimensionné (et de le découvrir le jour du sinistre).
La méthode défendable en CODIR tient en trois paramètres :
- CA horaire du service concerné : CA annuel porté par le service ÷ 1 800 heures ouvrées.
- Coefficient d'impact indirect : multiplicateur 1,5 (bureautique) à 3 (production industrielle) pour intégrer pénalités, personnel immobilisé, perte d'image.
- Durée probable d'arrêt non préparé : 3 à 10 jours ouvrés pour un ransomware PME selon observations terrain.
Le chiffrage produit une phrase du type : « Une indisponibilité de 5 jours ouvrés (40 h ouvrées) de notre facturation coûte entre 240 et 320 k€ (CA horaire ouvré 5,5 k€/h, coefficient d'impact 1,2 à 1,5). Le dispositif qui ramène à 4 h coûte 18 k€/an. Ratio de couverture ≥ 10 à 1. » Cette phrase n'est pas une certitude, c'est un argument. Un CODIR peut contester les hypothèses ; il ne peut pas balayer un raisonnement chiffré. L'argumentation économique est ce qui transforme un « budget IT » en « décision business ».
Grille de synthèse, Bonne pratique vs mauvaise pratique
✗ Mauvaise pratique. « On a des sauvegardes, donc on a un PRA. »
✓ Bonne pratique. Distinguer sauvegarde (RPO) et PRA (RTO) dans les contrats et les budgets. Service par service.
✗ Mauvaise pratique. Vérifier les jobs au vert dans la console une fois par mois.
✓ Bonne pratique. Test trimestriel granulaire + test semestriel VM + test annuel PRA complet chronométré.
✗ Mauvaise pratique. Une seule copie sur NAS local accessible depuis le domaine AD.
✓ Bonne pratique. Règle 3-2-1-0 avec au minimum une copie cloud immuable sur compte séparé.
✗ Mauvaise pratique. Le PRA « est dans la tête » de l'admin principal.
✓ Bonne pratique. Runbook écrit, imprimé, stocké hors site, revu annuellement, avec mots de passe rescue et téléphones personnels.
✗ Mauvaise pratique. « Microsoft sauvegarde M365 pour nous. »
✓ Bonne pratique. Backup tiers M365 avec RPO court, rétention longue, restauration granulaire et copie hors-tenant.
✗ Mauvaise pratique. Choisir la formule « intermédiaire » au feeling.
✓ Bonne pratique. Chiffrer le coût d'arrêt horaire, arbitrer en ratio de couverture devant le CODIR.
À retenir, 3 actions concrètes cette semaine
Sans attendre le prochain comité IT
- Lancer une restauration réelle d'un service non critique cette semaine. Pas « vérifier les jobs ». Restaurer un partage de fichiers ou une VM de test sur une infrastructure de reprise, chronomètre en main. Documenter tout ce qui a manqué.
- Écrire en une page l'ordre de redémarrage des 5 services critiques. AD, DNS, DHCP, messagerie, ERP. Identifier les dépendances. Imprimer. Stocker hors site. Le test précédent révélera au moins deux étapes absentes du document.
- Vérifier la présence et la fraîcheur du backup Microsoft 365. Si vous n'avez pas encore de solution tierce, la décision d'achat à prendre avant la fin du trimestre est celle-ci. Sinon, confirmer le RPO et tester une restauration sur trois périmètres, un e-mail, un fichier OneDrive, un site SharePoint.
Le meilleur moment pour tester votre PRA, c'était il y a 6 mois. Le deuxième meilleur moment, c'est cette semaine.
Sources et références : ISO 22301 (continuité d'activité), ANSSI, Guide PCA et EBIOS Risk Manager, US-CERT 2012 (règle 3-2-1-0), Microsoft, Shared Responsibility Model (Microsoft 365 Service Description), observations terrain MAIANO 2023-2025 sur audits PRA PME/ETI francophones.