Ce récit est une fiction réaliste, construite à partir de dizaines de cas réels accompagnés par des professionnels de la réponse à incident en France. Les noms, secteurs et détails ont été modifiés, mais les mécanismes, les erreurs et les décisions décrits sont fidèles à la réalité vécue par les PME victimes de ransomware.
Metalix est une PME industrielle de 95 salariés, spécialisée dans l'usinage de pièces de précision pour l'aéronautique. Basée en Occitanie, elle réalise 14 millions d'euros de chiffre d'affaires. Son système d'information repose sur un ERP métier, un serveur de fichiers partagés, une messagerie Microsoft 365 et une vingtaine de machines à commande numérique connectées au réseau. L'informatique est gérée par un responsable IT à temps plein, assisté d'un technicien. Il n'y a pas de RSSI. Les sauvegardes sont réalisées quotidiennement sur un NAS dans la salle serveur.
Heure 0 — Lundi, 6h47 : la découverte
Marc, le responsable IT, reçoit un appel sur son portable personnel alors qu'il prend son café. C'est le chef d'atelier : les écrans des machines à commande numérique affichent un message en anglais. Les postes de travail de l'administration aussi. Le message est clair : tous les fichiers ont été chiffrés par le groupe LockBit. Une rançon de 180 000 dollars en Bitcoin est exigée sous 72 heures, après quoi le montant doublera. Un lien vers un portail sur le dark web est fourni pour « négocier ».
Marc arrive à l'usine en vingt minutes. La scène est surréaliste : des dizaines d'écrans affichent tous le même message sur fond noir. L'ERP est inaccessible. Le serveur de fichiers ne répond plus. La messagerie fonctionne encore — les boîtes sont dans le cloud — mais les fichiers locaux synchronisés via OneDrive sont chiffrés. L'atelier est à l'arrêt complet.
Heures 1 à 4 — La panique et les premières décisions
7h15. Marc appelle Nathalie, la directrice générale, qui était en déplacement à Paris. En quelques minutes, le téléphone de Nathalie ne cesse de sonner : le directeur commercial signale que les bons de commande sont inaccessibles, la comptable ne peut plus émettre de factures, le responsable qualité n'a plus accès aux dossiers de certification.
7h30. Marc débranche les câbles réseau des serveurs et des postes encore allumés. Il désactive le Wi-Fi de l'entreprise. Il tente de se connecter au NAS de sauvegarde : les fichiers de sauvegarde sont également chiffrés. Le NAS était monté en tant que lecteur réseau sur le serveur principal, directement accessible avec les mêmes identifiants. Les attaquants l'ont trouvé et chiffré en même temps que le reste.
C'est à cet instant précis que Marc comprend la gravité de la situation. Sans sauvegarde exploitable, la restauration des données devient extrêmement incertaine.
8h00. Nathalie convoque une cellule de crise improvisée en salle de réunion : elle-même, Marc, le directeur financier, le directeur commercial et le responsable de production. La question qui domine : faut-il payer la rançon ?
8h30. Marc contacte le prestataire informatique habituel de l'entreprise — une petite société locale qui assure la maintenance du parc. Le prestataire est honnête : il n'a jamais géré ce type d'incident et recommande de faire appel à un spécialiste en réponse à incident. Il fournit deux contacts.
9h00. Nathalie appelle le premier cabinet de réponse à incident. Un consultant est disponible et peut être sur site en fin de journée. Tarif : 1 800 euros la journée, avec une estimation initiale de 5 à 10 jours d'intervention. Nathalie accepte sans hésiter.
10h00. Sur les conseils du consultant joint par téléphone, Marc effectue les premières actions de préservation : il photographie les écrans affichant la note de rançon, il note les extensions des fichiers chiffrés (.lockbit), il vérifie les journaux d'événements Windows encore accessibles sur les postes non chiffrés, il isole physiquement le NAS pour préserver les données chiffrées en l'état.
Heures 4 à 24 — Confinement, investigation et le dilemme de la rançon
L'arrivée de l'expert
15h00. Sophie, consultante en réponse à incident, arrive sur site avec son kit d'analyse forensique. Elle commence par cartographier l'étendue de la compromission : combien de machines sont touchées, quels systèmes fonctionnent encore, y a-t-il des indices sur le vecteur d'entrée initial.
Ses premières constatations sont préoccupantes :
- L'ensemble des serveurs Windows (4 serveurs physiques et 2 machines virtuelles) sont chiffrés.
- 45 postes de travail sur 60 sont touchés.
- Le NAS de sauvegarde est intégralement chiffré.
- Les machines à commande numérique fonctionnent sous un OS embarqué qui n'a pas été chiffré, mais elles ne peuvent plus recevoir de programmes de fabrication depuis le serveur.
- La messagerie cloud (Microsoft 365) est intacte, mais les fichiers locaux synchronisés sont chiffrés.
L'enquête forensique
17h00. Sophie identifie le vecteur d'entrée probable. En examinant les logs de connexion VPN conservés sur le pare-feu, elle découvre une connexion suspecte trois jours plus tôt, un vendredi soir à 23h17, depuis une adresse IP localisée en Europe de l'Est. Cette connexion a utilisé le compte VPN de Marc — dont le mot de passe, relativement simple et sans authentification multifacteur, avait probablement été compromis via une campagne de phishing ou une fuite de données.
L'attaquant a pénétré le réseau le vendredi soir, a passé le week-end à explorer silencieusement le système d'information, à identifier les serveurs critiques, les sauvegardes et les comptes à privilèges. Il a désactivé l'antivirus sur les serveurs (la console d'administration antivirus était accessible avec les identifiants de Marc, administrateur du domaine). Puis, dans la nuit de dimanche à lundi, il a lancé le chiffrement massif.
Faut-il payer ?
20h00. Cellule de crise élargie. Nathalie est face au dilemme que redoutent tous les dirigeants. Le directeur financier a fait les calculs : chaque jour d'arrêt de production coûte environ 45 000 euros en chiffre d'affaires perdu, sans compter les pénalités de retard sur les commandes aéronautiques en cours.
Sophie présente les arguments de manière factuelle :
Arguments pour ne pas payer :
- Aucune garantie de récupération des données. Les outils de déchiffrement fournis par les attaquants sont souvent buggés et ne restaurent que 60 à 80 % des fichiers.
- Payer finance le crime organisé et encourage de futures attaques.
- L'entreprise sera identifiée comme « payeuse » et risque d'être ciblée à nouveau.
- La position officielle de l'ANSSI et du gouvernement français est de ne pas payer.
Arguments que les partisans du paiement avancent :
- Sans sauvegarde exploitable, certaines données sont potentiellement perdues à jamais (historique ERP de 8 ans, dossiers de certification qualité).
- Le coût de l'arrêt de production dépasse rapidement le montant de la rançon.
- Certains clients donneurs d'ordre pourraient remettre en cause leur relation commerciale si les délais ne sont pas tenus.
Nathalie décide de ne pas payer. C'est un choix courageux, appuyé par Sophie qui estime qu'une restauration partielle est possible à partir des sauvegardes cloud (OneDrive) et des données non chiffrées sur les postes éteints au moment de l'attaque.
Heures 24 à 48 — La reconstruction commence
Notification aux autorités
Mardi 8h00. Sur les conseils de Sophie, Nathalie procède aux notifications obligatoires :
- Dépôt de plainte : Nathalie se rend à la gendarmerie locale, qui transmet le dossier à la section cybercriminalité (C3N). Ce dépôt de plainte est indispensable, notamment pour l'assurance — depuis la loi LOPMI de janvier 2023, l'indemnisation d'une attaque par rançongiciel est conditionnée au dépôt de plainte dans les 72 heures.
- Notification CNIL : Sophie aide Marc à évaluer si des données personnelles ont été compromises. Le serveur de fichiers contenait des dossiers RH avec des données salariés (bulletins de paie, contrats, arrêts maladie). Une notification à la CNIL est obligatoire dans les 72 heures suivant la découverte. Nathalie procède à la déclaration en ligne sur le site de la CNIL.
- Signalement ANSSI : même si Metalix n'est pas un opérateur d'importance vitale, Sophie recommande un signalement volontaire via le formulaire de l'ANSSI. Cela permet de contribuer à la veille nationale et d'accéder éventuellement à des outils de déchiffrement si le groupe LockBit a déjà été neutralisé par les forces de l'ordre.
Le plan de restauration
Mardi 10h00. Sophie et Marc établissent un plan de restauration priorisé :
- Priorité 1 : remettre en service la messagerie et les outils de communication interne (déjà fonctionnels via le cloud).
- Priorité 2 : restaurer l'ERP métier pour relancer la chaîne de production. L'éditeur de l'ERP est contacté : il dispose d'une sauvegarde hébergée datant du jeudi précédent. Trois jours de données seront perdus, mais c'est acceptable.
- Priorité 3 : reconstruire le serveur de fichiers à partir des versions OneDrive et des postes non chiffrés.
- Priorité 4 : réinstaller les postes de travail à partir d'images système propres.
Mardi 14h00. Deux techniciens du prestataire informatique rejoignent Marc pour accélérer la réinstallation des postes. L'ambiance est tendue mais organisée. Nathalie a réquisitionné une salle de réunion comme « salle de guerre », avec un tableau blanc où l'avancement est suivi heure par heure.
Mardi 18h00. L'ERP est partiellement restauré. Les données du jeudi sont récupérées. Le directeur de production estime pouvoir relancer une partie de l'atelier le lendemain matin avec les programmes de fabrication déjà chargés dans les machines CNC.
La communication interne et externe
Mardi 20h00. Nathalie rédige deux communications avec l'aide de Sophie :
En interne : un message factuel aux salariés expliquant la situation, les mesures prises, le calendrier prévisionnel de reprise et les consignes de sécurité (ne pas tenter de se connecter aux systèmes, changer tous les mots de passe, signaler tout e-mail suspect). La transparence est essentielle pour maintenir la confiance des équipes.
En externe : un message personnalisé aux trois principaux clients donneurs d'ordre, expliquant qu'un incident de sécurité informatique a perturbé la production, que les données clients n'ont pas été exfiltrées (confirmé par l'analyse forensique), et que la reprise progressive est en cours. Nathalie propose un appel individuel à chaque directeur achats pour rassurer et discuter des délais.
Heures 48 à 72 — La reprise et les premiers enseignements
Mercredi : la production redémarre
Mercredi 7h00. L'atelier reprend partiellement. Huit machines sur vingt peuvent fonctionner avec les programmes déjà chargés. Les opérateurs travaillent à partir de bons de travail imprimés manuellement — le système de planification n'est pas encore restauré. C'est artisanal, mais la production tourne à environ 40 % de sa capacité.
Mercredi 12h00. Les postes de travail administratifs sont progressivement réinstallés. Chaque poste est réimagé à partir d'une installation propre de Windows, avec un nouvel antivirus déployé et l'authentification multifacteur activée sur tous les comptes Microsoft 365. Seize postes sur quarante-cinq sont opérationnels.
Mercredi 15h00. Le serveur de fichiers est reconstruit. Environ 70 % des fichiers ont pu être récupérés via OneDrive, les postes non chiffrés et les copies envoyées par e-mail au fil des années. Les 30 % restants sont principalement des archives anciennes et des fichiers de travail intermédiaires. Les dossiers de certification qualité, priorité absolue pour les donneurs d'ordre aéronautiques, ont été intégralement récupérés.
Jeudi : le bilan de la première semaine
Jeudi 9h00. Sophie présente son rapport préliminaire à la cellule de crise. Le bilan est lourd mais aurait pu être catastrophique :
- Durée d'arrêt complet : 2 jours (lundi et mardi)
- Durée de fonctionnement dégradé : estimée à 2 semaines supplémentaires
- Coûts directs immédiats : environ 45 000 euros (réponse à incident, réinstallation, prestataires)
- Perte de chiffre d'affaires estimée : 180 000 à 250 000 euros sur le mois
- Données définitivement perdues : environ 30 % du serveur de fichiers (archives principalement)
- Aucune donnée client exfiltrée : confirmé par l'analyse réseau (les attaquants ont chiffré sans exfiltrer, probablement par manque de temps)
Les leçons : ce qui aurait pu empêcher cette attaque
Avec le recul, Sophie identifie cinq mesures qui auraient pu empêcher l'attaque ou en réduire drastiquement l'impact.
1. L'authentification multifacteur sur le VPN
Le vecteur d'entrée était un compte VPN protégé par un simple mot de passe. Si l'authentification multifacteur (MFA) avait été activée — ce que la plupart des solutions VPN professionnelles permettent — l'attaquant n'aurait pas pu se connecter, même avec le mot de passe compromis. Coût de mise en place : quelques heures de configuration et des licences MFA à environ 3 euros par utilisateur et par mois.
2. Des sauvegardes hors ligne
Le NAS de sauvegarde était accessible depuis le réseau avec les mêmes identifiants que les serveurs. C'est l'erreur la plus courante et la plus fatale. Une sauvegarde dite « 3-2-1 » — trois copies, deux supports différents, une copie hors site ou hors ligne — aurait permis une restauration complète en quelques heures. Les solutions de sauvegarde immuable (où les données ne peuvent être ni modifiées ni supprimées pendant une période définie) offrent une protection encore plus robuste.
3. La segmentation réseau
Une fois dans le réseau, l'attaquant a pu accéder librement à tous les serveurs, postes de travail et équipements. Si le réseau avait été segmenté — serveurs dans un VLAN dédié, postes de travail dans un autre, machines industrielles dans un troisième, avec des règles de filtrage entre les segments — la propagation aurait été limitée et la détection facilitée.
4. La détection et la surveillance
L'attaquant est resté trois jours dans le réseau sans être détecté. Une solution EDR (Endpoint Detection and Response) sur les serveurs et les postes critiques aurait généré des alertes lors des mouvements latéraux, de la désactivation de l'antivirus ou de l'exploration du réseau. Un SOC (Security Operations Center) externalisé, même basique, aurait pu détecter la connexion VPN anormale le vendredi soir.
5. Un plan de réponse à incident
L'absence de plan formalisé a coûté des heures précieuses le lundi matin. Les premières réactions — tenter de redémarrer les serveurs, chercher les numéros de téléphone des prestataires dans la panique — auraient pu être remplacées par des actions réflexes documentées : déconnecter du réseau, appeler le prestataire de réponse à incident (numéro affiché en salle serveur), préserver les traces, alerter la direction. Un plan testé une fois par an, même sommaire, change tout le jour J.
Épilogue : six mois après
Six mois après l'attaque, Metalix a profondément transformé son approche de la cybersécurité. L'entreprise a recruté un RSSI externalisé qui intervient trois jours par mois. L'authentification multifacteur est déployée sur tous les accès. Les sauvegardes sont désormais répliquées sur un cloud sécurisé avec rétention immuable de 30 jours. Le réseau a été segmenté. Un EDR est déployé sur tous les postes et serveurs, supervisé par un SOC externalisé. Les collaborateurs ont suivi une première session de sensibilisation, avec des campagnes de phishing simulé trimestrielles.
Nathalie a présenté le bilan de l'incident au comité de direction et a fait inscrire la cybersécurité comme risque stratégique dans la cartographie des risques de l'entreprise. Le budget IT a été augmenté de 35 %, avec un volet sécurité identifié et sanctuarisé.
Aucun client n'a été perdu. La transparence et la réactivité de la communication de crise ont paradoxalement renforcé la confiance des donneurs d'ordre, qui ont apprécié la maturité de la gestion de l'incident. Metalix est désormais en avance sur la plupart de ses concurrents en matière de cybersécurité — un avantage compétitif inattendu, né d'une crise.
L'histoire de Metalix n'est pas exceptionnelle. Elle se répète chaque semaine dans des PME françaises de toute taille et de tout secteur. La seule question est : préférez-vous investir 30 000 euros par an en prévention, ou risquer 300 000 euros en réparation ?