Business Impact Analysis (BIA) : comment définir les priorités de reprise de votre PRA ?

1. Qu'est-ce qu'un business impact analysis ?

Le BIA part des activités de l'organisation, pas de son infrastructure. Pour chaque activité ou service rendu, il cherche à établir ce qu'une interruption provoque, et à partir de quelle durée ces effets deviennent inacceptables.

Le guide de planification de continuité du NIST (SP 800-34 Rev. 1) organise ce travail en trois temps : déterminer les processus métier et leur criticité de reprise, identifier les ressources nécessaires à leur reprise, puis fixer l'ordre de reprise de ces ressources.

BIA et analyse de risques : deux questions différentes

L'analyse de risques s'intéresse aux menaces, à leur probabilité et aux mesures qui les réduisent. Le BIA pose une autre question : quelle que soit la cause d'une interruption, quelles en sont les conséquences et dans quel ordre faut-il reprendre ?

Les deux démarches se complètent. L'analyse de risques aide à choisir les scénarios à préparer. Le BIA aide à décider ce qui doit être protégé et relancé en priorité.

Un outil d'arbitrage avec les métiers

Toutes les activités ne peuvent pas être prioritaires. Le BIA rend ces arbitrages explicites : il oblige à comparer les activités entre elles, à documenter pourquoi l'une passe avant l'autre et à faire valider ce classement par ceux qui en portent les conséquences.

2. Pourquoi le BIA précède le PRA et les objectifs RTO/RPO

Un plan de reprise met en œuvre des décisions qui doivent être prises en amont. La chaîne se lit dans cet ordre :

1. Priorités métiers : ce que l'organisation doit maintenir ou relancer en premier.
2. BIA : les impacts dans le temps, les durées d'interruption tolérables et les dépendances de chaque activité.
3. Objectifs RTO et RPO : la traduction de ces priorités en délais de reprise et en pertes de données acceptables, système par système.
4. Stratégie de reprise : les modes dégradés et les moyens de sauvegarde, de restauration ou de secours retenus pour tenir ces objectifs.
5. Tests et amélioration : la vérification que ces objectifs sont tenus en pratique, et la correction des écarts.

Dans cette logique, les choix techniques viennent après la criticité métier. Les contraintes techniques restent déterminantes, mais à l'étape suivante : elles servent à vérifier si les objectifs issus du BIA sont réalistes, et à arbitrer lorsqu'ils ne le sont pas.

C'est sur cette base que l'on peut ensuite définir des objectifs RTO et RPO fondés sur les besoins réels plutôt que sur des valeurs types.

3. Les informations à recueillir pour chaque activité critique

Il n'existe pas de formulaire obligatoire. La grille ci-dessous rassemble les informations le plus souvent utiles ; elle est à adapter au périmètre et à la maturité de l'organisation.

• Activité ou service rendu : ce que l'activité produit, pour qui, et qui en est responsable.
• Impacts d'une interruption selon sa durée : opérationnels, contractuels, financiers, réglementaires ou relationnels, lorsqu'ils sont pertinents. L'intérêt est de voir comment ces impacts évoluent après quelques heures, une journée, une semaine.
• Durée d'interruption tolérable : le délai au-delà duquel les conséquences deviennent inacceptables. Elle est décidée par les responsables concernés, pas déduite des capacités techniques.
• Perte de données tolérable : la quantité d'informations que l'activité peut perdre ou ressaisir sans conséquence grave.
• Dépendances : personnes et compétences clés, sites, applications, données, équipements, fournisseurs, partenaires, et moyens manuels utilisables en mode dégradé.
• Conditions de reprise : ce qui doit être disponible et vérifié pour que l'activité redémarre, et qui valide ce redémarrage.

Le NIST insiste sur le recensement des ressources nécessaires à la reprise et de leurs interdépendances. L'ANSSI rappelle de son côté qu'il n'est pas réaliste de tout cartographier, et qu'il faut commencer par les applications critiques.

4. Comment conduire un BIA en pratique

La démarche suivante est un cadre de travail. Son niveau de détail dépend de la taille de l'organisation, du périmètre retenu et des décisions attendues.

Étape 1 : définir le périmètre et les décisions attendues

Préciser quelles entités, quels sites et quelles activités sont couverts, et à quoi serviront les résultats : construire un premier PRA, réviser des priorités existantes, préparer un exercice, choisir une solution de reprise. Sans décision attendue, le BIA risque de rester un document de plus.

Étape 2 : préparer les ateliers avec les responsables métiers et IT

Identifier les interlocuteurs qui connaissent réellement chaque activité, puis leur transmettre la grille à l'avance. Les ateliers sont plus productifs quand les participants viennent avec leurs exemples d'incidents passés, leurs engagements clients et leurs contraintes de délai.

Étape 3 : cartographier activités, services et dépendances

Relier chaque activité aux applications, données, infrastructures, prestataires et personnes dont elle a besoin. Les dépendances transverses, comme l'annuaire, la messagerie, le réseau ou un fournisseur cloud, apparaissent souvent à cette étape et modifient l'ordre de reprise.

Étape 4 : qualifier les impacts dans le temps et les priorités

Pour chaque activité, décrire les impacts à plusieurs horizons de temps, puis en déduire une durée d'interruption tolérable et un niveau de priorité. Les échelles d'impact sont à définir avec la direction pour que les activités soient comparables entre elles.

Étape 5 : arbitrer, documenter et réutiliser les résultats

Consolider les résultats, trancher les conflits de priorité et faire valider le classement. Les résultats alimentent ensuite les objectifs de reprise, la stratégie de continuité, les procédures et le choix des scénarios de test.

Qui décide de la criticité ? Les résultats doivent être validés par les responsables métiers et par la direction. L'IT apporte la connaissance des systèmes et des dépendances, mais ne peut pas décider seule de ce qui est critique pour l'activité.

5. Du BIA aux RTO/RPO et aux scénarios de reprise

Les objectifs de reprise découlent du BIA. Pour chaque activité, la durée d'interruption tolérable encadre le délai dans lequel les systèmes qui la soutiennent doivent être remis en service, en tenant compte des étapes qui suivent la restauration technique : vérifications, reprise des traitements, ressaisie. La perte de données tolérable oriente le RPO, et donc la fréquence et le type de sauvegardes.

Le NIST distingue ainsi la durée d'arrêt maximale acceptée pour l'activité et le délai de reprise de chaque ressource, qui doit normalement être plus court pour laisser le temps aux opérations qui suivent la restauration.

Ces objectifs doivent ensuite être vérifiés. Un RTO défini dans un tableur reste une hypothèse tant qu'une restauration en conditions réalistes n'a pas montré qu'il peut être tenu. Les écarts constatés conduisent soit à renforcer les moyens de reprise, soit à revoir les priorités avec les métiers.

Le BIA sert aussi à choisir les scénarios à exercer et les activités à couvrir en priorité pour tester concrètement son PRA.

6. Prendre en compte les scénarios cyber et les tiers

Un BIA construit uniquement autour de la panne d'un serveur ou d'un site sous-estime souvent les situations les plus difficiles. Le guide de gestion de crise d'origine cyber de l'ANSSI souligne qu'une crise cyber peut rendre plusieurs ressources indisponibles en même temps, et que le plan de continuité doit intégrer la perte d'une solution cloud, d'un partenaire ou d'un prestataire.

Il est donc utile de confronter les priorités du BIA à des situations comme :

• l'indisponibilité d'une application centrale, ou de plusieurs applications à la fois ;
• la perte d'un site ou d'un datacenter ;
• la défaillance d'un fournisseur ou d'un service cloud ;
• la compromission des identités et de l'annuaire ;
• la perte des moyens de communication habituels.

Après un incident cyber, la reprise peut aussi devoir composer avec une compromission encore active. Avant de redémarrer un service, il faut évaluer l'intégrité des données et des systèmes, et disposer d'une copie saine à restaurer. L'ANSSI note d'ailleurs qu'une crise cyber peut fausser les mesures définies en amont, comme la durée d'arrêt maximale : les durées tolérables du BIA sont à confronter à des scénarios d'indisponibilité longue.

Pour les dépendances externes, le BIA peut préciser les coordonnées utiles, les engagements de secours prévus au contrat et les modes de fonctionnement dégradés possibles si le prestataire est lui-même touché. Le BIA ne désigne pas une architecture : il fournit les priorités à partir desquelles choisir une architecture de reprise.

7. Les erreurs fréquentes dans un BIA

• Partir de la liste des serveurs au lieu des services rendus, ce qui donne un inventaire technique plutôt que des priorités.
• Confondre priorité technique et priorité métier. Un système très utilisé n'est pas forcément critique pour l'activité, et inversement.
• Ignorer les tiers et les dépendances transverses. Un service restauré peut rester inutilisable si l'annuaire, le réseau ou un fournisseur manque.
• Appliquer les mêmes RTO et RPO à toutes les activités, sans lien avec leurs impacts réels.
• Oublier le BIA une fois rédigé, au lieu de le réutiliser dans les tests et lors des changements majeurs : nouvelle application, migration, changement de prestataire, réorganisation.

Ces erreurs se retrouvent ensuite dans le plan de reprise. Nous détaillons les erreurs fréquentes dans un PRA ou PCA et la façon de les corriger.