PRA informatique : préparer la reprise avant que tout s’arrête

À quoi sert un PRA informatique ?

Le plan de reprise d’activité organise le redémarrage des services informatiques après une interruption. Il décrit les personnes à mobiliser, les ressources nécessaires et la séquence de remise en service. Il donne un cadre à l’action lorsque les outils habituels ou les interlocuteurs ne sont pas disponibles.

Le plan de continuité d’activité, ou PCA, s’intéresse plus largement au maintien des activités pendant la perturbation. Les deux approches se complètent. Pour une petite structure, un document court et testé est plus utile qu’un classeur détaillé que personne ne sait retrouver.

Partir des activités indispensables

Demandez à chaque responsable ce qui doit fonctionner pour servir les clients, produire, facturer ou payer les fournisseurs. Identifiez ensuite les applications, les données, les accès et les personnes nécessaires. Le service qui paraît le plus visible n’est pas toujours celui à rétablir en premier.

Exemple illustratif : 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. Une discussion métier permet de distinguer le confort, la dégradation acceptable et l’arrêt complet.

Fixer des objectifs compréhensibles

Question	Objectif associé
Combien de temps cette activité peut-elle rester arrêtée ?	Délai de reprise visé, ou RTO
Quelle quantité de travail peut-on perdre ?	Perte de données maximale acceptable, ou RPO
Quel fonctionnement réduit reste possible ?	Mode dégradé validé par le métier
Comment vérifier le retour à la normale ?	Critères de validation du service

Ces objectifs orientent les moyens nécessaires. Ils ne constituent pas une garantie tant que l’architecture, les contrats et les tests n’ont pas confirmé leur faisabilité. Si le budget ne permet pas l’objectif souhaité, l’écart doit être présenté pour arbitrage.

Cartographier les dépendances de la reprise

Un serveur restauré peut rester inutilisable sans réseau, résolution de noms, authentification ou accès à un fournisseur externe. Écrivez ces dépendances et l’ordre dans lequel elles doivent revenir. Vérifiez la disponibilité des clés, configurations et moyens d’administration.

• Contacts de crise et suppléants.
• Accès aux sauvegardes et aux procédures hors du système principal.
• Ressources de remplacement ou environnement de reprise.
• Coordonnées des fournisseurs et modalités de mobilisation.
• Procédures de restauration et de validation métier.
• Moyens de communication si la messagerie est indisponible.

La copie du plan doit rester accessible sans dépendre uniquement du service qu’elle permet de restaurer. Les secrets ne doivent toutefois pas être diffusés librement avec le document : leur récupération relève d’une procédure contrôlée.

Tester un scénario réaliste

Commencez par un exercice sur table : un incident est annoncé et les participants expliquent ce qu’ils feraient. Cet exercice révèle les contacts manquants et les décisions ambiguës. Complétez-le par des tests de restauration dans un environnement adapté.

Un scénario de panne matérielle et un scénario d’incident de sécurité n’imposent pas les mêmes vérifications. Après une compromission, la reprise nécessite notamment une analyse et un environnement considéré comme suffisamment maîtrisé avant reconnexion. Le plan doit identifier qui prend ces décisions, avec les spécialistes mobilisables.

Mesurez les délais observés et consignez les limites de l’exercice. Un test sur un faible volume ne permet pas d’affirmer que tout le système sera rétabli dans le même temps. Documentez les hypothèses pour éviter une confiance excessive.

Garder le plan à jour

Révisez-le lors d’un changement d’application, de fournisseur, de site ou d’interlocuteur. Chaque exercice doit produire une courte liste d’actions suivies jusqu’à leur clôture. Un plan périmé peut envoyer les équipes vers des contacts ou des accès qui n’existent plus.

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 doivent être vérifiées 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. CWAM peut vous aider à cadrer ces premières étapes.