Continuité TI : comment prioriser les systèmes quand tout semble critique

Lorsqu’un incident majeur affecte les technologies d’une organisation, les équipes doivent rapidement déterminer quels systèmes doivent être rétablis en premier, combien de temps les opérations peuvent fonctionner sans eux et quelles dépendances doivent être restaurées avant de pouvoir relancer les applications critiques. Ces décisions deviennent particulièrement difficiles lorsque chaque unité d’affaires considère ses propres outils comme indispensables.

La conférence présentée par Premier Continuum et Énergir au Sommet Comitti s’est intéressée à cette problématique à partir d’un programme concret de continuité. Martin Laberge, responsable de la cybersécurité, de la gouvernance et des services TI chez Énergir, y a notamment présenté le travail réalisé autour du Business Impact Analysis (BIA), des objectifs de reprise, de la classification des systèmes et des exercices de gestion de crise.

La démarche montre que la continuité ne se limite pas à disposer de sauvegardes ou d’un plan de reprise informatique. Elle consiste également à comprendre les activités de l’organisation, leurs dépendances et les conséquences réelles d’une interruption afin que les priorités techniques correspondent aux besoins opérationnels.

Créer un langage commun entre les TI et les unités d’affaires

Les équipes techniques et les unités d’affaires n’évaluent pas nécessairement la criticité de la même manière. Un spécialiste TI peut considérer une infrastructure comme fondamentale parce que de nombreux systèmes en dépendent, tandis qu’une unité d’affaires peut demander le rétablissement immédiat d’une application directement associée à ses opérations. Si cette discussion commence uniquement pendant un incident, les équipes doivent prendre des décisions importantes sous pression.

Une démarche de continuité permet de réaliser ce travail à l’avance. Plutôt que de demander simplement si une application est importante, l’organisation cherche à comprendre les conséquences de son indisponibilité, le moment où ces conséquences deviennent significatives et les solutions temporaires disponibles.

Le BIA contribue ainsi à transformer une perception subjective de criticité en critères pouvant être comparés entre plusieurs activités.

Se préparer aux conséquences plutôt qu’à tous les scénarios possibles

Une organisation peut être confrontée à un nombre pratiquement illimité d’incidents : cyberattaque, panne réseau, indisponibilité d’un fournisseur, perte d’un bâtiment, défaillance électrique ou manque important de personnel. Construire un plan entièrement différent pour chaque scénario devient rapidement difficile à maintenir.

L’approche présentée consiste davantage à réfléchir aux conséquences. Une organisation peut perdre l’accès à un bâtiment pour différentes raisons, mais les besoins opérationnels qui en découlent restent relativement similaires. Une indisponibilité importante du personnel peut également provenir de plusieurs événements différents.

Cette logique permet de construire des plans plus modulaires. Plutôt que d’essayer de prévoir précisément l’événement futur, les équipes développent des capacités permettant de répondre aux effets qu’il pourrait produire.

La transformation numérique modifie la criticité des TI

Le cas d’Énergir illustre également la manière dont la dépendance envers les technologies évolue. Les TI ont historiquement pu être perçues comme un service de soutien aux opérations. À mesure que les processus deviennent numériques, la frontière entre technologie et activité principale devient moins nette.

Martin Laberge a notamment décrit cette évolution en expliquant qu’Énergir ne pouvait plus être considérée uniquement comme une entreprise de gaz utilisant de la technologie : les systèmes technologiques participent directement à la capacité de livrer le service.

Cette dépendance rend la continuité TI indissociable de la continuité des activités. Une application ou une infrastructure n’est pas critique uniquement en raison de ses caractéristiques techniques, mais parce qu’elle soutient un processus dont l’interruption produit des conséquences pour l’organisation.

Le BIA permet de mesurer l’impact d’une interruption

Le Business Impact Analysis vise à identifier les activités essentielles et à comprendre comment les impacts évoluent lorsque celles-ci sont interrompues. Ces conséquences peuvent être financières, opérationnelles, réglementaires, réputationnelles ou liées à la sécurité.

La durée joue un rôle important. Une interruption de quelques minutes n’a pas nécessairement les mêmes conséquences qu’une interruption de plusieurs heures ou plusieurs jours. Le BIA cherche donc à déterminer le moment où l’absence d’une activité devient suffisamment importante pour nécessiter son rétablissement.

Ces informations permettent ensuite d’établir des objectifs de reprise plus réalistes et de comparer la priorité de plusieurs systèmes. Elles permettent également de comprendre les dépendances : une application qui semble peu critique isolément peut fournir un service indispensable à une activité beaucoup plus prioritaire.

RTO : dans quel délai le service doit-il revenir?

Le Recovery Time Objective (RTO) représente le délai cible dans lequel un service ou un système doit être rétabli après une interruption. Définir cet objectif nécessite une discussion entre les unités d’affaires et les équipes techniques.

Une unité peut naturellement souhaiter que son application soit restaurée immédiatement. Le BIA oblige cependant à examiner les conséquences concrètes de l’interruption. Si le processus peut fonctionner manuellement pendant plusieurs jours, un RTO de quelques heures n’est peut-être pas justifié.

Cette distinction a des conséquences financières importantes. Plus l’objectif de reprise est exigeant, plus l’architecture nécessaire pour l’atteindre peut devenir coûteuse. La continuité aide donc à aligner les investissements techniques sur le niveau réel de criticité.

RPO : quelle quantité de données peut réellement être perdue?

Le Recovery Point Objective (RPO) répond à une autre question : jusqu’à quel point dans le temps l’organisation doit-elle être capable de restaurer ses données? Autrement dit, quelle quantité d’information peut être perdue lors d’un incident?

La réponse initiale d’une unité d’affaires peut être qu’aucune donnée ne peut être perdue. Dans la pratique, garantir un RPO proche de zéro exige des mécanismes techniques et des investissements particuliers. Le dialogue permet donc de déterminer ce qui est réellement nécessaire en fonction des processus.

Le scénario d’une cyberattaque complexifie encore cette question. Certaines sauvegardes peuvent être compromises ou les équipes peuvent devoir revenir à un point antérieur afin de retrouver un environnement sain. L’objectif défini sur papier ne garantit donc pas que chaque incident permettra de récupérer exactement le volume de données prévu.

Le BIA peut révéler des applications inconnues des TI

L’un des résultats intéressants de la démarche menée chez Énergir concerne l’inventaire des systèmes. Les entretiens avec les unités d’affaires peuvent faire apparaître des applications qui ne figurent pas nécessairement dans les inventaires TI traditionnels.

Le développement des services SaaS facilite particulièrement ce phénomène. Une équipe peut s’abonner à une application sans passer par un projet technologique formel. Avec le temps, cet outil peut devenir une composante importante d’un processus d’affaires sans être pleinement intégré à la gouvernance TI.

Le BIA devient alors un moyen d’identifier ce Shadow IT et d’améliorer les informations présentes dans la CMDB ou les autres référentiels de l’organisation. Une application inconnue ne peut pas être correctement protégée ou intégrée à un plan de reprise.

Les dépendances déterminent l’ordre réel de restauration

Connaître la criticité individuelle de chaque application ne suffit pas. Les systèmes dépendent les uns des autres et doivent souvent être restaurés dans un ordre précis. Une application métier peut nécessiter une base de données, un réseau, un service d’identité ou plusieurs autres composantes avant de pouvoir fonctionner.

Ces dépendances évoluent également avec le temps. Une architecture correctement documentée lors de son déploiement peut changer progressivement à mesure que de nouvelles intégrations sont ajoutées.

Le travail de continuité fournit donc une occasion de revoir régulièrement ces relations. Pendant une crise, cette connaissance permet aux équipes de comprendre pourquoi un système considéré comme très critique ne peut pas nécessairement être restauré en premier.

Le Tier 0 représente les fondations de l’environnement TI

Énergir a utilisé les informations recueillies pour classer ses systèmes selon différents niveaux de criticité. L’organisation a également introduit une catégorie Tier 0 correspondant aux composantes nécessaires avant même de pouvoir restaurer les applications métiers.

Un système comme SAP peut être extrêmement important pour les opérations, mais sa restauration nécessite d’abord un environnement fonctionnel. Réseau, télécommunications, services d’identité et autres infrastructures fondamentales doivent être disponibles.

Cette distinction entre criticité métier et dépendance technique permet d’établir un ordre de reprise plus réaliste. Les équipes ne cherchent pas uniquement à restaurer l’application la plus visible, mais à reconstruire les fondations qui permettront ensuite de remettre les autres services en fonction.

Les modes manuels peuvent réduire la criticité technique

L’analyse des processus peut également révéler que certaines activités disposent de solutions de contournement. Une unité d’affaires peut demander qu’une application soit rétablie dans un délai très court, mais son plan de continuité peut indiquer qu’elle est capable de fonctionner manuellement pendant plusieurs jours.

Dans ce cas, le système reste important, mais son RTO peut être différent de celui initialement demandé. Cette information permet de concentrer les investissements sur les environnements pour lesquels aucune alternative temporaire n’existe.

Les processus manuels ne constituent évidemment pas toujours une solution durable. Leur rôle est plutôt de fournir une capacité temporaire permettant à l’organisation de poursuivre ses activités pendant que les équipes restaurent les systèmes selon l’ordre de priorité défini.

Continuité et cybersécurité utilisent plusieurs informations communes

Les données produites par un BIA peuvent également être utiles aux équipes de cybersécurité. La classification des systèmes peut être rapprochée des exigences liées à la disponibilité, à l’intégrité et à la confidentialité de l’information.

Un système très important pour la continuité n’est pas nécessairement celui qui contient les données les plus confidentielles, et inversement. Les deux disciplines apportent donc des perspectives complémentaires sur les mêmes actifs.

La démarche peut également servir à revoir la classification de l’information et à déterminer quels systèmes nécessitent des contrôles particuliers. Continuité et cybersécurité se rejoignent notamment dans les scénarios de rançongiciel, où les équipes doivent simultanément contenir l’incident et reconstruire les services essentiels.

Un plan trop détaillé peut devenir rapidement obsolète

La documentation de continuité doit contenir suffisamment d’informations pour guider les équipes sans tenter de remplacer entièrement leur expertise. Un document trop vague risque de ne pas être utile en situation de crise, mais une procédure décrivant chaque clic nécessaire à la restauration d’un système peut devenir obsolète dès qu’une interface ou une architecture change.

L’objectif consiste à documenter les éléments réellement nécessaires : architecture, dépendances, responsabilités, ordre de reprise, coordonnées importantes et procédures spécifiques lorsqu’elles sont indispensables. Les spécialistes peuvent ensuite utiliser leurs compétences techniques pour réaliser les opérations correspondantes.

Un plan doit surtout être accessible et maintenu. Une documentation parfaite mais impossible à retrouver lorsque les systèmes habituels sont indisponibles apporte peu de valeur.

La continuité doit être intégrée aux processus TI courants

Un programme de continuité ne peut pas être traité comme un exercice réalisé une seule fois. Les systèmes changent, de nouvelles applications apparaissent et les dépendances évoluent. Les informations du BIA et les plans de relève doivent donc être intégrés aux processus normaux de gestion des technologies.

Lorsqu’un nouveau système est déployé, sa criticité peut être évaluée dès le projet. Si un plan de relève est nécessaire, il peut être développé avant la mise en production. La gestion du changement peut également tenir compte de la documentation de continuité afin que les modifications importantes soient répercutées dans les plans.

Cette intégration réduit le risque de disposer de documents qui décrivent un environnement n’existant plus depuis plusieurs années.

Les exercices permettent de vérifier les hypothèses

Un plan qui n’a jamais été testé repose largement sur des hypothèses. Énergir a donc développé progressivement son programme d’exercices. Les premières étapes ont notamment été consacrées à la sensibilisation des différents niveaux de gestion de crise : opérationnel, tactique et stratégique.

L’objectif n’était pas immédiatement de provoquer une panne réelle. Les exercices permettaient d’abord aux participants de comprendre leurs responsabilités et les informations dont ils auraient besoin. Ils faisaient également apparaître certaines zones d’incertitude : documentation manquante, dépendance envers une personne particulière ou autorité de décision insuffisamment définie.

Ces problèmes sont beaucoup plus simples à traiter lorsqu’ils sont découverts pendant une simulation plutôt qu’au milieu d’un incident réel.

Tester les communications entre les cellules de crise

Une étape suivante a consisté à réunir plusieurs cellules dans un exercice plus important impliquant environ 60 personnes. Le scénario intégrait notamment une cyberattaque et la perte progressive de certains outils. Des communications externes fictives et d’autres événements venaient augmenter graduellement la pression exercée sur les participants.

À un certain moment, les équipes ont même dû poursuivre l’exercice sans leurs ordinateurs portables. Ce type de contrainte permet de tester une question simple mais importante : comment l’organisation continue-t-elle à communiquer lorsque les outils utilisés quotidiennement ne sont plus disponibles?

Les exercices permettent ainsi d’évaluer autant les mécanismes de coordination que les procédures techniques.

Passer progressivement vers des tests plus réalistes

Après les exercices de type tabletop et les tests isolés, une organisation peut évoluer vers des simulations plus proches d’une interruption réelle. Énergir a présenté une progression vers des scénarios dans lesquels certains segments ou services pourraient être volontairement rendus indisponibles dans un environnement contrôlé afin de vérifier la capacité des équipes à les reconstruire.

Cette progression réduit le risque associé aux exercices. Une organisation développe d’abord ses processus, clarifie les rôles et corrige les principales lacunes avant de tester réellement ses capacités techniques.

La continuité devient alors une compétence qui se développe dans le temps plutôt qu’un document à valider périodiquement.

La résilience dépend aussi des personnes

Une infrastructure peut disposer d’excellentes sauvegardes et rester vulnérable si une seule personne sait comment effectuer la restauration. Les exercices permettent donc également d’identifier les dépendances humaines et les connaissances concentrées chez quelques spécialistes.

Ces informations peuvent conduire à améliorer la documentation, former d’autres employés ou modifier l’organisation des responsabilités. Elles permettent également de clarifier la gouvernance pendant une crise. La personne qui dirige une opération particulière n’est pas nécessairement celle qui occupe le poste hiérarchique le plus élevé dans les conditions normales.

Définir ces responsabilités à l’avance évite de devoir négocier l’autorité au moment où les équipes doivent agir rapidement.

Le BIA devient un outil de gouvernance au-delà de la continuité

Les informations recueillies pendant l’analyse peuvent finalement alimenter plusieurs pratiques : classification des applications, CMDB, cybersécurité, stratégies de sauvegarde, plans de relève, gestion des changements, décisions d’investissement et formation des équipes.

Des référentiels comme ISO 22301, ISO 27001 ou NIST abordent d’ailleurs différentes dimensions liées à la continuité et à la résilience. La valeur du BIA ne réside donc pas uniquement dans la production d’un document supplémentaire, mais dans la création d’une compréhension commune des activités critiques et de leurs dépendances.

Pour les équipes TI, cette connaissance permet de transformer une affirmation générale — « ce système est critique » — en questions plus précises : quel est l’impact de son interruption, combien de temps peut-on fonctionner sans lui, quelles sont ses dépendances et existe-t-il un mode de fonctionnement temporaire?

Prioriser avant que l’incident ne survienne

Lorsqu’une organisation considère tous ses systèmes comme également critiques, elle ne dispose en réalité d’aucune priorité. Les équipes doivent alors prendre des décisions sous pression au moment même où leurs ressources sont les plus sollicitées.

Le BIA permet de déplacer cette discussion avant l’incident. Les besoins des unités d’affaires sont comparés aux dépendances techniques, aux solutions de contournement et aux conséquences réelles d’une interruption. Les investissements en résilience peuvent ensuite être concentrés sur les systèmes dont l’indisponibilité présente le plus grand risque.

Le cas présenté par Énergir montre ainsi que la continuité TI ne se résume pas à la restauration des technologies. Elle permet de créer un lien entre les activités de l’entreprise, les architectures techniques et les décisions qui devront être prises lorsqu’une partie de l’environnement ne sera plus disponible.