Article mis à jour le 31/10/2026
Un serveur chiffré par un rançongiciel, un incendie dans la salle technique, une erreur de manipulation qui efface une base de données, un fournisseur cloud injoignable : la question n’est pas de savoir si une panne majeure surviendra, mais combien de temps l’entreprise saura fonctionner sans son informatique. Le plan de reprise d’activité informatique (PRA, parfois appelé PRI ou PRAI) répond à cette question par écrit, avant l’incident. Voici une méthode pour le construire, de la plus simple à la plus complète.
PRA, PCA, sauvegarde : ne pas confondre
- La sauvegarde est une copie des données. Elle est indispensable, mais elle ne dit ni dans quel ordre restaurer, ni sur quelle machine, ni qui s’en charge.
- Le PRA décrit comment rétablir les systèmes d’information après un sinistre : procédures, ressources, ordre de redémarrage, responsables.
- Le PCA (plan de continuité d’activité) est plus large : il vise à maintenir l’activité pendant l’incident, y compris en mode dégradé, par exemple au papier ou sur un site de repli. Le PRA en est la composante informatique.
Étape 1 : analyser l’impact de l’arrêt (le « BIA »)
Le guide de planification de contingence du NIST (NIST SP 800-34 Rev. 1, publié en mai 2010) propose un processus en sept étapes : politique de planification, analyse d’impact sur l’activité (BIA), mesures préventives, stratégies de reprise, rédaction du plan, tests et exercices, puis maintenance. Le point de départ est le BIA : il recense les systèmes qui soutiennent chaque processus métier et les classe par criticité.
Concrètement, pour chaque application (facturation, messagerie, téléphonie, production, site web), posez trois questions : qui est bloqué si elle s’arrête, quel est le coût d’une heure ou d’une journée d’arrêt, et de quoi dépend-elle (serveur, base de données, réseau, annuaire, fournisseur externe).
Étape 2 : fixer deux chiffres, le RTO et le RPO
Deux indicateurs structurent tout le reste. Le NIST les définit ainsi :
- le RTO (Recovery Time Objective) est la durée maximale pendant laquelle une ressource peut rester indisponible avant que l’impact devienne inacceptable ;
- le RPO (Recovery Point Objective) est le moment, avant l’incident, jusqu’auquel les données peuvent être restaurées d’après la dernière sauvegarde disponible. Autrement dit, la quantité de données que l’on accepte de perdre.
Le NIST définit aussi la durée d’interruption maximale tolérable (MTD) : le RTO doit rester inférieur à ce plafond. Exemple : une facturation tolérant une journée d’arrêt aura un RTO de 24 heures ; si l’on accepte de ressaisir le travail d’une demi-journée, le RPO est de 12 heures, donc une sauvegarde au moins deux fois par jour. Plus ces valeurs sont basses, plus la solution est chère : un RTO de quelques minutes impose une réplication permanente vers un second site, un RTO de plusieurs jours se contente de sauvegardes restaurées sur du matériel de remplacement. Ces objectifs se négocient avec la direction et les métiers, pas seulement avec le service informatique.
Étape 3 : choisir la stratégie de reprise
Pour chaque application critique, la stratégie découle du couple RTO/RPO :
- Restauration à partir de sauvegardes : économique, adaptée aux systèmes tolérant une interruption longue.
- Site de secours à froid ou tiède : un environnement prêt à recevoir les données, mais à démarrer et à alimenter.
- Réplication vers un site ou un cloud distant : pour les systèmes à faible RTO et RPO ; elle protège d’une panne matérielle, mais réplique aussi une corruption ou un chiffrement si rien ne l’en empêche.
Étape 4 : des sauvegardes qui survivent à une attaque
Le #StopRansomware Guide de l’agence américaine CISA recommande de conserver des sauvegardes de données critiques hors ligne et chiffrées, et de tester régulièrement leur disponibilité et leur intégrité dans un scénario de reprise après sinistre. La raison est simple : des sauvegardes accessibles depuis le réseau compromis peuvent être chiffrées avec le reste.
La règle empirique dite « 3-2-1 » est largement répandue chez les praticiens : trois copies des données, sur deux supports différents, dont une conservée hors site. Elle ne figure pas dans le guide cité ci-dessus ; retenez-la comme repère, et ajoutez-y une copie isolée du réseau de production. Pensez aussi à sauvegarder ce qui permet de reconstruire : configurations réseau, annuaire, clés de chiffrement, licences, et la documentation du PRA elle-même, stockée ailleurs que sur les serveurs qu’elle sert à relever.
Étape 5 : externaliser sans abandonner la maîtrise
L’externalisation (infogérance, hébergement, cloud) apporte souvent des sauvegardes géographiquement réparties et des infrastructures plus robustes que celles d’une petite structure. Elle déplace toutefois le risque plus qu’elle ne le supprime. Avant de signer, vérifiez :
- que le contrat couvre explicitement la sauvegarde, la restauration et la gestion de crise, avec la plage de disponibilité du support (heures ouvrées ou 24/24) ;
- que les engagements de délai du prestataire sont compatibles avec vos RTO et RPO, et pas seulement avec un taux de disponibilité global ;
- que vous gardez une copie de vos données hors du périmètre du prestataire, au cas où il serait lui-même défaillant ou victime d’une attaque ;
- que la connexion à Internet est redondante, de préférence avec deux liens de nature différente (fibre et 4G/5G, par exemple), faute de quoi un service cloud parfaitement disponible reste inaccessible ;
- la localisation des données et la réversibilité : comment récupérer vos données, et sous quel format, si vous changez de prestataire. Sur ce thème, voir aussi notre article sur les logiciels métiers qui restent sur site.
Étape 6 : rédiger un plan utilisable à 3 heures du matin
Un bon PRA tient en documents courts et actionnables : liste des contacts avec suppléants, critères de déclenchement, ordre de redémarrage des systèmes (réseau et annuaire d’abord, applications ensuite), procédures de restauration pas à pas, accès de secours aux comptes d’administration, et modèle de communication vers les salariés et les clients. Le plan doit pouvoir être exécuté par une personne qui ne l’a pas écrit, sans le support des systèmes tombés en panne : imprimez-en un exemplaire et conservez-en une copie hors ligne.
Étape 7 : tester, car un plan non testé n’est qu’une hypothèse
Le NIST insiste sur les tests, la formation et les exercices : les tests valident les capacités de reprise, la formation prépare les équipes à l’activation du plan, et les exercices révèlent les lacunes de la planification. Son modèle de plan prévoit un test au moins une fois par an. Commencez simplement : restaurer un fichier depuis la sauvegarde, puis une machine entière sur un environnement isolé, en chronométrant le temps réel pour le comparer au RTO annoncé. L’écart entre le RTO théorique et le temps mesuré est le meilleur indicateur de ce qu’il reste à corriger. Mettez le plan à jour à chaque changement important : nouvelle application, changement de prestataire, départ d’une personne clé.
Récapitulatif : les points à retenir
- La sauvegarde ne suffit pas : le PRA décrit comment, dans quel ordre et par qui le système est rétabli.
- Commencez par l’analyse d’impact (BIA) : quelles applications, quel coût d’arrêt.
- Fixez pour chaque application un RTO (durée d’arrêt acceptable) et un RPO (perte de données acceptable).
- Choisissez la stratégie (restauration, site de secours, réplication) selon ces valeurs et le budget.
- Gardez des sauvegardes hors ligne et chiffrées, avec une copie hors site, et testez leur restauration.
- En cas d’externalisation, contractualisez la restauration, la gestion de crise et la réversibilité, et gardez une copie indépendante.
- Rédigez un plan exécutable sans les systèmes en panne, avec une copie hors ligne.
- Testez au moins une fois par an, chronométrez, corrigez, et mettez le plan à jour à chaque évolution.
Les centres de données qui hébergent ces sauvegardes ont leurs propres exigences de sécurité, que nous détaillons dans l’article consacré à la sécurité des datacenters.