Plan de reprise après incident
Le minimum vital pour une PME

Le vrai problème n’est pas seulement la panne, c’est l’improvisation

Lorsqu’un site devient indisponible, qu’une messagerie ne reçoit plus les emails ou qu’un outil métier est bloqué, la première réaction est souvent de chercher “qui peut réparer”. C’est normal, mais insuffisant.

Dans une PME, la difficulté vient rarement d’un manque total de solutions. Il existe parfois une sauvegarde, un prestataire, un accès hébergeur, un compte administrateur, une facture avec un support, une console DNS, un plugin de sécurité. Le problème est que ces éléments sont dispersés, détenus par plusieurs personnes, mal documentés ou connus d’un seul interlocuteur.

Le jour de l’incident, cette dispersion coûte du temps. On ne sait pas qui décide. On ne sait pas si l’on peut couper le site. On ne sait pas quelle sauvegarde utiliser. On ne sait pas si le prestataire détient tous les accès. On ne sait pas si les clients doivent être prévenus. On ne sait pas si l’incident touche des données personnelles. On ne sait pas si la restauration risque de supprimer des commandes récentes.

Plan de reprise, plan de continuité, gestion de crise : clarifier sans compliquer

Il n’est pas nécessaire de transformer une PME en grande direction informatique pour structurer la reprise. Mais trois notions doivent être distinguées.

L’ANSSI propose des ressources dédiées à la gestion de crise d’origine cyber.[2] Pour une PME, le minimum viable est souvent un document unique qui combine ces trois dimensions : reprise technique, continuité métier et décisions de crise.

Les incidents à prévoir : pas seulement la cyberattaque

Un bon plan ne doit pas être écrit uniquement pour le scénario spectaculaire du rançongiciel. Les incidents les plus fréquents peuvent être beaucoup plus simples.

La valeur du plan vient de sa capacité à traiter les cas courants, pas seulement les scénarios extrêmes.

Définir les services prioritaires

Tout ne doit pas repartir en même temps. C’est une erreur fréquente : vouloir restaurer “tout le site” sans hiérarchiser.

Le plan doit indiquer ce qui est critique, ce qui est important, et ce qui peut attendre.

RPO et RTO : reprendre avec des délais réalistes

Comme pour les sauvegardes, deux repères structurent le plan de reprise. Le NIST SP 800-34 est une référence de fond complémentaire sur la planification de continuité et les priorités de reprise, même s’il vise d’abord les systèmes fédéraux américains.[4]

Ces valeurs sont des exemples à ajuster selon le contexte métier, les contrats, les moyens techniques et les exigences de l’entreprise.

Les rôles : qui décide, qui agit, qui communique ?

Un plan de reprise doit éviter une situation fréquente : tout le monde appelle tout le monde, mais personne ne sait qui arbitre.

Dans une petite structure, une même personne peut tenir plusieurs rôles. L’important est de le savoir avant l’incident.

Les accès critiques à documenter

Un plan de reprise sans accès est inutilisable. La PME doit savoir où se trouvent les accès suivants, même si elle ne les utilise pas tous au quotidien.

Les premières heures : la procédure minimale

Le plan doit prévoir une procédure simple, utilisable sous stress.

Le mode dégradé : continuer sans l’outil principal

La reprise ne signifie pas toujours “réparer immédiatement le système complet”. Parfois, le plus utile est de maintenir une activité minimale.

Ce mode dégradé doit être prévu à l’avance. En crise, improviser une adresse email ou une page temporaire peut créer de nouvelles erreurs.

Dire assez, sans dire trop

La communication de crise est souvent sous-estimée. Pourtant, elle protège la confiance. Elle doit être sobre, factuelle, cohérente, non accusatoire, actualisée si nécessaire et validée par la direction ou le référent désigné.

Il faut éviter les formulations trop définitives tant que le diagnostic n’est pas terminé : “aucune donnée n’est concernée”, “tout est sécurisé”, “simple panne”, “incident sans impact”. Ces phrases peuvent devenir problématiques si l’analyse montre ensuite autre chose.

La recherche sur la communication après incident cyber souligne qu’un incident peut devenir une crise réputationnelle, d’où l’intérêt de préparer la communication avant l’événement.[5]

Documenter et décider vite

Si l’incident touche des données personnelles, il faut traiter le sujet dès le début, pas après la restauration. La CNIL définit une violation comme une perte de disponibilité, d’intégrité ou de confidentialité de données personnelles, de manière accidentelle ou illicite.[1]

Clarifier les responsabilités avant l’incident

Dans beaucoup de PME, le site est géré par un prestataire web, l’hébergement par un autre acteur, les emails par Microsoft ou Google, le nom de domaine par un registrar, le DNS par Cloudflare, et la maintenance par une agence. En situation normale, cette organisation fonctionne. En crise, elle peut devenir un labyrinthe.

Un contrat de maintenance sérieux devrait préciser au minimum : périmètre, délais d’intervention, sauvegardes, restauration, responsabilités, accès, astreinte éventuelle, limites de garantie et procédure d’escalade.

Le plan de reprise PME en dix fiches

Le plan peut tenir en dix pages ou moins. L’important est qu’il soit exploitable.

Tester le plan : l’exercice vaut mieux que le document

Un plan non testé reste théorique. Il n’est pas nécessaire d’organiser une simulation lourde. Une PME peut commencer par un exercice court, sur table.

Ce qui bloque souvent une reprise

Les questions à poser avant l’incident

Questions fréquentes

Un bon plan de reprise est court, connu et utilisable

Une PME n’a pas besoin d’un classeur de crise de 200 pages. Elle a besoin d’un plan clair, à jour et accessible : contacts, accès, priorités, sauvegardes, mode dégradé, procédure des premières heures, communication, données personnelles et retour à la normale.

Le plan de reprise ne supprime pas le risque. Il réduit le désordre. Il permet de gagner du temps, d’éviter les décisions dangereuses, de protéger les données, de rassurer les clients et de mieux piloter les prestataires.