Construire un plan de reprise après un rançongiciel qui fonctionne vraiment

La plupart des plans de reprise après un rançongiciel sont un PDF que personne n'a ouvert depuis le jour de sa rédaction. Ils se lisent bien lors d'un audit de conformité, puis s'effondrent dès qu'un véritable attaquant touche à la production. Un plan qui fonctionne est différent : il est répété, mesurable et ennuyeux, parce que chaque étape a déjà été éprouvée sous pression.

Ce guide explique comment construire ce type de plan en 2026, à une époque où les attaquants volent les données avant de les chiffrer et où vos sauvegardes sont la première chose qu'ils cherchent.

Pourquoi la plupart des plans de reprise échouent

L'échec vient rarement d'un outil manquant. Il tient presque toujours à l'une de ces trois lacunes.

• Des restaurations non testées. Les équipes sauvegardent religieusement et n'effectuent jamais une seule restauration complète. Quand elles s'y essaient enfin, la sauvegarde est corrompue, incomplète, ou met quatre jours à se réhydrater.
• Des sauvegardes accessibles. Si votre système de sauvegarde utilise les mêmes identifiants, le même réseau et la même console d'administration que la production, un attaquant qui possède le domaine possède aussi vos sauvegardes. Les groupes de rançongiciels modernes suppriment ou chiffrent d'abord les sauvegardes, puis déclenchent l'attaque.
• Aucun responsable de décision. À la deuxième heure d'un incident, quelqu'un doit décider s'il faut isoler tout le réseau, s'il faut payer et qui parle aux clients. Si cette personne n'est pas désignée à l'avance, les premières heures sont perdues à discuter.

Un plan de reprise n'est pas une politique de sauvegarde. C'est un manuel opérationnel qui part du principe que la prévention a déjà échoué et pose une question plus difficile : comment relancer l'activité, en toute sécurité, et à quelle vitesse.

Fixez vos objectifs de reprise avant toute chose

Deux chiffres pilotent toutes les autres décisions. Convenez-en avec la direction, et pas seulement avec le service informatique.

• Objectif de temps de reprise (RTO) : combien de temps l'entreprise peut tolérer qu'un système donné soit hors service. Un paiement e-commerce pourrait être de 1 heure. Un wiki interne pourrait être de 3 jours.
• Objectif de point de reprise (RPO) : quelle quantité de données vous pouvez vous permettre de perdre, mesurée en temps. Un registre de paiements pourrait être de 5 minutes. Un site marketing pourrait être de 24 heures.

Ce sont des décisions métier assorties de compromis de coût. Un RPO de 5 minutes pour chaque système est techniquement possible et financièrement absurde. D'après notre expérience, l'exercice utile consiste à hiérarchiser : classez les systèmes en trois ou quatre niveaux, attribuez à chacun un RTO et un RPO, puis concevez la fréquence de sauvegarde et l'infrastructure en conséquence. Le niveau 1 bénéficie d'une réplication continue et de captures immuables. Le niveau 4 se contente d'une sauvegarde nocturne et personne ne panique si elle date d'un jour.

L'architecture de sauvegarde qui survit à une attaque

L'ancienne règle du 3-2-1 (trois copies, deux types de supports, une hors site) reste le minimum, mais les attaques de 2026 exigent davantage. Visez le 3-2-1-1-0.

• 3 copies de vos données.
• 2 types de stockage différents.
• 1 copie hors site.
• 1 copie immuable ou isolée physiquement (air-gapped), afin qu'elle ne puisse être ni altérée ni supprimée, même par un administrateur de domaine.
• 0 erreur, vérifiée par des tests de restauration réguliers.

La copie immuable est ce qui vous sauve. Le verrouillage d'objets sur un stockage cloud, les captures en écriture unique ou une copie réellement hors ligne fonctionnent tous. La propriété essentielle est que les identifiants qui exécutent la production ne peuvent pas la supprimer. Si un attaquant disposant du contrôle total du domaine ne peut toujours pas toucher cette copie, vous avez une voie de reprise. S'il le peut, vous avez un faux sentiment de sécurité.

Deux autres choix de conception comptent. D'abord, gardez votre catalogue de sauvegarde et votre plan de gestion sur une infrastructure d'identité distincte, idéalement un fournisseur d'identité distinct ou au minimum des comptes privilégiés distincts protégés par des clés matérielles. C'est là qu'une architecture zero trust plus large porte directement ses fruits, parce qu'elle supprime le réseau plat et de confiance qui permet à un seul ordinateur portable compromis d'atteindre tout le reste. Ensuite, conservez suffisamment d'historique. Les attaquants restent souvent dans un réseau pendant des semaines avant de déclencher l'attaque, si bien qu'une sauvegarde datant de trois jours peut déjà contenir leur point d'ancrage. Conservez des points de restauration remontant assez loin pour en trouver un propre.

Construisez le guide opérationnel, pas seulement la politique

Un guide opérationnel est une séquence d'actions concrètes qu'un humain fatigué peut suivre à 3 heures du matin. Rédigez-le pour la personne qui n'a pas conçu le système. Voici un squelette éprouvé sur le terrain que vous pouvez adapter.

1. Détecter et déclarer. Définissez ce qui déclenche un incident de rançongiciel (modifications massives de fichiers, note de rançon, alerte EDR) et qui a l'autorité de le déclarer formellement. Déclarer tôt est presque toujours la bonne décision.
2. Isoler, ne pas éteindre. Déconnectez les segments touchés du réseau pour stopper la propagation, mais évitez de couper l'alimentation des machines infectées, car la mémoire volatile contient des preuves et parfois des clés de déchiffrement. Isolez immédiatement les sauvegardes pour qu'elles ne puissent pas être atteintes.
3. Constituer l'équipe d'intervention. Des rôles nommés : commandant d'incident, responsable technique, responsable de la communication et contact juridique ou de conformité. Une personne par rôle, plus un remplaçant désigné pour chacun.
4. Évaluer l'étendue. Quels systèmes sont chiffrés, quelles données ont été consultées ou exfiltrées, et à quel niveau appartient chaque système. L'exfiltration compte sur le plan juridique même si vous restaurez parfaitement.
5. Contenir la cause racine. Identifiez et fermez le point d'entrée (hameçonnage, RDP exposé, VPN non corrigé) avant de restaurer, sinon vous serez simplement réinfecté. C'est là qu'un test d'intrusion antérieur prouve son utilité, parce que vous connaissez déjà vos points faibles.
6. Restaurer à partir d'un point propre vérifié. Commencez par les systèmes de niveau 1. Restaurez vers un environnement reconstruit et corrigé, pas vers l'environnement compromis. Validez l'intégrité avant de reconnecter.
7. Renouveler tous les secrets. Partez du principe que tous les mots de passe, clés d'API et jetons sont compromis. Renouvelez les identifiants, les certificats et les comptes de service sur toute la ligne.
8. Reconnecter par étapes. Remettez les systèmes en service niveau par niveau, en surveillant de près les signes de persistance ou de réinfection.
9. Communiquer. Informez les clients, les régulateurs et le personnel conformément à vos obligations légales et à vos modèles pré-rédigés. Le silence détruit la confiance plus vite que la panne.
10. Débriefer. Dans les deux semaines, menez une revue post-incident sans recherche de coupable et réinjectez chaque enseignement dans le plan.

Imprimez ce guide opérationnel. Gardez une copie papier et une copie numérique hors ligne, car si vos serveurs de fichiers sont chiffrés, un guide stocké uniquement sur eux a disparu lui aussi.

La partie que tout le monde néglige : les tests

Un plan que vous n'avez pas testé est une hypothèse. Transformez-le en fait grâce à trois niveaux d'exercice.

• Exercices de restauration (mensuels). Choisissez une sauvegarde au hasard et restaurez-la de bout en bout. Mesurez le temps que cela a pris et si les données étaient intactes. Suivez cette tendance dans le temps.
• Exercices sur table (trimestriels). Faites parcourir à l'équipe d'intervention un scénario réaliste de manière verbale. Aucun système touché, juste des décisions. Ces exercices révèlent à moindre coût les lacunes du type "qui décide ?".
• Simulation de bascule complète (annuelle). Restaurez réellement un système critique dans un environnement isolé sous contrainte de temps. C'est le seul test qui valide votre véritable RTO.

La métrique qui compte n'est pas "avons-nous des sauvegardes". C'est "combien de minutes notre dernière restauration complète du système de paiements a-t-elle prises, et était-elle propre". Si vous ne pouvez pas répondre à cela avec un chiffre récent, votre plan n'est pas testé.

Payer ou ne pas payer

C'est une décision métier et juridique, pas technique, et elle devrait être prise à l'avance. Payer n'est pas une stratégie de reprise : les déchiffreurs sont souvent lents ou bogués, payer vous désigne comme une cible consentante et, dans certaines juridictions, les paiements à des groupes sous sanctions sont illégaux. La position la plus solide est celle où vous n'avez jamais à l'envisager, parce que vous disposez d'une sauvegarde propre et immuable et d'une voie de restauration testée. Construisez vers cette position plutôt que de budgéter une rançon.

Comment Innovation T peut aider

La résilience face aux rançongiciels n'est pas un produit que l'on achète une fois. C'est une architecture et une habitude. Chez Innovation T, nos ingénieurs cloud et sécurité aident les équipes à concevoir des systèmes de sauvegarde à véritable immuabilité, à hiérarchiser leurs systèmes selon des objectifs RTO et RPO métier réels, et à transformer une politique restée sur l'étagère en un guide opérationnel que l'équipe a réellement répété. Nous menons les exercices sur table, construisons l'automatisation de la restauration et validons qu'une reprise propre fonctionne véritablement avant qu'un attaquant n'impose le test.

Si votre dernière restauration complète était une hypothèse plutôt qu'un fait mesuré, c'est la lacune qu'il vaut le mieux combler en premier. Explorez nos services pour voir comment nous abordons la résilience cloud, l'ingénierie de la sécurité et le conseil informatique, ou contactez-nous pour passer en revue votre posture de reprise actuelle. Le meilleur moment pour tester votre plan est un mardi tranquille, pas le matin où la note de rançon apparaît.