Le tableau de bord est vert. Les sauvegardes de la nuit sont terminées, les copies sont verrouillées, les alertes silencieuses. Puis le rançongiciel frappe. L’annuaire ne répond plus, les administrateurs perdent leurs accès et personne ne sait quelle version de la base clients restaurer. La copie existe, mais l’activité reste arrêtée. La sauvegarde protège une possibilité de retour ; seul un exercice démontre qu’elle est praticable. À l’horizon de septembre 2026, c’est sur cette différence que devrait se jouer la maturité des stratégies de récupération.
L’immutabilité, un verrou indispensable mais limité
Une sauvegarde immuable est protégée contre la modification ou la suppression pendant une durée définie. Selon les architectures, cette protection repose sur un stockage de type WORM, un verrouillage d’objets ou une appliance dédiée. Les garanties varient avec le mode choisi : certaines configurations autorisent des dérogations privilégiées, d’autres imposent une rétention beaucoup plus contraignante. Le mot « immuable » ne dispense donc jamais de lire les conditions techniques.
Ce verrou répond à une évolution bien documentée des attaques : les opérateurs de rançongiciels cherchent aussi à neutraliser les moyens de récupération. Ils peuvent supprimer des copies accessibles, compromettre la console de sauvegarde ou modifier les politiques avant le déclenchement du chiffrement. Séparer les identités d’administration, isoler les infrastructures et conserver une copie hors du domaine de confiance principal restent essentiels. Immuable ne signifie ni déconnecté ni indépendant.
Surtout, le verrou ne juge pas le contenu. Il peut conserver parfaitement une base déjà corrompue, un serveur contenant une porte dérobée ou des données chiffrées avant leur copie. Il ne protège pas davantage contre la publication d’informations volées. La récupération traite la continuité d’activité ; elle n’annule ni l’exfiltration ni les obligations de notification.
Les crises réelles racontent une reprise laborieuse
L’attaque subie par la British Library en octobre 2023 a illustré la longueur d’une reconstruction informatique. Dans son retour d’expérience publié en mars 2024, l’institution a décrit les destructions, l’exfiltration et les difficultés liées à une infrastructure complexe, comportant des systèmes anciens. La leçon dépasse le stockage : remettre des fichiers à disposition ne suffit pas à reconstituer tous les services qui les utilisent.
En février 2024, l’attaque contre Change Healthcare a, elle, perturbé à grande échelle les échanges administratifs et financiers du système de santé américain. Sans attribuer ces difficultés à une technologie de sauvegarde particulière, cet épisode rappelle qu’un intermédiaire indisponible peut bloquer de nombreuses organisations. Ces cas documentés éclairent notre analyse prospective pour septembre 2026 : la résilience se mesure au service rendu, pas au volume sauvegardé.
Le chronomètre doit partir avant la restauration
Deux objectifs structurent habituellement les plans : le RPO, soit la perte de données maximale acceptable, et le RTO, le délai visé pour rétablir un service. Mais un RTO annoncé sans exercice ressemble souvent à un temps de trajet calculé sans embouteillage. Inclut-il la décision de déclencher la reprise, l’investigation, la préparation d’un environnement sain et la validation métier ? Le périmètre doit être explicite.
La vitesse de lecture du stockage n’est qu’une composante. Il faut retrouver les catalogues, récupérer les clés de chiffrement, mobiliser les bonnes personnes et disposer de machines disponibles. Dans le cloud s’ajoutent parfois les quotas, les délais de récupération des classes d’archivage et les limites réseau. Une restauration massive peut aussi coûter sensiblement plus cher qu’un test portant sur quelques fichiers.
Un exercice qui met réellement le plan à l’épreuve
Le bon scénario ne commence pas par « choisissez un fichier à restaurer ». Il suppose, par exemple, que l’annuaire de production est compromis et que la console habituelle est inaccessible. L’équipe doit alors démontrer qu’elle sait reprendre depuis des identités de secours, une documentation disponible hors du système touché et des copies effectivement récupérables. L’exercice reste isolé pour ne pas mettre la production en danger.
- Choisir un service critique : commande, facturation ou gestion des stocks, avec un responsable métier identifié.
- Définir un point de reprise : expliquer pourquoi cette version est considérée comme suffisamment saine.
- Chronométrer chaque étape : accès, reconstruction, transfert, contrôles et réouverture.
- Tester une transaction complète : aller au-delà du simple démarrage d’une machine.
- Consigner les écarts : attribuer chaque correction à un responsable, puis la retester.
Restaurer dans le bon ordre, pas au hasard
Une application dépend rarement d’elle-même. Elle appelle un annuaire, un DNS, une base, un service de secrets, parfois un fournisseur externe. La difficulté devient circulaire lorsque l’outil de sauvegarde dépend précisément de l’environnement qu’il doit reconstruire. Une console nécessitant l’annuaire disparu, ou des clés stockées uniquement sur un serveur indisponible, peut transformer une copie intacte en coffre sans serrure utilisable.
Il faut donc dessiner un ordre de récupération et prévoir un socle minimal indépendant. Des comptes d’urgence correctement protégés, des configurations exportées et des procédures accessibles hors ligne peuvent faire la différence. Cet ordre doit aussi refléter les priorités économiques : rétablir un portail commercial sans son paiement ou sa logistique donne une impression trompeuse de reprise.
L’intégrité se prouve aussi au guichet métier
Un contrôle de somme de vérification confirme qu’un fichier correspond à la référence comparée ; il ne prouve pas que cette référence est saine. De même, une analyse antivirus sans détection ne garantit pas l’absence de compromission. La sélection du point de reprise doit croiser la chronologie de l’incident, les journaux disponibles et les investigations, dans un environnement de récupération isolé.
Vient ensuite la cohérence applicative. La base restaurée contient-elle des transactions partielles ? Les pièces jointes correspondent-elles aux dossiers ? Les commandes et les stocks racontent-ils la même histoire ? Restaurer plusieurs composants à des instants différents peut créer des incohérences sans produire d’erreur système. Les mécanismes de sauvegarde cohérente et de rejeu des journaux doivent être testés, pas simplement activés.
La validation finale appartient aussi aux utilisateurs. Un comptable doit pouvoir vérifier une écriture, un logisticien suivre une commande. Avant la reconnexion, les équipes techniques doivent traiter les accès compromis et les causes identifiées de l’intrusion. Sans cela, la restauration risque de remettre en service les conditions de l’attaque.
Remplacer le voyant vert par des preuves
Les tests automatisés réguliers restent utiles pour repérer tôt une copie illisible ou un démarrage impossible. Ils complètent, sans remplacer, des exercices transverses après les changements majeurs. Le tableau de bord pertinent montre le dernier test concluant par service, le délai réellement observé, la perte de données constatée et les dépendances encore non testées. Une exception visible vaut mieux qu’une promesse globale.
Et maintenant ? Pour septembre 2026 et au-delà, la trajectoire souhaitable est moins une course aux copies supplémentaires qu’une discipline de récupération démontrable. L’automatisation pourrait multiplier les vérifications en environnement isolé, mais elle ne décidera pas seule si une entreprise peut reprendre. La prochaine question à poser n’est donc pas « notre sauvegarde est-elle immuable ? », mais « quand avons-nous prouvé que nous pouvions retravailler avec ? »
