Plan de reprise d'activité dans le cloud : un PRA n'est pas une politique de sauvegarde

Une politique de sauvegarde dit quelles données sont copiées, à quelle fréquence, où et pour combien de temps. Un plan de reprise d'activité (PRA) dit qui relance quoi, dans quel ordre, en combien de temps et avec quelle perte de données acceptée, puis comment on le vérifie. Confondre les deux peut produire un dossier rassurant et une reprise improvisée : des sauvegardes au vert, mais aucune restauration exercée ni aucun temps de reprise mesuré.

Ce guide définit, sources à l'appui, le plan de continuité d'activité (PCA), le PRA, la sauvegarde, le RTO et le RPO, puis les traduit sur Amazon Web Services (AWS) et Kubernetes : objectifs tenables, sauvegardes isolées, exercices, preuves, attentes de NIS2, de DORA et d'ISO/IEC 27001.

PCA, PRA, sauvegarde : trois objets, trois signatures

Les définitions officielles séparent déjà ces objets. Les confondre revient à croire qu'une copie suffit à relancer un service, ce que seul un exercice peut montrer.

Continuité : ce qui doit continuer

La CNIL définit la continuité d'activité comme le fait de « prévoir des moyens de continuer de fonctionner, en général de manière dégradée, malgré des dysfonctionnements ». Le guide pour réaliser un plan de continuité d'activité du Secrétariat général de la défense et de la sécurité nationale (SGDSN, édition 2013) cite la définition du règlement n° 97-02 du Comité de la réglementation bancaire et financière : le PCA représente « l'ensemble des mesures visant à assurer, selon divers scénarios de crises, y compris face à des chocs extrêmes, le maintien, le cas échéant de façon temporaire selon un mode dégradé, des prestations de services ou d'autres tâches opérationnelles essentielles ou importantes de l'entreprise, puis la reprise planifiée des activités ». Le PCA est un objet métier : il décide quelles activités tiennent, et à quel niveau.

Reprise : ce qu'il faut relancer

Pour la CNIL, la reprise d'activité « englobe toutes les actions nécessaires pour relancer un système arrêté ». Le référentiel de mesures de MonServiceSécurisé, service de l'Agence nationale de la sécurité des systèmes d'information (ANSSI), demande de formaliser la durée maximale d'interruption admissible (DMIA) et la perte de données maximale admissible (PDMA) du système (mesure 0118), puis un PRA « cohérent » avec ces deux valeurs, appuyé sur la cartographie de l'écosystème, la procédure de gestion des incidents et celle des crises d'origine cyber (mesure 0120). Le guide SP 800-34 Rev. 1 du National Institute of Standards and Technology (NIST) distingue de même le plan de continuité métier (BCP), centré sur les processus, le plan de reprise après sinistre (DRP), qui relance des systèmes sur un site de repli après une perturbation majeure, et le plan de secours d'un système d'information (ISCP), qui décrit la reprise d'un système quel que soit le site.

Sauvegarde : des copies, rien de plus

La fiche CNIL « Sauvegarder » demande des sauvegardes fréquentes, au moins une sauvegarde sur un site géographiquement distinct, au moins une sauvegarde isolée hors ligne, « déconnectée du réseau de l'entreprise », une protection au même niveau que les données des serveurs d'exploitation et des tests réguliers d'intégrité et de restauration ; elle conseille la règle « 3-2-1 » : trois copies, sur deux supports différents, dont une hors ligne. L'ANSSI demande des procédures de sauvegarde et de restauration testées « a minima annuellement » (mesure 0116) et des sauvegardes protégées d'un incident qui les rendrait inexploitables, par exemple par un stockage hors ligne face à un rançongiciel (mesure 0117). Une politique de sauvegarde répond à « quoi, quand, où, combien de temps » ; elle ne dit rien de l'ordre de relance, des identités ni du délai.

RTO, RPO et durée maximale tolérable

Le NIST SP 800-34 Rev. 1 fournit les définitions les plus exploitables. La durée maximale tolérable d'interruption (MTD, Maximum Tolerable Downtime) est la durée totale d'interruption d'un processus métier que le propriétaire du système accepte. L'objectif de temps de reprise (RTO, Recovery Time Objective) est la durée maximale pendant laquelle une ressource peut rester indisponible avant un impact inacceptable sur les autres ressources, sur les processus métier et sur la MTD ; il doit donc normalement rester plus court qu'elle. L'objectif de point de reprise (RPO, Recovery Point Objective) est l'instant, antérieur à l'interruption, auquel les données peuvent être reconstituées compte tenu de la copie de sauvegarde la plus récente. AWS définit de même le RTO comme le délai maximal acceptable entre l'interruption et le rétablissement du service, et le RPO comme la durée maximale acceptable depuis le dernier point de récupération. DMIA et PDMA expriment la même exigence côté métier.

RTO et RPO réalistes sur AWS et Kubernetes

Un RPO réaliste ne se déclare pas, il se lit : c'est l'âge de la dernière copie exploitable de chaque classe de données, pour le scénario retenu. Une réplication continue offre un RPO très court face à une panne de zone, mais elle ne remplace pas une copie à un instant donné face à une corruption ou à une suppression malveillante. Un RTO réaliste est la longueur du chemin critique depuis l'interruption du service : détecter, décider, reconstruire l'infrastructure, restaurer, laisser les volumes se charger, rebrancher les dépendances, vérifier une donnée métier, rouvrir le trafic. Le temps affiché par l'outil de restauration n'en est qu'un segment.

Les quatre stratégies AWS et leurs ordres de grandeur

La bonne pratique REL13-BP02 du cadre AWS Well-Architected associe quatre stratégies de reprise à des ordres de grandeur, par ordre croissant de coût et de complexité.

Trois précisions d'AWS changent la lecture de ce tableau. Sans infrastructure décrite en code (IaC, Infrastructure as Code), la restauration dans la région de reprise peut devenir complexe, allonger le temps de reprise et dépasser le RTO : le dépôt d'infrastructure compte autant que les sauvegardes. La réplication continue protège moins bien qu'une sauvegarde à un instant donné contre la corruption ou la suppression malveillante, sauf si la stratégie inclut le versionnage ou la restauration à un instant donné (PITR, point-in-time recovery). Enfin, une bascule devrait reposer uniquement sur des opérations du plan de données, dont les objectifs de disponibilité sont en général plus élevés que ceux du plan de contrôle.

AWS rappelle aussi qu'une stratégie plus coûteuse que la panne ou la perte qu'elle couvre ne se justifie que par un autre motif, réglementaire par exemple : le choix se fait par activité, à partir de la DMIA et de la PDMA.

Ce que les services managés permettent vraiment

• Amazon RDS : la restauration à un instant donné crée une nouvelle instance, sans modifier l'instance source. RDS envoie les journaux de transactions vers Amazon S3 toutes les cinq minutes, et le champ LatestRestorableTime donne le dernier instant restaurable. Après la restauration, les volumes continuent de charger leurs blocs depuis S3 en arrière-plan : l'instance fonctionne, sans être à pleine performance tant que cette initialisation n'est pas terminée. Le RTO inclut ce chargement et le changement de point de terminaison côté application.
• Amazon DynamoDB : la restauration à un instant donné offre jusqu'à 35 jours de points de récupération, à la seconde près, sur une période réglable de 1 à 35 jours ; le dernier instant restaurable se situe en général cinq minutes avant l'instant présent, et la restauration crée toujours une nouvelle table, qu'il faut rebrancher.

Sur Kubernetes, l'état n'est pas là où on le croit

Une plateforme pilotée en GitOps se reconstruit depuis son dépôt, mais le dépôt décrit l'état voulu des objets, pas le contenu des volumes ni des bases ; l'ordre de cette reconstruction compte, comme le montre « Argo CD App-of-Apps et ApplicationSet : amorcer un cluster sans masquer les dépendances ». Velero sauvegarde les objets de l'API Kubernetes et peut déclencher des instantanés de volumes. Par défaut, sa restauration est non destructive : une ressource déjà présente dans le cluster cible est ignorée, d'où l'intérêt de restaurer dans un cluster propre.

La sauvegarde de système de fichiers de Velero (FSB, File System Backup) lit le système de fichiers vivant : selon sa documentation, les données ne sont pas capturées au même instant, et l'analyse de déduplication des gros fichiers, comme ceux d'une base de données, peut prendre longtemps même si la différence est faible. Un volume de base de données copié ainsi ne remplace pas la sauvegarde propre au moteur.

Pour PostgreSQL, la voie documentée est la sauvegarde de base complétée par l'archivage continu des journaux d'écriture anticipée (WAL, Write-Ahead Log), qui permet de restaurer la base dans l'état de n'importe quel instant postérieur à la sauvegarde de base. Le paramètre archive_timeout borne l'âge des données non archivées ; la documentation de PostgreSQL 18 juge raisonnable une valeur de l'ordre d'une minute et déconseille une valeur très courte, qui gonfle l'archive. Les topologies et la bascule sont détaillées dans « PostgreSQL sur Kubernetes en haute disponibilité : topologies, bascule, RPO et tests de panne ». Le fournisseur d'identité mérite le même soin : sans lui, personne ne s'authentifie pour restaurer le reste (« Keycloak en haute disponibilité sur Kubernetes : caches, sessions, tests de panne et restauration »).

Le RPO d'une application est celui de son composant le moins bien couvert, son RTO celui de sa plus longue chaîne de dépendances. Ce tableau, rempli et daté, vaut mieux qu'un chiffre global.

Des sauvegardes isolées du système qu'elles protègent

Une panne de disque ou de zone n'est pas le seul scénario à couvrir. La CNIL déconseille de conserver les sauvegardes sur les mêmes systèmes que les données sans les isoler, car une menace comme un rançongiciel pourrait alors s'attaquer aux deux. Ce chapitre rassemble ce que demandent les textes et ce que documente AWS ; il ne décrit aucune architecture.

Ce que demandent les textes

Les textes décrivent une séparation, sans nommer de produit. La CNIL demande d'isoler au moins une sauvegarde hors ligne, déconnectée du réseau ; l'ANSSI, de protéger les sauvegardes d'un incident qui les rendrait inexploitables (mesure 0117). Le règlement d'exécution (UE) 2024/2690 demande, pour les entités qu'il vise, des copies stockées en un ou plusieurs endroits sûrs qui ne se trouvent pas sur le même réseau que le système, avec des contrôles d'accès physiques et logiques adaptés (annexe, point 4.2.2). Hors cadre simplifié de son article 16, DORA demande aux entités financières qui restaurent avec leurs propres systèmes d'utiliser des systèmes séparés physiquement et logiquement du système source (article 12, paragraphe 3). Côté AWS, la documentation décrit les mécanismes suivants.

Mode conformité ou mode gouvernance

Sur un compartiment S3 versionné, la documentation d'AWS indique qu'une suppression simple pose un marqueur de suppression, tandis qu'une suppression qui cible un identifiant de version, comme l'expiration des versions non courantes par le cycle de vie, est définitive. S3 Object Lock, qui ne fonctionne que sur un compartiment versionné, propose deux modes de rétention. En mode conformité, aucun utilisateur, pas même l'utilisateur racine du compte, ne peut écraser ou supprimer une version protégée, ni changer son mode, ni raccourcir sa rétention ; la documentation précise que la seule façon de supprimer un tel objet avant l'échéance est de supprimer le compte AWS qui le porte. En mode gouvernance, les utilisateurs ne peuvent ni écraser ni supprimer une version protégée, ni modifier ses paramètres de verrouillage, sauf s'ils disposent d'autorisations particulières, comme la permission s3:BypassGovernanceRetention. Une règle de cycle de vie ne supprime pas une version verrouillée, une rétention par défaut peut verrouiller chaque version à l'écriture, et Object Lock, une fois activé sur un compartiment, ne se désactive plus et interdit de suspendre le versionnage. Le verrou protège une version : il n'empêche ni l'écriture de nouvelles versions ni l'ajout de marqueurs de suppression.

Avec AWS Backup, le verrou de coffre (Vault Lock) en mode conformité rend le coffre et son verrou immuables, pour tout utilisateur comme pour AWS, à l'issue d'un délai de grâce d'au moins trois jours (72 heures) ; les sauvegardes qu'il contient ne peuvent plus être supprimées avant la fin de leur cycle de vie, ce qui impose de vérifier les rétentions avant la fin du délai de grâce pour éviter des coûts durables. Le coffre logiquement isolé (logically air-gapped vault) est livré avec un verrou en mode conformité, chiffré par défaut avec une clé détenue par AWS, et partageable, par AWS Resource Access Manager (RAM) ou par approbation multipartite, avec un autre compte qui peut y restaurer.

Copier vers un autre compte

AWS présente la copie de sauvegardes vers un autre compte comme une protection contre des sinistres qui incluent une menace interne ou la compromission d'un compte, et recommande, pour une stratégie multirégion, un compte distinct par région pour obtenir le plus haut niveau d'isolation des ressources et de la sécurité.

Clés de chiffrement : ce que documente AWS

Sur AWS Key Management Service (KMS), la suppression d'une clé est irréversible : les données chiffrées sous cette clé deviennent irrécupérables. KMS impose un délai d'attente de 7 à 30 jours (30 par défaut) avant la suppression effective, et AWS CloudTrail enregistre la programmation de cette suppression. Pour un coffre logiquement isolé, AWS Backup recommande la clé détenue par AWS et, si une clé gérée par le client est choisie, de préférence une clé qui appartient à un autre compte.

Ce que les textes permettent de vérifier

Les exigences citées plus haut se relisent comme une liste de contrôle :

1. au moins une sauvegarde isolée hors ligne, déconnectée du réseau de l'entreprise (CNIL) ;
2. des copies stockées en un ou plusieurs endroits sûrs, hors du réseau du système et assez loin du site principal, avec des contrôles d'accès physiques et logiques et des périodes de conservation définies (règlement d'exécution (UE) 2024/2690, annexe, point 4.2.2) ;
3. des contrôles d'intégrité réguliers des copies (point 4.2.3) et des tests de récupération dont les résultats sont consignés (point 4.2.6) ;
4. lorsque l'entité financière, hors cadre simplifié de l'article 16, restaure avec ses propres systèmes, des systèmes séparés physiquement et logiquement du système source (DORA, article 12, paragraphe 3).

Tester la reprise : exercices, preuves, fréquence

Un PRA non exercé reste une hypothèse. Le glossaire du NIST, repris du guide SP 800-84, distingue l'exercice sur table, où les personnes qui ont un rôle dans le plan en discutent à partir d'un scénario présenté par un animateur, et l'exercice fonctionnel, qui leur permet de valider leurs plans et leur état de préparation dans un environnement opérationnel simulé. Le premier vérifie que le plan est compris ; seul le second, ou une restauration complète, mesure un RTO.

Quelle fréquence

DORA impose aux entités financières de tester leurs plans de continuité des activités de technologies de l'information et de la communication (TIC) et leurs plans de réponse et de rétablissement des TIC au moins une fois par an, ainsi qu'en cas de modification substantielle des systèmes qui soutiennent des fonctions critiques ou importantes (article 11, paragraphe 6) ; les entités relevant du cadre simplifié de l'article 16 doivent, elles, tester régulièrement leurs plans. Le règlement d'exécution (UE) 2024/2690 demande aux entités qu'il vise de tester les plans à intervalles prédéfinis, ainsi qu'en cas d'incident important ou de changement majeur (annexe, point 4.1.4), et de consigner les résultats des tests de récupération des sauvegardes (point 4.2.6). L'ANSSI demande de tester les procédures de sauvegarde et de restauration a minima annuellement (mesure 0116). La CNIL recommande de tester régulièrement la restauration des sauvegardes et l'application du plan, d'éprouver de temps en temps la continuité et la reprise des éléments les plus critiques, et d'envisager un test de l'arrêt complet du système d'information.

L'automatisation aide sans suffire. Les plans de test de restauration d'AWS Backup lancent périodiquement des restaurations à partir du point de récupération le plus récent ou d'un point tiré au hasard, mesurent leur durée, permettent une validation facultative, puis suppriment les ressources restaurées ; chaque test a un coût. C'est une preuve de restaurabilité, pas un exercice de PRA.

Ce qui constitue une preuve

Modèle de ligne de rapport, à remplir avec vos propres mesures : « RTO visé (valeur signée) ; RTO observé (horodatages de début et de fin) ; RPO observé (horodatage de la donnée la plus récente restaurée) ; cause de l'écart ; action décidée ; date du prochain exercice ». Un rapport sans écart mesuré ne prouve aucun RTO.

Sans preuve datée d'une restauration, d'une copie isolée et d'un écart mesuré en exercice, le document soumis à signature reste une politique de sauvegarde et un plan d'exercice, pas un PRA. Fixer ces objectifs, tenir la chaîne de copie et conduire les exercices relève de l'exploitation de la plateforme : la page Infogérance cloud & maintien en conditions opérationnelles (MCO) décrit ce périmètre.

Ce qu'attendent NIS2, DORA et ISO/IEC 27001

Les trois référentiels convergent sur un noyau commun : objectifs de reprise, sauvegardes isolées et intègres, tests, amélioration du plan. Ils diffèrent par leur force juridique et leur niveau de détail.

NIS2

La directive (UE) 2022/2555, dite NIS2, range parmi les mesures de son article 21, paragraphe 2, point c), « la continuité des activités, par exemple la gestion des sauvegardes et la reprise des activités, et la gestion des crises ». Pour les fournisseurs de services d'informatique en nuage, de centres de données, de services gérés et de services de sécurité gérés, entre autres catégories numériques, le règlement d'exécution (UE) 2024/2690 détaille ces mesures en annexe : un plan de continuité de l'activité et de rétablissement qui comprend, s'il est besoin, l'ordre de rétablissement des opérations et des objectifs de rétablissement (point 4.1.2), un bilan d'impact sur l'activité (point 4.1.3), des tests à intervalles prédéfinis (point 4.1.4) ; des plans de sauvegarde qui exigent la preuve de copies complètes et exactes, données de configuration et données stockées en nuage comprises, des copies stockées hors du réseau du système et assez loin du site principal, avec contrôles d'accès et périodes de conservation (point 4.2.2), des contrôles d'intégrité réguliers (point 4.2.3) et des tests de récupération consignés (point 4.2.6). L'Agence de l'Union européenne pour la cybersécurité (ENISA) a publié en juin 2025 un guide technique de mise en œuvre de ce règlement.

La directive devait être transposée au plus tard le 17 octobre 2024. En France, à la date de vérification, la loi de transposition n'est pas adoptée : le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025, n'a pas achevé sa première lecture à l'Assemblée nationale. Son examen en séance publique, inscrit à l'ordre du jour des 7 et 9 octobre 2026, en a été retiré par la Conférence des présidents du 6 octobre 2026.

DORA

Le règlement (UE) 2022/2554, dit DORA, s'applique depuis le 17 janvier 2025 et se montre le plus précis. Hors entités relevant du cadre simplifié de son article 16, son article 11 impose de tester au moins une fois par an les plans de continuité et les plans de réponse et de rétablissement, ainsi qu'à chaque modification substantielle des systèmes qui soutiennent des fonctions critiques ou importantes ; hors microentreprises, les plans de test incluent des scénarios de cyberattaque et de basculement vers la capacité redondante, les sauvegardes et les installations redondantes. Pour les mêmes entités, son article 12 demande des politiques de sauvegarde qui précisent la portée des données et la fréquence minimale (paragraphe 1), des tests périodiques des procédures de sauvegarde et de restauration (paragraphe 2), des systèmes de restauration séparés physiquement et logiquement du système source lorsque l'entité restaure avec ses propres systèmes (paragraphe 3), des objectifs de délai et de point de rétablissement fixés pour chaque fonction (paragraphe 6) et des contrôles d'intégrité lors du rétablissement (paragraphe 7). Les entités du cadre simplifié doivent, elles, tester régulièrement leurs plans de continuité et leurs mesures de réponse et de rétablissement, qui comprennent au moins des mesures de sauvegarde et de restauration (article 16, paragraphe 1). La page outiller les preuves techniques de DORA décrit ce volet technique.

ISO/IEC 27001

Pour ISO/IEC 27001:2022, l'ENISA rappelle que les mesures de l'annexe A, alignées sur ISO/IEC 27002:2022, s'utilisent dans le cadre du traitement des risques de sécurité de l'information (article 6.1.3 de la norme). La table de correspondance publiée par l'ENISA rattache le plan de continuité et de rétablissement du règlement 2024/2690 (point 4.1) aux mesures A.5.29 et A.5.30, et la gestion des sauvegardes (point 4.2) aux mesures A.8.13 et A.8.14 ; l'agence précise qu'une correspondance n'est pas une équivalence. Les objectifs de reprise et le rythme des exercices découlent donc du traitement des risques de l'organisation ; lors d'un audit de certification, ce sont les preuves du chapitre précédent qui en montrent l'application.

Pour une organisation qui prépare une certification, la page construire les preuves ISO 27001 décrit comment ces preuves s'organisent.

Sources officielles et limites de lecture

Les définitions viennent de la CNIL, de l'ANSSI, du SGDSN et du NIST ; les comportements techniques, des documentations d'AWS, de Velero 1.18 et de PostgreSQL 18 ; les textes européens, d'EUR-Lex en français ; la correspondance avec ISO/IEC 27001, de l'ENISA. Ces sources ont été consultées le 7 octobre 2026.

Les ordres de grandeur d'AWS décrivent des stratégies, pas un engagement de service. La sémantique d'Object Lock décrite est celle d'Amazon S3 ; un autre stockage compatible S3 peut l'implémenter différemment. La liste de contrôle du chapitre sur les sauvegardes isolées reprend les textes cités ; elle ne constitue pas une configuration prête à déployer. Le texte de la norme ISO/IEC 27001 n'est pas reproduit ici : les numéros de mesures cités viennent de la table de l'ENISA. Enfin, ce texte ne qualifie aucune entité au titre de NIS2 ou de DORA et ne fixe aucun RTO universel : les objectifs se déduisent de l'analyse d'impact de chaque activité.

Sources

1. Sécurité : Prévoir la continuité et la reprise d'activité (fiche du 14 mars 2024), CNIL, https://www.cnil.fr/fr/securite-prevoir-la-continuite-et-la-reprise-dactivite, consulté le 07/10/2026.
2. Sécurité : Sauvegarder (fiche du 14 mars 2024), CNIL, https://www.cnil.fr/fr/securite-sauvegarder, consulté le 07/10/2026.
3. Référentiel de mesures, mesures 0116, 0117, 0118 et 0120, MonServiceSécurisé, ANSSI, https://monservicesecurise.cyber.gouv.fr/referentiel-mesures, consulté le 07/10/2026.
4. Guide pour réaliser un plan de continuité d'activité (édition 2013), SGDSN, https://www.sgdsn.gouv.fr/files/files/Nos_missions/guide-pca-sgdsn-110613-normal.pdf, consulté le 07/10/2026.
5. SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (sections 2.2 et 3.2.1), NIST, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf, consulté le 07/10/2026.
6. Glossaire CSRC : Tabletop Exercise et Functional Exercise (source SP 800-84), NIST, https://csrc.nist.gov/glossary/term/tabletop_exercise, consulté le 07/10/2026.
7. Disaster Recovery of Workloads on AWS, Disaster recovery options in the cloud, Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html, consulté le 07/10/2026.
8. Disaster Recovery of Workloads on AWS, Business continuity plan (BCP), Amazon Web Services, https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html, consulté le 07/10/2026.
9. REL13-BP02 Use defined recovery strategies to meet the recovery objectives, AWS Well-Architected Framework, Amazon Web Services, https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_disaster_recovery.html, consulté le 07/10/2026.
10. Restoring a DB instance to a specified time, Amazon RDS User Guide, Amazon Web Services, https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html, consulté le 07/10/2026.
11. Point-in-time backups for DynamoDB, Amazon DynamoDB Developer Guide, Amazon Web Services, https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Point-in-time-recovery.html, consulté le 07/10/2026.
12. Enable point-in-time recovery in DynamoDB, Amazon DynamoDB Developer Guide, Amazon Web Services, https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html, consulté le 07/10/2026.
13. Locking objects with Object Lock, Amazon S3 User Guide, Amazon Web Services, https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html, consulté le 07/10/2026.
14. Configuring S3 Object Lock, Amazon S3 User Guide, Amazon Web Services, https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html, consulté le 07/10/2026.
15. Object Lock considerations, Amazon S3 User Guide, Amazon Web Services, https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html, consulté le 07/10/2026.
16. Deleting object versions from a versioning-enabled bucket, Amazon S3 User Guide, Amazon Web Services, https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html, consulté le 07/10/2026.
17. AWS Backup Vault Lock, AWS Backup Developer Guide, Amazon Web Services, https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html, consulté le 07/10/2026.
18. Logically air-gapped vault, AWS Backup Developer Guide, Amazon Web Services, https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html, consulté le 07/10/2026.
19. Restore testing, AWS Backup Developer Guide, Amazon Web Services, https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html, consulté le 07/10/2026.
20. Delete an AWS KMS key, AWS Key Management Service Developer Guide, Amazon Web Services, https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html, consulté le 07/10/2026.
21. File System Backup (v1.18), Velero, https://velero.io/docs/v1.18/file-system-backup/, consulté le 07/10/2026.
22. How Velero Works (v1.18), Velero, https://velero.io/docs/v1.18/how-velero-works/, consulté le 07/10/2026.
23. Continuous Archiving and Point-in-Time Recovery (PITR), documentation PostgreSQL 18, section 25.3, PostgreSQL Global Development Group, https://www.postgresql.org/docs/18/continuous-archiving.html, consulté le 07/10/2026.
24. Directive (UE) 2022/2555 (NIS2), articles 21 et 41, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555, consulté le 07/10/2026.
25. Règlement d'exécution (UE) 2024/2690 de la Commission du 17 octobre 2024, article premier et annexe, points 4.1 et 4.2, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32024R2690, consulté le 07/10/2026.
26. Technical implementation guidance on cybersecurity risk management measures, version 1.0 (juin 2025), ENISA, https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf, consulté le 07/10/2026.
27. Technical Implementation Guidance, table de correspondance, version 1.2, ENISA, https://www.enisa.europa.eu/sites/default/files/2025-09/ENISA_Technical_Implementation_Guidance_Mapping_table_version_1.2.xlsx, consulté le 07/10/2026.
28. Projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, dossier législatif, Assemblée nationale, https://www.assemblee-nationale.fr/dyn/17/dossiers/DLR5L17N50731, consulté le 07/10/2026.
29. Conférence des présidents, relevé de conclusions de la réunion du mardi 6 octobre 2026, Assemblée nationale, https://www2.assemblee-nationale.fr/17/la-conference-des-presidents/releve-de-conclusions/reunion-du-mardi-6-octobre-2026, consulté le 07/10/2026.
30. Règlement (UE) 2022/2554 (DORA), articles 11, 12, 16 et 64, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022R2554, consulté le 07/10/2026.