La planification de la continuité des activités échoue le plus souvent non pas pendant une crise, mais lors de l'évaluation qui la précède. Les entreprises réalisent des analyses d'impact sur l'activité, définissent des objectifs de temps de reprise, élaborent des plans de reprise complets, puis découvrent, au pire moment, qu'un service d'authentification hérité, apparemment non critique, constitue un point de défaillance unique pour l'ensemble de leur plateforme e-commerce ; que le programme COBOL, considéré comme peu prioritaire, alimente le service de validation des paiements en temps réel ; ou encore que deux applications ayant le même niveau de reprise présentent une dépendance non documentée qui rend impossible une reprise séquentielle. L'évaluation a été effectuée. Les dépendances, elles, ne l'ont pas été.
L'évaluation de la criticité des applications consiste à attribuer à chaque application du portefeuille d'une organisation une mesure quantitative ou hiérarchisée de son importance. Cette mesure détermine sa priorité de reprise, son niveau d'investissement en redondance, ses exigences en matière de gestion des changements et sa position dans le plan de reprise après sinistre. Lorsque cette évaluation repose uniquement sur des enquêtes d'impact métier et des entretiens avec les responsables d'applications, elle reflète la perception qu'ont les utilisateurs du fonctionnement des applications. En revanche, lorsqu'elle s'appuie sur une analyse structurelle du fonctionnement réel des applications (qui appelle qui, quels flux de données transitent par quels programmes, quels composants partagés se trouvent sur le chemin critique de plusieurs systèmes prioritaires), elle reflète la réalité opérationnelle.
C’est au niveau du fossé entre les convictions et la réalité que les plans de continuité d’activité échouent.
Séquences de rétablissement qui reflètent les dépendances réelles
SMART TS XL identifie chaque programme du chemin critique de vos applications de niveau 1, et ce, dans tous les langages de votre portefeuille.
EN SAVOIR PLUS…Que mesure réellement le score de criticité des applications ?
La criticité n'est pas une notion unidimensionnelle. Pour déterminer le score de criticité d'une application d'entreprise, il est possible de prendre en compte les retours des utilisateurs afin d'évaluer son importance, notamment son impact sur les besoins stratégiques de l'entreprise, ses répercussions sur les partenaires commerciaux, les interactions clients et les autres applications de l'entreprise. Chacune de ces dimensions reflète un aspect différent de la notion de « critique ».
L'impact sur l'activité correspond aux pertes subies par l'organisation par heure d'indisponibilité. La perte de revenus est la dimension la plus visible : un système de traitement des paiements qui gère 10 millions de dollars par heure a un coût quantifiable par minute d'indisponibilité. Mais l'impact sur l'activité ne se limite pas aux pertes de revenus ; il englobe également les risques réglementaires (quelles obligations de conformité la panne engendre-t-elle ?), l'atteinte à la réputation (les clients sont-ils directement touchés ?) et les sanctions contractuelles (les SLA déclenchent-ils des clauses pénales ?).
La dépendance opérationnelle désigne le nombre d'autres systèmes ou processus qui dépendent de cette application. Une application ayant un faible impact direct sur l'activité peut s'avérer très critique car elle se situe dans la chaîne de dépendance d'applications ayant un impact direct important. Le service d'authentification, indispensable au fonctionnement de toutes les autres applications destinées aux clients, est plus critique que sa propre fonction ne le laisse supposer.
La complexité de la récupération correspond à la difficulté et au temps nécessaire pour restaurer l'application. Une application ayant un impact modéré sur l'activité et un temps de récupération de 48 heures peut nécessiter un investissement plus important en redondance qu'une application ayant un impact plus important et un temps de récupération de 2 heures, car le risque total d'indisponibilité est plus élevé.
Obligation réglementaire : quelles applications sont soumises à des exigences de continuité réglementaire ? Les institutions financières soumises à la loi DORA doivent démontrer que leurs fonctions critiques ou importantes peuvent résister à des scénarios de perturbation spécifiques. Les organismes de santé soumis à la loi HIPAA doivent garantir la disponibilité des systèmes contenant des informations de santé protégées. La dimension réglementaire peut primer sur l’évaluation de l’impact sur l’activité pour certaines applications.
Le score de criticité est une synthèse des quatre dimensions, pondérée par la tolérance au risque spécifique de l'organisation, son environnement réglementaire et son modèle économique.
Les niveaux de criticité standard
La plupart des portefeuilles d'applications d'entreprise utilisent un modèle de criticité à quatre niveaux. Les catégories de criticité dans une matrice de criticité des applications sont : applications critiques pour la mission, applications critiques pour l'activité, applications opérationnelles et applications administratives. Les définitions ci-dessous reflètent les pratiques actuelles du secteur, conformément à la norme ISO 22301 (Systèmes de management de la continuité d'activité) et aux recommandations de bonnes pratiques du Business Continuity Institute.
Applications critiques de niveau 1, dont la défaillance interrompt immédiatement les opérations essentielles de l'entreprise ou engendre un risque inacceptable en matière de réglementation ou de sécurité. Objectif de temps de reprise (RTO) : généralement de 0 à 4 heures. Objectif de point de reprise (RPO) : généralement de 0 à 1 heure. Exemples : traitement des transactions bancaires, systèmes de négociation en temps réel, systèmes de gestion des urgences, interfaces de contrôle industriel, systèmes d'autorisation de paiement. Ces applications justifient un investissement maximal dans l'infrastructure : redondance active-active, réplication avec RPO nul, basculement automatique et gestion des changements rigoureuse.
Applications critiques de niveau 2 : leur défaillance perturbe significativement les opérations commerciales sans toutefois les interrompre immédiatement. Objectif de temps de récupération (RTO) : généralement de 4 à 24 heures. Objectif de point de récupération (RPO) : généralement de 1 à 4 heures. Exemples : systèmes CRM, modules ERP, gestion des commandes, systèmes RH pendant les périodes de paie, systèmes de reporting pendant les périodes de soumission réglementaire. Ces applications justifient une infrastructure à haute disponibilité, un basculement régulier et testé, ainsi qu’une séquence de reprise prioritaire.
Applications de niveau 3 : Applications opérationnelles qui prennent en charge les opérations métier, mais dont l’indisponibilité temporaire peut être gérée par des solutions de contournement manuelles. Objectif de temps de récupération (RTO) : généralement de 24 à 72 heures. Objectif de point de récupération (RPO) : généralement de 4 à 24 heures. Exemples : outils de collaboration interne, rapports non destinés aux clients, portails d’administration, plateformes de formation. Les procédures standard de sauvegarde et de restauration sont appropriées.
Niveau 4 : Applications administratives prenant en charge les fonctions d’administration sans impact opérationnel direct. Objectif de temps de récupération (RTO) : généralement plus de 72 heures. Objectif de point de récupération (RPO) : plus de 24 heures ou la dernière sauvegarde. Exemples : wikis de documentation interne, outils de développement non essentiels, rapports historiques. Restauration à partir d’une sauvegarde selon les besoins.
L'attribution d'un niveau de criticité n'est pas définitive. Une application de niveau 3 pendant la majeure partie de l'année peut passer au niveau 2 lors des clôtures financières mensuelles, des périodes de reporting réglementaire ou des pics d'activité boursière. La criticité dynamique, où le niveau de criticité évolue en fonction du calendrier opérationnel, est une amélioration que les organisations dotées de programmes de continuité d'activité (PCA) matures mettent en œuvre après avoir établi la structure de niveaux de référence.
Méthodologie de notation : traduire les dimensions en chiffres
Une méthodologie de notation structurée convertit les quatre dimensions de criticité en un score numérique qui détermine objectivement le niveau de criticité, indépendamment des enjeux politiques internes. L'approche ci-dessous produit un score composite de 0 à 100 à l'aide de critères pondérés :
Dimension 1 : Impact sur l'activité (pondération : 35 %)
| Impact sur le chiffre d'affaires par heure d'indisponibilité | Score |
|---|---|
| > 1 million de dollars par heure | 35 |
| 100 000 $ à 1 million de dollars par heure | 28 |
| 10 000 $ à 100 000 $ de l'heure | 21 |
| 1 000 $ à 10 000 $ de l'heure | 14 |
| Moins de 1 000 $ par heure | 7 |
| Aucun impact direct sur les revenus | 0 |
L'impact réglementaire (obligations de conformité DORA, HIPAA, PCI-DSS, SOX déclenchées par une panne) ajoute jusqu'à 10 points supplémentaires à cette dimension.
Dimension 2 : Dépendance opérationnelle (pondération : 30 %)
| Fan-In : Applications dépendant de cette application | Score |
|---|---|
| > 20 applications dépendantes | 30 |
| 10 à 20 applications dépendantes | 24 |
| 5 à 9 applications dépendantes | 18 |
| 2 à 4 applications dépendantes | 12 |
| 1 application dépendante | 6 |
| Aucune personne à charge (autonome) | 0 |
Le nombre d'applications entrantes correspond ici au nombre de dépendances structurelles, c'est-à-dire le nombre d'applications qui appellent cette application, lisent ses résultats ou dépendent de ses données, et non au nombre d'utilisateurs ou à l'importance perçue. Cette dimension est la plus souvent mal calculée dans les enquêtes, car les propriétaires d'applications ne connaissent pas tous leurs utilisateurs en aval.
Dimension 3 : Complexité de la récupération (pondération : 20 %)
| Temps de récupération estimé sans plan de reprise d'activité préconfiguré | Score |
|---|---|
| > Heures 72 | 20 |
| 24-72 heures | 16 |
| 8-24 heures | 12 |
| 2-8 heures | 8 |
| <2 heures | 4 |
| Basculement automatique en moins de 15 minutes | 0 |
Dimension 4 : Sensibilité des données et obligation réglementaire (pondération : 15 %)
| Classification des données et exigences réglementaires | Score |
|---|---|
| Données PII/PHI/CHD réglementées avec obligation de délai de récupération explicite | 15 |
| Données réglementées sans obligation de délai de récupération spécifique | 12 |
| Données internes sensibles (secrets commerciaux, documents financiers) | 9 |
| données opérationnelles internes | 6 |
| Données internes non sensibles | 3 |
| Aucune donnée stockée | 0 |
Correspondance entre le score composite et le niveau :
| Score composite | Attribution des niveaux |
|---|---|
| 75-100 | Niveau 1, Mission critique |
| 50-74 | Niveau 2, critique pour l'entreprise |
| 25-49 | Niveau 3, Opérations commerciales |
| 0-24 | Niveau 4, administratif |
Le problème de la dépendance : pourquoi la notation basée sur des enquêtes se trompe
La dimension de dépendance opérationnelle est celle qui risque le plus d'être mal évaluée, et c'est celle dont l'erreur a les conséquences les plus graves. Un service d'authentification hérité, apparemment non critique, peut constituer un point de défaillance unique pour toute une plateforme de commerce électronique, et sa défaillance pourrait paralyser toutes les transactions génératrices de revenus. Ce processus permet de passer des menaces abstraites aux impacts concrets et mesurables sur les accords de niveau de service.
Les responsables d'applications connaissent leurs dépendances amont directes, c'est-à-dire les systèmes qu'elles appellent. Ils connaissent rarement l'intégralité de leurs dépendances aval, c'est-à-dire les systèmes qui les appellent. Un service d'authentification utilisateur interne peut être considéré comme peu critique par son responsable (il ne génère pas de revenus, il est simple et il tombe rarement en panne), alors qu'il est indispensable à douze applications destinées aux clients, toutes de niveau 1. La criticité réelle de ce service d'authentification est de niveau 1, non pas en raison de sa fonction propre, mais en raison de sa position dans le graphe de dépendances des systèmes de niveau supérieur.
L'évaluation de la criticité basée sur des enquêtes produit systématiquement cette erreur. Une enquête auprès des propriétaires d'applications leur demande : « Quel est le niveau de criticité de cette application ? » Le responsable du service d'authentification répond « faible à moyen » en fonction de la fonctionnalité de son service. Les douze responsables des applications dépendantes ne répondent pas à cette enquête concernant le service d'authentification, mais concernant leurs propres applications. La relation de dépendance n'est donc jamais prise en compte.
La conséquence se manifeste dans la séquence de reprise : le plan de continuité d’activité (PCA) définit l’ordre de reprise en fonction des scores de criticité issus de l’enquête, et le service d’authentification est programmé pour une reprise de niveau 3. Lors d’un incident réel, les applications de niveau 1, qui devraient être rétablies en premier, ne peuvent pas l’être car le service d’authentification dont elles dépendent n’a pas été restauré. La séquence de reprise échoue au niveau de sa dépendance la plus critique.
Trois types de dépendance que les enquêtes omettent systématiquement :
Composants partagés cachés. Un programme COBOL interne gérant la conversion de devises pour trois processus métier distincts, dont aucun composant n'a été identifié comme partageant lors de l'enquête, constitue une dépendance cachée affectant la reprise des trois processus. Si le programme de conversion de devises est de niveau 3 et que l'un des trois processus métier est de niveau 1, la criticité effective du programme de conversion de devises est de niveau 1.
Dépendances liées au pipeline de données. Les applications qui consomment des données traitées par lots provenant d'autres applications présentent une dépendance temporelle, et non en temps réel. Le risque n'est pas une défaillance simultanée, mais séquentielle : l'application en aval se rétablit, mais sa source de données n'a pas été restaurée au même point de restauration, ce qui donne l'illusion d'un fonctionnement correct sur des données obsolètes. Ce type de dépendance n'apparaît pas dans les schémas de topologie réseau ni dans l'analyse du graphe d'appels, sauf si le flux de données lui-même est tracé.
Dépendances de configuration et de schéma partagées. Les applications qui partagent des schémas de base de données, des services de configuration ou des fournisseurs d'identité présentent une dépendance implicite, même si elles ne communiquent jamais directement entre elles. Une modification de schéma dans une base de données partagée peut affecter plusieurs applications. La restauration d'une seule application après une corruption de schéma, sans restaurer toutes les applications partageant ce schéma, engendre un état incohérent au sein du parc applicatif.
Intégration du plan de continuité d'activité : comment les scores de criticité influencent les décisions de reprise
Le score de criticité sert de donnée d'entrée pour six décisions spécifiques de conception du plan de continuité des activités :
1. Définition de la séquence de récupération. Les applications sont récupérées par ordre de criticité : niveau 1 avant niveau 2, puis niveau 3. Au sein d’un même niveau, la séquence est déterminée par le graphe de dépendances. Les applications sans dépendances entrantes (aucune autre application ne dépend d’elles) peuvent être récupérées dans n’importe quel ordre au sein de leur niveau. Les applications ayant un fan-in élevé doivent être récupérées avant leurs dépendantes, indépendamment de leur score relatif au sein du niveau. La séquence de récupération est donc : l’ordre des niveaux appliqué à la sous-séquence contrainte par les dépendances au sein de chaque niveau.
2. Définition des objectifs RTO et RPO. Le score de criticité calibre les objectifs RTO et RPO. La durée maximale d'indisponibilité tolérable (MTD) et l'objectif de point de récupération (RPO) de chaque application de production constituent le fondement technique de la stratégie de continuité d'activité. La MTD correspond à la durée maximale d'indisponibilité d'une application que l'entreprise peut tolérer. Le RTO doit être inférieur à la MTD. La marge entre le RTO et la MTD représente la marge de sécurité. Les applications critiques (Tier 1), dont l'impact sur l'activité est élevé par heure d'indisponibilité, présentent des marges MTD/RTO étroites et nécessitent une infrastructure conçue pour une reprise automatisée rapide.
3. Calibrage des investissements d'infrastructure. Les scores de criticité déterminent directement les décisions d'investissement dans l'infrastructure de reprise après sinistre. Les applications de niveau 1 justifient une redondance active-active multirégionale. Les applications de niveau 2 justifient une redondance active-passive avec basculement testé. Les applications de niveau 3 justifient des sauvegardes régulières avec des procédures de restauration documentées. Les applications de niveau 4 peuvent s'appuyer sur des politiques de sauvegarde standard. Sans scores de criticité, les décisions d'investissement d'infrastructure aboutissent par défaut soit à un surinvestissement uniforme (coûteux), soit à un sous-investissement uniforme (risqué).
4. Exigences de gestion des changements. Les applications à criticité élevée nécessitent une gestion des changements plus rigoureuse : périodes de gel des changements plus longues, davantage d’approbateurs obligatoires, tests préalables aux changements plus approfondis et procédures de restauration plus prudentes. Appliquer une gestion des changements de niveau 1 à des applications de niveau 4 représente une perte de temps pour les ingénieurs. Appliquer une gestion des changements de niveau 4 à des applications de niveau 1 engendre un risque inacceptable.
5. Fréquence des tests et de la validation. Le plan de continuité d'activité (PCA) exige des tests périodiques des procédures de reprise, des exercices de simulation, des tests de basculement au niveau des composants et des simulations complètes de reprise après sinistre. La fréquence des tests est déterminée par le niveau de criticité : les applications de niveau 1 nécessitent des tests trimestriels ; celles de niveau 4, des tests annuels. Tester toutes les applications à la même fréquence n'est ni pratique ni nécessaire.
6. Exigences relatives aux SLA des fournisseurs. Pour les applications dépendant de services tiers, le niveau de criticité détermine les exigences des SLA qui doivent figurer dans les contrats fournisseurs. Une application de niveau 1 avec un RTO de 4 heures nécessite un SLA tiers garantissant une disponibilité conforme à ce RTO. Ce n'est pas le cas pour une application de niveau 4.
La complication du système hérité
Les systèmes hérités complexifient l'évaluation de la criticité d'une manière que les cadres modernes de gestion de portefeuille d'applications ne prennent pas suffisamment en compte. L'évaluation standard de la criticité part du principe que les responsables d'applications connaissent le fonctionnement de leurs applications et les applications qui en dépendent. Or, pour les systèmes hérités – programmes COBOL maintenus par plusieurs générations de développeurs, flux de travaux JCL dont les dépendances n'ont pas été documentées depuis 2008, programmes RPG produisant des fichiers de sortie utilisés par des processus et écrits par des personnes n'existant plus dans l'organisation –, cette hypothèse ne se vérifie pas.
La structure de dépendances réelle d'un système existant n'est visible que dans le code lui-même. Un programme COBOL qui écrit dans un fichier de données lu par douze programmes en aval possède douze dépendances en aval, mais ce fait peut être inconnu du propriétaire du programme COBOL, qui ne perçoit que sa fonction (traitement des transactions quotidiennes) plutôt que son rôle structurel (production du fichier de données permettant l'exécution de douze autres processus).
Pour les systèmes existants, l'évaluation de la criticité par la dimension de dépendance nécessite une analyse du code plutôt que des enquêtes auprès des propriétaires. Le nombre de programmes entrants d'un programme COBOL ne peut être déterminé qu'en examinant tous les autres programmes de l'environnement et en identifiant ceux qui référencent les fichiers de sortie, les conventions d'appel ou les copybooks partagés du programme initial. Cette analyse est précisément ce que proposent les plateformes d'analyse structurelle de code ; sans elle, l'évaluation de la criticité d'un programme existant par la dimension de dépendance n'est, au mieux, qu'une estimation.
Les conséquences d'une mauvaise évaluation de la criticité des applications existantes sont particulièrement graves, car ces systèmes sont souvent à la fois hautement critiques (ils contiennent fréquemment une logique métier essentielle accumulée au fil des décennies) et mal évalués (leurs responsables peinent à identifier précisément ce qui en dépend et attribuent donc des scores conservateurs). Il en résulte des programmes classés en niveau 3 alors qu'ils se trouvent en réalité sur le chemin critique de processus métier de niveau 1, soit le mode de défaillance exact qui se produit lors des échecs de la séquence de reprise après incident.
Comment SMART TS XL Fournit les preuves de dépendance pour l'évaluation de la criticité
SMART TS XL aborde directement la dimension de dépendance de l'évaluation de la criticité des applications, pour la classe d'applications pour lesquelles les approches basées sur des enquêtes sont les moins fiables.
La fonctionnalité de cartographie des dépendances applicatives construit le graphe de dépendances complet pour chaque langage de l'environnement : chaque programme COBOL appelant un autre, chaque étape de tâche JCL produisant des données utilisées par les programmes en aval, chaque copybook partagé créant une dépendance implicite entre des programmes qui ne s'appellent jamais directement, chaque ensemble de données circulant entre les programmes producteurs et consommateurs. Ce graphe constitue la base de données structurelles pour le calcul de la criticité par dépendance, le décompte des entrées, l'identification des composants partagés et les dépendances cachées du pipeline de données que les enquêtes ne peuvent pas détecter de manière fiable.
La fonctionnalité d'analyse d'impact permet d'interroger le graphe de dépendances pour la planification de la continuité d'activité : pour chaque application du portefeuille, on peut énumérer toutes les autres applications qui en dépendent, directement ou indirectement, et qui héritent donc de ses exigences de disponibilité. Un programme COBOL avec trois dépendants directs et vingt dépendants transitifs (programmes qui dépendent des dépendants directs) a une criticité effective qui reflète celle des vingt-trois programmes dont il fait partie du chemin critique, et non seulement sa propre fonction.
L' analyse statique du code révèle les métriques de complexité structurelle qui renseignent sur la complexité de la restauration : complexité cyclomatique, métriques de couplage, pourcentage de code mort et indicateurs de dette technique. Ces indicateurs permettent de prédire la durée et le niveau de risque de la restauration de chaque application. Une application complexe et fortement couplée est plus coûteuse à restaurer (son score de complexité de restauration, dimension 3, est plus élevé) qu'une application aux fonctionnalités équivalentes et à l'architecture propre.
La fonction de recherche d'entreprise permet d'interroger l'inventaire complet des dépendances tout au long du cycle de vie du plan de continuité d'activité : elle permet de trouver chaque programme accédant à un ensemble de données spécifique (identifiant ainsi tous les programmes qui dépendent de sa disponibilité), chaque programme partageant un copybook spécifique (identifiant ainsi tous les programmes affectés par sa disponibilité), chaque tâche JCL exécutée dans une fenêtre de traitement par lots spécifique (identifiant ainsi tous les programmes devant être récupérés avant le début de cette fenêtre). Cette fonction de recherche facilite la revue annuelle des scores de criticité, processus de mise à jour qui permet de maintenir ces scores à jour au fur et à mesure de l'évolution du portefeuille d'applications.
Pour les organisations menant modernisation de l'héritage programmes parallèlement au développement du plan de continuité des activités, SMART TS XLL'analyse de [nom de l'entreprise] remplit simultanément les deux objectifs : la carte des dépendances qui renseigne sur le score de criticité détermine également le séquencement des migrations, et les indicateurs de complexité qui renseignent sur le score de complexité de la récupération déterminent également l'estimation des efforts de modernisation.
Mise à jour des scores : le cycle de révision annuel
Une évaluation de la maturité en matière de continuité d'activité devrait vous aider à accomplir trois choses : comprendre votre situation actuelle, identifier les lacunes les plus importantes et définir un plan d'amélioration réaliste. C'est ce qui transforme l'évaluation de la maturité en un programme plus efficace.
Les scores de criticité des applications s'éloignent de la réalité à mesure que les organisations évoluent. De nouvelles applications sont ajoutées. D'anciennes applications sont mises hors service, mais pas complètement. Des intégrations sont créées entre des applications qui étaient auparavant indépendantes. Les processus métier évoluent, et avec eux les applications dont ils dépendent. Les exigences réglementaires évoluent et imposent de nouvelles obligations de reprise.
Le cycle annuel de révision des scores de criticité devrait inclure :
Réanalyse structurelle. Relancez la cartographie des dépendances afin d'identifier les nouvelles dépendances apparues depuis la dernière analyse. Des applications auparavant autonomes peuvent désormais présenter des dépendances qui augmentent leur criticité. Des applications fortement dépendantes peuvent avoir vu leurs utilisateurs migrer vers des systèmes plus récents, réduisant ainsi leur criticité.
Réévaluation de l'impact sur l'activité. Les chiffres relatifs à l'impact sur le chiffre d'affaires et les opérations évoluent en fonction de la croissance de l'entreprise et de son portefeuille d'applications. Une application qui générait 1 000 $ de valeur ajoutée par heure il y a trois ans peut désormais en générer dix fois plus suite à la croissance de l'activité.
Intégration des résultats des tests de récupération. Les tests de récupération révèlent des écarts entre la complexité de récupération supposée et la complexité de récupération réelle. Une application ayant obtenu un faible score de complexité de récupération lors de l'évaluation initiale peut avoir obtenu de mauvais résultats lors d'un exercice sur table, ce qui suggère une révision à la hausse du score.
Examen des modifications réglementaires. Les nouvelles réglementations ou les modifications apportées aux réglementations existantes peuvent imposer de nouvelles obligations de délai de rétablissement à certaines applications. Par exemple, les exigences de résilience opérationnelle du règlement DORA pour les institutions financières de l'UE ont imposé des obligations de délai de rétablissement spécifiques aux « fonctions critiques ou importantes », obligations qui n'étaient pas nécessairement prises en compte dans les scores de criticité antérieurs à DORA.
Les organisations dotées de programmes de continuité d'activité matures considèrent l'évaluation de la criticité non pas comme un exercice ponctuel, mais comme un processus continu : les scores sont mis à jour lorsque des changements importants surviennent au niveau des dépendances des applications, de l'impact sur l'activité ou des obligations réglementaires, et validés annuellement par le biais d'un examen structuré.
La qualité du score dépend de la qualité des preuves de dépendance.
L'évaluation de la criticité des applications est plus pertinente lorsque sa dimension de dépendance repose sur des données structurelles plutôt que sur des enquêtes. Les dimensions « impact sur l'activité » et « obligations réglementaires » peuvent être évaluées de manière fiable par le biais d'entretiens et d'analyses des processus métier. En revanche, la dimension de dépendance opérationnelle ne peut être évaluée, car elle suppose de connaître les éléments dépendants de chaque application, or les responsables d'applications sous-estiment systématiquement leurs utilisateurs en aval.
Le mode de défaillance est prévisible : une séquence de reprise basée sur des scores de criticité issus d’enquêtes échoue au niveau des dépendances cachées. Un service d’authentification obsolète effectue une restauration tardive. Un programme de conversion de devises COBOL est hors ligne lorsque les applications qui en dépendent tentent une reprise. Un schéma de base de données partagé se trouve à un point de reprise différent de celui des applications qui y accèdent. Chacune de ces défaillances est évitable grâce aux informations sur les dépendances fournies par l’analyse structurelle, et chacune s’avère coûteuse lorsqu’elle survient lors d’un incident réel plutôt que lors d’un exercice de simulation.
La méthodologie de notation est établie. Les cadres de référence existent. Le problème de la plupart des organisations ne réside pas dans le cadre de notation lui-même, mais dans les données probantes relatives à sa dimension la plus cruciale. Comblez cet écart par une analyse structurelle avant que le prochain incident ne nécessite la mise en œuvre du plan de continuité d'activité.
