ANALYSE LPCD
Ransomware : ce qu'une PME/ETI doit vérifier concrètement dans son plan de reprise
Avoir des sauvegardes ne suffit pas à démontrer une capacité de reprise. Voici cinq vérifications concrètes pour tester les identités, les accès de secours et le redémarrage des services critiques après un ransomware.
Publié le · 6 min de lecture · Analyse LPCD
Disposer de sauvegardes ne suffit pas à démontrer une capacité de reprise. Cette distinction, presque triviale sur le papier, prend un relief particulier à la lecture des dernières données publiées sur les incidents ransomware et, surtout, sur ce qui se passe réellement une fois qu'une organisation est compromise.
Pour une PME ou une ETI, l'enjeu opérationnel n'est plus seulement « comment éviter l'attaque » — probabilité sur laquelle aucune posture n'apporte de garantie — mais bien « que se passe-t-il le jour J et le jour J+1 ? ». Cet article propose une grille d'évaluation opérationnelle, à adapter au contexte de chaque entreprise.
Ce que les sources permettent d'observer, avec leurs limites
Deux publications éclairent les difficultés de reprise, dans des périmètres qu’il faut distinguer.
-
La pression des ransomwares. Dans son bilan d’août 2026, Comparitech recense 997 attaques, contre 809 en juillet, soit une hausse de 23 %. Son suivi inclut des attaques confirmées et des revendications de groupes criminels non confirmées. Ces données peuvent être révisées : ce total n’est donc ni un décompte exhaustif mondial ni un nombre d’incidents tous vérifiés.
-
L’écart entre objectif et reprise effective. Fenix24 indique que, sur plus de 800 interventions clients, quatre seulement se sont approchées de l’objectif de 24 à 48 heures pour une reprise partielle. Le prestataire rapporte aussi que 99,2 % de ses clients arrivaient sans plan documenté de récupération des identités. Ces constats décrivent son expérience d’intervention ; ils ne représentent pas statistiquement toutes les PME et ETI.
Autre point utile : dans 38 % des interventions Fenix24 où les sauvegardes avaient survécu intactes ou presque, elles n’ont pas permis d’assurer la reprise. Le dénominateur est important : ce pourcentage porte sur les interventions avec sauvegardes survivantes. La disponibilité d’une copie et son utilité opérationnelle sont deux questions différentes.
Lecture LPCD : un plan de reprise doit prouver que les dépendances nécessaires à un service peuvent être rétablies, dans un délai acceptable pour le métier. Les statistiques précédentes motivent cette vérification ; elles ne permettent pas de prédire le délai de reprise de votre entreprise.
Dépendances critiques : identités, authentification, applications, fournisseurs
Un scénario de crise utile doit envisager la perte de plusieurs composants dont l’activité dépend, notamment l’identité, les applications et les accès d’administration.
-
Identité. Pour Active Directory sur site, le plan doit prévoir la récupération de l’annuaire dans un environnement maîtrisé. Pour Entra ID, il faut identifier les objets et configurations récupérables, les outils disponibles et leurs limites. La récupération d’objets cloud ne doit pas être assimilée à une restauration complète de contrôleurs de domaine.
-
Authentification. Sans comptes valides, sans MFA opérationnel, sans stratégie d'accès de secours, les services qui en dépendent peuvent devenir inaccessibles, même si les sauvegardes existent.
-
Applications métier. ERP, CRM, outils de production, qui s'appuient sur l'identité et parfois sur des secrets (comptes de service, clés API) qu'il faut également savoir restaurer.
-
Fournisseurs SaaS critiques. Messagerie, bureautique collaborative, outils financiers. Leur compromission ou la perte d'accès peut entraîner un blocage aussi sévère qu'une attaque interne.
C'est donc l'ensemble de la chaîne d'authentification et de ses dépendances qu'il faut savoir relancer — pas seulement les fichiers.
Grille LPCD : cinq points à vérifier dans votre plan de reprise
L'objectif n'est pas de cocher des cases, mais de pouvoir répondre honnêtement « oui, testé » à chacune des questions qui suivent.
1. Sauvegardes effectivement isolées de l'environnement compromis. Les sauvegardes sont-elles stockées sur un support ou un tenant séparé, non rattaché au même annuaire que celui compromis ? Les comptes d’administration, les clés et les procédures de récupération restent-ils accessibles si l’annuaire de production est compromis ? Existe-t-il au moins une sauvegarde hors-ligne ou immuable (air-gapped, WORM, etc.) ?
2. Restauration effectivement testée, au-delà de la simple vérification de sauvegarde. A-t-on déjà restauré un annuaire complet (AD on-premises) dans un environnement isolé et mesuré le temps ? Pour Entra ID, a-t-on testé la récupération des objets et configurations pris en charge par les outils disponibles, ainsi que la reprise des accès d’administration ? Les périmètres et procédures diffèrent de ceux d’AD sur site. Le même test a-t-il été mené sur les applications critiques et leurs dépendances (secrets, comptes de service) ?
3. Accès de secours documentés et fonctionnels. Existe-t-il des comptes d’accès d’urgence testés, avec des moyens d’authentification distincts de ceux utilisés au quotidien et conservés en lieu sûr ? Pour Entra ID, ces accès cloud doivent rester indépendants de l’annuaire local et des dépendances susceptibles d’empêcher leur connexion. Qui les utilise, dans quel ordre, avec quel délai d'activation ? Ces accès permettent-ils effectivement d'administrer l'annuaire et de déclencher les restaurations ?
4. Ordre de redémarrage défini et réaliste. Quelle application ou quel service redémarre en premier, et selon quel impact économique ? Les dépendances entre services ont-elles été cartographiées (réseau, identité, sauvegardes, bases de données et services externes, selon l’architecture) ? Ce séquencement est-il écrit, validé et connu des équipes qui ne sont pas en première ligne ?
5. Responsabilités identifiées hors des documents. Qui prend la décision de déclencher le plan de reprise, et à quel moment ? Qui détient les accès d'administration aux sauvegardes quand les comptes standards sont invalidés ? Quel est le rôle du RSSI, du DSI, du dirigeant, du prestataire ? Qui appelle qui en premier ?
Cette grille n'a pas vocation à être exhaustive. LPCD propose de l’adapter au contexte de l’entreprise et de la réviser après un incident ou une évolution importante du SI.
Organiser un exercice avec des objectifs mesurables
Sans exercice, le délai de reprise annoncé reste une estimation. Trois formats complémentaires peuvent être mobilisés.
-
Exercice sur table (tabletop). Discussion structurée autour d'un scénario. Utile pour vérifier la compréhension des rôles, peu coûteux en temps. LPCD propose un premier exercice avec les décideurs impliqués, puis une fréquence adaptée aux risques et aux changements du SI.
-
Exercice technique partiel. Restauration d’un annuaire AD ou d’une application critique dans un environnement isolé ; pour Entra ID, exercice de récupération sur un périmètre de test compatible avec les outils utilisés. Permet de mesurer le temps réel, et non le temps estimé.
-
Simulation de crise complète. Mobilisation des décideurs, communication, déclencheur de restauration. À programmer à intervalle plus espacé, pour éprouver l’ensemble de la chaîne.
Indicateurs à suivre : temps de décision, temps de redémarrage du premier service d'authentification, taux d'applications critiques relancées sous 24/48/72 heures, nombre d'accès imprévus nécessaires pendant l'exercice. Ces délais sont à comparer au RTO (durée d’interruption maximale visée). Il faut aussi mesurer la perte de données et la comparer au RPO (ancienneté maximale acceptable des données récupérées). Les écarts doivent être analysés et donner lieu à un plan d'action correctif documenté, le cas échéant.
Points de vigilance et limites propres au contexte
-
Comparitech décrit un suivi d’attaques confirmées et non confirmées. Fenix24 décrit ses interventions clients. Ces périmètres différents ne doivent pas être confondus ni extrapolés à toutes les entreprises.
-
Les constats sur l'identité concernent pour l'essentiel Active Directory on-premises. Les environnements Entra ID ou hybrides présentent d'autres vecteurs et d'autres modes opératoires ; les mécanismes de récupération ne sont pas interchangeables et méritent une approche dédiée.
-
Les moyens de reprise varient selon l’entreprise, son architecture et ses prestataires. L'enjeu est alors de calibrer les objectifs en fonction de la criticité réelle des métiers, et non en fonction d'un référentiel sectoriel qui ne tient pas compte de la taille de la structure.
Conclusion
Première action concrète : choisir un service critique — l'authentification est le candidat naturel —, fixer un délai de reprise mesurable, et programmer un exercice technique adapté : restauration en environnement isolé pour AD ou les applications, récupération des objets et accès sur un périmètre de test pour Entra ID. C'est souvent l'écart entre ce test et la procédure théorique qui révèle, le plus utilement, les angles morts du plan de reprise.