Ransomware, PRA et PCA : survivre au scénario catastrophe

Un lundi matin, 7 h 40. La responsable administrative allume son poste et ne trouve plus un seul fichier lisible : devis, comptabilité, bons de livraison portent tous une extension inconnue. Dans chaque dossier, un fichier texte explique la démarche à suivre pour « récupérer vos données ». Le serveur de fichiers ne répond plus. La boutique en ligne, elle, tourne encore pour deux heures. À 9 h 15, le service commercial confirme : plus personne ne peut éditer une commande. À 11 h, on découvre que les sauvegardes existaient bien, mais qu’elles étaient stockées sur un partage du même serveur, avec les mêmes identifiants. Elles sont chiffrées aussi.

Le réflexe naturel, face à un rançongiciel, c’est de se demander « est-ce qu’on paie ? ». La question arrive beaucoup trop tard, et ce n’est presque jamais la bonne. Tout ce qui va déterminer votre survie a été décidé des mois avant l’attaque : la vitesse de reprise, le volume de données perdues et la capacité à continuer de vendre dépendent de choix de sauvegarde, d’architecture et d’organisation. Un rançongiciel ne crée pas la crise, il révèle l’état de votre préparation. Voici comment se déroule réellement une attaque, ce qu’il faut avoir tranché avant, et comment organiser la réponse à incident et la reprise sans construire une usine à gaz.

Un rançongiciel n’est pas un virus, c’est une prise d’otage

Un ransomware chiffre vos données puis réclame une rançon contre la clé de déchiffrement. Techniquement, ce n’est pas le plus intéressant. Ce qui compte, c’est le modèle économique derrière : des groupes organisés, des outils loués comme un service à des affiliés, et un objectif unique, obtenir un paiement. Vous n’êtes pas visé personnellement, vous êtes rentable.

Deux points sont systématiquement mal compris.

Le chiffrement n’est pas le début de l’attaque, c’est sa fin. Avant d’appuyer sur le bouton, l’attaquant est entré : accès distant mal protégé, identifiant volé, faille non corrigée. Il a exploré le réseau, repéré vos sauvegardes, élevé ses privilèges, puis attendu le bon moment, un vendredi soir, un week-end de pont, un mois d’août. Cette phase discrète dure plusieurs jours, souvent plusieurs semaines. C’est aussi la seule fenêtre où vous pouviez encore le voir.

La plupart des groupes pratiquent la double extorsion. Les données sont d’abord copiées, puis chiffrées. Même avec une restauration parfaite, la menace de publication reste : fichiers clients, contrats, pièces comptables, bulletins de paie. Une bonne sauvegarde règle le problème de disponibilité, pas celui de confidentialité. Les deux se traitent séparément, et beaucoup d’entreprises ne découvrent le second qu’au moment où l’attaquant publie un échantillon.

Le scénario catastrophe, heure par heure

Une attaque réussie suit presque toujours le même déroulé. Le connaître à froid évite de le découvrir à chaud.

PCA et PRA, deux plans pour deux questions différentes

On les cite souvent ensemble, comme un seul sigle un peu administratif. Ce sont pourtant deux outils distincts, qui répondent à deux questions que personne ne se pose au bon moment.

Résumé brutal : le PCA vous permet d’encaisser, le PRA vous permet de revenir. Une entreprise qui n’a que des sauvegardes possède un demi-PRA et aucun PCA. Et un plan qui vit dans un fichier partagé sur le serveur chiffré n’existe pas. La version imprimée, ou stockée hors ligne, n’est pas un détail de forme.

RTO et RPO, les deux chiffres à décider avant, pas pendant

Deux indicateurs suffisent à cadrer toute la discussion, et ils appartiennent au dirigeant, pas au technicien.

Le RPO (Recovery Point Objective) répond à une question simple : combien de données peut-on accepter de perdre ? Si vous sauvegardez une fois par nuit, vous acceptez de perdre jusqu’à une journée de commandes, de factures et de saisies. Pour certaines activités c’est tolérable. Pour une boutique qui encaisse le samedi, non.

Le RTO (Recovery Time Objective) répond à une autre : combien de temps peut-on rester arrêté ? Pas « combien de temps ça va prendre », mais « au-delà de combien de temps l’entreprise est en danger ». Trois jours d’arrêt sur un site marchand, c’est du chiffre d’affaires jamais rattrapé, des campagnes payantes qui pointent vers une page morte et des clients qui commandent ailleurs.

Ces deux chiffres se posent activité par activité, pas globalement. Prendre les commandes, expédier, facturer, payer les salaires, ce ne sont pas les mêmes exigences. Une fois écrits, ils dictent tout le reste : fréquence des sauvegardes, redondance, budget. Sans eux, chaque décision technique se prend au feeling, et généralement trop tard.

Les sauvegardes, seul vrai contre-pouvoir face au chiffrement

C’est le point où presque tout se gagne ou se perd. Un attaquant sérieux cherche vos sauvegardes avant de chiffrer quoi que ce soit, parce qu’il sait qu’elles sont sa seule concurrence. Une sauvegarde montée en permanence sur le réseau, pilotée par un compte d’administration du domaine, ne survit pas.

Cinq exigences, à vérifier une par une :

• Plusieurs copies, sur des supports différents, dont une hors du site de production. C’est la règle 3-2-1, et elle n’a pas vieilli.
• Au moins une copie hors ligne ou immuable, impossible à modifier ou supprimer même avec des droits d’administrateur.
• Des identifiants dédiés, séparés de l’annuaire de l’entreprise. Si le compte qui pilote les sauvegardes est un compte du domaine, la compromission du domaine emporte les sauvegardes.
• Des restaurations testées, régulièrement, sur un jeu complet et pas sur un fichier isolé. C’est là qu’on découvre les surprises : une base sauvegardée sans ses fichiers, une archive chiffrée dont personne n’a la clé, deux heures annoncées qui deviennent deux jours.
• Une rétention suffisante pour revenir avant l’intrusion, pas seulement avant le chiffrement. Si vos sauvegardes couvrent sept jours et que l’attaquant est là depuis trois semaines, vous restaurez un système déjà compromis.

Ce dernier point conditionne l’ordre des opérations : on cherche par où c’est entré avant de restaurer, sinon on remet en ligne une porte ouverte. C’est exactement la logique du durcissement de PrestaShop et WordPress/WooCommerce que nous détaillons par ailleurs : traiter la cause, pas le symptôme. Sur une plateforme hébergée, la question ne disparaît pas, elle se pose autrement, et c’est tout l’objet des enjeux de sauvegarde d’une boutique Shopify.

Les six premières heures, ce qu’il faut faire et surtout ne pas faire

La réponse à incident se juge sur les premières heures. Voici l’ossature, dans l’ordre.

• Isoler sans tout éteindre. Débrancher du réseau, couper les accès distants, suspendre les synchronisations vers le cloud. Éteindre brutalement les machines détruit des éléments d’analyse encore en mémoire, et parfois la seule chance de comprendre l’entrée.
• Couper les accès et changer les secrets depuis un poste sain : comptes d’administration, VPN, clés d’API, accès d’hébergement, comptes prestataires.
• Ouvrir une cellule de crise restreinte, avec un décideur clairement identifié et un canal qui ne passe pas par le système compromis. Une messagerie chiffrée par l’attaquant ne sert plus à rien, et si elle fonctionne encore, il la lit peut-être.
• Tenir un journal horodaté des constats et des décisions. Utile pour l’analyse, indispensable pour l’assureur, souvent réclamé par les autorités.
• Ne pas restaurer tout de suite. Restaurer sur une infrastructure encore compromise, c’est offrir une deuxième cible. Il faut d’abord identifier le point d’entrée et le fermer, d’autant qu’un système piraté héberge souvent plusieurs intrus.
• Ne pas négocier seul et ne pas improviser la communication. Un message maladroit aux clients, un communiqué approximatif, une déclaration hasardeuse à un fournisseur : ces mots-là restent.

Un principe vaut tous les outils : la détection reste le meilleur investissement. Une intrusion repérée pendant sa phase de reconnaissance ne devient jamais un rançongiciel. C’est précisément le rôle d’une supervision comme celle que nous décrivons dans notre article sur la surveillance d’un site web avec Wazuh : voir en minutes ce qui, sinon, se découvre un samedi matin.

Ce qu’un rançongiciel coûte vraiment à une boutique en ligne

Sur une activité en ligne, l’attaque ne se traduit pas seulement par une perte de fichiers, elle coupe le tuyau qui apporte le chiffre d’affaires. Chaque heure d’indisponibilité est une vente perdue, et les jours d’arrêt laissent des traces durables : clients partis ailleurs, budget publicitaire brûlé vers une page morte, positions de référencement qui décrochent, commandes en cours dont personne ne sait quoi faire.

La reprise ne consiste donc pas à « remonter le site ». Elle demande de savoir précisément quoi restaurer, dans quel ordre, et à quel niveau de fraîcheur.

S’ajoute une contrainte souvent oubliée : restaurer des données de commande, c’est manipuler des données personnelles. La reprise se fait sous contrainte RGPD, avec un devoir de traçabilité sur ce qui a été remonté, depuis quand, et par qui.

Payer ou ne pas payer, ce que ça change vraiment

La question finit toujours par arriver. Autant la trancher à froid plutôt qu’en pleine panique. Payer n’achète pas une restauration, ça achète une promesse.

Les outils de déchiffrement fournis sont parfois lents, incomplets, inopérants sur une partie des données. Payer n’efface pas non plus l’exfiltration : rien ne garantit la destruction des copies, et les doubles sollicitations existent. Enfin, payer finance l’écosystème qui vous a attaqué et signale que vous êtes solvable.

« Ne pas négocier seul » sonne comme un conseil de prudence tant qu’on n’a pas vu à quoi ressemble l’exercice. Un négociateur cyber passe ses journées entre l’entreprise paralysée et le groupe qui détient ses données. Cette compétence-là, on l’appelle. On ne l’invente pas le jour J.

En France, les autorités, ANSSI comprise, recommandent de ne pas payer et de déposer plainte. Le volet assurantiel est par ailleurs encadré : depuis la loi d’orientation et de programmation du ministère de l’Intérieur de 2023, le remboursement d’une cyber-rançon par un assureur est conditionné au dépôt d’une plainte dans les 72 heures suivant la connaissance de l’infraction. Autrement dit, cette décision se prépare en amont, avec votre courtier et votre conseil, pas à 3 heures du matin. Nous détaillons ces mécanismes dans notre guide de la cyber-assurance pour les PME.

Obligations, preuves et documentation

Une crise cyber est aussi un dossier administratif, et les délais sont courts. Si des données personnelles ont été compromises, la violation doit être notifiée à la CNIL dans les 72 heures, et les personnes concernées informées lorsque le risque est élevé. Un rançongiciel avec exfiltration entre pleinement dans ce cadre. La plainte, elle, se dépose rapidement, notamment parce qu’elle conditionne certains dispositifs d’indemnisation.

Au-delà, les obligations sectorielles se renforcent. La directive NIS2 et ses obligations pour les PME impose aux entités concernées des délais de signalement resserrés et, surtout, la démonstration qu’un dispositif de continuité existe et qu’il est éprouvé. Ce point change la nature du travail : il ne suffit plus d’être prêt, il faut pouvoir le prouver. Les assureurs lisent désormais les dossiers avec la même grille.

Tester, sinon rien

Un plan jamais joué n’est pas un plan, c’est une intention. Le test n’a rien de spectaculaire ni de coûteux : deux heures autour d’une table, un scénario réaliste, et les questions qui font mal. Qui décide de couper le réseau ? Où est la liste des contacts si l’annuaire est chiffré ? Combien de temps prend réellement la restauration complète de la base ? Qui parle aux clients ? Que fait-on des commandes déjà payées ?

Ce type d’exercice révèle en une matinée ce qu’aucun audit documentaire ne montre : un mot de passe de sauvegarde connu d’une seule personne, en congés, un serveur de secours dont personne n’a la procédure, un plan parfaitement à jour en 2022. C’est tout l’intérêt d’une simulation de cyberattaque en entreprise, qui apprend souvent plus qu’un rapport de quatre-vingts pages.

Les erreurs les plus fréquentes face au risque ransomware

Certaines fausses sécurités reviennent presque à chaque intervention.

• Sauvegarder dans le même environnement. Un partage monté en permanence, avec un compte du domaine, est chiffré en même temps que le reste.
• Croire que l’hébergeur s’occupe de tout. La plupart des offres sauvegardent leur infrastructure, pas votre contenu, et la restauration reste souvent à votre charge. Cette clause se lit avant l’incident.
• Confondre haute disponibilité et sauvegarde. Un cluster répliqué en temps réel réplique aussi le chiffrement, à la seconde près.
• Restaurer avant d’avoir compris. On remet en service, on est rechiffré trois semaines plus tard, et on recommence en ayant perdu les traces.
• Garder le plan uniquement en ligne. Un PRA stocké dans l’outil collaboratif chiffré est d’une inutilité parfaite.
• Oublier les personnes. Sans suppléants désignés, sans numéros accessibles hors du système, sans consignes claires pour les équipes, le meilleur plan technique reste sur l’étagère.

Retour d’expérience, l’entreprise qui avait tout sauvegardé et rien testé

Un cas de terrain, anonymisé et reconstitué à partir de plusieurs situations observées.

À la fin du premier trimestre 2026, une PME de distribution B2B d’une soixantaine de salariés, dont un site de vente en ligne qui pèse environ un tiers de l’activité, nous contacte un dimanche soir. Chiffrement complet des serveurs internes, découvert le samedi matin. Le site e-commerce, hébergé ailleurs, tourne encore, mais plus rien ne peut être expédié parce que l’ERP est à l’arrêt. Le dirigeant a une phrase qui résume tout : « on a des sauvegardes, pourtant. »

Il en avait, effectivement. Le problème n’était pas leur existence. Il était ailleurs, trois fois ailleurs.

Le premier : les sauvegardes tournaient chaque nuit, sur un serveur de stockage du même réseau, avec le compte d’administration du domaine. L’attaquant, qui disposait de ce compte depuis onze jours, les a supprimées avant de lancer le chiffrement. Restait une copie sur bande, honnêtement complète, mais datée de trois mois plus tôt, parce que le lecteur était en panne depuis et que l’alerte de sauvegarde partait vers l’adresse d’un salarié parti entre-temps.

Le deuxième : personne n’avait de RTO. À la question « à partir de quand est-ce grave ? », les réponses allaient de deux heures à une semaine selon l’interlocuteur. Résultat, aucune priorité. On a essayé de tout redémarrer en même temps, serveurs secondaires compris, pendant que la prise de commandes restait à l’arrêt. Deux jours passés sur les mauvaises machines.

Le troisième, le plus rageant : le plan existait. Un document sérieux, rédigé deux ans plus tôt par un prestataire, complet et bien structuré. Il était stocké sur le serveur de fichiers. Chiffré. Personne ne l’avait imprimé, personne ne l’avait joué, et deux des trois personnes qu’il désignait comme responsables ne travaillaient plus dans l’entreprise.

La suite s’est jouée en mode dégradé : reprise des commandes sur un poste neuf hors du réseau, téléphone et papier pour la logistique, communication client assumée dès le mardi, sobre et factuelle. En parallèle, recherche du point d’entrée, un accès de maintenance distant sans double authentification, ouvert pour un prestataire deux ans plus tôt et jamais refermé. Puis reconstruction propre plutôt que restauration en l’état. La base de commandes a finalement pu être remontée depuis une copie de l’ERP moins ancienne que redoutée. Onze jours pour revenir à un fonctionnement acceptable, quatre semaines pour la reconstruction complète.

Ce qui a le plus marqué le dirigeant n’est pas technique. C’est de réaliser qu’il avait acheté des sauvegardes, un plan et un contrat de maintenance en croyant acheter une capacité de reprise. Trois lignes de facture, jamais vérifiées. Aujourd’hui, la sauvegarde immuable est en place, hors domaine, et une restauration test est réalisée chaque trimestre, chronomètre en main. Six mois plus tard, la leçon qu’il répète volontiers tient en peu de mots : une sauvegarde qu’on n’a jamais restaurée, un plan qu’on n’a jamais joué et un numéro qu’on n’a jamais composé ne sont pas une protection, ce sont trois hypothèses.

Se préparer sans construire une usine à gaz

Survivre à un rançongiciel ne demande pas le budget d’un grand compte. Ça demande quatre choses : des sauvegardes hors d’atteinte et testées, deux chiffres décidés par la direction (RTO et RPO), un plan court et imprimé avec des noms et des numéros, et un exercice par an pour vérifier que tout ça tient debout. Le reste (segmentation du réseau, double authentification partout, supervision, durcissement) réduit la probabilité que ça arrive. Ces quatre points-là déterminent ce qui se passe si ça arrive quand même.

Chez Zetruc, on aborde ce sujet avec une double casquette web et cyber : l’équipe qui construit et maintient vos outils est la même qui prépare leur reprise. Audit des sauvegardes et test de restauration, rédaction d’un PCA/PRA proportionné à votre taille, exercice de crise, supervision continue, formation de vos équipes à la cybersécurité, on adapte la profondeur à votre activité, à votre budget et à votre niveau de maturité.

Si vous ne savez pas aujourd’hui combien de temps il vous faudrait pour redémarrer, ni ce que vous perdriez en route, c’est précisément le bon moment pour en parler avec notre équipe. On commence toujours par un état des lieux concret, sans jargon, pour identifier ce qui doit être renforcé en priorité.