Le bilan d'impact sur l'activité (BIA) : DMIA, PDMA et ressources critiques

Le bilan d'impact sur l'activité, ou BIA (de l'anglais business impact analysis), est l'analyse qui part des activités de l'organisation, et non de ses risques : pour chacune, on se demande ce qui se passerait si elle s'arrêtait, et comment la situation se dégraderait au bout d'une heure, d'une journée, d'une semaine. On l'appelle aussi analyse d'impact sur l'activité.

ISO 22301 en fait le premier volet de son article 8 (fonctionnement), aux côtés de l'appréciation des risques. L'ISO lui consacre une spécification technique dédiée, ISO/TS 22317:2021, et le règlement DORA l'impose explicitement aux entités financières (article 11). En France, le guide PCA du SGDSN décrit la même démarche sous l'angle des besoins de continuité des activités essentielles.

Le BIA répond à des questions différentes de celles de l'analyse de risques : il ne cherche pas ce qui pourrait arrêter une activité, mais ce que coûte son arrêt. Les deux se complètent, comme le montre la page d'accueil de ce guide.

Le BIA aboutit à deux durées par activité, que le guide du SGDSN définit et que l'on retrouve sous des noms anglais dans la plupart des outils :

Deux précisions évitent des malentendus fréquents. D'abord, la DMIA n'est pas le délai de reprise informatique : c'est une limite métier, que la solution technique doit tenir avec une marge. Ensuite, une DMIA courte ne veut pas forcément dire « redémarrer le système en quelques heures » : elle peut être tenue par un mode dégradé (procédures papier, fonctionnement manuel) qui laisse plus de temps à l'informatique. Le SGDSN demande alors de fixer pour chaque mode dégradé un niveau de service minimal et une durée maximale.

Le guide du SGDSN appelle activités essentielles celles qui sont nécessaires pour atteindre les objectifs de l'organisation et respecter ses obligations, légales, contractuelles ou de service public. ISO 22301 parle d'activités prioritaires. Pour chacune, le BIA recense les ressources critiques dont elle dépend, que le SGDSN range en cinq familles :

• les ressources humaines : effectifs minimaux, compétences rares, personnes habilitées ;
• les infrastructures : locaux, énergie, équipements ;
• les systèmes d'information : applications, données, réseaux, téléphonie ;
• les ressources immatérielles : savoir-faire, documentation, procédures ;
• les prestataires et fournisseurs externes.

Cette étape révèle souvent des dépendances oubliées : un unique infogérant, un logiciel métier hébergé chez un éditeur sans plan de secours, un annuaire dont dépendent toutes les applications. Les dépendances envers les tiers méritent un examen particulier, que prolongent la gestion des risques tiers et l'étude des attaques par la chaîne d'approvisionnement.

1. Cadrer : obtenir le mandat de la direction, fixer le périmètre (sites, activités) et les échelles d'impact. Reprenez les échelles déjà utilisées pour vos autres risques, comme le recommande aussi l'ANSSI pour EBIOS RM.
2. Recenser les activités du périmètre, en partant des processus et non des applications.
3. Évaluer les impacts dans le temps, en entretien avec chaque responsable métier : que se passe-t-il à 4 heures, 24 heures, 72 heures, une semaine, un mois ? Le SGDSN propose de coter les impacts humains, financiers, contractuels, environnementaux, juridiques et réglementaires, opérationnels, sociaux et d'image, sur une échelle de 1 (très faible) à 4 (très fort).
4. Fixer DMIA et PDMA, ainsi que le niveau de service minimal acceptable en mode dégradé.
5. Identifier les ressources critiques et les dépendances de chaque activité, y compris envers les prestataires.
6. Consolider et faire valider par la direction : classement des activités, objectifs retenus, arbitrages. C'est ce document validé qui engage ensuite la DSI et les métiers.

Deux décisions sont sorties de ce BIA. D'abord, imprimer chaque nuit les informations dont les services auraient besoin le lendemain si tout s'arrêtait. Ensuite, demander à la DSI de mesurer le délai réel de restauration du dossier patient : la réponse, plus de 30 heures, a montré que seul le mode dégradé permettait de tenir les objectifs. La suite au chapitre plan de reprise d'activité.

Un BIA vieillit vite : nouvelle application, nouveau prestataire, réorganisation d'un service. ISO 22301 attend qu'il soit revu régulièrement, notamment après un changement important. Le plus simple est de le relier aux autres référentiels de l'organisation : la classification DICP des applications, la cartographie des risques et l'inventaire des prestataires.