Les sauvegardes sont intactes. Pourtant, les commandes ne partent plus, les salariés ne peuvent pas se connecter et la direction ignore quelles données ont été volées. Ce scénario résume le malentendu qui entoure la sauvegarde immuable : protéger une copie ne signifie pas savoir redémarrer une entreprise. À l’horizon de septembre 2026, l’enjeu des stratégies antirançongiciel n’est plus seulement de conserver les fichiers. Il est de reconstruire, dans un environnement fiable, les conditions permettant de travailler.
Une copie survivante, pas une entreprise opérationnelle
Le principe de l’immutabilité est simple : pendant une durée définie, les données sauvegardées ne peuvent être modifiées ou supprimées, selon les garanties et le mode de verrouillage retenus. C’est un progrès considérable face aux attaquants qui cherchent à détruire les sauvegardes avant de chiffrer la production. Mais cette propriété porte sur la conservation des copies, pas sur leur pertinence, leur innocuité ou leur capacité à remettre un service en marche.
Une sauvegarde peut ainsi contenir des fichiers déjà altérés, une configuration vulnérable ou des éléments compromis. Elle peut aussi être inutilisable sans un catalogue, une clé de chiffrement ou une infrastructure d’administration devenue inaccessible. L’immutabilité est une propriété de stockage ; la résilience est une capacité opérationnelle. Confondre les deux revient à vérifier que le canot flotte sans jamais s’assurer que l’équipage sait le mettre à l’eau.
Le vol de données change l’équation
La double extorsion, qui associe chiffrement et menace de divulgation, est bien documentée depuis plusieurs années. Certains groupes peuvent même chercher à faire pression sans chiffrer massivement les systèmes. Dans ce cas, une restauration parfaite ne supprime ni les copies détenues par les criminels ni les risques pour les clients, les salariés et les partenaires. La sauvegarde répond à la destruction ou à l’indisponibilité ; elle ne rembobine pas une fuite.
L’attaque contre Change Healthcare, en février 2024, a illustré l’ampleur des conséquences possibles lorsqu’un intermédiaire essentiel du système de santé américain est paralysé. Lors d’une audition parlementaire en mai 2024, le dirigeant d’UnitedHealth Group a indiqué que les attaquants avaient utilisé des identifiants compromis pour accéder à un portail dépourvu d’authentification multifacteur. La leçon dépasse le stockage : une faiblesse d’accès peut déclencher une crise qui touche tout un écosystème.
La réponse doit donc suivre deux trajectoires : rétablir les activités et traiter la compromission des données. Cela suppose une investigation, une analyse des obligations de notification, une communication maîtrisée et un accompagnement des personnes concernées. Aucun tableau de bord affichant des sauvegardes réussies ne remplace ce travail.
Quand les clés du coffre sont compromises
Le compte administrateur est souvent le point aveugle des discours rassurants. Même lorsqu’un attaquant ne peut pas effacer les copies verrouillées, ses privilèges peuvent lui permettre, selon l’architecture, d’interrompre les nouvelles sauvegardes, de modifier les politiques futures ou de rendre les outils de restauration indisponibles. Un verrou robuste sur les données ne protège pas automatiquement toute la chaîne qui y donne accès.
La séparation des identités devient alors décisive : comptes dédiés, privilèges limités, authentification forte et accès d’urgence maîtrisés. L’administration des sauvegardes ne devrait pas tomber mécaniquement avec celle du réseau de production. Même vigilance pour les clés cryptographiques et les consoles hébergées : qui peut les utiliser si l’annuaire, la messagerie et les postes habituels sont indisponibles ? Une procédure accessible uniquement depuis le système en panne n’est pas une procédure de secours.
Restaurer des serveurs ne restaure pas un métier
Imaginons un distributeur dont la base de commandes a survécu. Pour reprendre les expéditions, il lui faut aussi l’annuaire, la résolution de noms, les certificats, le logiciel d’entrepôt, les connexions transporteurs et les interfaces de paiement. Si l’un de ces maillons manque, la base restaurée reste une archive consultable, pas un outil de travail. Et si les applications reviennent à des instants différents, leurs transactions peuvent devenir incohérentes.
Le retour d’expérience publié par la British Library en mars 2024, après l’attaque d’octobre 2023, décrit notamment le poids des systèmes anciens et de la complexité technique dans la reconstruction. Il rappelle une réalité : le patrimoine informatique n’est pas un ensemble de machines interchangeables. Versions logicielles, documentation incomplète et dépendances historiques peuvent transformer une restauration en chantier de réingénierie.
Le bon ordre de reprise ne se déduit donc pas seulement de la taille des serveurs. Il part des activités prioritaires et remonte leurs dépendances. Encaisser, produire ou assurer une permanence téléphonique n’exigent pas les mêmes composants. Certaines fonctions peuvent repartir en mode dégradé ; d’autres nécessitent des contrôles d’intégrité avant toute réouverture.
L’exercice qui distingue la promesse de la preuve
Un test consistant à récupérer quelques fichiers reste utile, mais il ne démontre pas une capacité de reprise. L’exercice probant restaure un service complet dans un environnement isolé, avec ses dépendances et ses utilisateurs de référence. Il intègre aussi la recherche d’une copie suffisamment saine : la dernière sauvegarde disponible n’est pas nécessairement celle qu’il faut remettre en production.
Quatre questions à mettre au programme
- Peut-on repartir sans les accès habituels ? Tester l’indisponibilité de l’annuaire, des postes administrateurs et de la messagerie révèle les dépendances cachées.
- Le service fonctionne-t-il vraiment ? Une commande doit pouvoir être saisie, traitée puis rapprochée de son paiement, pas simplement apparaître à l’écran.
- Combien de temps prend la reprise complète ? Le chronomètre doit inclure les décisions, la préparation de l’environnement, les transferts et les vérifications métier.
- Le redémarrage est-il sûr ? Il faut prévoir l’assainissement, la rotation des secrets concernés, la correction du point d’entrée et une surveillance renforcée.
Deux indicateurs structurent la discussion : le délai cible de reprise et la perte de données maximale acceptable. Ils ne valent toutefois que s’ils sont confrontés à des mesures. Restaurer une petite machine virtuelle ne prouve pas que des volumes beaucoup plus importants pourront traverser les mêmes réseaux dans le temps promis. Les limites de débit, les ressources disponibles et l’assistance des prestataires doivent entrer dans le scénario.
Un sujet de direction, pas seulement d’infrastructure
L’exercice doit réunir informatique, cybersécurité, métiers, juridique, communication et direction. Qui autorise la réouverture ? Quel service passe avant les autres ? Quel partenaire faut-il prévenir ? Ces arbitrages consomment du temps lorsqu’ils sont découverts pendant l’incident. Le compte rendu doit déboucher sur des corrections attribuées à des responsables, puis sur un nouveau test. Sans cela, la répétition devient une démonstration rassurante plutôt qu’un apprentissage.
Et maintenant ? Dans la perspective de septembre 2026, les entreprises gagneraient à déplacer leur exigence : demander moins « nos sauvegardes sont-elles immuables ? » et davantage « quel service avons-nous réellement reconstruit, dans quel délai et avec quelles preuves ? ». L’immutabilité restera une protection essentielle, mais la maturité se mesurera surtout à la répétition des reprises, à l’autonomie des accès de secours et à la capacité des métiers à fonctionner autrement. Le jour de l’attaque, ce sont ces gestes éprouvés qui feront la différence.
