Votre BIA est probablement un tableur rempli par une seule personne.

Parlons du BIA qui dort dans votre espace de partage.

Celui où l'IT a renseigné les niveaux d'impact un mardi après-midi, l'a envoyé au responsable BC pour « relecture », et personne n'y a retouché jusqu'à ce que l'auditeur le réclame.

Vous voyez lequel.

Toutes les colonnes sont au niveau « Élevé ». Ou au niveau « Moyen ». Personne ne se souvient de ce que signifient les seuils. Pas de RTO. Pas de MTPoD. Pas de dépendances système. Pas de colonne de continuité, parce que personne n'a pensé à ce qui se passe après l'approbation du tableur.

Et quand la vraie perturbation arrive ? Personne n'ouvre le BIA. Parce que le BIA n'apporte rien d'utile.

C'est ce BIA-là que nous remplaçons.

Pourquoi la plupart des BIA échouent

Un BIA n'est pas un formulaire. C'est une conversation. Et la plupart des organisations sautent la conversation pour aller directement au formulaire.

Voici ce qui dysfonctionne :

• L'IT travaille seul. Un BIA est un exercice métier. Si le CFO, le responsable des opérations et le responsable commercial n'ont pas participé, votre BIA est une supposition dans un tableur.
• Les niveaux d'impact ne sont pas définis. « Élevé » ne signifie rien si vous n'avez pas défini ce que « Élevé » représente en euros, en clients perdus, en exposition réglementaire.
• Il couvre les systèmes mais oublie les personnes. L'indisponibilité de votre ERP est un problème. L'incapacité totale de votre équipe finance à travailler en est un autre.
• Il couvre les systèmes mais oublie les sites. Si votre siège est inaccessible, votre plan de continuité fonctionne-t-il vraiment ?
• Il n'y a pas de dimension temporelle. Perdre la messagerie 4 heures, c'est gênant. La perdre 10 jours, c'est catastrophique. Un BIA sans matrice d'impact dans le temps est un instantané, pas une analyse.
• Le RTO et le MTPoD sont absents. Si vous ne définissez pas la vitesse de restauration requise et la durée maximale tolérable de perturbation, votre équipe DR improvise.

Ce que nous avons construit

Nous avons construit le modèle de BIA que nous utilisons réellement dans nos missions de conseil ISO 22301. Puis nous l'avons mis à disposition gratuitement.

Trois sections d'évaluation. Un référentiel de définition des impacts. Zéro ambiguïté.

Section 1 : Personnes

ColonneCe qu'elle captureDépartement / FonctionChaque unité métier, pas uniquement l'ITPrioritéÉlevé / Moyen / Faible : niveau de criticité du départementResponsable de départementPropriétaire nommé, pas « la personne responsable »EffectifTemps plein, temps partiel, prestataires : l'effectif influe sur la repriseLieu de travailD'où ils opèrent : oriente la planification des sites alternatifsImpact dans le tempsMatrice à 4 niveaux : 0–1 jour, 2–4 jours, 5–10 jours, >10 joursDépendances systèmesLes systèmes sans lesquels cette équipe ne peut pas fonctionner

Ce n'est pas une simple liste de départements. C'est une cartographie de la façon dont votre organisation se dégrade quand les personnes ne peuvent plus travailler.

Section 2 : Systèmes

ColonneCe qu'elle captureRôle du systèmeEn langage clair, pas le nom commercial du fournisseurNom du systèmeLe nom réel du systèmeUtilisateursLes équipes qui dépendent de ce systèmeRTORecovery Time Objective : délai maximal de restaurationMTPoDMaximum Tolerable Period of DisruptionImpact dans le tempsMême matrice à 4 niveaux : escalade de Faible à CatastrophiqueDépendancesPersonnes, fonctions, départements qui en dépendentContinuitéCe que vous déployez quand ce système tombe

Pré-renseigné avec les systèmes courants : application cœur de métier, comptabilité, RH, messagerie, stockage de fichiers, site web, hébergement web, gestion du code source, CRM, plus des lignes vierges pour les vôtres.

Section 3 : Sites

ColonneCe qu'elle captureNom du siteSiège, agences, centres de donnéesLocalisationAdresse physiqueUtilisateursLes équipes basées sur ce siteRTODélai maximal pour rendre le site à nouveau opérationnelMTPoDDurée maximale tolérable sans ce siteImpact dans le tempsMême matrice d'escalade à 4 niveauxDépendancesÉquipes et fonctions impactéesContinuité« Le télétravail » n'est pas toujours la réponse : quelle est la vôtre ?

« La plupart des BIA omettent complètement les sites. Puis l'inondation arrive et personne ne sait quelles équipes sont touchées, quels systèmes étaient hébergés là-bas, ni où les personnes doivent se rendre. »

Définitions des niveaux d'impact

Le modèle inclut un onglet dédié définissant quatre niveaux d'impact :

NiveauSeuil financierSignificationCatastrophique>100 000 £Risque vital. L'organisation ne peut plus satisfaire ses obligations légales. Cessation d'activité possible.Élevé30 000–50 000 £Préjudice exceptionnel. Risque de perte de clients et de contrats.Moyen10 000–30 000 £Impact interne ressenti. Faible risque pour l'activité. Faible impact client.Faible<10 000 £Impact nul ou négligeable.

« Adaptez les seuils à votre organisation, mais conservez la structure. L'objectif est que lorsqu'une personne sélectionne « Élevé », tout le monde dans la salle sache exactement ce que cela signifie. »

À qui s'adresse ce modèle

• Responsables BC qui réalisent leur premier BIA ou refont un BIA défaillant
• CISO et risk managers qui doivent relier la reprise informatique après sinistre à l'impact métier
• Implémenteurs ISO 22301 qui ont besoin d'une preuve documentée du BIA pour la certification
• Organisations concernées par NIS2 , l'article 21 exige des mesures de continuité d'activité, et le BIA en est le point de départ
• Entités régulées par DORA , les articles 11 et 12 exigent des tests de continuité TIC fondés sur une analyse d'impact
• Consultants qui en ont assez de construire des modèles de BIA from scratch pour chaque client

Comment l'utiliser

• Commencez par les Personnes. Réunissez les responsables de département. Pas uniquement l'IT. Renseignez ensemble les priorités, les effectifs, les sites et l'impact dans le temps.
• Passez aux Systèmes. Pour chaque système, définissez le RTO et le MTPoD. Renseignez la matrice d'impact. Documentez la continuité : « on verra le moment venu » n'est pas un plan de continuité.
• Couvrez les Sites. Chaque site physique. Que se passe-t-il s'il est indisponible un jour ? Une semaine ? Deux semaines ?
• Calibrez avec l'onglet Niveaux d'impact. Assurez-vous que tout le monde s'accorde sur la définition de « Catastrophique » avant que quiconque commence à noter.
• Révisez trimestriellement. Un BIA vieux de 12 mois est une fiction. Les systèmes évoluent, les personnes changent de poste, les priorités se déplacent.

Téléchargez-le

Adaptez les seuils financiers, ajoutez vos départements et vos systèmes : vous disposez d'un BIA opérationnel en une après-midi. Pas d'un BIA parfait, d'un BIA réel. La perfection vient après.

👉 Télécharger le modèle d'analyse d'impact sur l'activité, Gratuit

Vous voulez aller plus loin ?

Le BIA est la première étape. La méthodologie, les ateliers, les études de cas : c'est ce qui transforme un tableur en programme.

• ISO 22301 Lead Implementer, méthodologie BIA, stratégies de continuité, conception des exercices
• ISO 27001 Lead Implementer, parce que sécurité de l'information et continuité d'activité sont indissociables
• DORA Lead Manager, continuité TIC pour les entités financières
• NIS2 Lead Implementer, pour les entités essentielles et importantes sous NIS2

Toutes les formations : Certifiées ou Remboursées.

Cyber Academy, cyberacademy.net

Nous n'enseignons pas la théorie. Nous enseignons la survie.