RTO vs RPO : Principales différences dans la planification de la reprise après sinistre

RTO vs RPO : RTO définit la durée maximale d'indisponibilité acceptable, tandis que RPO définit la perte de données acceptable. Découvrez comment calculer ces deux indicateurs et éviter les erreurs courantes en matière de reprise après sinistre.

Qu'est-ce que le RTO et le RPO ?

Votre directeur financier pose une question simple après la panne de trois heures du trimestre dernier : « À quelle vitesse pouvons-nous récupérer la prochaine fois ? » Vous ouvrez la bouche pour répondre, puis vous hésitez. Vitesse de récupération ou protection des données ? Disponibilité du système ou perte de transactions ?

Cette panne de trois heures ? Votre RTO était de quatre heures, donc vous avez atteint l'objectif. Mais les clients ont perdu huit heures de données de commandes parce que votre dernière sauvegarde a été effectuée à 18h la veille. Votre RPO n'était pas un problème jusqu'à ce qu'il le devienne.

Le Recovery Time Objective (RTO) et le Recovery Point Objective (RPO) mesurent différentes dimensions de la  continuité d'activité. Le RTO définit la durée maximale pendant laquelle vos systèmes peuvent rester indisponibles avant que l'impact sur l'activité ne devienne inacceptable. Le RPO définit la quantité de perte de données que vous pouvez tolérer, mesurée comme l'écart entre votre dernière sauvegarde viable et le point de perturbation.

Selon le NIST SP 800-34 Rev. 1, la norme fédérale pour la planification de la continuité, le RTO répond à la question « Combien de temps le système peut-il être indisponible ? » tandis que le RPO répond à « Combien de données pouvons-nous nous permettre de perdre ? » Vous ne pouvez pas traiter ces questions comme interchangeables ; le faire crée des lacunes dans votre plan de reprise après sinistre.

Lorsque un ransomware chiffre votre base de données de production en dehors des heures ouvrées, le RTO détermine si vous restaurez les opérations à 6h du matin ou le mardi suivant. Le RPO détermine si vous perdez 15 minutes de transactions ou trois jours de commandes clients. Vous avez besoin des deux indicateurs, calculés indépendamment, pour élaborer des stratégies de reprise adaptées aux exigences réelles de l'entreprise.

La distinction clé : le RTO mesure vers l'avant à partir du sinistre (temps de restauration), tandis que le RPO mesure vers l'arrière à partir du sinistre (dernier point de récupération). La fréquence de vos sauvegardes définit le RPO. Vos capacités de restauration définissent le RTO. Un système avec des sauvegardes horaires a un RPO d'une heure, que la restauration prenne 30 minutes ou huit heures.

Comment le RTO et le RPO sont liés à la cybersécurité

La planification traditionnelle de la reprise après sinistre suppose des environnements de récupération sains. Un incendie détruit un centre de données. Une inondation endommage les équipements. Vous restaurez à partir de sauvegardes sur une infrastructure alternative et reprenez les opérations.

Les incidents de cybersécurité compliquent cette hypothèse.  Les attaques par ransomware ne se contentent pas de chiffrer les fichiers ; elles exigent une restauration à partir de points de sauvegarde vérifiés comme exempts de malwares. L'attaque contre Colonial Pipeline en mai 2021 illustre cette réalité. Selon le  communiqué de presse du Department of Justice, l'attaque par le ransomware DarkSide a entraîné un arrêt opérationnel de six jours du plus grand oléoduc des États-Unis. De même, JBS Foods a payé 11 millions de dollars de rançon aux attaquants REvil en juin 2021 après qu'un ransomware a forcé l'arrêt d'usines de transformation de viande aux États-Unis, au Canada et en Australie.

Selon les  Playbooks de réponse aux incidents et vulnérabilités de cybersécurité du gouvernement fédéral de la CISA, la reprise après ransomware pour les systèmes critiques nécessite généralement 24 à 72 heures contre 4 à 24 heures pour les objectifs traditionnels. Ce délai prolongé tient compte de :

• Vérification de la suppression des malwares
• Rétablissement des contrôles de sécurité
• Intégration du renseignement sur les menaces
• Coordination avec les forces de l'ordre

Les calculs de RPO rencontrent une complexité similaire. Votre sauvegarde de 6h semble saine, mais l'analyse forensique révèle que  le mouvement latéral a commencé à 3h. Votre véritable point de récupération viable se situe 15 heures plus tôt, avant la compromission initiale.

Le  NIST Cybersecurity Framework 2.0, publié en février 2024, positionne le RTO et le RPO dans la fonction Recover (RC) comme composants nécessaires à l'établissement des objectifs de reprise. Vous devez établir des  objectifs de reprise spécifiques à la cybersécurité alignés sur les recommandations du NIST.

Maintenant que nous avons défini les deux indicateurs et leurs implications en cybersécurité, détaillons précisément leurs différences selon cinq dimensions clés.

RTO vs RPO : principales différences en un coup d'œil

Comprendre les distinctions fondamentales entre le RTO et le RPO évite les lacunes de planification qui mènent à des échecs de reprise.

• Direction de la mesure : Le RTO mesure vers l'avant à partir du sinistre : combien de temps avant le retour en ligne des systèmes. Le RPO mesure vers l'arrière : à quelle distance se trouve votre dernier état de données sain. Cette différence directionnelle signifie que des équipes différentes sont souvent responsables de chaque indicateur. Les équipes infrastructure pilotent le RTO via les capacités de restauration, tandis que les administrateurs de sauvegarde pilotent le RPO via la fréquence de réplication.
• Facteurs de coût : Réduire le RTO nécessite d'investir dans une infrastructure redondante, des systèmes de secours à chaud et des capacités de basculement automatisé. Réduire le RPO nécessite d'investir dans la capacité de stockage, la bande passante de réplication et la fréquence des sauvegardes. 
• Exigences technologiques : Un RTO quasi nul exige des architectures actives-actives avec équilibrage de charge et basculement automatique. Un RPO quasi nul exige une protection continue des données avec réplication synchrone. Vous pouvez atteindre des objectifs ambitieux pour un indicateur avec un investissement modéré, mais atteindre les deux simultanément nécessite des dépenses exponentiellement plus élevées.
• Temporalité de l'impact métier : Les impacts du RTO se manifestent immédiatement par une perte de productivité, des SLA manqués et des perturbations opérationnelles. Les impacts du RPO peuvent n'apparaître qu'après la reprise. Vous découvrez les lacunes de données seulement après la restauration, lorsque des transactions manquent ou que des enregistrements sont obsolètes.
• Méthode de test : Les tests de RTO valident les procédures de restauration via des exercices de basculement réels. Les tests de RPO valident l'intégrité des sauvegardes via la vérification des points de récupération et des contrôles de complétude des données.

Ces différences ont de réelles conséquences financières. Les organisations qui traitent le RTO et le RPO comme interchangeables découvrent le coût de cette hypothèse lors de la reprise.

Pourquoi le RTO et le RPO diffèrent dans la planification de la reprise après sinistre

Selon l'Uptime Institute Global Data Center Survey 2024,  20 % des pannes majeures coûtent plus d'un million de dollars. Mais les impacts du RTO et du RPO sont différents : les coûts d'indisponibilité s'accumulent à la minute, tandis que les coûts de perte de données dépendent de ce qui a été perdu et de la possibilité de le recréer. Un prestataire de santé qui perd quatre heures de dossiers patients s'expose à des sanctions HIPAA, quelle que soit la rapidité de la restauration.

Les recommandations du NIST établissent trois niveaux d'impact qui déterminent différentes stratégies de reprise :

• Systèmes à fort impact (critiques pour la mission) nécessitent des systèmes en miroir, la réplication sur disque et des sites de secours à chaud avec basculement immédiat. Vous optimisez pour un RTO mesuré en minutes et un RPO mesuré en minutes à heures, selon la fréquence des sauvegardes et la criticité des données.
• Systèmes à impact modéré nécessitent des sauvegardes optiques, la réplication WAN/VLAN et des capacités de site de secours tiède. Votre RTO acceptable s'étend à quelques heures, et le RPO à des intervalles de 15 à 60 minutes.
• Systèmes à faible impact utilisent généralement des sauvegardes sur bande et des stratégies de relocalisation sur site de secours à froid, avec des objectifs de reprise établis via une  analyse de risque basée sur la perturbation opérationnelle acceptable. Ces systèmes tolèrent généralement des fenêtres de reprise plus longues que l'infrastructure critique, avec des fréquences de sauvegarde et des stratégies de reprise déterminées par l'impact métier documenté plutôt que par des délais prescrits.

Les organisations qui placent la modernisation des sauvegardes et de la reprise après sinistre parmi leurs principales initiatives IT n'appliquent pas de solutions uniformes à l'ensemble de leur environnement. Elles alignent les capacités de reprise sur des exigences métier différenciées via des systèmes de classification par niveaux qui attribuent des objectifs RTO et RPO différents selon la criticité métier.

Ces stratégies de reprise par niveaux fournissent le cadre ; il vous faut maintenant la méthodologie pour déterminer quel niveau s'applique à chacun de vos systèmes.

Comment calculer le RTO et le RPO

Calculer des objectifs de reprise pertinents nécessite de quantifier l'impact métier, et non de deviner des seuils acceptables.

Calcul du RTO

Commencez par votre Maximum Tolerable Downtime (MTD), la limite absolue avant que l'impact métier ne devienne catastrophique. Travaillez à rebours à partir de là. Si votre plateforme e-commerce génère 50 000 $ par heure et que votre entreprise peut absorber 200 000 $ de perte de revenus avant de faire face à des conséquences existentielles, votre MTD est de quatre heures. Votre RTO doit être inférieur au MTD avec une marge pour les complications. Fixez-le à trois heures.

Additionnez vos étapes de restauration :

• Récupération de la sauvegarde : 30 minutes
• Restauration des données : 90 minutes
• Redémarrage de l'application : 20 minutes
• Tests de validation : 40 minutes

Si le total fait trois heures, vous atteignez votre objectif. S'il fait cinq heures, il vous faut une infrastructure plus rapide.

Calcul du RPO

Identifiez votre taux de changement de données et le coût de recréation des données perdues. Si votre système traite 1 000 transactions par heure et que chaque transaction nécessite 15 minutes de ressaisie manuelle pour être recréée, perdre quatre heures de données coûte 1 000 heures de travail (4 000 transactions × 15 minutes). Si ce coût de main-d'œuvre dépasse votre investissement dans l'infrastructure de sauvegarde, réduisez votre RPO. Pour les systèmes où les données ne peuvent pas être recréées—imagerie médicale, transactions financières, télémétrie de capteurs—le RPO tend vers zéro, quel qu'en soit le coût.

Selon le  NIST SP 800-34 Rev. 1, le RTO doit être fixé au point où le coût des ressources de reprise égale le coût de l'indisponibilité continue du système. Tracez les deux courbes : le coût de la reprise augmente à mesure que le RTO diminue (une reprise plus rapide nécessite une infrastructure plus coûteuse), tandis que le coût de l'indisponibilité augmente à mesure que le RTO augmente. Le point d'intersection représente votre investissement RTO optimal.

Ces calculs diffèrent selon votre secteur d'activité.

Exemples de RTO et RPO par secteur

Les exigences réglementaires, la sensibilité des données et les dépendances opérationnelles déterminent ce que signifie « acceptable » pour les objectifs de reprise. Voici à quoi ressemblent le RTO et le RPO dans quatre grands secteurs.

• Services financiers : Les plateformes de trading exigent un RTO et un RPO quasi nuls car les conditions de marché évoluent à la seconde et les exigences réglementaires imposent la conservation complète des transactions. La  règle 17a-4 de la SEC impose aux courtiers de conserver les enregistrements dans un format non réinscriptible. Les banques visent généralement un RTO inférieur à 2 heures pour les systèmes bancaires centraux et un RPO inférieur à 15 minutes pour les données de transaction.
• Santé : HIPAA exige que les entités couvertes maintiennent l'intégrité et la disponibilité des données, sans imposer d'objectifs RTO ou RPO spécifiques. Cependant, les systèmes cliniques de soins aux patients visent souvent un RTO inférieur à 4 heures. Les dossiers médicaux électroniques nécessitent un RPO mesuré en minutes car la recréation de la documentation clinique compromet la sécurité des patients et crée un risque juridique. La  Security Rule du HHS impose la planification de la continuité mais laisse les objectifs spécifiques à l'évaluation des risques.
• E-commerce et distribution : Pendant les périodes de pointe, les grands distributeurs perdent  plus de 500 000 $ par heure d'indisponibilité. Les systèmes de gestion des commandes exigent généralement un RTO inférieur à 1 heure et un RPO inférieur à 15 minutes. Les systèmes d'inventaire peuvent tolérer des fenêtres plus longues. Les sites web orientés client exigent un RTO agressif car les acheteurs abandonnent les sites qui semblent défaillants.
• Industrie : Les systèmes technologiques opérationnels pilotant les lignes de production exigent un RTO mesuré en minutes car l'arrêt des équipements et les retards de production créent des impacts en cascade sur la chaîne d'approvisionnement. Cependant, les exigences RPO varient : la télémétrie de production peut tolérer des sauvegardes horaires tandis que les enregistrements de contrôle qualité exigent une protection continue.

Les références sectorielles sont utiles, mais vos objectifs spécifiques doivent découler d'une analyse interne rigoureuse. Des chiffres génériques ne protègent pas votre organisation. Seul l'impact métier documenté le fera.

Définir les objectifs RTO et RPO pour votre organisation

L'Analyse d'Impact Métier (BIA) détermine vos objectifs de reprise. Selon le NIST SP 800-34, la BIA identifie les systèmes critiques, évalue les impacts dans le temps et documente les dépendances. Vous ne pouvez pas définir d'objectifs de reprise pertinents sans évaluation documentée de ce qui se passe réellement lors d'une défaillance système.

L'obligation fédérale établit votre seuil pour les systèmes critiques. Tout système d'information soutenant des fonctions essentielles (MEF), PMEF ou NEF doit respecter un Maximum Tolerable Downtime de 12 heures ou moins selon FCD-1. Les systèmes critiques de votre organisation nécessitent une justification documentée si le RTO dépasse ce seuil.

Les tests sont essentiels car  48 % des pannes proviennent de défaillances procédurales, selon l'Uptime Institute 2024 Resiliency Survey. Votre RTO documenté de quatre heures devient une fenêtre de reprise plus longue lors d'incidents réels si les procédures de restauration n'ont pas été validées. Les contrôles de planification de la continuité du NIST SP 800-53 exigent des exercices sur table annuels pour les systèmes à faible impact, des exercices fonctionnels pour les systèmes à impact modéré et des exercices grandeur nature pour les systèmes à fort impact.

Évitez la planification statique. Considérez le RTO et le RPO comme des paramètres dynamiques nécessitant une révision régulière à mesure que les exigences métier évoluent. Les objectifs de reprise que vous avez définis il y a trois ans pour une infrastructure sur site ne s'appliquent pas forcément à des  environnements cloud avec des modes de défaillance différents.

Même les organisations qui suivent cette méthodologie peuvent échouer. Les échecs les plus courants ne sont pas techniques ; ce sont des erreurs de planification qui n'apparaissent qu'en cas de sinistre.

Erreurs courantes sur le RTO et le RPO

Les organisations commettent systématiquement les mêmes erreurs de planification qui ne se révèlent que lors de scénarios de reprise réels.

1. Fixer des objectifs identiques pour tous les systèmes : Tous les systèmes ne méritent pas le même investissement. Les organisations qui appliquent des objectifs RTO et RPO uniformes surprotègent les systèmes non critiques et sous-protègent les systèmes critiques. Votre serveur de messagerie et votre plateforme de trading nécessitent des investissements de reprise différents.
2. Confondre fréquence de sauvegarde et RPO réel : Des sauvegardes horaires ne garantissent pas un RPO d'une heure. Votre RPO réel inclut le temps de complétion de la sauvegarde, le délai de réplication et les retards de vérification. Si les sauvegardes horaires prennent 45 minutes à s'exécuter et 15 minutes à se répliquer, votre RPO effectif approche deux heures, pas une.
3. Ignorer les dépendances système : Votre portail client peut avoir un RTO de quatre heures, mais s'il dépend d'une base de données avec un RTO de 24 heures, le RTO effectif de votre portail est de 24 heures. Cartographiez les dépendances avant de fixer les objectifs. Selon le NIST SP 800-34, la Business Impact Analysis doit documenter les interdépendances entre systèmes pour établir des séquences de reprise pertinentes.
4. Ne jamais tester les procédures de reprise : L'Uptime Institute documente que  48 % des pannes proviennent de défaillances procédurales. Votre RTO de quatre heures n'existe que sur le papier si votre équipe n'a jamais exécuté les étapes de restauration dans des conditions réalistes.
5. Oublier que la cybersécurité allonge le RTO : La reprise traditionnelle suppose des environnements sains. La reprise après ransomware exige la vérification des menaces, la rotation des identifiants et la validation des contrôles de sécurité avant le retour en production. Votre RTO infrastructurel devient votre plancher, pas votre plafond, lorsque les incidents de sécurité nécessitent une investigation forensique.

Éviter ces erreurs nécessite à la fois une planification rigoureuse et la bonne technologie. Lorsqu'un ransomware frappe, les procédures manuelles échouent souvent sous pression, précisément au moment où la reprise doit fonctionner.

Renforcez la reprise après sinistre avec SentinelOne

Lorsque des ransomwares chiffrent des fichiers sur votre environnement de production, la restauration traditionnelle à partir de sauvegardes signifie des heures de travail : identification du point de récupération sain, restauration des données, validation de l'intégrité, redémarrage des applications. Vous mesurez le RTO en heures ou en jours.

La plateforme Singularity de SentinelOne offre des capacités de réponse autonome conçues pour les scénarios de reprise après ransomware. La  behavioral AI de la plateforme détecte les menaces et peut déclencher un rollback autonome pour les endpoints affectés.  Singularity Endpoint identifie les ransomwares à l'aide de modèles d'IA comportementale et statique qui analysent les comportements anormaux en temps réel sans intervention humaine.

Lors des évaluations indépendantes MITRE ATT&CK, SentinelOne a généré 88 % d'alertes en moins que ses concurrents : seulement 12 alertes contre 178 000 pour d'autres fournisseurs. Cela permet aux équipes de sécurité de se concentrer sur les menaces vérifiées lors de la reprise plutôt que de trier un volume excessif d'alertes.

Purple AI, l'assistant analyste sécurité de SentinelOne, soutient la phase d'investigation des incidents qui allonge le RTO dans les scénarios de cybersécurité. Lorsque vous devez identifier le point de récupération sain vérifié, Purple AI permet des investigations sur les menaces 80 % plus rapides selon les premiers utilisateurs.

La plateforme Singularity répond à la principale cause d'échec documentée dans l'enquête 2024 de l'Uptime Institute :  48 % des pannes proviennent de défaillances procédurales. La réponse autonome réduit la dépendance aux procédures manuelles que le personnel exécute incorrectement sous pression.

Demandez une démonstration SentinelOne pour découvrir comment la réponse autonome et les capacités de Purple AI soutiennent des objectifs RTO et RPO ambitieux.

Points clés à retenir

Le RTO et le RPO mesurent différentes dimensions de la reprise après sinistre—tolérance à l'indisponibilité système versus perte de données acceptable—et nécessitent une planification indépendante. Les incidents de cybersécurité allongent significativement les objectifs RTO traditionnels, la CISA fixant 24 à 72 heures pour les systèmes critiques en raison des exigences de vérification des malwares et de validation des contrôles de sécurité.

L'Analyse d'Impact Métier détermine des objectifs de reprise pertinents, mais ces objectifs n'ont de valeur que s'ils sont testés. Les recherches de l'Uptime Institute montrent que 48 % des pannes proviennent d'une mauvaise exécution des procédures par le personnel. Les capacités de réponse autonome contribuent à réduire ce risque d'erreur humaine en réagissant sur la base de l'analyse comportementale plutôt que de procédures manuelles qui échouent sous pression.

FAQ sur RTO vs RPO

Qu'est-ce que le RTO et le RPO ?

L'objectif de temps de reprise (RTO) définit la durée maximale acceptable pendant laquelle vos systèmes peuvent rester indisponibles après une interruption avant que l'impact sur l'activité ne devienne inacceptable. L'objectif de point de reprise (RPO) définit la quantité de perte de données que votre organisation peut tolérer, mesurée comme l'intervalle de temps entre votre dernière sauvegarde viable et le moment où l'incident s'est produit. 

Le RTO se mesure à partir du sinistre (temps nécessaire pour rétablir les opérations), tandis que le RPO se mesure en remontant à partir du sinistre (dernier point de restauration utilisable). Les deux indicateurs sont nécessaires pour une planification complète de la reprise après sinistre.

Que se passe-t-il si mes objectifs RTO et RPO sont en conflit ?

Les objectifs RTO et RPO ne peuvent pas être en conflit car ils mesurent des dimensions de récupération différentes. Votre RTO définit le délai de restauration tandis que le RPO définit la perte de données acceptable. Un système peut avoir un RTO de quatre heures (délai pour rétablir les opérations) et un RPO de 15 minutes (intervalle du dernier sauvegarde).

Ces objectifs fonctionnent ensemble : vous rétablissez les opérations en quatre heures à l’aide de sauvegardes effectuées toutes les 15 minutes. Des conflits surviennent lorsque les organisations confondent les métriques ou définissent des objectifs sans Analyse d’Impact sur l’Activité. Si les exigences métier imposent un RTO d’une heure mais que vos capacités de restauration nécessitent huit heures, vous disposez d’une infrastructure de récupération inadéquate, et non d’objectifs contradictoires.

Comment calculer la durée maximale d'interruption tolérable ?

Le Maximum Tolerable Downtime (MTD) représente la limite supérieure absolue avant qu’un impact sur l’activité ne devienne catastrophique. Commencez par identifier la perte de revenus par heure, les seuils de pénalités réglementaires, les limites des SLA des contrats clients et les dommages concurrentiels liés à des interruptions prolongées. 

Selon NIST SP 800-34 Rev. 1, le MTD établit la contrainte dans laquelle le RTO doit s’inscrire. Votre RTO doit être inférieur au MTD avec une marge pour les complications imprévues lors de la reprise. Pour les systèmes de télécommunications assurant la continuité des fonctions essentielles de mission (MEFs), PMEF ou NEF, votre MTD ne peut pas dépasser 12 heures conformément à l’exigence FCD-1.

Les services de sauvegarde cloud peuvent-ils garantir mon RPO ?

Les services de sauvegarde cloud fournissent la technologie permettant d’atteindre des objectifs RPO spécifiques, mais ne peuvent garantir les résultats métier sans une configuration appropriée. Votre RPO dépend de la fréquence des sauvegardes, des taux de modification des données et du moment de la réplication. Un service cloud avec réplication continue prend en charge un RPO quasi nul si vous le configurez correctement. 

Des plannings de sauvegarde quotidiens entraînent un RPO de 24 heures, quelles que soient les capacités du cloud. Selon le NIST SP 800-53 Contrôle CP-6(2), vous devez configurer des sites de stockage alternatifs pour faciliter les opérations de reprise conformément aux objectifs de temps et de point de reprise. Le service fournit les fonctionnalités ; la configuration et la validation vous incombent.

Pourquoi la récupération après une attaque par ransomware nécessite-t-elle des délais RTO prolongés ?

Récupération après ransomware prolonge votre RTO car il ne s'agit pas seulement de restaurer les systèmes, mais aussi d'éliminer les menaces actives. Les Playbooks fédéraux de réponse aux incidents et vulnérabilités de cybersécurité de la CISA établissent que la récupération après ransomware nécessite une vérification de la suppression des malwares, la réinitialisation des contrôles de sécurité, l'analyse du renseignement sur les menaces et la remédiation des méthodes d'attaque avant de remettre les systèmes en production. 

La reprise après sinistre traditionnelle suppose des environnements de récupération sains, mais les incidents de cybersécurité contaminent les sauvegardes, compromettent les identifiants et nécessitent une  analyse forensique pour identifier des points de récupération propres et vérifiés. Le RTO typique après ransomware varie de 24 à 72 heures pour les systèmes critiques, contre des objectifs traditionnels de récupération d'infrastructure de 4 à 8 heures.

À quelle fréquence dois-je tester mes hypothèses RTO et RPO ?

Les contrôles de planification de la continuité du NIST SP 800-53 établissent des fréquences minimales de test selon le niveau d'impact du système : exercices sur table annuels pour les systèmes à faible impact, exercices fonctionnels avec récupération de sauvegarde pour les systèmes à impact modéré, et exercices à grande échelle avec basculement vers un site alternatif pour les systèmes à fort impact. 

L'enquête sur la résilience 2024 de l'Uptime Institute indique que 48 % des pannes proviennent du non-respect des procédures par le personnel des centres de données, confirmant que les plans de reprise non testés échouent lors d'incidents réels. Testez chaque trimestre pour les systèmes critiques, tous les six mois pour les systèmes métiers importants, et chaque année pour l'infrastructure de support.