PRA informatique pour PME : modèle et exemple rempli

Un PRA informatique doit permettre de reprendre une activité, pas seulement de restaurer des fichiers. Pour chaque application indispensable, écrivez qui décide, dans quel délai elle doit redevenir utilisable, de quoi elle dépend et quel test autorise sa réouverture. Le modèle proposé sert à préparer ce travail avec votre prestataire ; son téléchargement ne prouve pas votre capacité de reprise.

Ce que le modèle doit contenir

Le plan de reprise d'activité, ou PRA, concerne ici la reprise informatique qui soutient vos activités. Il complète l'organisation du travail pendant l'incident : prise de commandes par téléphone, report d'une livraison ou utilisation d'un registre temporaire. Le responsable métier doit fixer ce qui peut attendre. Le prestataire confirme ensuite les moyens nécessaires.

Le référentiel ANSSI relie le PRA à l'interruption et à la perte de données acceptables. Notre trame rassemble le périmètre, les contacts, les applications prioritaires, leurs dépendances, les étapes de reprise et le compte rendu d'exercice. Elle est à adapter à votre entreprise, puis à éprouver.

Partir d'une activité et remonter ses dépendances

« Le serveur doit repartir en quatre heures » reste imprécis. Qui pourra faire quoi à la fin de ces quatre heures ? Demandez par exemple : « Le service commandes doit pouvoir retrouver les commandes validées et enregistrer une nouvelle commande. » Cette phrase devient un critère de recette. Elle évite de déclarer le succès dès que la machine démarre.

Dans un exemple fictif, la saisie des commandes dépend du réseau, d'un service d'identité, d'une base et du logiciel commercial. Un fichier restauré ne suffit pas si personne ne peut se connecter. Ajoutez les licences, les accès administratifs, l'espace disponible et le poste depuis lequel la restauration sera pilotée. L'ordre réel dépend de votre architecture : le schéma illustre une chaîne, pas une procédure universelle.

Pour chaque service, séparez l'objectif validé et le délai démontré lors du dernier exercice. Une case sans preuve reste « non testé ». Le guide de test de restauration précise les notions de RTO et de RPO : délai cible de reprise et ancienneté maximale acceptable du point de données récupéré.

Un exemple rempli qui révèle un problème

Voici un scénario pédagogique, entièrement fictif. Une PME perd sa gestion commerciale à 9 h. Elle a fixé une reprise en quatre heures et une perte de données de deux heures au maximum. Dans le compte rendu simulé, le test métier ne passe qu'à 13 h 45 ; la dernière sauvegarde exploitable date de 6 h.

L'exemple n'est pas un modèle de résultat réussi. Il montre pourquoi un compte rendu doit conduire à une correction : comprendre le retard, revoir la chaîne de sauvegarde ou faire réexaminer les objectifs par le métier. Il serait trompeur de remplacer les objectifs dans le document pour faire disparaître l'écart.

Le RPO ne mesure pas automatiquement trois heures de commandes perdues : il décrit ici l'ancienneté du point restauré. Des journaux applicatifs ou le registre temporaire peuvent permettre une récupération complémentaire, à vérifier séparément.

Garder des moyens utilisables pendant la panne

Un PRA enregistré uniquement dans le partage inaccessible ne sera pas disponible le jour de l'incident. Prévoyez une copie protégée accessible hors du système concerné, un annuaire d'urgence et un moyen de communication alternatif. Le guide ANSSI Préparer la remédiation décrit ces préparatifs et les limites d'un plan prévu seulement pour une panne classique.

Le document indique où obtenir les accès de secours, qui peut les délivrer et comment tracer leur utilisation. N'y collez pas les mots de passe ni les codes de récupération. Testez le mécanisme d'accès avec les personnes autorisées avant l'exercice ; prévoyez également un suppléant.

En cas de suspicion de compromission, la priorité de remise en route doit être articulée avec le confinement et l'investigation. Restaurer dans un environnement encore compromis peut relancer l'incident. Le responsable de réponse à incident et le responsable métier doivent décider des conditions de réouverture.

Faire un exercice avant de promettre un délai

Commencez par un exercice sur table : le décideur principal est absent, la messagerie est indisponible, le prestataire doit retrouver les contacts et les dépendances. Puis organisez une restauration dans un environnement isolé, sur un périmètre autorisé, sans écraser les données actives. Les deux exercices répondent à des questions différentes.

Le guide NIST SP 800-34 traite notamment de la préparation et de la validation de la reprise. C'est une référence de méthode pour les systèmes fédéraux américains, pas une obligation générale pour les PME françaises.

Dans votre compte rendu, notez les heures, le point de sauvegarde utilisé, les tests métier, les erreurs rencontrées, les écarts aux objectifs et les actions correctives avec leur responsable. Un test de quelques fichiers ne valide pas la reprise de l'application entière. La stratégie 3-2-1 traite les copies ; le PRA organise leur utilisation avec les personnes et les systèmes nécessaires.

Décider de la réouverture et de la prochaine vérification

Avant d'ouvrir aux utilisateurs, faites accepter les tests par le responsable métier, rapprochez les opérations réalisées en mode dégradé et fixez la surveillance après reprise. Si un retour à l'ancien système reste possible, précisez comment préserver les nouvelles écritures. Sinon, une restauration techniquement réussie peut créer une perte de données au retour.

Choisissez une application prioritaire, complétez sa fiche et faites vérifier les dépendances par votre prestataire. Prévoyez une nouvelle revue après un changement important, un incident ou un exercice. Pour cadrer ce travail, notre équipe infrastructure peut intervenir sur l'inventaire, les sauvegardes et la préparation des tests ; les délais de reprise se valident sur votre environnement.