Un lundi matin, le serveur ne redémarre pas. Panne, incendie, dégât des eaux ou rançongiciel, la cause change peu de choses, deux questions tombent aussitôt. Combien de temps l’entreprise va rester à l’arrêt, et combien de travail déjà fait va disparaître. Comme prestataire informatique pour PME, ce sont les deux questions qu’on nous pose. Cet article définit le PCA et le PRA, explique les indicateurs RPO et RTO, donne une méthode en trois temps pour bâtir votre plan, puis montre un cas réel de reprise sous 4 heures dans un cabinet d’avocats.
Quelle différence entre PCA et PRA ?
Les deux termes reviennent dans bien des devis, et on les confond souvent. Le guide méthodologique du ministère de la Transition écologique les distingue pourtant clairement.
Le PCA, Plan de Continuité d’Activité, regroupe les mesures prévues pour maintenir une activité minimale, ou dégradée, des missions les plus sensibles après qu’un incident les a interrompues. Le mode dégradé désigne un fonctionnement qui ne rend pas toutes ses fonctions, ou qui les rend avec des performances inférieures à la normale. Le PRA, Plan de Reprise d’Activité, regroupe les mesures prévues pour rétablir l’activité une fois l’incident passé.
Autrement dit, le PCA vise ce qui continue de fonctionner, même au ralenti, le PRA vise le retour à la normale.
| Critère | PCA | PRA |
|---|---|---|
| Objectif | Maintenir une activité minimale ou dégradée des missions sensibles | Rétablir l’activité après l’incident |
| Ce qu’il contient | Les mesures de fonctionnement en mode dégradé | Les mesures de reprise de l’activité |
| Indicateur pilote | Les missions maintenues et le niveau de service accepté en mode dégradé | La PDMA et la DMIA, c’est-à-dire le RPO et le RTO |
Ces deux plans ne s’opposent pas, ils se complètent. Dans une crise réelle, les deux démarches se chevauchent, la reprise s’engage pendant que la continuité tient.
Que signifient RPO et RTO ?
Deux indicateurs pilotent un PRA. Le RPO, Recovery Point Objective, chiffre le volume de production que votre entreprise consent à sacrifier. On le compte en durée, depuis la dernière sauvegarde encore exploitable. Le RTO, Recovery Time Objective, borne le temps au bout duquel un service doit avoir repris.
Le guide méthodologique du ministère emploie des équivalents français. Il nomme PDMA, Perte de Données Maximale Acceptée, ce que couvre le RPO, et DMIA, Durée Maximale d’Interruption Acceptable, ce que l’activité tolère. Le RTO, qui vise la reprise du service, se fixe en dessous de cette durée.
En pratique, ces durées se traduisent très concrètement. Une sauvegarde chaque nuit donne un RPO d’une journée au plus, puisque tout ce qui a été produit depuis la dernière copie peut disparaître. Un serveur miroir répliqué toutes les 2 heures ramène ce RPO à 2 heures. Ces objectifs ne tiennent que si la copie a bien abouti et se restaure, d’où les contrôles et les tests décrits plus bas. Le RTO, lui, ne tient pas qu’à la sauvegarde. Il découle du scénario de reprise retenu. Reconstruire les données sur du matériel neuf demande plus de temps qu’un redémarrage lancé directement en datacenter.
Ces deux chiffres se fixent application par application. La messagerie et le logiciel métier n’ont pas le même RTO que l’archivage. Une boîte mail hors service bloque le travail en quelques minutes, une archive consultée une fois par mois peut attendre.
Comment construire un PRA pour une PME ?
La démarche tient en trois temps. Elle ne réclame ni direction informatique interne (DSI) ni consultant à plein temps, mais un prestataire qui connaît votre infrastructure et un dirigeant qui tranche. C’est le travail que nous menons pour les PME que nous accompagnons en infogérance en Essonne.
Lister ce qui ne peut pas s’arrêter
Tout commence par un inventaire. Quelles activités ne supportent pas l’arrêt, et quelles applications les portent. La messagerie, le logiciel métier et les fichiers partagés arrivent presque toujours en tête. Vient ensuite l’évaluation des risques réels pour l’entreprise, une panne matérielle, un incendie, un dégât des eaux, un vol, un rançongiciel. Chacun n’a ni la même probabilité ni le même impact. Enfin, vous définissez un ordre de redémarrage, car tout ne peut pas repartir en même temps. Ce travail porte un nom, l’analyse d’impact. Elle sert aussi bien au PRA qu’au PCA, puisque les deux s’appuient dessus.
Fixer un RPO et un RTO par application
À cette étape, le dirigeant décide et le prestataire traduit. Un RPO court impose une réplication fréquente des données. Un RTO court impose de pouvoir redémarrer ailleurs, sans attendre le rapatriement complet des données. Chaque exigence a un coût, et c’est pourquoi elle se discute application par application. Le socle de tout cela reste la sauvegarde externalisée, la copie qui existe encore le jour où votre site est touché. En option, elle peut être rendue immuable, c’est-à-dire impossible à modifier ou à effacer, une protection utile contre les rançongiciels dont le principe est détaillé sur notre page sauvegarde immuable anti-rançongiciel.
Choisir le scénario de reprise et le tester
Une fois les objectifs fixés, reste à choisir comment on redémarre. Un scénario de reprise se résume à deux questions, depuis quelle copie on repart et sur quelle machine on repart. Les réponses découlent directement du RTO et du RPO fixés à l’étape précédente, et les scénarios détaillés sont décrits sur notre page de sauvegarde externalisée.
Ce choix se décide en amont du sinistre, jamais dans l’urgence. Rédigé et daté, le plan répond à ces deux questions et nomme les responsables, celui qui lance la bascule et ceux qu’on prévient. Il doit faire l’objet d’un essai au minimum annuel. Dernier point, gardez une copie papier des procédures et des numéros utiles, hors du réseau. Le jour d’un rançongiciel, vous n’ouvrez plus le partage de fichiers, et un plan enfermé dans le système en panne ne sert à rien.
Exemple, une reprise sous 4 heures chez un cabinet d’avocats
Prenons un cas que nous avons mené puis publié, raconté en détail sur la page consacrée à ce cabinet d’avocats. Le cabinet nomme ce dispositif un PCA sur sa page, dans les termes du guide il s’agit d’une reprise, les deux mots cohabitent dans le métier. Un cabinet juridique d’une quinzaine de collaborateurs, dont le métier est le droit des affaires, cherchait à remplacer un serveur vieillissant. Sa demande ne laissait pas de place au flou, tout devait repartir intégralement en moins de 4 heures après un sinistre, avec au maximum 2 heures de données perdues. S’y greffaient deux exigences fermes, pas de stockage dans le cloud et des données gardées sur le sol français.
Nous sommes partis sur une architecture à deux serveurs. L’un, principal, installé dans les locaux du cabinet, l’autre, miroir, hébergé en datacenter dans une baie que nous administrons. Les données sont recopiées toutes les 2 heures, une approche que nous avons privilégiée face à un cluster en haute disponibilité pour contenir le budget. La bascule reste manuelle et consignée, l’accès empruntant un réseau privé virtuel (VPN).
Le contrat fixe un engagement de redémarrage sous 4 heures et la mise en place s’est déroulée sans coupure notable. L’essai grandeur nature, d’abord différé pendant deux ans pour des raisons métier, a finalement eu lieu lors d’un déménagement du cabinet. Toute l’infrastructure a migré sur le serveur secondaire en datacenter, puis a été rétablie dans les nouveaux locaux.
Questions fréquentes
Combien coûte un PRA ?
Cela dépend. Le prix suit le RTO et le RPO que vous retenez, ainsi que le scénario de reprise choisi. Un simple rapatriement de données coûte moins qu’un serveur miroir répliqué à intervalle rapproché. Le chiffrage se fait après un état des lieux de votre infrastructure, impossible à donner sérieusement sans lui.
À quelle fréquence tester le plan ?
Au moins une fois par an, et après chaque évolution marquante de votre informatique. Un nouveau logiciel métier, une migration, un changement de serveur, autant d’occasions de revérifier que le plan tient toujours. La réalité fait parfois reporter l’essai complet, comme dans le cas raconté plus haut où il a attendu deux ans, et le plan s’en trouve d’autant plus fragile. Un plan jamais testé n’est pas un plan, c’est une intention.
Le cloud dispense-t-il d’un PRA ?
Non. Un service en ligne peut lui aussi devenir indisponible, ou se retrouver chiffré par un rançongiciel. Vos données Microsoft 365, par exemple, se sauvegardent à part, un point que détaille notre page sauvegarde Microsoft 365. Le cloud change le scénario de reprise, il ne remplace jamais le plan.
Faut-il un PCA ou un PRA en premier ?
Les deux partent de la même analyse de ce qui est critique. Pour une PME, le PRA informatique se construit souvent en premier, parce qu’il porte la sauvegarde et le redémarrage, le cœur de la reprise. Le PCA vient ensuite et élargit aux locaux, aux personnes et aux procédures dégradées.
Le PCA et le PRA sont-ils obligatoires ?
Il n’existe pas de loi générale qui l’impose à toute PME. En revanche, les entités visées par la directive NIS2, dans les secteurs régulés, doivent prévoir des mesures de continuité, de gestion des sauvegardes, de reprise et de gestion de crise, et la directive DORA fait de même pour le secteur financier. Pour les autres, l’ANSSI conseille à toutes les organisations de disposer d’un PCA robuste aux cyberattaques et d’un PRA, et de s’entraîner par des exercices de gestion de crise. Au-delà de cette recommandation, c’est surtout votre capacité à survivre à un sinistre qui se joue là.
