Un plan de reprise d’activité, tout le monde en parle. Peu d’entreprises en ont un vraiment prêt. Et quand il existe, il ressemble souvent à un classeur poussiéreux que personne n’ouvre en dehors des audits. Pendant ce temps, la réalité est là : une panne sérieuse, une cyberattaque, un incendie, et l’activité s’arrête net. Les clients attendent, les équipes s’impatientent, la direction cherche des réponses.
Le but d’un PRA n’est pas d’ajouter une couche de complexité ni de remplir des pages de procédures que personne ne lira. C’est de donner à l’entreprise un réflexe simple : comment redémarrer vite, avec le moins de pertes possible. En clair, poser noir sur blanc : quels systèmes doivent repartir en premier, combien de temps l’entreprise peut tenir sans eux, et combien de données elle est prête à perdre.
Ce guide n’est pas fait pour transformer votre DSI en usine à gaz. Il est là pour ramener le PRA à l’essentiel : une approche pragmatique, des objectifs clairs (RTO, RPO), des sauvegardes fiables, des scénarios de bascule réalistes, et surtout des tests réguliers. L’ANSSI le répète : une sauvegarde non testée n’est pas une sauvegarde. Une reprise non testée, c’est pareil : elle n’existe pas.
Dans les lignes qui suivent, vous trouverez une méthode simple pour bâtir un PRA efficace, compréhensible et actionnable.
PRA vs PCA : clarifier le duo continuité/reprise
On confond souvent les deux. Pourtant, un PRA n’est pas un PCA.
Le PCA (plan de continuité d’activité), c’est ce qui empêche l’entreprise de s’arrêter net. Une panne survient, une salle serveur tombe, mais les services critiques continuent de tourner sur un autre site, dans le cloud ou en mode dégradé. Les collaborateurs travaillent encore, les clients ont toujours un service minimum.
Le PRA (plan de reprise d’activité), lui, intervient quand tout est bel et bien à l’arrêt. L’activité est coupée, les systèmes sont indisponibles, les données inaccessibles. Le PRA, c’est l’organisation qui permet de restaurer les environnements, de redémarrer les applications, de rétablir les opérations. En clair : remettre l’entreprise sur ses rails.
Les deux approches se complètent. La norme ISO 22301 encadre la continuité (PCA), tandis que l’ISO/IEC 27031:2025 donne le cadre pour la reprise informatique (PRA). Prévenir d’un côté, réparer de l’autre.
Pour une PME, l’important n’est pas de jouer au juriste mais d’être lucide : il faut souvent un peu de continuité (ne pas couper les mails ou la téléphonie), et un vrai plan de reprise pour restaurer les systèmes essentiels après une crise.
Pour résumer : le PCA fait tenir, le PRA fait repartir.
Partir du métier : un BIA léger pour prioriser
Avant de parler serveurs, sauvegardes ou cloud, il faut se poser une question simple : qu’est-ce qui casse l’entreprise si ça s’arrête ? Pas besoin d’un audit de 200 pages ou d’un cabinet de conseil hors de prix. Ce qu’il faut, c’est une hiérarchie claire : quels processus sont vitaux, lesquels peuvent attendre, et combien de temps.
Le Business Impact Analysis (BIA) est souvent présenté comme un exercice lourd. En réalité, il peut tenir en quelques ateliers bien menés :
- Lister les activités critiques : facturation, commande en ligne, support client, paie…
- Identifier ce qui les alimente : quelles applications, quelles bases de données, quels serveurs, quels prestataires.
- Estimer l’impact d’une coupure : perte financière, image écornée, contrainte réglementaire.
Le but n’est pas la précision chirurgicale mais la lisibilité. En une page, vous devez pouvoir répondre : si tout tombe demain, qu’est-ce qu’on doit relever en premier, et qu’est-ce qui peut attendre 24 ou 48 heures.
La norme ISO 22301 recommande cette approche pour bâtir un PCA/PRA cohérent, et la directive NIS2 impose aux entreprises critiques de savoir hiérarchiser leurs services essentiels. Mais même sans obligation réglementaire, cet exercice est salutaire : il évite de perdre du temps à protéger des applications secondaires quand l’essentiel brûle.
Besoin d’un audit PRA & sauvegardes ?
Un PRA solide commence toujours par une réalité simple : des sauvegardes fiables, testées, et accessibles en cas de crise. Beaucoup d’entreprises pensent être prêtes… jusqu’au jour où la restauration échoue.
Chez ASAP, nous réalisons un audit complet de vos sauvegardes et de votre plan de reprise :
- vérification de l’exploitabilité des sauvegardes,
- analyse de vos objectifs RTO/RPO,
- recommandations concrètes pour renforcer la résilience de votre système d’information.
RTO / RPO : mettre des chiffres sur la reprise
Quand une panne frappe, deux questions surgissent aussitôt : combien de temps peut-on rester à l’arrêt ? Et combien de données peut-on se permettre de perdre ? Ces deux réponses portent un nom : RTO (Recovery Time Objective) et RPO (Recovery Point Objective).
Le RTO, c’est la durée maximale d’interruption tolérable pour un service ou une application. Est-ce que vos clients peuvent attendre deux heures sans commande en ligne ? Vos salariés, une journée sans paie ? Le chiffre doit être explicite, pas implicite.
Le RPO, c’est la perte de données acceptable en cas de reprise. Un CRM qui perd 10 minutes d’interactions peut survivre. Une banque qui perd une journée de transactions, non. Là encore, l’objectif doit être écrit noir sur blanc.
Pour être utile, RTO et RPO doivent être fixés par activité métier. Un même système peut héberger plusieurs applications, chacune avec ses exigences. L’ERP peut supporter 12 heures de coupure, la messagerie seulement deux.
Les grands clouds comme AWS ou Azure proposent des modèles clairs pour relier vos objectifs à des architectures concrètes : sauvegardes simples, réplication à chaud, sites de secours.
Une fois les chiffres posés, la discussion change : on ne parle plus en généralités, mais en objectifs mesurables. Et c’est ce qui fait toute la différence le jour où la DSI doit arbitrer.
Choisir l’architecture PRA sans sur-ingénierie
Tout le monde rêve d’un système qui ne tombe jamais. Dans la vraie vie, ça coûte trop cher et ça complexifie tout. La clé d’un PRA efficace, c’est de choisir une architecture adaptée à vos besoins… et à vos moyens.
Les options se situent sur un spectre assez simple :
- Backup & Restore : la méthode la plus basique. On sauvegarde, on stocke ailleurs, on restaure en cas de crash. RTO et RPO élevés, mais coûts faibles. Convient aux services non vitaux ou aux petites structures.
- Pilot Light : on garde une version minimale des systèmes critiques prête à être rallumée. Le redémarrage est plus rapide, mais nécessite de tester régulièrement que tout repart bien.
- Warm Standby : une copie réduite de la prod tourne en continu, prête à prendre le relais. C’est un bon compromis entre budget et temps de reprise.
- Multi-site Active/Active : le Graal, mais aussi le plus lourd. Deux sites (ou plus) fonctionnent en parallèle. Bascule immédiate, quasi zéro interruption… mais une complexité et des coûts que peu d’entreprises peuvent absorber.
Amazon Web Services ou Microsoft Azure décrivent bien ce continuum de stratégies. Ce n’est pas réservé aux grands groupes : un directeur informatique de PME peut s’en inspirer pour cadrer ses choix, plutôt que de copier-coller des solutions disproportionnées.
L’important est d’assumer vos arbitrages. Mieux vaut un plan simple qui marche qu’une architecture “idéale” jamais testée.
Sauvegardes solides = fondation du PRA
Un PRA sans sauvegarde fiable, c’est une coquille vide. Tout repose là-dessus : sans copie exploitable de vos données, aucun scénario de reprise ne tient la route. Et dans la pratique, c’est souvent le point faible.
L’ANSSI le martèle : une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde. Trop d’entreprises découvrent, en pleine crise, que leurs disques externes étaient corrompus ou que la restauration ne fonctionne pas.
Quelques règles simples suffisent à renforcer vos sauvegardes :
- Varier les supports et les emplacements (3 copies, 2 types de supports, 1 copie hors site, 1 isolée ou immuable).
- Durcir l’accès : un ransomware qui chiffre les serveurs peut aussi s’attaquer aux sauvegardes si elles sont connectées en permanence.
- Programmer des tests réguliers : restauration partielle toutes les semaines, restauration complète tous les trimestres.
- Superviser : une sauvegarde qui plante sans alerte est aussi dangereuse qu’une absence de sauvegarde.
Ces principes ne relèvent pas de la haute science. Ils relèvent de la discipline. Ce sont eux qui font la différence entre une entreprise qui repart après une panne, et une autre qui reste à l’arrêt faute de données récupérables.
Gouvernance de crise : préparer, tester, apprendre
Un PRA n’existe pas seulement dans un document PDF rangé dans un dossier. Le jour de la crise, ce qui compte, c’est la capacité des équipes à réagir sans paniquer et à suivre un fil déjà répété. C’est là que la gouvernance fait la différence.
Exercices de crise : répéter pour ne pas improviser
La meilleure façon de savoir si un plan tient, c’est de le tester. Pas une fois tous les trois ans pour cocher une case, mais régulièrement, avec des scénarios réalistes : coupure totale du datacenter, ransomware, perte d’un fournisseur clé. L’ANSSI insiste : c’est l’entraînement qui transforme un plan en réflexe.
Un exercice peut être simple : simuler la restauration d’un serveur critique ou la bascule sur un lien secondaire. L’essentiel est d’impliquer les équipes et de vérifier que les gestes sont connus, pas seulement écrits quelque part.
RETEX : transformer chaque incident en progrès
Chaque test, chaque panne, chaque alerte doit laisser une trace utile. C’est le retour d’expérience (RETEX). On note ce qui a fonctionné, ce qui a coincé, et on ajuste. Ce n’est pas une punition, c’est une méthode.
Un PRA qui vit, c’est un plan qui se réécrit un peu à chaque exercice. Les normes comme l’ISO 22361 sur la gestion de crise vont dans ce sens : gouvernance, communication et amélioration continue.
En bref, un plan non testé reste théorique. Un plan testé et amélioré devient un réflexe collectif. Et c’est cette différence qui sauve l’entreprise quand la crise éclate.
Cloud & PRA : opportunité ou dépendance ?
Le cloud a changé la donne. Avant, un PRA signifiait souvent une deuxième salle serveur, coûteuse et rarement utilisée. Aujourd’hui, des services comme Azure Site Recovery ou les modèles de disaster recovery AWS permettent de répliquer des systèmes et de basculer en quelques clics. Pour une PME, c’est la promesse d’éviter l’investissement d’un second site et de disposer d’outils testés à grande échelle.
Mais attention à l’illusion. Le cloud n’est pas un PRA clé en main. Les responsabilités sont partagées : l’infrastructure est gérée par le fournisseur, mais la planification, les tests et la documentation restent du ressort de l’entreprise. Trop de DSI découvrent trop tard que la bascule ne fonctionne pas parce qu’aucun runbook n’a été écrit, ou que les droits d’accès bloquent la restauration.
La documentation, le maillon qu’on oublie
Quel que soit l’outil choisi, il faut un guide simple. Pas un manuel de 100 pages, mais une fiche pratique par application :
- qui déclenche la reprise,
- où se trouvent les sauvegardes ou réplicas,
- quelles étapes pour relancer le service,
- quels tests pour vérifier que tout fonctionne.
Ce n’est pas glamour, mais c’est vital. Sans cette documentation minimale, le cloud ne sauvera rien.
Le cloud apporte donc vitesse et flexibilité, mais il ne dispense pas de rigueur. C’est un levier puissant, à condition d’en garder la maîtrise.
Conclusion : un PRA utile, pas un classeur
Un PRA ne doit pas être un document qui prend la poussière. Il doit vivre dans les mains de ceux qui, un jour, devront l’utiliser. Sa valeur n’est pas dans les pages écrites mais dans les réflexes qu’il crée : savoir quoi relancer, dans quel ordre, et avec quels moyens.
Pas besoin d’un plan complexe réservé aux grands groupes. Ce qu’il faut, c’est de la lucidité : identifier vos activités vitales, fixer des objectifs de reprise réalistes, choisir une architecture adaptée (sauvegarde, réplication, cloud), et tester jusqu’à ce que les gestes deviennent naturels.
Chez ASAP, nous aidons les entreprises à bâtir des PRA clairs et actionnables : pas de jargon, pas de sur-ingénierie, mais un plan qui tient debout quand la crise frappe.
FAQ – PRA informatique : vos questions fréquentes
Quelle est la différence entre PRA et PCA ?
Le PRA (Plan de Reprise d’Activité) sert à restaurer les systèmes informatiques et redémarrer l’activité après un arrêt complet. Le PCA (Plan de Continuité d’Activité) vise à maintenir un niveau de service même en cas d’incident. Les deux sont complémentaires. L’ISO 22301 encadre la continuité, tandis que l’ISO/IEC 27031:2025 se concentre sur la reprise informatique.
Comment définir des RTO et RPO réalistes ?
Le RTO (Recovery Time Objective) est le temps maximal d’interruption acceptable. Le RPO (Recovery Point Objective) correspond à la perte de données tolérable. On les définit en fonction des processus métier : la messagerie peut supporter deux heures d’arrêt, la paie non. Des guides comme ceux d’AWS donnent des exemples clairs pour aligner objectifs et architecture.
À quelle fréquence faut-il tester un PRA ?
L’ANSSI recommande de tester régulièrement les sauvegardes (restaurations partielles et complètes) et de réaliser des exercices de crise au moins une fois par an. L’objectif : éviter l’improvisation et vérifier que le plan est réellement opérationnel.
Un simple backup cloud suffit-il comme PRA ?
Non. Une sauvegarde est nécessaire, mais pas suffisante. Un PRA inclut aussi l’orchestration de la reprise, la gestion des accès, la documentation et les tests. Sans plan de bascule, un backup seul rallonge les délais de reprise et peut mettre l’activité en danger.
Quelles obligations impose NIS2 en matière de PRA ?
La directive NIS2 renforce les exigences de continuité et de gestion de crise pour les entreprises critiques et opérateurs de services essentiels. Même les PME de certains secteurs (santé, énergie, transport, numérique) devront démontrer qu’elles disposent d’un PRA testé et documenté.
Et pour les établissements de santé ou médico-sociaux (ESMS) ?
L’Agence du Numérique en Santé et les ARS diffusent des kits PRA/PCA adaptés aux hôpitaux et ESMS, avec financement via le programme CaRE. Ces structures doivent garantir la disponibilité des données patients et la traçabilité des soins, ce qui rend le PRA encore plus critique.
