Des solutions IT
pour un monde
plus performant
Des solutions IT
pour un monde
plus performant
Un sinistre informatique majeur ne prévient pas. Ransomware, panne de datacenter, incendie : quelle que soit la cause, la question n’est pas de savoir si votre entreprise sera un jour confrontée à une interruption critique, mais dans quel état sera votre SI au moment où cela surviendra. C’est précisément la raison d’être du plan de reprise d’activité.
Le plan de reprise d’activité (PRA) est un document opérationnel qui définit comment votre entreprise rétablira son système d’information après un incident grave. Il décrit les procédures, les responsabilités, les ressources techniques et la séquence d’actions nécessaires pour restaurer vos systèmes dans un délai acceptable et avec un niveau de perte de données maîtrisé.
Le PRA est un outil avant tout technique : il concerne vos infrastructures, vos applications, vos données et vos réseaux. Il répond à une question précise : comment remettre le SI en état de fonctionner après un sinistre majeur ? Il ne couvre pas, en revanche, l’organisation humaine de crise ni les processus métier en mode dégradé : c’est le rôle du plan de continuité d’activité.
PRA et PCA sont fréquemment confondus, parfois utilisés de façon interchangeable. Ils sont complémentaires, mais distincts dans leur périmètre et leurs objectifs.
Le plan de continuité d’activité (PCA) traite la résilience de l’entreprise dans sa globalité : ressources humaines, locaux, fournisseurs, processus métier. Il anticipe comment votre organisation fonctionnera en mode dégradé, quelle que soit la nature du sinistre. Le PCA organise les priorités de reprise, les délégations de décision, les modes d’organisation alternatifs. Il peut couvrir des scénarios sans composante informatique directe (indisponibilité de locaux, pandémie, crise fournisseur majeur).
Notre article sur la continuité d’activité et le PCA détaille ce périmètre organisationnel.
Le plan de reprise d’activité est le volet technique du PCA. Il ne traite pas l’organisation humaine ni les processus métier, mais la restauration des systèmes informatiques après un sinistre majeur. C’est une feuille de route d’intervention technique : quels serveurs remonter en premier, dans quel ordre, avec quels outils, en combien de temps, et jusqu’à quel niveau de perte de données peut-on descendre.
Le PRA se construit au niveau de chaque système ou application critique, avec des objectifs de reprise mesurables définis en amont.
Un PCA sans PRA revient à organiser la continuité métier sur un SI hors d’état de fonctionner. Un PRA déconnecté du PCA produit des plans techniques sans cohérence avec les priorités réelles de l’entreprise : les équipes techniques peuvent rebâtir en premier des systèmes dont les métiers n’ont pas besoin immédiatement.
Les deux plans doivent être conçus conjointement, en associant les responsables de processus métier et les équipes techniques dès la phase d’analyse. C’est cette articulation qui détermine la solidité d’un dispositif de résilience.
Le Recovery Time Objective désigne la durée maximale tolérée entre la survenue d’un incident et le rétablissement du service. Il exprime combien de temps votre activité peut fonctionner sans tel ou tel système informatique. Un ERP critique ou un outil de traitement des paiements aura un RTO court, chaque heure perdue ayant un impact direct et mesurable. Un système d’archivage documentaire supportera un RTO sensiblement plus long.
Le RTO se fixe système par système, jamais de façon uniforme sur l’ensemble du SI.
Le Recovery Point Objective définit la quantité maximale de données que votre entreprise peut perdre sans conséquences inacceptables, exprimée en durée. Un RPO de 4 heures signifie qu’en cas de sinistre, vous acceptez de ne pas récupérer les données produites dans les 4 heures précédant l’incident. Ce chiffre conditionne directement la fréquence de vos sauvegardes et la nature de vos mécanismes de réplication.
Le RPO est intimement lié à votre stratégie de sauvegarde. Une politique de sauvegarde 3-2-1-1-0 bien construite est la fondation sur laquelle repose tout RPO réaliste et tenable.
La définition du RTO et du RPO ne doit pas partir de ce que votre infrastructure peut techniquement offrir. Elle doit partir de ce que vos métiers peuvent réellement accepter de perdre ou d’attendre. Cela suppose d’interroger les directions opérationnelles, les responsables de processus clés et la direction générale, puis de confronter leurs attentes à la réalité des coûts et de la complexité des solutions techniques associées.
À savoir : Plus le RTO et le RPO sont courts, plus la solution technique est coûteuse et complexe à opérer. Il n’existe pas de valeurs universellement applicables : tout dépend de votre activité, de votre tolérance au risque et de votre budget. L’enjeu est de trouver le bon équilibre pour votre entreprise, pas de viser les meilleures métriques sur le papier.
Un PRA sérieux ne se construit pas sur un scénario unique. La liste des événements à anticiper dépend du contexte de chaque entreprise, mais certains scénarios sont devenus incontournables pour toute PME ou ETI :
🔴 Cyberattaque de type ransomware : chiffrement massif des données et des systèmes, qui constitue aujourd’hui la menace la plus couramment couverte par les PRA. Le vecteur de restauration repose ici sur la sauvegarde immuable et hors ligne.
🔴 Panne matérielle majeure : défaillance d’un serveur, d’un SAN ou d’un équipement réseau critique, sans possibilité de redémarrage rapide.
🔴 Sinistre physique : incendie, dégât des eaux, coupure électrique prolongée touchant votre site principal.
🔴 Erreur humaine : suppression accidentelle de données, fausse manipulation en production, restauration sur le mauvais environnement.
🔴 Indisponibilité d’un fournisseur cloud : panne d’un hébergeur ou d’un éditeur SaaS critique pour votre activité.
L’analyse de risques informatiques réalisée en amont permet de hiérarchiser ces scénarios selon leur probabilité et leur impact, et d’orienter les priorités de votre PRA. Votre stratégie de maintien en conditions de sécurité (MCS) contribue à réduire la probabilité de plusieurs d’entre eux.
La construction d’un PRA opérationnel suit une séquence logique, chaque étape conditionnant la suivante.
Le Business Impact Analysis est le socle de tout PRA. Il vise à identifier les processus métier critiques, leurs dépendances informatiques, et les conséquences d’une interruption dans le temps. À l’issue de la BIA, chaque application ou système critique est associé à un RTO et un RPO, validés par les directions métier concernées. Cette étape doit impérativement associer les responsables de processus et les équipes techniques : sans ce dialogue, les objectifs fixés seront soit inatteignables, soit sous-calibrés.
Tous vos systèmes n’ont pas besoin du même niveau de protection. La stratégie de reprise classe les applications par niveau de criticité et détermine, pour chacune, le mécanisme le plus adapté : sauvegarde classique avec restauration, réplication, basculement vers un site de secours. Le coût de chaque option doit être mis en regard de l’impact réel d’une interruption, pour aboutir à des arbitrages cohérents et budgétairement soutenables.
Cette étape traduit la stratégie en architecture technique concrète : emplacement et capacité du site de secours, mécanismes de réplication retenus, infrastructure réseau d’urgence, accès distants sécurisés, disponibilité des licences logicielles sur le site cible. Elle implique des choix structurants sur vos infrastructures et une coordination avec votre stratégie de sauvegarde et d’hébergement cloud.
Le PRA doit être utilisable par une équipe technique sous pression, parfois en dehors des horaires habituels, parfois par des intervenants extérieurs. Les procédures doivent être précises, séquencées et sans ambiguïté : qui fait quoi, dans quel ordre, avec quels droits d’accès, en cas d’indisponibilité de quel interlocuteur. La documentation doit comporter un annuaire de contacts actualisé, les schémas d’architecture, et les accès aux outils de sauvegarde et de monitoring.
Un PRA rédigé mais non testé est un PRA fictif. La validation du plan passe par des exercices réguliers, documentés, dont les résultats sont analysés et exploités pour améliorer le dispositif en continu.
C’est l’approche la plus répandue. Des sauvegardes régulières sont stockées sur un support séparé (local, hors site ou cloud), et la reprise d’activité consiste à restaurer les données et systèmes à partir de ces copies. Le RTO est généralement plus long (quelques heures à quelques jours selon les volumes et la nature des systèmes), mais le modèle reste accessible en termes de coût. La qualité du RPO dépend directement de la fréquence des sauvegardes et du respect de la règle 3-2-1-1-0, qui prévoit notamment une copie immuable hors ligne, condition indispensable face aux ransomwares.
La réplication consiste à dupliquer les données en temps réel ou quasi-réel vers un site secondaire. En mode synchrone, chaque écriture est simultanément validée sur les deux sites : le RPO approche zéro, mais les contraintes de latence réseau sont importantes. En mode asynchrone, la réplication s’effectue avec un léger décalage : le RPO se mesure en minutes plutôt qu’en secondes, ce qui est compatible avec des liaisons réseau plus standards. Ces approches sont adaptées aux systèmes critiques dont le RTO doit être très court.
Trois niveaux de site de secours répondent à des ambitions différentes :
🔵 Site chaud : l’infrastructure de secours est opérationnelle en permanence, synchronisée avec la production. Le basculement est quasi-instantané. Coût élevé, justifié pour les systèmes dont toute interruption est inacceptable.
🔵 Site tiède : l’infrastructure existe, mais doit être activée et configurée avant utilisation. Délai de quelques heures. Compromis coût/délai souvent adapté aux PME et ETI.
🔵 Site froid : seule la capacité d’hébergement est réservée. L’ensemble de l’environnement reste à installer. Délai de plusieurs jours. Pertinent pour les systèmes non critiques dont le RTO est long.
Le choix découle directement du RTO cible défini lors de la BIA.
Le Disaster Recovery as a Service (DRaaS) désigne les offres de PRA hébergées dans le cloud, proposées sous forme de service managé. L’infrastructure de secours est hébergée chez un fournisseur cloud et peut être activée rapidement en cas de sinistre. Les avantages sont réels : pas d’investissement lourd en infrastructure de secours propre, grande agilité de déploiement, facturation à l’usage, et une testabilité généralement simplifiée par rapport à un site de secours physique.
Il convient d’en évaluer également les limites avant tout engagement. La dépendance à un fournisseur unique peut introduire un point de vulnérabilité supplémentaire. Les coûts récurrents peuvent dépasser sur la durée ceux d’une infrastructure en propre, selon les volumes et la fréquence d’activation. La complexité de réversibilité, c’est-à-dire la capacité à rapatrier vos données et à changer de fournisseur, doit être analysée contractuellement dès le départ.
À savoir : Le DRaaS n’est pas une solution universelle. Les entreprises gérant des données sensibles ou soumises à des contraintes de souveraineté doivent évaluer attentivement le choix du fournisseur, la localisation des données de secours et les conditions de sortie du contrat. Notre page dédiée à la sécurité aborde ces enjeux.
Un plan de reprise d’activité qui n’a jamais été testé ne tient pas. C’est la règle la plus importante, et la plus souvent contournée. Un PRA non testé repose sur des hypothèses : que les sauvegardes sont restaurables dans les délais prévus, que les procédures sont comprises et utilisables sous pression, que les accès fonctionnent, que les RTO sont tenables. Un test confronte ces hypothèses à la réalité.
Trois niveaux de test, complémentaires, permettent de valider progressivement le dispositif :
📋 L’exercice sur table (tabletop exercise) : simulation théorique sans manipulation technique. Les équipes jouent le scénario de crise, identifient les manques documentaires et les zones d’incertitude. Peu coûteux et organisable à intervalles réguliers.
🔧 Le test partiel : une partie du plan est exécutée techniquement dans un environnement isolé : restauration de certains systèmes, basculement d’une application non critique. Il permet de valider des briques du dispositif sans risque pour la production.
🚨 Le test de basculement complet : l’ensemble du dispositif est activé sur le site de secours dans des conditions proches du réel. Exigeant en ressources, il doit être planifié avec soin, mais c’est le seul moyen de valider le PRA de bout en bout.
Chaque exercice doit faire l’objet d’un rapport documenté : délais constatés versus objectifs, écarts identifiés, actions correctives planifiées. Le PRA est un document vivant : il évolue avec votre SI, avec l’apparition de nouvelles applications critiques, avec les retours de tests successifs.
La fréquence minimale à retenir : un test complet annuel, complété par des exercices partiels ou sur table plus fréquents selon la criticité de vos activités. Les exigences contractuelles ou assurantielles peuvent imposer un rythme plus soutenu.
Le maintien en conditions opérationnelles (MCO) de votre infrastructure contribue également à la robustesse du dispositif : un PRA s’appuie sur des composants techniques qui doivent rester fiables dans le temps, indépendamment des scénarios de crise.
Depuis plus de 20 ans, nos équipes techniques accompagnent des PME et ETI dans la conception, la mise en œuvre et les tests de leurs plans de reprise d’activité. Un PRA solide ne se décrète pas : il se construit dans la durée, en partant des besoins métier et en maintenant le dispositif vivant.