Une PME peut perdre l’accès à ses outils en quelques minutes : ransomware, serveur indisponible, erreur humaine, panne électrique ou incident chez un opérateur. Le guide du plan de reprise informatique n’est donc pas un document réservé aux grands groupes. C’est une méthode concrète pour redémarrer les services utiles, dans le bon ordre, sans improviser sous pression.
Pour une entreprise de 5 à 200 collaborateurs, l’enjeu est simple : continuer à vendre, produire, facturer, répondre aux clients et communiquer, même après un incident sérieux. Un bon plan de reprise ne promet pas le risque zéro. Il réduit la durée et le coût de l’arrêt, tout en donnant à chaque interlocuteur un rôle clair.
À quoi sert un plan de reprise informatique ?
Le plan de reprise informatique, souvent appelé PRA, décrit les moyens techniques et organisationnels permettant de remettre en service le système d’information après une interruption majeure. Il intervient lorsque l’incident a déjà eu lieu et que les outils ne sont plus utilisables normalement.
Il ne faut pas le confondre avec le plan de continuité d’activité, ou PCA. Le PCA prévoit comment maintenir les activités pendant une crise : télétravail, solutions de secours, procédures manuelles ou bascule vers un site alternatif. Le PRA se concentre davantage sur la restauration des données, des postes, des applications, des accès réseau et de la téléphonie.
Dans la pratique, les deux sujets se rejoignent. Si votre logiciel de gestion est restauré mais que les collaborateurs ne peuvent ni s’y connecter ni joindre les clients, la reprise reste incomplète. C’est pourquoi une PME doit traiter son informatique, son réseau, ses sauvegardes et ses communications comme un ensemble cohérent.
Commencer par les activités, pas par les équipements
Un PRA efficace ne débute pas par une liste de serveurs. Il débute par les conséquences métier d’un arrêt. Demandez-vous ce qui bloque réellement l’entreprise après une heure, une journée, puis trois jours d’indisponibilité.
Pour un cabinet comptable, l’accès aux dossiers clients, à la messagerie et aux logiciels métiers sera prioritaire. Pour une société de services, ce seront souvent le CRM, la téléphonie, les outils collaboratifs et les accès distants. Dans une entreprise avec un entrepôt, l’ERP, les terminaux mobiles, les imprimantes d’étiquettes et la connexion internet peuvent devenir critiques.
Cette analyse permet de classer les services en trois niveaux : essentiels pour travailler immédiatement, nécessaires à court terme et secondaires. Ce classement évite de mobiliser les équipes sur une imprimante ou un poste isolé alors que la messagerie, les données clients ou le pare-feu ne sont pas encore rétablis.
Fixer des objectifs réalistes : RTO et RPO
Deux indicateurs structurent le plan. Le RTO, ou délai de reprise, correspond au temps maximal acceptable avant le redémarrage d’un service. Le RPO, ou point de reprise, indique la quantité maximale de données que l’entreprise accepte de perdre.
Un RTO de quatre heures pour le CRM signifie que l’outil doit être de nouveau accessible dans ce délai. Un RPO d’une heure signifie qu’en cas de restauration, l’entreprise ne doit pas perdre plus d’une heure de saisie. Ces objectifs ont un coût : une sauvegarde quotidienne ne peut pas répondre à un RPO d’une heure, et une restauration manuelle sur un matériel non préparé ne garantit pas un RTO très court.
Il faut donc arbitrer. Toutes les données n’exigent pas la même fréquence de sauvegarde, et tous les logiciels ne nécessitent pas une haute disponibilité. Le bon niveau de protection est celui qui correspond aux pertes réellement supportables par l’entreprise.
Cartographier ce qu’il faut réellement restaurer
Beaucoup de plans échouent parce qu’ils oublient les dépendances. Restaurer une machine virtuelle ne suffit pas toujours. L’application peut dépendre d’un annuaire d’entreprise, d’une base de données, d’un VPN, de licences, d’un accès internet, d’un certificat ou d’un fournisseur externe.
La cartographie doit couvrir les postes de travail, serveurs, applications SaaS, comptes administrateurs, équipements réseau, accès Wi-Fi, pare-feu, liens fibre, téléphones, mobiles professionnels et sauvegardes. Pour chaque élément critique, notez le propriétaire, la méthode de restauration, les identifiants ou coffres-forts nécessaires, les dépendances et le délai visé.
Les outils cloud ne dispensent pas de cette démarche. Une messagerie collaborative ou un logiciel SaaS est généralement hébergé et maintenu par son éditeur, mais votre entreprise reste responsable de ses comptes, de ses droits d’accès, de sa configuration et parfois de ses données. Une suppression massive, un compte administrateur compromis ou une mauvaise synchronisation peuvent aussi perturber l’activité.
Sécuriser les sauvegardes avant d’en avoir besoin
Une sauvegarde non testée est une hypothèse, pas une garantie. Le plan doit préciser quelles données sont sauvegardées, à quelle fréquence, où elles sont stockées et qui contrôle les alertes d’échec.
La règle 3-2-1 reste une base pertinente : conserver trois copies des données, sur deux supports différents, dont une copie hors site. Face aux ransomwares, il est utile d’ajouter une protection contre l’altération ou la suppression des sauvegardes, par exemple avec une copie immuable ou isolée des comptes d’administration courants.
La sécurité des identifiants est tout aussi déterminante. Si le pirate dispose des droits administrateurs, il peut chiffrer les serveurs, effacer les sauvegardes accessibles et empêcher la restauration. L’authentification multifacteur, la séparation des comptes administrateurs et la surveillance des accès réduisent fortement ce scénario.
Construire le guide du plan de reprise informatique
Le document doit être utilisable à 8 heures du matin après une nuit d’incident, y compris par une personne qui n’a pas conçu l’infrastructure. Évitez les formulations vagues telles que « restaurer le serveur ». Indiquez plutôt la séquence, les responsables, les contacts, les prérequis et le résultat attendu.
Un guide opérationnel comprend généralement les éléments suivants :
- les coordonnées de la cellule de crise, des prestataires, de l’assureur cyber et des fournisseurs critiques ;
- les critères qui déclenchent le PRA et la personne habilitée à prendre cette décision ;
- l’ordre de restauration des services, avec les RTO et RPO attendus ;
- les procédures techniques validées pour restaurer les données, les postes, le réseau et les accès ;
- les modèles de communication destinés aux collaborateurs, clients et partenaires ;
- les contrôles à réaliser avant de remettre un outil en production.
L’ordre de reprise est essentiel. Dans de nombreux environnements, on restaure d’abord la connectivité et la sécurité périmétrique, puis les services d’identité et les accès, ensuite les données et applications métier, enfin les postes et services périphériques. Cet ordre dépend toutefois de votre architecture : une PME très orientée cloud pourra prioriser la connexion internet, les identités et les équipements utilisateurs.
Prévoir la téléphonie et les communications de crise
Une panne informatique est aussi une crise de communication. Sans téléphone, les équipes ne peuvent pas informer les clients, qualifier les urgences ou coordonner les actions. Une solution de téléphonie IP bien préparée permet de renvoyer les appels vers des mobiles, d’activer des messages d’information et de faire travailler les équipes à distance si les locaux ou le réseau principal sont indisponibles.
Les communications doivent aussi être organisées en interne. Définissez un canal alternatif à la messagerie professionnelle, les personnes autorisées à communiquer à l’extérieur et la fréquence des points de situation. En cas de suspicion de cyberattaque, évitez de diffuser des informations techniques non vérifiées : l’objectif est de protéger l’entreprise tout en restant transparent sur les impacts opérationnels.
Tester le plan sans attendre une panne
Le test est la partie la plus révélatrice du PRA. Il met en évidence les sauvegardes incomplètes, les comptes administrateurs inaccessibles, les procédures obsolètes et les dépendances oubliées. Un test annuel est un minimum ; les services très critiques méritent des exercices plus fréquents, notamment après une migration, un changement de prestataire ou l’arrivée d’un nouvel outil métier.
Commencez par un exercice simple : simulez l’indisponibilité d’un serveur ou d’une application, restaurez une copie dans un environnement isolé et vérifiez que les utilisateurs peuvent se connecter et travailler. Mesurez le délai obtenu, comparez-le au RTO défini et consignez les écarts.
Les simulations de crise sont également utiles. Réunissez les responsables concernés autour d’un scénario réaliste : ransomware, perte de connexion fibre, incendie dans les locaux ou compromission de comptes Microsoft 365. Sans toucher à la production, l’équipe déroule les décisions et les communications prévues. Cet exercice révèle souvent que la technique est prête, mais que la gouvernance ne l’est pas.
Faire vivre le PRA avec un partenaire informatique
Un plan de reprise ne doit pas rester dans un dossier partagé jusqu’au prochain incident. Chaque évolution du système d’information doit entraîner une mise à jour : nouveau logiciel, changement de sauvegarde, arrivée d’un site, déploiement de téléphonie IP ou modification des droits d’administration.
Pour les PME sans DSI interne, l’infogérance apporte un cadre utile : supervision des sauvegardes, maintenance des équipements, documentation, gestion des accès et accompagnement lors des tests. Meonet peut notamment aider à relier la protection des données, la disponibilité du réseau et la continuité des communications dans une démarche adaptée à la taille de l’entreprise.
Le bon réflexe n’est pas d’attendre l’incident parfait pour écrire un plan parfait. Identifiez vos trois services les plus critiques, vérifiez qu’ils sont restaurables et testez-les. C’est souvent ce premier exercice qui transforme une crainte diffuse en capacité réelle de reprise.
