PRA informatique : préparer la reprise avant que tout s'arrête
Un plan de reprise d'activité informatique décrit qui fait quoi, avec quels moyens et dans quel ordre, pour redémarrer après un incident. Pour une PME, il commence par les activités indispensables, leurs dépendances et des objectifs de reprise qu'on peut tester.
L’essentiel
- Le métier fixe les priorités et la perte de données acceptable ; l'informatique dit ce que ça coûte.
- La reprise dépend aussi des accès, du réseau, des fournisseurs et des moyens de communication.
- Un plan court et testé vaut mieux qu'un classeur détaillé que personne ne retrouve.
- Après une cyberattaque, on ne redémarre pas sur un environnement compromis : la décision se prépare à l'avance.
Sommaire de l’article
Un incendie, une panne de serveur, un rançongiciel : le jour où tout s'arrête n'est pas le jour pour réfléchir à l'ordre de redémarrage. Le plan de reprise d'activité, ou PRA, existe pour que les décisions soient déjà prises.
À quoi sert un PRA informatique ?
À organiser le redémarrage des services informatiques après une interruption : qui mobiliser, avec quels moyens, dans quel ordre. Il donne un cadre à l'action quand les outils habituels ou les interlocuteurs ne sont pas disponibles.
PRA, reprise d'activité
- Redémarrer après l'arrêt
- Ordre de remise en service
- Restaurations, accès, fournisseurs
PCA, continuité d'activité
- Continuer pendant la perturbation
- Modes dégradés validés par le métier
- Organisation, communication, alternatives
Pour une petite structure, un document court et testé est plus utile qu'un classeur détaillé que personne ne sait retrouver.
Par où commencer ?
Par les activités indispensables, pas par les serveurs. Demandez à chaque responsable ce qui doit fonctionner pour servir les clients, produire, facturer et payer les fournisseurs. Le service le plus visible n'est pas toujours celui à rétablir en premier.
Exemple : une entreprise peut consulter sa messagerie, mais ne peut pas préparer ses commandes sans le logiciel de stock. La priorité de reprise doit refléter ce blocage.
Quels objectifs fixer ?
Deux durées par activité, décidées avec le métier.
- RTO
- Combien de temps à l'arrêt ? Le délai de reprise visé pour l'activité.
- RPO
- Combien de travail perdu ? La perte de données maximale acceptable, en heures.
| Question au métier | Ce qu'elle fixe |
|---|---|
| Combien de temps cette activité peut-elle s'arrêter ? | le délai de reprise visé (RTO) |
| Quelle quantité de travail peut-on perdre ? | la perte de données acceptable (RPO) |
| Quel fonctionnement réduit reste possible ? | le mode dégradé validé |
| Comment vérifier le retour à la normale ? | les critères de validation |
Ces objectifs orientent les moyens. Ils ne sont pas une garantie tant que l'architecture, les contrats et les tests ne les ont pas confirmés. Si le budget ne permet pas l'objectif souhaité, l'écart se présente pour arbitrage.
Quelles dépendances cartographier ?
Tout ce sans quoi un service restauré reste inutilisable. Un serveur restauré ne sert à rien sans réseau, sans authentification ou sans accès au fournisseur de l'application.
- Les applications métier Validées par leurs utilisateurs.
- Les données Restaurées au point choisi, contrôlées.
- Les identités Annuaire, comptes, double authentification.
- Le réseau Connexion, pare-feu, accès à distance.
- Les moyens de crise Contacts, procédures hors ligne, communication de secours.
- Les contacts de crise et leurs suppléants.
- L'accès aux sauvegardes et aux procédures, hors du système principal.
- Les ressources de remplacement ou l'environnement de reprise.
- Les coordonnées des fournisseurs et leurs engagements.
- Les procédures de restauration et de validation métier.
- Un moyen de communiquer si la messagerie est indisponible.
Le plan doit rester accessible sans dépendre du service qu'il permet de restaurer. Les secrets ne se diffusent pas pour autant avec le document : leur récupération suit une procédure contrôlée.
Comment tester le plan ?
Par un exercice sur table, puis par des restaurations réelles. L'exercice sur table, où chacun explique ce qu'il ferait, révèle les contacts manquants et les décisions ambiguës. Les tests de restauration confrontent ensuite les objectifs aux délais observés.
- Exercice sur table Un scénario raconté, sans rien toucher
- Restauration ciblée Une activité critique, chronométrée
- Exercice complet Un scénario de bout en bout, une fois par an
Comment garder le plan à jour ?
En le révisant à chaque changement d'application, de fournisseur, de site ou d'interlocuteur. Chaque exercice produit une courte liste d'actions, suivies jusqu'à leur clôture. Un plan périmé envoie les équipes vers des contacts ou des accès qui n'existent plus.
Sauvegarde cloud : la mettre en place correctement dans une PME
Questions fréquentes
Le cloud remplace-t-il un PRA ?
Non. Même avec des services hébergés, il faut prévoir les accès, les données, les dépendances réseau et l'organisation de la reprise. Les responsabilités du fournisseur se vérifient dans le périmètre souscrit.
Par quoi commencer avec peu de moyens ?
Choisissez une activité critique, identifiez ses dépendances et testez un scénario limité. Étendez ensuite la démarche, activité par activité.
Le PRA est-il obligatoire ?
Pas pour toutes les entreprises, mais NIS2 exige des mesures de continuité pour les entités concernées, et de plus en plus de clients et d'assureurs les demandent. Voir notre article sur NIS2.
Qui doit piloter le PRA ?
Un responsable désigné côté direction, avec l'appui du prestataire informatique. Le prestataire exécute la reprise ; la direction arbitre les priorités et la communication.
