Un PRA informatique organise la remise en service du système d’information après une interruption importante. Il relie les besoins des métiers à des moyens techniques, des responsabilités et des procédures de restauration vérifiables. Une copie de sauvegarde est un élément du dispositif : elle ne prouve pas, à elle seule, que les applications, les accès et les échanges entre systèmes pourront redémarrer dans le délai attendu.
La démarche commence donc par une question concrète : quel service doit fonctionner de nouveau, avec quelles données et dans quel état acceptable ? Ce guide explique comment définir les objectifs, choisir une architecture, préparer les décisions de crise et établir un budget fondé sur votre situation. Les chiffres proposés comme exemples sont hypothétiques ; ils ne constituent ni des prix de marché ni une garantie de performance.
Délimiter le PRA et son articulation avec le PCA
Le plan de continuité d’activité organise la poursuite des activités prioritaires, éventuellement en mode dégradé. Le PRA se concentre ici sur le rétablissement informatique. Les deux doivent se rejoindre : restaurer le logiciel de commandes ne suffit pas si les équipes ne peuvent pas retrouver les commandes prises manuellement pendant l’arrêt.
Définissez les scénarios couverts : perte d’un serveur, indisponibilité d’un site, compromission des comptes d’administration, corruption d’une base ou disparition d’un fournisseur. Une architecture qui résiste à une panne matérielle ne résiste pas nécessairement à une suppression volontaire répliquée sur tous ses sites. Chaque scénario doit préciser les fonctions affectées, les moyens encore utilisables et l’autorité qui peut déclencher la reprise.
Rattachez ce périmètre à la politique de sécurité des systèmes d’information. La direction valide les activités prioritaires et les risques résiduels ; les métiers définissent le service acceptable ; l’équipe informatique décrit les moyens et leurs limites. Cette répartition évite de transformer une préférence technique en engagement commercial que personne n’a approuvé.
RTO, RPO et durée d’interruption métier
Le RTO, ou objectif de délai de reprise, correspond au délai visé pour restaurer une ressource ou un service défini. Le RPO, ou objectif de point de reprise, désigne le point dans le passé jusqu’auquel les données doivent pouvoir être récupérées. Un RPO de deux heures signifie, dans cet exemple, que l’organisation accepte au maximum de revenir à un état vieux de deux heures ; il ne mesure pas la durée de l’interruption.
Précisez votre vocabulaire. Le guide ANSSI rapproche la durée maximale d’interruption admissible du RTO. Le NIST SP 800-34 révision 1, pages 17 à 19, distingue le délai de restauration d’une ressource de la durée maximale tolérable pour le processus métier. Cette distinction est utile : il faut parfois encore rapprocher les données, traiter un retard et obtenir une validation métier après le redémarrage technique.
Par exemple, une entreprise fictive tolère huit heures d’interruption de la préparation des commandes. Elle réserve deux heures à la vérification du stock et au traitement des opérations manuelles ; son objectif technique est alors de six heures. Elle choisit séparément un RPO de trente minutes après avoir évalué les commandes qu’elle pourrait reconstituer. Ces valeurs demandent une validation et un exercice ; aucune catégorie de logiciel ne les garantit automatiquement.
Fixez aussi le point de départ du chronomètre et le critère de fin. Le délai commence-t-il à l’interruption du service, à sa détection ou à la décision de bascule ? Pour l’utilisateur, l’attente précédant cette décision compte également. Conservez donc les différents horodatages et mesurez le délai total d’indisponibilité, même lorsque le contrat du prestataire emploie une définition plus étroite.
Établir l’ordre de reprise à partir des dépendances
La cartographie du système d’information doit permettre de relier chaque activité à ses applications, données, identités et fournisseurs. Une liste de machines virtuelles ne suffit pas. Il faut connaître les services nécessaires pour se connecter, retrouver les secrets, résoudre les noms réseau, vérifier les certificats et échanger les données avec les partenaires.
Prenez une application de facturation. Sa restauration peut dépendre d’un annuaire, d’un serveur de base de données, d’une licence, d’une messagerie et d’une connexion au prestataire de paiement. Si la procédure suppose que la messagerie fonctionne pour recevoir le code d’accès au coffre de secours, vous avez créé une dépendance circulaire. L’exercice doit révéler ce type de blocage avant une crise réelle.
Classez les services selon les conséquences de leur interruption et les possibilités de contournement. Une fonction peu visible peut être indispensable au redémarrage d’une fonction prioritaire. Documentez les prérequis de chaque étape et identifiez la personne capable de vérifier son succès. L’ordre de reprise devient ainsi une séquence de décisions vérifiables, plutôt qu’un classement abstrait par importance.
Choisir une architecture sans confondre réplication et sauvegarde
La reconstruction à partir de sauvegardes peut convenir si le délai nécessaire pour obtenir les ressources, transférer les données et reconfigurer les services respecte les objectifs. Elle demande des supports lisibles, les versions logicielles nécessaires, des procédures et des capacités disponibles. Un stockage peu coûteux peut entraîner un temps de récupération ou des frais de sortie importants : comparez l’ensemble du parcours de restauration.
Un site de secours partiellement préparé réduit certaines opérations de reconstruction, mais laisse subsister des tâches de configuration, de synchronisation et de validation. Un environnement maintenu prêt à démarrer exige davantage de suivi. Les expressions « froid », « tiède » et « chaud » doivent être traduites dans le contrat en ressources réellement disponibles et en opérations restant à accomplir, sans leur attribuer un délai universel.
Une architecture active sur plusieurs sites peut limiter certaines interruptions. Elle introduit aussi des difficultés de cohérence et ne protège pas automatiquement contre une compromission commune. La réplication peut propager une suppression ou un chiffrement malveillant. Il faut conserver une capacité de retour à un état antérieur et décider comment vérifier cet état avant de le réintroduire.
Le DRaaS, service externalisé de reprise après sinistre, regroupe des prestations variables. Vérifiez les applications couvertes, la capacité réservée, les prérequis réseau, le nombre d’exercices compris et l’assistance réellement disponible. Une démonstration de bascule d’une machine ne remplace pas un exercice de votre service complet. Examinez également la sortie du contrat : récupérer les sauvegardes dans un format exploitable doit rester possible.
Protéger les sauvegardes et les moyens de les restaurer
Le guide ANSSI sur les fondamentaux de la sauvegarde, version 1.1 du 27 novembre 2025, formule des recommandations à adapter au contexte. Sa recommandation R11 propose trois copies distinctes : les données de production et deux sauvegardes sur des supports différents, dont une hors ligne. Le guide insiste également sur l’isolement de l’administration, les exercices réguliers et l’ordre de restauration.
Une sauvegarde hors site protège contre certains risques physiques ; une sauvegarde hors ligne est déconnectée des systèmes. L’immuabilité vise à empêcher certaines modifications pendant une période donnée, avec une robustesse dépendant du mécanisme et des droits d’administration. Ces propriétés répondent à des risques différents. Vérifiez les possibilités réelles de suppression, de modification des règles de conservation et de récupération après la compromission d’un compte privilégié.
Le chiffrement doit être accompagné d’une gestion des clés compatible avec la reprise. Une sauvegarde intacte devient inutilisable si la seule clé se trouve dans le système détruit. Prévoyez l’accès de secours, son contrôle et sa traçabilité. Le catalogue des sauvegardes, les configurations, les supports d’installation et les instructions de restauration doivent également rester accessibles en dehors du périmètre sinistré.
La politique de conservation des sauvegardes doit servir les besoins de reprise sans créer un archivage illimité. Définissez les générations conservées, leur rotation et le traitement des données qui ont été supprimées du système courant. Après une restauration, un contrôle peut être nécessaire pour réappliquer les suppressions ou restrictions intervenues depuis la copie utilisée. Attribuez cette vérification à un responsable identifié.
Écrire une procédure utilisable pendant la crise
Une procédure efficace indique qui constate l’incident, qui évalue les options et qui autorise la bascule. Elle prévoit des moyens de communication de secours et des coordonnées accessibles si l’annuaire principal ne fonctionne plus. Définissez aussi les décisions réservées à la direction, notamment l’acceptation d’une perte de données supérieure à l’objectif prévu.
Pour chaque opération, indiquez le prérequis, le résultat attendu et la preuve à conserver. La consigne « restaurer la base » est insuffisante : quelle copie, quelle version, dans quel environnement et avec quel contrôle de cohérence ? Un intervenant de remplacement doit pouvoir comprendre la procédure sans connaître les habitudes de son auteur. Les secrets restent dans un dispositif sécurisé accessible selon une procédure distincte.
Après une attaque, la remise en service doit intégrer la recherche de la cause et la sécurisation de l’environnement. Restaurer rapidement un système encore vulnérable peut provoquer une nouvelle interruption. Isolez les opérations de récupération, conservez les éléments utiles à l’analyse et vérifiez les composants restaurés. Le choix de la dernière copie disponible n’est pas automatiquement le choix d’une copie saine.
Prévoyez enfin le retour au fonctionnement habituel. La bascule peut avoir créé des écritures nouvelles sur le site de secours. Le retour demande une synchronisation contrôlée, un traitement des écarts et une nouvelle validation métier. Sans cette étape, le dispositif de secours risque de devenir une production provisoire durable, avec des responsabilités et une facturation mal définies.
Tester ce qui prouve effectivement la reprise
Adaptez la fréquence et l’étendue des exercices aux risques, aux changements et aux obligations applicables. Un calendrier interne peut combiner des restaurations ciblées, des exercices de décision et une reprise de bout en bout ; ce calendrier doit être présenté comme un choix justifié lorsqu’aucun texte particulier ne l’impose. Une simple vérification du succès des tâches de sauvegarde ne mesure pas la capacité à rendre le service.
Définissez un scénario, un périmètre et des critères de réussite avant l’exercice. Faites exécuter une transaction représentative après restauration : retrouver un dossier, modifier un enregistrement, vérifier un paiement ou produire un document attendu. Contrôlez la cohérence entre les applications et les droits d’accès. Mesurez le délai obtenu et le point des données effectivement récupérées, puis comparez-les aux objectifs approuvés.
Le compte rendu décrit les écarts, leur cause, un responsable et une échéance. Si le test échoue parce qu’une personne détient seule une connaissance essentielle, la correction peut être documentaire ou organisationnelle. Si le débit est insuffisant, il faut modifier l’architecture ou renégocier l’objectif. Un résultat défavorable est utile lorsqu’il entraîne une action suivie et un nouvel essai proportionné.
Construire un budget comparable
Séparez les dépenses initiales, récurrentes et déclenchées par un sinistre. La conception comprend l’analyse des besoins, la préparation technique, la documentation et les premiers exercices. Le fonctionnement comprend les licences, les capacités réservées, le stockage, les transferts, l’assistance et le temps des équipes. Ajoutez les frais de restauration, de retour à la normale et de sortie du fournisseur.
Comparez les devis sur un même scénario et un même volume de données. Demandez si les tests consomment des ressources facturées séparément, si une assistance nocturne est incluse et si plusieurs clients peuvent mobiliser simultanément la capacité promise. Le coût d’un arrêt dépend de vos commandes, engagements et solutions de contournement ; un chiffre médian présenté sans contexte ne permet pas de dimensionner votre PRA.
Un arbitrage peut conduire à renforcer le secours d’une activité et à accepter un délai plus long ailleurs. Cette décision doit mentionner les conséquences acceptées et les conditions de réexamen. Évitez les économies invisibles : supprimer les exercices ou conserver une documentation obsolète réduit la dépense affichée tout en dégradant la capacité que le budget devait financer.
Identifier les obligations réellement applicables
L’article 32 du RGPD impose des mesures adaptées au risque, notamment la capacité de rétablir la disponibilité des données personnelles et l’accès à celles-ci dans des délais appropriés. Il prévoit également une procédure de vérification régulière de l’efficacité des mesures. Il ne fixe pas un RTO universel ni une architecture unique. Le guide sur la sécurité des traitements permet de relier la reprise aux risques pour les personnes.
Une indisponibilité peut constituer une violation de données personnelles. La notification à l’autorité compétente intervient sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés. Un retard doit être expliqué. Toutes les violations sont documentées ; la communication aux personnes en cas de risque élevé relève d’une appréciation distincte selon l’article 34.
NIS2 prévoit notamment la continuité et la reprise dans son article 21. Au 30 septembre 2026, la page officielle de l’ANSSI présente encore la transposition française comme en cours et ReCyF comme une version de travail. Distinguez donc préparation, textes déjà applicables et futures obligations nationales ; le suivi de la transposition NIS2 en France aide à vérifier cette évolution.
Pour les entités financières concernées, DORA comporte des exigences spécifiques. Dans le cadre ordinaire, ses articles 11 et 12 organisent continuité, sauvegardes et rétablissement ; l’article 11 prévoit notamment des tests au moins annuels et après certains changements substantiels. Le périmètre, la proportionnalité et le cadre simplifié de l’article 16 doivent être examinés. N’étendez pas ces prescriptions particulières à toute entreprise.
Enfin, vérifiez les engagements contractuels et les conditions exactes de l’assurance. Une exclusion ou une obligation déclarative dépend du contrat ; aucun principe général ne permet d’annoncer qu’un sinistre sera toujours couvert ou refusé. La répartition des responsabilités dans le cloud et le contrat avec un sous-traitant complètent cette analyse lorsqu’un prestataire traite des données pour votre compte.
Le livrable utile associe un service précisément défini, des objectifs approuvés, une procédure exécutable et des résultats d’exercice. Faites vivre ces éléments ensemble : une modification de fournisseur, de volume ou d’authentification peut rendre caduc un résultat auparavant satisfaisant. Le PRA devient fiable lorsque cette évolution est détectée et vérifiée avant le prochain incident.