Speaker #0dans les livres, et chaque génération semble redécouvrir, avec la même stupéfaction, les circonstances de ce drame. Mais ce qu'on en sait moins, c'est que cette catastrophe n'est pas simplement l'histoire d'un iceberg mal placé et d'un navire qui allait trop vite. C'est avant tout l'histoire d'une série de questions que personne n'a pris la peine de se poser sérieusement avant le départ. Que se passe-t-il si le navire heurte un obstacle ? Combien de canots de sauvetage faut-il vraiment ? Combien de temps faut-il pour évacuer 2200 personnes ? Quelles sont les conséquences si les compartiments étanches sont percés au-delà de ce qui a été prévu ? Et surtout, quel est l'impact réel d'un naufrage sur les vies humaines ? sur la compagnie et sur l'industrie maritime. Parce que voyez-vous, le Titanic disposait de canots de sauvetage pour 1178 personnes, alors qu'il transportait 2224 passagers et membres d'équipage. Ce n'était pas un oubli, c'était un choix délibéré. La réglementation maritime de l'époque, établie par le Board of Trade britannique, datait de 1894 et ne prévoyait le nombre de canots qu'en fonction du tonnage du navire, pas du nombre de passagers. personne n'avait mis à jour ce règlement pour tenir compte de l'augmentation spectaculaire de la taille des paquebots. Et la White Star Line, propriétaire du Titanic, s'était contentée de respecter à la lettre la loi, sans jamais se demander si cette loi était encore pertinente. Pire encore, on avait même envisagé un moment de mettre encore moins de canaux que prévu, pour ne pas encombrer le pont de promenade et gâcher la vue des passagers de première classe. L'esthétique avant la sécurité, le confort avant la survie. Ces questions ? Si elles avaient été posées avec rigueur et honnêteté, auraient peut-être changé le cours de l'histoire. On aurait embarqué suffisamment de canaux pour tout le monde, on aurait formé l'équipage aux procédures d'évacuation, car il faut savoir que le soir du naufrage, aucun exercice d'évacuation n'avait jamais été réalisé avec les passagers. On aurait peut-être même ralenti dans cette zone connue pour ses icebergs, zone pour laquelle le Titanic avait d'ailleurs reçu pas moins de 6 avertissements radios le jour même de la collision. En d'autres termes, On aurait fait ce qu'on appelle aujourd'hui en cybersécurité une analyse d'impact sur les activités, un BIA, un BIA pour Business Impact Analysis. Le BIA, c'est précisément cet exercice qui consiste à se poser, avant la catastrophe, la question fondamentale. Si tel ou tel élément de notre organisation venait à tomber en panne, à être compromis ou à disparaître, quelles en seraient les conséquences réelles sur notre activité ? Et surtout, sommes-nous préparés à y faire face ? Mais croyez-moi, c'est une question que beaucoup trop d'organisations ne se posent pas, ou pas assez sérieusement, avant qu'il ne soit trop tard. On préfère croire que le navire est insubmersible jusqu'à ce que l'iceberg apparaisse. Alors qu'est-ce que le BIA exactement ? Le BIA, ou Business Impact Analysis, que l'on traduit en français par « analyse d'impact sur les activités » , est un processus structuré qui permet d'identifier et d'évaluer les conséquences potentielles d'une interruption des fonctions et des processus critiques d'une organisation. En termes simples, le BIA répond à une question très concrète. Si demain matin, tel système, tel processus ou tel service ne fonctionne plus, que se passe-t-il ? Quelles sont les pertes financières ? Quels clients sont impactés ? Quelles obligations légales ne peuvent plus être respectées ? Combien de temps peut-on tenir avant que la situation ne devienne critique ? Et au-delà de combien de temps la situation devient-elle tout simplement irréversible ? Vous voyez, le BIA n'est pas un exercice théorique réservé aux grandes entreprises avec des départements entiers dédiés à la gestion des risques. C'est un outil fondamental, presque existentiel, et qui constitue la pierre angulaire de tout plan de continuité d'activité, ce qu'on appelle en anglais le BCP, BCP pour Business Continuity Plan, et de tout plan de reprise après-sinistre, le fameux DRP, Disaster Recovery Plan. Pour faire une analogie simple, le BIAS est un peu comme le diagnostic que fait un médecin avant de prescrire un traitement. Vous n'allez pas prescrire de la chimiothérapie sans savoir d'abord quels organes est atteint et quel est le stade de la maladie. Le BIA, c'est le diagnostic de votre organisation. Il vous dit où sont les organes vitaux, lesquels sont les plus fragiles et ce qui se passe si l'un d'entre eux lâche. Sans BIA, vous construisez votre plan de continuité en aveugle. C'est un peu comme si les ingénieurs du Titanic avaient conçu le système de canneaux de sauvetage sans jamais se demander combien de passagers le navire allait transporter. Ah mais attendez, c'est exactement ce qui s'est passé. Le BIA est d'ailleurs explicitement requis ou fortement recommandé par de nombreux référentiels et de réglementations. On le trouve dans la norme ISO 23301 sur le management de la continuité d'activité, dans le règlement DORA, le Digital Operational Act, pour le secteur financier européen, dans les recommandations du NIST, notamment le SP 800-34, consacré à la planification de la continuité pour les systèmes d'information fédéraux, et bien sûr, dans les bonnes pratiques de l'ANSI. Pour ceux qui sont dans le secteur financier, DORA rend l'exercice du BIA pratiquement obligatoire, avec des exigences très précises sur l'identification des fonctions critiques et les dépendances vis-à-vis des prestataires tiers. Et je vous en parlerai un peu plus en détail dans la suite de cet épisode. Avant de plonger dans la méthodologie, Laissez-moi vous raconter quelques histoires qui illustrent parfaitement ce qui se passe quand on n'a pas fait son BIA, ou quand on l'a mal fait. Le 10 mars 2021, aux alentours de minuit, un incendie dévaste le datacenter SBG2 d'OVHcloud à Strasbourg. Cet incendie détruit l'intégralité du bâtiment SBG2 et endommage partiellement le bâtiment voisin SBG1. En quelques heures, des milliers de serveurs partent en fumée. Et avec eux ? les données et les services de millions de clients à travers l'Europe. Ce qui est fascinant avec cette affaire, c'est la diversité des réactions. Certaines entreprises avaient des sauvegardes externalisées, des plans de reprise testés et ont pu remonter leurs services en quelques heures. D'autres ont découvert, dans la panique, que leurs sauvegardes étaient hébergées dans le même data center que les données de production. Autrement dit, elles avaient mis leurs copies de sauvegardes dans le même bâtiment que les originaux. Quand le bâtiment a brûlé, tout a brûlé ensemble. Certaines de ces entreprises ont perdu définitivement des données irremplaçables. Des sites web, des applications métiers, des bases de données clients se sont volatilisées sans possibilité de récupération. Si ces entreprises avaient réalisé un BIA sérieusement, elles auraient identifié le risque de perte de leur hébergement comme un scénario à traiter. Elles auraient défini un RPO, un objectif de point de reprise, qui leur aurait conduit à externaliser leur sauvegarde vers un site géographiquement distinct. Elles auraient défini un RTO. qui les auraient emmenés à préparer un plan de bascule vers un hébergeur de secours. Mais sans BIA, personne n'avait posé ces questions. Un autre exemple marquant. En juin 2017, la compagnie maritime danoise Marx, le plus grand armateur de porte-containers au monde, est frappée de plein fouet par le ransomware NotPetya. L'ensemble de l'infrastructure informatique de Marx est paralysé. 49 000 ordinateurs portables, 4000 serveurs, tout est chiffré, tout est hors service. Le résultat ? Merckx gère environ 20% du commerce maritime mondial. Ses terminaux portuaires ne peuvent plus fonctionner. Les containers ne peuvent plus être chargés ni déchargés. Les navires arrivent dans les ports sans que personne ne sache quels containers sont à bord ni où ils doivent aller. Pendant 10 jours, l'entreprise revient littéralement à l'ère du papier et du crayon. Les estimations font état de pertes de 250 à 300 millions de dollars. Ce qui a sauvé Merckx, c'est un coup de chance extraordinaire. Un seul contrôleur de domaine Active Directory avait survécu à l'attaque, dans un bureau au Ghana qui avait été mis hors réseau par une coupure de courant au moment exact de la propagation du malware. Sans cette sauvegarde involontaire, Marx aurait dû reconstruire l'intégralité de son annuaire d'entreprise à partir de zéro, ce qui aurait pris des semaines supplémentaires. Si Marx avait disposé d'un BIA complet et à jour, l'entreprise aurait identifié son Active Directory comme un composant vital avec un RTO de quelques heures. et auraient mis en place des sauvegardes hors ligne spécifiques. Au lieu de ça, la survie de l'entreprise a tenu à une panne de courant au Ghana. Un dernier exemple, tout aussi éloquent. En mai 2017, British Airways subit une panne informatique massive due au problème d'alimentation électrique dans son data center. Tous les systèmes tombent simultanément. Plus de 75 000 passagers sont bloqués, des centaines de vols sont annulés pendant trois jours et l'entreprise estime les pertes à plus de 100 millions de livres Starling. L'enquête a révélé que le plan de reprise de British Airways n'avait pas correctement identifié les interdépendances entre les systèmes. La remise en route s'est avérée beaucoup plus complexe et plus longue que prévu, parce que personne n'avait analysé dans quel ordre les systèmes devaient être redémarrés. C'est exactement ce que le BIA est censé documenter, l'ordre de priorité de restauration et de dépendance entre les systèmes. Vous le voyez, le point commun de tous ces incidents, c'est l'absence ou l'insuffisance d'un BIA. Les organisations savent, théoriquement, que leur système était important, mais elles n'avaient pas pris le temps de quantifier précisément les impacts d'une interruption, ni de préparer les réponses adaptées. Alors quels sont les objectifs du BIA ? Maintenant que vous avez compris pourquoi le BIA est indispensable, voyons plus en détail ce qu'il cherche à accomplir. Le BIA poursuit plusieurs objectifs fondamentaux. Le premier, et le plus évident, c'est l'identification des processus et fonctions critiques de l'organisation. Toutes les activités d'une entreprise n'ont pas la même importance. Certaines sont vitales, si elles s'arrêtent, l'entreprise est en danger immédiat. D'autres sont importantes mais peuvent tolérer une interruption de quelques heures ou quelques jours. D'autres encore sont secondaires et peuvent attendre une reprise progressive sans conséquences graves. Le BIA permet de faire ce tri. C'est un exercice de lucidité, parfois inconfortable, qui oblige l'organisation à se regarder dans le miroir et à se demander honnêtement qu'est-ce qui est vraiment essentiel à notre survie. Et vous seriez surpris de voir à quel point les réponses divergent selon les interlocuteurs. Le directeur commercial est persuadé que le CRM est le système le plus critique. Le directeur financier est convaincu que les systèmes de facturation le sont. Le directeur de la production est certain que c'est l'ERP. Le BEIA permet d'objectiver ses perceptions et de bâtir un consensus sur ce qui est réellement vital pour l'organisation dans son ensemble et non pour un département en particulier. Le deuxième objectif, c'est la quantification des impacts. Il ne suffit pas de dire qu'un process est critique, il faut comprendre pourquoi il l'est et mesurer les conséquences de son arrêt. Les impacts peuvent être financiers, bien sûr. Avec des pertes des chiffres d'affaires, des pénalités contractuelles, les coûts de remise en service, les heures supplémentaires du personnel mobilisé. Mais ils peuvent aussi être opérationnels, réglementaires, réputationnels, voire juridiques. Prenez un exemple concret. Imaginez une plateforme de commerce en ligne. Si le site tombe un mardi à 3h du matin, l'impact est probablement limité. Quelques commandes perdues et quelques clients frustrés. Mais si cette même panne arrive un vendredi du Black Friday... Les pertes peuvent se chiffrer en millions d'euros par heure. Et si la panne dure suffisamment longtemps, l'impact réputationnel s'ajoute à l'impact financier. Les clients vont chez le concurrent, les réseaux sociaux s'enflamment et la confiance met des mois à se rétablir. Le BIA permet de quantifier ces scénarios et les modéliser dans le temps et de prioriser les investissements en conséquence. Le troisième objectif, c'est la détermination des délais de reprise acceptables. C'est ici qu'on rentre dans le vocal bullard technique du BIA. avec deux indicateurs clés que vous devez absolument connaître et que l'on va décortiquer ensemble. Le quatrième objectif, souvent négligé, mais tout aussi important, c'est l'identification des dépendances. Le BIA met en lumière les liens parfois insoupçonnés entre les différents processus, systèmes et ressources de l'organisation. Comme un médecin qui découvre que la douleur au genou est en fait causée par un problème de hanche, le BIA révèle les chaînes de dépendance qui font qu'un incident apparemment localisé, peut avoir des répercussions en cascade sur toute l'organisation. Il y a donc deux indicateurs essentiels, le RTO et le RPO. Nous voilà au cœur technique du BIA, ces deux acronymes que vous allez entendre partout dans le monde de la continuité d'activité, le RTO et le RPO. Si vous devez ne retenir que deux choses de cet épisode, ce sont ces deux indicateurs. Le premier indicateur, c'est le RTO, Recovery Time Objective ou Objectif de Temps de Reprise. C'est la durée maximale acceptable pendant laquelle un processus ou un système peut être interrompu avant que les conséquences ne deviennent inacceptables pour l'organisation. En d'autres termes, le RTO répond à la question « Combien de temps peut-on se permettre d'être à l'arrêt ? » Pour un système de paiement en ligne d'une banque, le RTO pourrait être de quelques minutes. Pour un système de messagerie interne d'une entreprise de service, peut-être quelques heures. Pour un système d'archivage documentaire, peut-être quelques jours. Tout dépend de la criticité des processus que le système supporte. Mais attention, le RTO n'est pas une valeur abstraite que l'on choisit arbitrairement. C'est le résultat direct de l'analyse d'impact. C'est le moment précis, sur la courbe temporelle des impacts, où la ligne rouge est franchie. Par exemple, si votre analyse montre qu'au bout de 4 heures d'interruption de votre système de facturation, vous commencez à violer des obligations contractuelles envers vos clients et accumuler des pénalités, Alors votre RTO pour ce système est de 4 heures. Ce n'est pas vous qui décidez du RTO par confort ou par ambition, c'est la réalité de votre activité qui le dicte. Deuxième indicateur, le RPO, pour Recovery Point Objective, ou objectif de point de reprise. C'est la quantité maximale de données que l'on peut se permettre de perdre en cas d'incident, et ceci mesuré en temps. Le RPO répond la question, jusqu'où dans le passé peut-on accepter de revenir ? Ou pour le dire autrement, Quelle quantité de travail peut-on se permettre de perdre ? Si votre RPO est de 24 heures, cela signifie que vous acceptez de perdre au maximum une journée de données. Votre stratégie de sauvegarde devra donc prévoir au minimum une sauvegarde quotidienne. Si votre RPO est d'une heure, il faudra des sauvegardes toutes les heures ou une réplication quasi continue. Si votre RPO est de zéro, cela signifie que vous ne pouvez vous permettre de perdre aucune donnée, pas même la dernière transaction. Il faudra alors mettre en place une réplication synchrone en temps réel. Ce qui est évidemment beaucoup plus coûteux et complexe. Pour bien comprendre les différences entre RTO et RPO, prenons une image concrète. Imaginez que votre maison prend feu. Le RTO, c'est le temps qu'il vous faut pour retrouver un toit au-dessus de la tête, que ce soit un hôtel, un logement temporaire ou la reconstruction de votre maison. Le RPO, c'est ce que vous perdez dans l'incendie, vos photos de famille, vos documents importants, vos souvenirs. Si vous avez fait une copie numérique de vos photos la veille, votre RPO est d'un jour. vous perdez au maximum une journée de souvenir. Si vous n'avez jamais fait de copie, votre RPO est catastrophique, vous perdez tout. Reprenons notre analogie du Titanic. Le RTO, c'est le temps dont vous disposez pour mettre les canaux à l'eau et évacuer les passagers avant que le navire ne coule. Les ingénieurs avaient estimé que le Titanic restait à flot environ une heure après une collision majeure. En réalité, il a tenu 2h40, ce qui a permis de sauver plus de personnes que prévu, mais pas assez, loin de là. Le RPO, dans cette analogie, c'est le nombre de vies que l'on accepte de ne pas pouvoir sauver. Évidemment, la réponse devrait être zéro. Mais encore faut-il avoir posé la question et prévu les moyens en conséquence, c'est-à-dire suffisamment de canaux pour tout le monde. Il existe aussi un troisième indicateur, moins connu mais tout aussi important, le MTPD, Maximum Tolerable Period of Disturptions, ou Durée Maximum Tolérable d'Interruption. C'est le point de non-retour. Le moment au-delà duquel l'organisation ne pourra simplement plus se remettre de l'interruption, quel que soit l'effort de reprise déployé. Le MTPD est toujours supérieur au RTO. Le RTO, c'est le délai visé pour la reprise, celui que vous essayez de respecter. Le MTPD, c'est la limite absolue au-delà de laquelle c'est la survie même de l'organisation qui est en jeu. Pour reprendre l'image de la maison en feu, le RTO, c'est le temps pour trouver un hébergement temporaire. le MTPD C'est le délai au-delà duquel vous ne pouvez plus payer votre loyer et vous vous retrouvez à la rue. Entre les deux, il y a une fenêtre dans laquelle vous devez agir. Un dernier concept à connaître, le WRT, le Work Recovery Time, ou le temps de récupération du travail. C'est le temps nécessaire, une fois le système technique restauré, pour vérifier les données, rattraper les retards accumulés et revenir à un fonctionnement normal. On l'oublie souvent, mais mettre un serveur en route ne suffit pas. Il faut ensuite que les équipes métiers vérifient l'intégralité des données, traitent les transactions en attente et rattrapent tout ce qui s'est accumulé pendant l'interruption. Le WRT s'ajoute au RTO pour donner le temps total avant retour à la normale. Et c'est ce total qui doit rester inférieur au MTPD. Alors attention, il ne faut pas confondre BIA et analyse de risque. Un point que je tiens à clarifier, parce que la confusion est extrêmement fréquente, même chez les professionnels, le BIA... et l'analyse de risque sont deux exercices complémentaires mais distincts. L'analyse de risque s'intéresse à la question « qu'est-ce qui pourrait mal tourner et quelle est la probabilité que cela arrive ? » Elle identifie les menaces, évalue les vulnérabilités et estime la vraisemblance des scénarios d'incidents. C'est le domaine du « quoi » et du « combien de chances » . Le BIA, lui, s'intéresse à la question « si ça tourne mal, quelles sont les conséquences ? » Il ne s'occupe pas de savoir si l'incident est probable ou non. Il part du principe que l'interruption se produit et en mesure les impacts. C'est le domaine du « et alors » et du « combien ça coûte » . Prenons un exemple pour bien comprendre la différence. L'analyse de risque va vous dire la probabilité qu'un ransomware paralyse notre système de production est de X% par an, en fonction de notre exposition, de nos mesures de protection et du paysage de la menace. Le BIA, lui, vous dira si notre système de production est paralysé, Quelle qu'en soit la cause, les pertes seront de Y euros par heure, Z clients seront impactés, et au bout de N heures, nous serons en violation de nos obligations réglementaires. Les deux exercices se complètent parfaitement. L'analyse du risque vous aide à décider où investir en prévention, pour réduire la probabilité des incidents. Le BIA vous aide à décider où investir en résilience, pour réduire les conséquences des incidents, quand ils surviennent malgré tout. Et croyez-moi, ils finissent toujours par survenir. C'est un peu comme l'assurance automobile. Vous pouvez être le conducteur le plus prudent du monde, la probabilité que vous ayez un accident est faible. Mais si un jour vous en avez un, les conséquences peuvent être considérables. L'analyse de risque, c'est la prudence au volant. Le BIA, c'est l'assurance. Mais comment réaliser le BIA concrètement ? Réaliser un BIA, c'est un projet en soi. Selon la taille de l'organisation, cela peut prendre de quelques semaines à plusieurs mois. Mais ne vous laissez pas intimider. La méthodologie est accessible à condition de la suivre avec rigueur et méthode. Voici les grandes étapes. Étape numéro 1. Définir le périmètre et obtenir le soutien de la direction. Avant de commencer, il faut savoir ce qu'on va analyser. Quels sont les processus métier de l'organisation ? Quels sont les systèmes d'information qui les supportent ? Quelles sont les dépendances entre les processus et les systèmes ? Mais avant même de répondre à ces questions, il y a un prérequis indispensable. Obtenir le soutien explicite de la direction générale. Le BEIA n'est pas un exercice que l'on peut mener en sous-marin dans un coin du département informatique. nécessite la participation active des responsables métiers de toute l'organisation, et ceux-ci ne se mobiliseront que si la direction donne le ton. Un courrier ou un message de la direction générale expliquant l'importance de l'exercice, son caractère stratégique et demandant la coopération active de tous les responsables de département, fait des miracles. Sans ce soutien, vous vous heurterez à l'indifférence, aux agendas chargés et au « je n'ai pas le temps pour ça » . Une fois le soutien obtenu, procédez à la cartographie des activités de l'entreprise. Idéalement, vous devez identifier les grands processus métiers, la production, la vente, la facturation, le support client, la logistique, les ressources humaines, la comptabilité, la gestion de la conformité, etc. Pour chaque processus, identifiez les ressources dont ils dépendent, les applications informatiques, les bases de données, les infrastructures réseau et télécom, mais aussi les locaux physiques, le personnel clé, les compétences rares, les fournisseurs et les prestataires externes. N'oubliez surtout pas ces derniers. Dans un monde où on externalise de plus en plus, une grande partie de vos processus critiques dépendent peut-être des prestataires tiers. Votre système de paye peut être hébergé chez un éditeur en mode SaaS. Votre logistique dépend peut-être d'un transporteur unique. Vos infrastructures cloud reposent peut-être sur un seul fournisseur. C'est d'ailleurs l'une des grandes préoccupations du règlement DORA, la dépendance vis-à-vis des prestataires de services numériques et les risques de concentration. Étape numéro 2 Collecter les informations auprès des métiers. C'est la phase la plus importante et souvent la plus longue du processus. Il faut aller à la rencontre des responsables de chaque processus métier pour comprendre ce qu'ils font, comment ils le font et ce qui se passerait concrètement si leurs outils venaient à manquer. Concrètement, cela passe par des entretiens structurés, des questionnaires préalables que les interlocuteurs remplissent avant l'entretien et des ateliers de travail réunissant plusieurs parties prenantes. Chaque approche a ses avantages. Les entretiens individuels permettent d'aller en profondeur et de mettre les gens à l'aise. Les questionnaires permettent de couvrir un large périmètre rapidement. Les ateliers permettent de confondre les points de vue et de faire émerger les interdépendances. Les questions à poser sont simples dans leur formulation, mais fondamentales dans leur portée. Quelles sont vos activités principales ? Quels sont les plus sensibles en facteur de temps ? De quels systèmes et applications dépendez-vous au quotidien ? Que se passe-t-il si ces systèmes sont indisponibles pendant une heure, une demi-journée, un jour, une semaine ? Quels sont les impacts financiers d'une interruption, heure par heure ? Avez-vous des obligations réglementaires ou contractuelles avec des délais impératifs ? Par exemple des déclarations fiscales, des obligations de reporting, des engagements de niveau de service envers vos clients ? Quelles sont les périodes de l'année les plus critiques pour votre activité ? La clôture comptable ? Les soldes ? Les campagnes de lancement ? Avez-vous des solutions de contournement en cas de panne ? Pouvez-vous travailler manuellement pendant un temps ? Combien de temps ? Je vous recommande vivement de ne pas faire cet exercice depuis votre bureau, en remplissant vous-même les réponses à partir de ce que vous croyez savoir. Allez parler aux gens, vous serez surpris de ce que vous apprendrez. Les responsables métiers connaissent leurs activités infiniment mieux que quiconque, et ils ont souvent une vision très précise des impacts d'une interruption que les équipes informatiques ne soupçonnent même pas. Sans ces entretiens, on passe à côté de l'essentiel. Un conseil pratique ? Utilisez des scénarios concrets pour faciliter les échanges. Plutôt que de demander de façon abstraite quel est l'impact d'une interruption, proposez un scénario. Imaginez que lundi matin, en arrivant au bureau, votre système de gestion commerciale ne fonctionne plus. Votre écran affiche un message d'erreur. Le support informatique vous dit qu'il faut compter au minimum 8 heures avant la remise en service. Que fait-on ? Quels sont les impacts sur les clients ? Pouvez-vous travailler autrement ? Les gens répondent beaucoup mieux quand on leur raconte une histoire concrète plutôt que quand on leur pose des questions abstraites. Étape numéro 3. Analyser et quantifier les impacts. Une fois les informations collectées, il faut les analyser, les croiser et les structurer. Pour chaque processus, évaluer les impacts selon plusieurs dimensions. L'impact financier d'abord, c'est souvent le plus parlant pour la direction, mais ce n'est pas toujours le plus facile à quantifier avec précision. On peut néanmoins estimer les pertes de chiffre d'affaires à partir du revenu quotidien moyen, les pénalités contractuelles à partir des clauses de contrat client, et les coûts de remise en service à partir de l'expérience des incidents passés, les heures supplémentaires du personnel mobilisé, l'allocation éventuelle de matériel de remplacement, et ainsi de suite. N'hésitez pas à demander l'aide du contrôleur de gestion et de la direction financière pour affiner ces estimations. L'impact opérationnel ensuite. Combien de personnes sont bloquées dans leur travail ? Quels autres processus sont affectés en cascade par effet domino ? Est-ce que la production s'arrête ? Est-ce que les livraisons prennent du retard ? Est-ce que le support client ne peut plus répondre aux demandes ? L'effet domino est particulièrement important à cartographier, car un système qui semble peu critique peut en réalité bloquer 5 autres process en aval. L'impact réglementaire. Y a-t-il des obligations légales qui ne peuvent pas être respectées ? Des déclarations fiscales ou comptables à effectuer dans des délais précis ? Des obligations de reporting aux autorités et de tutelle ? Des données personnelles exposées qui déclenchent une obligation de notification à la CNIL ? dans un délai de 72 heures au titre de RGPD. Dans le secteur financé, les obligations de reporting sont particulièrement strictes et les délais impératifs. L'impact réputationnel, comme les clients, les partenaires, les investisseurs, le grand public vont-ils percevoir l'incident ? Dans certains secteurs, une interruption de service peut faire la une des journaux et alimenter les réseaux sociaux pendant des jours. La perte de confiance qui en résulte peut durer bien plus longtemps que l'incident lui-même. et se traduire par une érosion de la base client qu'il est très difficile de quantifier, mais qu'il serait imprudent d'ignorer. L'impact juridique, enfin. Y a-t-il des risques de poursuites judiciaires de la part des clients, de partenaires ou du régulateur ? De mise en cause pour la responsabilité personnelle des dirigeants, pour manquement à leurs obligations de diligence ? Dans certaines juridictions et certains secteurs, les dirigeants peuvent être tenus personnellement responsables, s'il est démontré qu'ils n'ont pas pris les mesures raisonnables pour assurer la continuité de service. Un point crucial, l'analyse des impacts doit absolument être réalisée dans le temps. Un système indisponible pendant une heure n'a pas du tout les mêmes conséquences que s'il est indisponible pendant une semaine. Généralement, on évalue les impacts à plusieurs jalons temporels. Une heure, quatre heures, huit heures, un jour, trois jours, une semaine et au-delà. Cela permet de tracer ce qu'on appelle la courbe de dégradation. c'est-à-dire l'évolution de l'impact dans le temps. Et c'est en observant cette courbe que l'on identifie le point de bascule, le moment précis où l'impact franchit le seuil de l'inacceptable. Ce point de bascule, c'est votre RTO. Étape numéro 4. Prioriser et classifier. Sur la base de l'analyse des impacts, vous allez pouvoir classer vos processus et systèmes par ordre de criticité. Généralement, on utilise une échelle de 3 à 5 niveaux. Personnellement, je recommande 4 niveaux. ce qui offre une bonne granularité sans tomber dans une complexité excessive. Au niveau le plus élevé, on trouve les processus vitaux, ceux dont l'interruption met en danger la survie même de l'organisation ou expose à des risques légaux majeurs et immédiats. Le RTO est très court, de l'ordre de quelques minutes ou quelques heures. Pour le Titanic, c'est le système de propulsion et le système de navigation. Sans eux, le navire ne peut tout simplement plus fonctionner. Un deuxième niveau, les processus essentiels. dont l'interruption cause des pertes significatives mais gérables à court terme. L'URTO est de quelques heures ou de quelques jours. Pour le Titanic, c'est le système de communication radio, important, mais le navire pourrait continuer à naviguer sans lui pendant quelques heures. Un troisième niveau, le processus important, mais non critique, à court terme. Ils peuvent supporter des interruptions de plusieurs jours, sans conséquences dramatiques. Le RTO est de quelques jours. Et enfin, au quatrième niveau, les processus secondaires, dont l'interruption a un impact limité et qui peuvent attendre une reprise progressive. Pour le Titanic, c'est le restaurant de première classe ou le salon de coiffure. Agréable, mais pas indispensable à la survie du navire. Cette classification est fondamentale parce qu'elle va guider toutes les décisions d'investissement en matière de continuité et de reprise. Vous n'allez pas mettre en place une réplication synchrone en temps réel avec bascule automatique pour un système secondaire, ni vous contenter d'une sauvegarde hebdomadaire sur bande pour un système vital. Un niveau de protection doit être proportionnel à la criticité, et c'est le BIA qui établit cette proportionnalité de manière objective et documentée. Étape numéro 5. Définir les exigences de reprise et les solutions. Pour chaque processus critique, définissez précisément le RTO et le RPO. Ces valeurs ne sortent pas de nulle part. Elles découlent directement de l'analyse des impacts réalisés à l'étape précédente. Le RTO correspond au moment où l'impact franchit le seuil de l'inacceptable. Le RPO dépend de la nature des données et de la fréquence à laquelle elles changent. Définissez également les niveaux de service minimum acceptable en mode dégradé. C'est un concept très important et souvent négligé. La reprise ne signifie pas nécessairement un retour immédiat au fonctionnement nominal. Il peut y avoir une phase intermédiaire en mode dégradé, où le service fonctionne, mais avec des limitations acceptables. Par exemple, votre site de commerce en ligne peut fonctionner temporairement sans le moteur de recommandation personnalisée, mais pas sans le module de paiement. Votre système de messagerie peut fonctionner en mode dégradé, avec des accès web uniquement, sans l'application mobile ni les agendas partagés. Votre système de production peut tourner à 60% de sa capacité le temps que les systèmes secondaires soient restaurés. Ces informations sont précieuses pour concevoir votre stratégie de reprise, car elles permettent de restaurer d'abord le minimum vital, puis d'enrichir progressivement le service. C'est aussi à cette étape que vous commencez à esquisser les solutions techniques de continuité de reprise. Pour un RTO de quelques minutes, vous aurez besoin d'une architecture active-active, avec bascule automatique. Pour un RTO de quelques heures, un système de secours avec des données répliquées peut suffire. Pour un RTO de quelques jours, une sauvegarde quotidienne avec une procédure de restauration documentée peut être adéquate. Le choix de la solution est un compromis entre le niveau de protection souhaité et le coût que l'on est prêt à consentir. Il y a quelques erreurs classiques à éviter. Le BIA est un exercice qui paraît simple sur le papier, mais qui recèle de nombreux pièges. Voici les erreurs les plus courantes que j'ai observées au fil des années. Et croyez-moi, j'en ai vu beaucoup. La première erreur, c'est de faire le BIA uniquement d'un point de vue technique. Je ne répéterai jamais assez. Le BIA n'est pas un exercice informatique, c'est un exercice métier. Ce sont les responsables des processus d'affaires qui doivent évaluer les impacts, pas les équipes IT. Les équipes IT interviennent ensuite pour identifier les solutions techniques adaptées, mais la définition de ce qui est critique et de ce qui ne l'est pas, c'est une décision métier. Si vous laissez les informaticiens faire le BIA seuls, vous obtiendrez une vision biaisée, centrée sur le système technique plutôt que sur les processus d'affaires. Deuxième erreur, c'est de sous-estimer les dépendances. Un processus peut paraître autonome alors qu'il dépend en réalité d'une dizaine de sous-systèmes, dont certains sont partagés avec d'autres processus. Si vous ne cartographiez pas ces dépendances avec soin, vous aurez des surprises désagréables le jour où un incident survient. C'est un peu comme les dominos, la chute d'un seul peut entraîner toute la chaîne. Et les dépendances les plus dangereuses sont souvent les plus discrètes. Ce petit connecteur entre deux systèmes, cette API qui synchronise les données toutes les 5 minutes, Ce fichier de configuration qui se trouve sur un serveur dont personne ne se souvient. La troisième erreur, c'est de confondre probabilité et impact. Je l'ai déjà mentionné, mais cela mérite d'être répété car c'est une confusion extrêmement courante. Le BI ne s'intéresse pas à la probabilité qu'un incident survienne. Ça, c'est le travail de l'analyse des risques. Le BI s'intéresse exclusivement aux conséquences. Même si la probabilité d'un incident dans votre data center est faible, l'impact serait considérable. Même si la probabilité d'un tsunami à Paris est quasi nulle, ce n'est pas une question que le BIA se pose. Le BIA dit, si votre data center est détruit, quelles sont les conséquences ? Point. La quatrième erreur, c'est de faire le BIA une fois et de le mettre dans un tiroir. J'appelle ça le syndrome du classeur. Vous passez trois mois à réaliser un BIA magnifique, vous le mettez dans un joli classeur sur une atagère et vous le présentez aux auditeurs quand il passe. Et ensuite, plus personne ne le regarde pendant trois ans. Le problème ? c'est que votre organisation a évolué pendant ces années. De nombreux processus sont apparus, des systèmes ont changé, des applications ont été migrées vers le... le cloud. Des prestateurs ont été échangés. Le BIA qui date de trois ans ne reflète probablement plus les réalités d'autres organisations. C'est comme une carte routière de 2010 pour naviguer en 2026. Les routes ont changé, les ronds-points ont été ajoutés et les sens interdits sont apparus. La cinquième erreur, la plus insidieuse peut-être, c'est de définir des RTO et des RPO irréalistes. J'ai vu des organisations annoncer fièrement un RTO de 15 minutes pour tout leur système critique. sans jamais vérifier si c'était techniquement et financièrement réalisable. Un RTO de 15 minutes, ça signifie des infrastructures entièrement redonnantes, de la réplication synchrone en temps réel, des procédures de basculement automatique et testées régulièrement, une équipe de support disponible 24h sur 24, 7 jours sur 7. C'est un investissement considérable, qui se chiffre souvent en millions d'euros. Il vaut mieux un RTO réaliste de 4h que l'on sait atteindre, et que l'on a testé, qu'un RTO fantasmé de 15 minutes, qui ne sera jamais respecté le jour J et qui donnera une fausse impression de sécurité. Et la sixième erreur, que je vois le plus fréquemment, c'est d'oublier les prestataires et sous-traitants dans le périmètre BIA. Dans un monde où le cloud, le SaaS et l'externalisation sont omniprésents, une part significative de processus critique dépend de tiers. Si votre fournisseur cloud a un RTO de 24h, votre RPO ne pourra pas être inférieur à 24h, quel que soit le niveau de votre propre infrastructure. Il est donc essentiel d'inclure vos prestataires critiques dans votre BIA, de vérifier leur engagement de niveau de service et de s'assurer que leur capacité de reprise soit compatible avec vos exigences. Vous vous demandez peut-être quel est le rapport entre le BIA et la cybersécurité ? Eh bien le lien est direct, fondamental et de plus en plus étroit. Les cyberattaques, et en particulier les ransomware, sont aujourd'hui l'une des premières causes d'interruption d'activité pour les entreprises. Selon plusieurs études récentes, Les ransomware sont devenus la metasse numéro 1 en termes d'impact opérationnel. Quand un ransomware chiffre l'ensemble de vos données et de vos systèmes, c'est exactement le scénario d'interruption massive que le BIA est censé anticiper. Et la particularité d'une attaque par un ransomware, c'est qu'elle touche souvent tout simultanément. Ce n'est pas un serveur qui tombe, c'est toute l'infrastructure. Le système de messagerie, la comptabilité, la production, le CRM, le site web, tout est chiffré en même temps. C'est un scénario de sinistre total, comparable à un incendie de datacenter. Mais avec une différence de taille. Dans le cas d'un ransomware, vos sauvegardes elles-mêmes peuvent être ciblées et chiffrées si elles ne sont pas correctement protégées. Le BIA vous aide à déterminer quels systèmes doivent être restaurés en priorité après une attaque. Si vous n'avez pas fait de BIA, vous retrouverez dans la panique à devoir décider en temps réel ce que vous restaurez d'abord. Le directeur commercial veut le CRM. Le directeur financier veut le système de facturation. Le directeur de production veut le RP. Tout le monde crie, tout le monde a raison de son point de vue. Et pendant ce temps, les équipes techniques s'épuisent à essayer de tout restaurer en même temps, sans ordre de priorité claire. C'est la recette du chaos. Avec un BI à jour, vous savez exactement dans quel ordre restaurer vos systèmes. Vous savez quel est le niveau de perte de données acceptable pour chaque processus. Vous savez combien de temps vous avez avant que la situation ne devienne irrémédiablement critique. C'est une feuille de route en pleine tempête. Et croyez-moi, quand la tempête d'un ransomware frappe, vous êtes infiniment reconnaissant d'avoir cette feuille de route. Le billet est aussi un outil précieux pour justifier les investissements en cybersécurité auprès de la direction. Quand vous pouvez démontrer, chiffre à l'appui, qu'une journée d'interruption du système de facturation coûte 500 000 euros à l'entreprise, il est beaucoup plus facile de justifier un investissement de 100 000 euros dans une solution de sauvegarde en ligne. Un plan de reprise après sinistre testé ou... un système de détection d'intrusion capable d'identifier un ransomware avant qu'il ne chiffre l'ensemble du réseau. Le BIA transforme une conversation abstraite sur la sécurité en une conversation concrète sur les finances. Et c'est un langage que les dirigeants comprennent parfaitement. Par ailleurs, dans le cadre de la réponse aux incidents, le BIA permet de comprendre les décisions éclairées dans l'urgence. Par exemple, en cas de compromission d'un système, faut-il l'isoler immédiatement du réseau au risque d'interrompre un processus critique qui en dépend ? Ou faut-il le maintenir temporairement en service, le temps de préparer une bascule vers un système de secours, au risque de laisser l'attaquant progresser ? C'est un dilemme cornélien que les équipes de réponse à incidents doivent trancher en quelques minutes. Le BIA fournit les éléments objectifs, la hiérarchie des priorités, le seuil d'impact, qui permet de prendre cette décision de manière raisonnée plutôt qu'instinctive. Pour ceux qui évoluent dans le secteur financier, le règlement DORA, entré en application le 17 janvier 2025, place le BIA au cœur des exigences de résilience opérationnelle numérique. Et ce n'est pas un hasard. DORA part d'un constat simple. Le secteur financier est devenu tellement dépendant de la technologie que toute perturbation informatique majeure peut avoir des conséquences systémiques. C'est-à-dire des conséquences qui dépassent l'organisation touchée et affectent l'ensemble du système financier. Souvenez-vous de l'exemple de Marx. Quand 20% du commerce maritime mondial est paralysé, les répercussions se font sentir partout dans le monde. Dora exige que les entités financières identifient et classifient leurs fonctions critiques et importantes. Elles doivent cartographier les dépendances vis-à-vis des prestataires tiers sur les services TIC, les technologies de l'information et de communication. Elles doivent définir les objectifs de reprise pour chaque fonction critique et elles doivent tester régulièrement, et je dis bien régulièrement, et pas une fois tous les cinq. ans leur capacité à atteindre ces objectifs. Le BIA est l'outil naturel et incontournable pour répondre à ces exigences. Sans BIA, il est tout simplement impossible de démontrer aux régulateurs que vous avez identifié vos fonctions critiques, évaluer les impacts d'une interruption et mettre en place des dispositifs de continuité adaptés. Dora va même plus loin en exigeant que les organisations évaluent l'impact d'une défaillance de leurs prestataires critiques. Que se passe-t-il si votre fournisseur cloud tombe en panne ? Que se passe-t-il si votre prestataire de service de paiement est victime d'une cyberattaque ? Que se passe-t-il si votre éditeur de logiciel métier fait faillite et que leur support n'est plus assuré ? Le BIA doit couvrir tous les scénarios de dépendance au tiers et les stratégies de sortie doivent être documentées pour les prestataires les plus critiques. Pour les organisations concernées par DORA, le BIA n'est donc plus un exercice optionnel ou de bonne pratique. C'est une obligation réglementaire avec des conséquences potentielles sévères. en cas de non conformité. Un BIA qui n'est jamais testé est un BIA théorique. Et un BIA théorique, le jour de la crise, risque fort de s'avérer inadéquat. C'est un peu comme un gilet de sauvetage que l'on n'a jamais essayé. Le jour où le navire coule, on découvre qu'il est trop petit, qu'il n'a plus de flotteur ou qu'on ne sait pas comment l'enfiler. Tester le BIA, cela signifie réaliser des exercices de simulation qui mettent à l'épreuve les hypothèses, les priorités et les procédures que vous avez définies. Il existe plusieurs types d'exercices, du plus simple au plus complexe. L'exercice sur table, ou tabletop exercise en anglais, est le plus accessible. On réunit les parties prenantes clés autour d'une table, on décrit un scénario d'incident fictif mais réaliste, et on déroule collectivement la réponse. Que fait-on en premier ? Qui appelle-t-on ? Dans quel ordre resteront les systèmes ? Ce type d'exercice ne nécessite aucune manipulation technique, mais révèle rapidement les lacunes dans les procédures. les incompréhensions entre les équipes et les hypothèses erronées. L'exercice technique ou test de reprise va plus loin. On simule réellement la panne d'un système et on met en œuvre le plan de reprise. On mesure les temps effectifs de restauration et on compare au RTO défini dans le BIA. On vérifie que les sauvegardes fonctionnent, que les données sont intègres, que les équipes savent quoi faire. C'est le crash test de votre plan de continuité. Et puis, il y a l'exercice grandeur nature qui simule un incident majeur affecté. plusieurs systèmes simultanément, avec mobilisation de la cellule de crise, communication de crise et coordination entre les équipes. C'est l'exercice le plus coûteux et le plus complexe, mais aussi le plus révélateur. L'expérience montre que les premières campagnes de tests révèlent presque toujours des écarts significatifs entre ce qui est prévu et ce qui se passe réellement. Les RTO ne sont pas atteints, les sauvegardes ne fonctionnent pas comme prévu, les équipes ne savent pas quoi faire. Les procédures sont incomplètes ou obsolètes. C'est normal. C'est même l'objectif, identifier ces écarts avant qu'un vrai incident ne les révèle de manière beaucoup plus douloureuse. Chaque exercice doit être suivi d'un retour d'expérience et d'un plan d'action correctif. Et le BIA lui-même doit être mis à jour en fonction des enseignements tirés. Pour terminer avant notre conclusion, voici quelques conseils supplémentaires issus de l'expérience. Commencez par les processus les plus critiques, surtout si c'est votre premier BIA. Ne cherchez pas à tout analyser d'un coup. Identifiez 5 ou 10 processus les plus importants de votre organisation et concentrez-vous dessus. Un BIA partiel mais fait avec des process vitaux vaut infiniment mieux qu'un BIA exhaustif mais superficiel sur tous les processus. Vous pourrez étendre le périmètre progressivement dans les itérations suivantes. Documentez tout soigneusement. Le BIA produit une quantité importante d'informations qui doivent être structurées, accessibles et compréhensibles. Utilisez des matrices d'impact, des tableaux de synthèse. des schémas de dépendance. Un bon BIA doit pouvoir être compris par quelqu'un qui n'a pas participé aux entretiens, y compris à un nouveau RSSI qui arriverait dans une organisation deux ans après. Faites vivre le document, planifiez une révision annuelle au minimum, ou plus fréquente si votre organisation évolue rapidement. Profitez de chaque incident, même mineur, pour vérifier que votre BIA reflète bien la réalité. Profitez aussi des grands projets de transformation, comme une migration vers le cloud, une fusion-acquisition, ou un changement de RP, pour mettre à jour le BIA en parallèle. Chaque changement majeur de l'organisation est une occasion de revalider les hypothèses du BIA. Enfin, N'oubliez pas que le BIA est un outil de communication autant qu'un outil technique. Il doit être compréhensible par la direction générale, qui l'utilisera pour prendre des décisions d'investissement. Il doit être compréhensible pour les responsables métiers, qui l'utiliseront pour comprendre leur interdépendance. Il doit être compréhensible par les équipes techniques, qui l'utiliseront pour dimensionner les solutions de continuité, adapter le niveau de détail et le vocabulaire à chaque audience. Revenons une dernière fois au Titanic. Après le naufrage, Le monde entier a été choqué, incrédule, révolté. Comment avait-on pu laisser partir le plus grand paquebot du monde avec un nombre de canaux de sauvetage aussi insuffisant ? Comment avait-on pu naviguer à pleine vitesse dans une zone infestée d'icebergs sans plan d'urgence sérieux ? La réponse est aussi simple que dérangeante, parce que personne n'avait voulu se poser les bonnes questions avant le départ. Le navire était réputé insubmersible, à quoi bon prévoir des canaux pour tout le monde si le navire ne peut pas couler ? Le naufrage du Titanic a provoqué une révolution dans la sécurité maritime. La Convention internationale Solace, pour Safety of Life at Sea, adoptée en 1914, a imposé suffisamment de canaux de sauvetage pour tous les passagers, des exercices d'évacuation obligatoires, une veille radio permanente et la création de patrouilles internationales des glaces. Ces mesures, toutes issues d'analyses d'impact a posteriori, ont sauvé d'innombrables vies depuis lors. Le BIAS est exactement cette réflexion, mais réalisée a priori. Avant la catastrophe, c'est le courage de se poser les questions difficiles, avant qu'elles ne se posent d'elles-mêmes dans l'urgence et le chaos. C'est la lucidité d'admettre que notre navire, aussi solide et moderne soit-il, n'est pas insurmercible. C'est un investissement en temps et en ressources qui, le jour où l'incident survient, et croyez-moi, il finira par survenir, fera toute la différence entre une crise maîtrisée et un naufrage. Alors ne soyez pas comme les armateurs du Titanic, ne vous laissez pas bercer par l'illusion de l'invulnérabilité. Posez-vous les bonnes questions. Faites votre BIA, testez-le, mettez-le à jour et surtout ne le laissez pas dormir dans un tiroir. Faites-le vivre, parce que le jour où l'iceberg se présentera, il sera trop tard pour compter les canaux. Encore merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres et à en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Et surtout n'oubliez pas... Pour certains, la cybersécurité est un enjeu de vie de mort. C'est bien plus sérieux que ça.
