Plan de reprise informatique PME, la méthode concrète avant la panne

Une PME découvre souvent son besoin de plan de reprise d’activité informatique le jour où tout s’arrête : serveur inaccessible, données chiffrées, prestataire indisponible, box Internet coupée, logiciel métier bloqué. À ce moment-là, le problème n’est plus de savoir si l’informatique est importante. Le problème est de savoir quoi relancer en premier, avec qui, à partir de quelles sauvegardes et dans quel délai réaliste.

Un PRA n’a pas besoin de ressembler au dossier d’un grand groupe. Il doit surtout être utilisable sous stress. Pour une petite structure, la bonne version tient dans un inventaire clair, quelques priorités métier, des sauvegardes testées, des accès de secours et une liste de décisions à prendre quand l’incident arrive.

Par où commencer un PRA informatique en PME ?

Commencez par l’activité, pas par les serveurs. Listez les services qui permettent encore de vendre, facturer, produire, livrer, répondre aux clients et payer les équipes. Ensuite seulement, reliez chaque activité à ses applications critiques, ses données, ses accès, ses prestataires et son délai maximal d’arrêt acceptable.

Cette entrée métier évite un piège classique : protéger ce qui est visible techniquement, mais oublier ce qui bloque réellement l’entreprise. Un serveur de fichiers peut paraître central, alors que le point le plus critique est parfois l’accès au logiciel de caisse, à l’ERP, à la messagerie, au VPN du cabinet comptable ou à un export de commandes.

Le premier document peut rester simple. Une page par activité critique suffit pour démarrer, tant qu’elle reste utilisable.

Ce tableau donne une base de discussion entre dirigeant, responsable opérationnel, prestataire informatique et personne qui gère les données. Il évite que le PRA soit écrit par la seule technique alors que la décision de reprise appartient aussi au métier.

RTO et RPO : les deux chiffres à définir sans jargon

Deux repères structurent tout le plan. Le RTO indique le délai maximal d’interruption acceptable avant que l’activité ne soit trop dégradée. Le RPO indique la quantité de données que l’entreprise accepte de perdre, par exemple une heure, une demi-journée ou une journée de travail.

Ces notions semblent techniques, mais elles sont très concrètes. Si la facturation peut attendre deux jours, son RTO n’est pas le même que celui d’un site de commande qui prend 80 % du chiffre d’affaires. Si une journée de données saisies à la main peut être reconstituée, le RPO n’est pas le même que pour un outil de production qui enregistre des mesures impossibles à refaire.

La bonne méthode consiste à fixer des objectifs modestes mais tenables. Un RTO de deux heures n’a aucune valeur si personne ne sait restaurer le serveur, si la sauvegarde met six heures à revenir, si le prestataire ne peut intervenir que le lendemain ou si le dirigeant découvre trop tard que l’application prioritaire dépend d’un service externe non documenté. Le PRA doit refléter la capacité réelle, puis prévoir les investissements nécessaires si cette capacité est insuffisante.

Inventorier les dépendances avant la crise

Un bon inventaire réduit les surprises. Il prépare les décisions.

Un PRA échoue rarement à cause d’un seul serveur. Il échoue parce qu’une dépendance a été oubliée : DNS, licence, certificat, compte administrateur, clé de chiffrement, accès VPN, imprimante d’étiquettes, NAS, outil SaaS, ligne Internet ou compte d’un ancien salarié. L’inventaire doit donc décrire la chaîne complète, pas seulement les machines.

Une PME peut commencer avec un fichier très sobre : service, responsable, application, données, emplacement, sauvegarde, prestataire, accès, priorité, délai attendu. Le but n’est pas de documenter chaque câble au millimètre, mais de rendre visible ce qui empêchera la reprise si une personne manque ou si un système tombe.

Pour approfondir ce point, consultez Apprendre l'informatique seul avec une méthode fiable, qui traite plus précisément de apprendre l'informatique seul avec une méthode fiable.

La version utile est celle que quelqu’un peut ouvrir un vendredi soir et comprendre sans réunion préparatoire. Pas une archive.

Sauvegardes : ce qu’il faut vérifier avant de leur faire confiance

La sauvegarde est le cœur du PRA, mais elle ne suffit pas. Il faut savoir ce qui est sauvegardé, à quelle fréquence, où la copie est stockée, qui peut y accéder, comment elle est protégée contre un rançongiciel et combien de temps prend une restauration complète. Une sauvegarde qui réussit chaque nuit peut malgré tout être inutilisable le jour de l’incident.

Le point critique est l’isolement. Les recommandations publiques insistent sur l’intérêt de sauvegardes hors ligne ou protégées des compromissions courantes. Si l’attaquant, le logiciel malveillant ou une erreur d’administration peut supprimer la copie en même temps que les données de production, l’entreprise n’a pas une sauvegarde de secours ; elle a une dépendance de plus. Ce détail paraît secondaire quand tout fonctionne, mais il devient décisif lorsque la production et les copies connectées sont touchées ensemble.

Vérifiez aussi les petites données périphériques : exports de configuration, clés de chiffrement, paramètres réseau, comptes de service, licences, scripts de déploiement, documentation des outils SaaS. La restauration d’un serveur sans ces éléments peut laisser l’activité bloquée.

1. Copie locale : rapide pour restaurer un fichier, mais exposée si elle reste connectée.
2. Copie cloud : utile hors site, à condition de maîtriser les droits, versions et coûts de restauration.
3. Copie hors ligne : précieuse contre certains scénarios de compromission, mais elle doit être organisée.
4. Journal de sauvegarde : indispensable pour savoir si la dernière copie est réellement exploitable.

Le bon indicateur n’est pas “la sauvegarde est verte”. C’est : “nous avons restauré un échantillon récent, et il fonctionne”. Notez-le.

Tester la restauration sans attendre un incident réel

Un test de restauration doit être prévu, daté et documenté. Il peut commencer petit : restaurer un dossier partagé, une base de test, une boîte mail, une configuration réseau, puis vérifier que les utilisateurs concernés peuvent réellement travailler avec les données récupérées. Ce n’est pas un exercice théorique ; c’est la preuve de reprise.

Le test révèle souvent des surprises : sauvegarde trop lente, mot de passe manquant, dépendance oubliée, version incompatible, documentation ancienne, prestataire non disponible, ou données restaurées sans droits corrects. Ces problèmes sont acceptables pendant un exercice. Ils deviennent critiques pendant une crise.

Un test annuel vaut mieux qu’une promesse permanente. Fixez une date.

Planifiez-le pour les services importants, et plus souvent si l’activité change vite. Chaque nouveau logiciel critique, migration cloud ou changement de prestataire doit déclencher une relecture du PRA.

Deux tests à faire avant de se croire prêt

Un PRA sérieux distingue le fichier récupéré du service réellement utilisable.

Restaurer un échantillon

Choisir un dossier, une base ou une boîte mail récente, puis vérifier contenu, droits et temps réel de récupération.

Simuler une priorité métier

Demander à une équipe de reprendre une tâche simple avec les données restaurées et noter tout ce qui manque.

Organiser les rôles pendant l’incident

La reprise a besoin d’un pilote identifié. Avant l’incident.

En crise, la technique ne suffit pas. Il faut savoir qui décide, qui communique, qui contacte le prestataire, qui informe les salariés, qui vérifie les clients prioritaires et qui garde la trace des actions. Sans ce minimum, l’équipe risque de multiplier les initiatives contradictoires, avec des redémarrages lancés trop tôt, des messages divergents aux équipes et des informations perdues alors qu’elles devraient servir au diagnostic.

Une PME peut définir trois rôles simples : un décideur, qui arbitre les priorités ; un référent technique, interne ou prestataire, qui pilote la restauration ; un relais métier, qui confirme ce qui fonctionne réellement. La même personne peut porter plusieurs rôles dans une petite structure, mais ils doivent être nommés.

Prévoyez aussi un canal hors système principal. Si la messagerie est indisponible, l’équipe doit savoir comment se coordonner sans improviser dans un groupe créé à la hâte.

Pour approfondir ce point, consultez infrastructure informatique, qui traite plus précisément de infrastructure informatique : les bases pour structurer un si de pme sans surdimensionner.

Les scénarios à couvrir sans écrire un roman

Quatre scénarios suffisent souvent pour commencer. Ils cadrent l’essentiel.

Un PRA de PME doit rester court, mais il ne peut pas dépendre d’un seul scénario. La panne électrique, le serveur en défaut, l’erreur humaine, le vol d’ordinateur, la coupure Internet et l’incident cyber ne se traitent pas avec les mêmes gestes. L’objectif n’est pas de prévoir chaque détail, mais de savoir quelles décisions changent selon la cause de l’arrêt.

Le scénario le plus facile à tester est souvent la perte d’un fichier ou d’un dossier. Il vérifie la sauvegarde, les droits et la capacité du prestataire à restaurer vite. Le scénario le plus structurant est la perte d’un service complet, par exemple messagerie, ERP ou serveur de fichiers. Il oblige à documenter les dépendances cachées : annuaire, DNS, certificats, licence, réseau, poste utilisateur et validation métier.

Le scénario le plus sensible reste la compromission. Si un rançongiciel ou un compte administrateur compromis est possible, le plan doit préciser à quel moment on isole les machines, qui autorise la remise en ligne et comment on évite de restaurer un système encore infecté. Une restauration rapide mais contaminée peut recréer la panne quelques heures plus tard.

Cette grille permet de garder le document lisible. Chaque scénario doit tenir sur quelques lignes : déclencheur, personnes à appeler, première action, décision de sécurité, service à restaurer, preuve de retour à la normale. Si le scénario demande trois pages, c’est souvent que la procédure opérationnelle manque de clarté.

Maintenir le PRA vivant après chaque changement

Le PRA vieillit vite. C’est normal.

Il devient faux dès que l’entreprise change sans mettre à jour le document. Nouveau logiciel métier, migration Microsoft 365 ou Google Workspace, remplacement du NAS, changement de prestataire, départ d’un administrateur, déménagement, nouveau site e-commerce : chacun de ces événements peut casser le chemin de reprise. Le risque n’est pas seulement d’avoir oublié une ligne : c’est de croire que la ligne ancienne protège encore.

La règle pratique consiste à lier le PRA aux changements importants. Quand un outil critique évolue, on vérifie trois choses : la donnée est-elle toujours sauvegardée, qui sait restaurer, et le test précédent reste-t-il valable ? Cette vérification prend moins de temps qu’un audit complet, mais elle évite de découvrir en crise que l’ancien plan pointe vers un serveur supprimé, un compte qui n’existe plus ou un prestataire qui n’a jamais reçu les nouvelles consignes.

Gardez une trace courte des versions. Notez la date, la modification, la personne qui a validé et le prochain test prévu. Cette discipline donne une preuve utile en cas d’incident, mais surtout elle aide l’équipe à comprendre ce qui a vraiment été vérifié. Un PRA non daté, sans responsable et sans historique inspire rarement confiance le jour où il faut l’utiliser.

1. Après une migration : refaire au moins un test de restauration sur les données déplacées.
2. Après un changement de prestataire : vérifier les contacts d urgence, les accès et les engagements réels.
3. Après un départ sensible : contrôler les comptes administrateur, MFA, coffres de mots de passe et délégations.
4. Après une croissance rapide : réviser les priorités métier, car une application secondaire peut devenir centrale.

Cette mise à jour régulière évite un faux sentiment de sécurité. Le PRA n’est pas un fichier figé ; c’est un outil de pilotage qui suit l’entreprise.

Le plan minimum à rédiger cette semaine

Il vaut mieux un PRA de trois pages utilisé qu’un classeur complet jamais ouvert. La première version doit répondre aux questions qui bloquent la reprise : quoi relancer, dans quel ordre, avec quelles données, qui appelle qui, où sont les accès, quelle sauvegarde utiliser et comment vérifier que le service est revenu.

Écrivez court, mais précis. Les phrases doivent être actionnables : “appeler le prestataire au numéro d’urgence”, “restaurer la base comptabilité depuis la dernière copie vérifiée”, “valider la facturation sur trois dossiers clients”, “prévenir les équipes via le canal de secours”. Ce niveau de détail rend le plan exploitable quand personne n’a le temps de reformuler, et il force aussi à repérer les zones floues avant que l’incident ne les transforme en blocage.

Ce qu’il faut retenir

Un PRA informatique de PME n’est pas un document destiné à rassurer. C’est une procédure de reprise qui doit fonctionner quand les outils habituels, les personnes et les certitudes manquent. Sa valeur se mesure au test de restauration, à la clarté des rôles et à la capacité de l’entreprise à reprendre d’abord ce qui compte vraiment.

La prochaine action est simple : choisissez une activité critique, identifiez ses données, fixez un RTO et un RPO réalistes, puis restaurez un échantillon cette semaine. Si le test échoue, le PRA a déjà servi : il vient de révéler le point à corriger avant le vrai incident.

Pour approfondir ce point, consultez outil ticketing informatique PME, qui traite plus précisément de outil de ticketing informatique pme : choix, exemples, déploiement.