Un serveur inaccessible à 8 h 30, des emails bloqués, des dossiers clients indisponibles et une équipe qui ne sait plus quoi faire : c’est précisément ce qu’un exemple PRA petite entreprise doit permettre d’éviter. Un plan de reprise d’activité n’est pas réservé aux grandes organisations. Pour une PME, il transforme une panne, une cyberattaque ou un sinistre en incident gérable, avec des responsabilités claires et un ordre de redémarrage défini.

Le bon PRA ne cherche pas à tout remettre en ligne instantanément, quel qu’en soit le coût. Il fixe une priorité simple : préserver les données, assurer la continuité des fonctions essentielles et rétablir progressivement le reste de l’environnement informatique. Cette approche est plus réaliste, plus lisible et souvent plus efficace pour une petite structure.

À quoi sert un PRA dans une petite entreprise ?

Le plan de reprise d’activité décrit ce que l’entreprise fait après un incident majeur qui rend ses outils ou ses locaux indisponibles. Il couvre notamment la perte d’un serveur, le chiffrement de fichiers par un ransomware, une panne internet prolongée, la défaillance d’un prestataire cloud, le vol de matériel ou un dégât des eaux.

Il ne faut pas le confondre avec la sauvegarde. Une sauvegarde conserve une copie des données. Le PRA explique comment restaurer cette copie, sur quel environnement, dans quel délai, qui prend les décisions et comment les collaborateurs continuent à travailler pendant la remise en service. Sans ces réponses, même une bonne sauvegarde peut rester inutilisable pendant plusieurs jours.

Pour une petite entreprise, l’enjeu est directement opérationnel : continuer à répondre aux clients, émettre des factures, accéder aux dossiers de production, communiquer avec les fournisseurs et protéger les données personnelles. Le niveau d’exigence dépend de l’activité. Un cabinet médical, une entreprise de construction et une agence de communication n’ont pas les mêmes priorités ni le même coût d’arrêt.

Exemple PRA petite entreprise : le cas d’une PME de 15 personnes

Prenons une entreprise de services de 15 collaborateurs. Elle utilise une suite bureautique cloud, une messagerie professionnelle, un logiciel de gestion installé sur un serveur local, des fichiers partagés, la téléphonie VoIP et un accès internet fibre. Son équipe travaille principalement depuis un même bureau, avec deux personnes en déplacement régulier.

Un lundi matin, le serveur de fichiers et de gestion devient inaccessible après une attaque par ransomware. Les emails fonctionnent encore, mais les équipes ne peuvent plus consulter les dossiers clients ni accéder au logiciel de facturation. Le PRA vise alors à limiter l’arrêt à quelques heures pour les services critiques et à éviter toute restauration de données compromises.

1. Identifier les activités réellement prioritaires

La première étape consiste à classer les activités selon leur importance métier. Dans notre exemple, la messagerie, l’accès aux dossiers clients, la téléphonie et la facturation sont critiques. L’archivage historique, certains outils internes ou les postes non utilisés immédiatement peuvent être rétablis plus tard.

Cette distinction évite de mobiliser les équipes sur des éléments secondaires alors que les clients attendent une réponse. Elle permet aussi d’adapter l’investissement : toutes les applications n’ont pas besoin d’une infrastructure de secours identique.

Le plan peut formaliser les priorités ainsi : la communication client doit être disponible dans l’heure, les dossiers actifs et la téléphonie dans les quatre heures, puis la gestion et les postes secondaires dans la journée ouvrée. Ces objectifs doivent être définis avec la direction, pas seulement avec le service informatique.

2. Fixer des objectifs RTO et RPO compréhensibles

Deux indicateurs structurent un PRA. Le RTO, ou délai de reprise, indique le temps acceptable avant le retour d’un service. Le RPO, ou point de reprise, précise la quantité maximale de données que l’entreprise accepte de perdre.

Dans cette PME, le RTO de la messagerie peut être fixé à une heure si elle est hébergée dans le cloud et accessible depuis une connexion de secours. Pour le serveur de gestion, un RTO de quatre heures peut être acceptable. Le RPO des factures et dossiers clients pourrait être de deux heures : les sauvegardes ou réplications doivent donc permettre de récupérer des données très récentes.

Ces valeurs sont des choix métier. Exiger un RTO de quelques minutes pour chaque application augmente fortement les coûts et la complexité. À l’inverse, accepter une journée complète d’indisponibilité peut être risqué pour une activité qui dépend d’échanges quotidiens avec ses clients.

3. Prévoir des sauvegardes restaurables et isolées

Le PRA de notre exemple repose sur plusieurs copies des données : une sauvegarde locale pour une restauration rapide, une copie externalisée pour résister à un sinistre sur site, et une conservation isolée ou immuable pour limiter l’impact d’un ransomware. Les comptes de sauvegarde doivent être protégés par des accès distincts et une authentification renforcée.

La fréquence des sauvegardes doit correspondre au RPO annoncé. Sauvegarder les données chaque nuit ne permet pas de promettre une perte maximale de deux heures. Il faut également inclure les configurations critiques : serveur, pare-feu, postes clés, téléphonie, licences, paramètres de messagerie et documentation réseau.

Surtout, une sauvegarde doit être testée. Restaurer un fichier isolé ne garantit pas qu’un serveur complet, son application et sa base de données redémarreront correctement. Une vérification périodique sur un environnement séparé est indispensable.

4. Organiser le mode de travail dégradé

Pendant la reprise, l’entreprise doit pouvoir fonctionner autrement. Dans notre scénario, les collaborateurs sont invités à utiliser la messagerie cloud depuis leur navigateur ou leur téléphone. Une liste actualisée des contacts clients et fournisseurs est disponible dans un espace sécurisé distinct du serveur touché. Les demandes urgentes sont consignées dans un outil cloud temporaire afin d’éviter les oublis et les doubles traitements.

Pour la téléphonie, un renvoi vers des mobiles ou une solution VoIP accessible à distance peut préserver l’accueil. Si l’accès internet principal est en cause, une connexion de secours 4G ou 5G permet de maintenir les usages prioritaires. Cette continuité dégradée ne remplace pas l’environnement normal, mais elle évite le silence total vis-à-vis des clients.

Le PRA doit aussi prévoir le télétravail ponctuel. Les collaborateurs doivent savoir quels outils utiliser, sur quels équipements autorisés et avec quelles règles de sécurité. Ouvrir l’accès dans l’urgence sans authentification multifacteur ou sans contrôle des postes créerait une seconde faille au moment où l’entreprise est la plus exposée.

5. Désigner les rôles et les contacts avant l’incident

Un document technique sans responsables nommés ne suffit pas. Dans une petite structure, le dirigeant peut décider de l’arrêt ou de la communication externe, un responsable interne coordonner les utilisateurs, et le partenaire informatique qualifier l’incident, isoler les systèmes, restaurer les services et documenter les actions.

Le document doit contenir les numéros d’urgence, les accès conservés dans un coffre-fort de mots de passe, les coordonnées des opérateurs internet et télécoms, les références des licences et les contacts d’assurance cyber si l’entreprise en possède une. Ces informations doivent rester accessibles même si le réseau de l’entreprise est hors service.

La communication mérite une procédure courte. Qui informe les équipes ? Qui répond aux clients si les délais de traitement sont affectés ? Quel message transmettre sans révéler d’informations techniques inutiles ni spéculer sur l’origine de l’incident ? Une communication sobre et factuelle protège la relation commerciale.

6. Décrire la procédure de reprise dans le bon ordre

Dans le cas du ransomware, la première action n’est pas de restaurer : c’est d’isoler les équipements concernés pour empêcher la propagation. Le prestataire ou la personne responsable évalue ensuite l’étendue de l’incident, conserve les éléments utiles à l’analyse et vérifie que les sauvegardes ne sont pas contaminées.

La reprise suit un ordre précis : sécurisation des identités et mots de passe, remise en état de la connectivité, restauration des services de communication, reconstruction ou restauration du serveur de gestion, contrôle des données, puis remise à disposition des utilisateurs. Chaque étape doit prévoir un critère de validation. Un service n’est pas considéré comme rétabli parce qu’il démarre, mais parce que les utilisateurs peuvent réaliser les opérations prévues sans erreur.

Cette procédure doit préciser les décisions à ne pas prendre dans la précipitation, par exemple payer une rançon, reconnecter un poste suspect ou réutiliser une sauvegarde non vérifiée. Selon l’incident, l’entreprise peut devoir solliciter son assureur, un conseil juridique ou les autorités compétentes.

7. Tester, corriger et maintenir le plan

Un PRA non testé est une hypothèse. Pour une PME, un exercice annuel complet, complété par des contrôles ciblés au fil de l’année, constitue souvent un bon équilibre. Il peut s’agir de restaurer un dossier, de basculer la téléphonie, de vérifier l’accès distant ou de simuler l’indisponibilité d’un serveur.

Après chaque test ou incident, le plan doit être mis à jour : nouveaux collaborateurs, changement de logiciel, nouveau site, évolution des accès internet ou remplacement du matériel. La documentation technique, les droits d’administration et l’inventaire des équipements doivent suivre le même rythme.

Un partenaire informatique unique peut simplifier cette maintenance en centralisant l’hébergement, les sauvegardes, la cybersécurité, la connectivité et le support. L’intérêt n’est pas de supprimer toute responsabilité interne, mais de disposer d’un interlocuteur capable de coordonner la reprise sur l’ensemble de l’infrastructure.

Un PRA efficace tient souvent sur des décisions claires plutôt que sur un document interminable : quelles activités sauver d’abord, quelles données restaurer, qui appelle qui et comment travailler pendant la panne. Le meilleur moment pour obtenir ces réponses reste bien avant le prochain incident.