Résilience numérique : protéger l’activité

Une indisponibilité du système d’information ne devient pas nécessairement une crise majeure. Elle le devient lorsque l’organisation ne sait plus quelles activités prioriser, qui décide des modes dégradés, comment communiquer ni dans quel délai retrouver un niveau de service acceptable. La résilience numérique répond précisément à cette question : maintenir et rétablir les capacités numériques indispensables à l’activité, y compris lorsque les scénarios prévus ne se déroulent pas comme prévu.

Pour une organisation exposée à des exigences réglementaires, à des chaînes de valeur étendues ou à des services critiques, le sujet dépasse largement la sauvegarde des données et le plan de reprise informatique. Il concerne la gouvernance, les métiers, les prestataires, la cybersécurité, la gestion de crise et la continuité d’activité. Une démarche efficace relie ces composantes au lieu de les traiter comme des dispositifs indépendants.

La résilience numérique ne se limite pas au PRA

Le plan de reprise d’activité informatique, ou PRA, reste un élément central. Il organise la restauration d’infrastructures, d’applications, de données et de services techniques après une interruption. Mais un PRA techniquement performant ne garantit pas, à lui seul, la continuité des activités critiques.

Prenons le cas d’une application restaurée dans les délais annoncés, alors que son fournisseur d’identité reste indisponible, que les équipes métiers ne disposent pas de procédures de contournement ou que les données restaurées ne correspondent pas au dernier état validé. Le service n’est alors pas réellement disponible pour les utilisateurs. La reprise technique doit donc être évaluée à l’aune d’une reprise opérationnelle.

La résilience numérique englobe cette capacité à absorber une perturbation, à fonctionner dans un mode acceptable pendant l’incident, puis à rétablir l’activité de manière maîtrisée. Elle couvre les cyberattaques, les pannes majeures, les erreurs de changement, les indisponibilités de fournisseurs cloud, la corruption de données et les défaillances de télécommunications. Elle prend aussi en compte les incidents combinés, par exemple une attaque par rançongiciel suivie d’une crise de communication et d’une indisponibilité de prestataire.

Il ne s’agit pas de promettre l’absence d’interruption. Cette promesse serait rarement crédible. L’objectif consiste plutôt à définir ce qui doit impérativement être préservé, dans quelles limites de temps et de dégradation, avec quelles responsabilités et quels moyens de décision.

Partir des activités critiques, pas des seuls actifs techniques

La difficulté la plus fréquente est de construire la démarche à partir de l’inventaire des technologies. Cette approche est utile pour connaître le patrimoine numérique, mais elle peut conduire à protéger avec le même niveau d’effort des composants dont les impacts métiers sont très différents.

L’analyse d’impact sur l’activité, ou BIA, apporte le point de départ nécessaire. Elle permet d’identifier les processus critiques, leurs dépendances, les conséquences d’une interruption et les délais maximaux admissibles. Les objectifs de délai de reprise, les RTO, et les objectifs de perte de données, les RPO, ne doivent pas être décidés uniquement par l’IT. Ils traduisent une décision de risque portée par les métiers et arbitrée par la gouvernance.

Cette analyse fait émerger des dépendances souvent sous-estimées : annuaires et gestion des identités, outils collaboratifs, messagerie, interfaces avec des partenaires, équipements de sécurité, données de référence, personnel habilité ou accès aux sites. Un service client peut, par exemple, disposer d’une solution de secours, mais rester incapable de traiter les demandes si la base de connaissance ou l’outil de téléphonie n’est pas accessible.

La granularité doit rester proportionnée. Cartographier l’ensemble du système d’information dans le moindre détail peut devenir coûteux et vite obsolète. À l’inverse, une cartographie trop générale ne permet pas de concevoir des stratégies réalistes. Le bon niveau est celui qui permet de prendre une décision utilisable en situation de crise : quelles fonctions sont prioritaires, quelles dépendances les conditionnent et quel niveau de service doit être assuré.

Définir un niveau de service acceptable en crise

La continuité ne signifie pas toujours la poursuite à 100 % de la capacité nominale. Pour certaines activités, un traitement manuel temporaire, une limitation des canaux d’accès ou la priorisation de catégories de clients constituent des réponses adaptées. Pour d’autres, notamment lorsqu’une obligation réglementaire ou de sécurité est en jeu, aucune dégradation ne sera acceptable au-delà d’un délai très court.

Le mode dégradé doit être conçu, documenté et testé avec les équipes qui l’exécuteront. Une procédure qui dépend d’un tableur inaccessible, d’un annuaire compromis ou d’une validation par une personne indisponible ne constitue pas une solution de continuité fiable. La question à poser n’est pas seulement « comment reprendre ? », mais aussi « comment opérer avant la reprise complète ? ».

Construire une gouvernance de résilience numérique

La résilience numérique est transversale par nature. La direction des systèmes d’information, la sécurité des systèmes d’information, les responsables métiers, le risque, la conformité, les achats, le juridique et la communication de crise ont chacun un rôle à jouer. Sans gouvernance claire, l’organisation obtient généralement des plans nombreux mais peu coordonnés.

Une gouvernance efficace définit des responsabilités explicites avant l’incident. Elle précise qui qualifie l’événement, qui peut déclencher un dispositif de crise, qui arbitre la restauration des services, qui valide le retour à la normale et qui porte la communication interne ou externe. Ces décisions doivent être préparées en amont, car elles ne peuvent pas être improvisées sous la pression.

Le cadre de l’ISO 22301 aide à structurer cette démarche en reliant politique, analyse d’impact, analyse des risques, stratégies, plans, exercices et amélioration continue. Il ne remplace pas l’expertise technique ni les exigences sectorielles, mais il fournit un langage commun et une logique de management qui facilitent la démonstration de maîtrise auprès de la direction, des auditeurs et des autorités de supervision.

Les prestataires doivent faire partie du périmètre. L’externalisation d’une application, d’une plateforme cloud ou d’un centre de services ne transfère pas la responsabilité de la continuité à l’extérieur. Les contrats, engagements de service, capacités de réversibilité, modalités d’alerte et preuves de tests doivent être examinés au regard des exigences réelles de l’activité. Un engagement de disponibilité élevé ne répond pas nécessairement à une exigence de récupération des données ou de gestion de crise.

Tester ce qui se passera réellement

Un plan non exercé reste une hypothèse. Les tests techniques de restauration sont indispensables, mais ils ne suffisent pas à vérifier les mécanismes de décision, la coordination interéquipes et la capacité des métiers à opérer en situation dégradée.

Les exercices les plus utiles sont progressifs. Un test de restauration peut confirmer l’intégrité d’une sauvegarde et le respect d’un délai de reprise. Un exercice sur table permet ensuite aux décideurs de travailler les arbitrages, la communication et l’escalade. Enfin, une simulation de crise plus large révèle les difficultés de coordination avec les prestataires, les fonctions support et les équipes métiers.

L’objectif n’est pas de mettre les participants en défaut. Il est de détecter les écarts entre le dispositif théorique et les capacités effectives : informations manquantes, dépendances oubliées, accès d’urgence non opérationnels, rôles imprécis ou seuils de décision mal définis. Chaque exercice doit déboucher sur un plan d’actions priorisé, doté d’un responsable, d’une échéance et d’un suivi de gouvernance.

La fréquence des tests dépend du niveau de criticité, de la stabilité de l’environnement et du rythme des transformations. Une organisation qui déploie régulièrement de nouvelles architectures cloud, des interconnexions ou des solutions SaaS doit réviser ses hypothèses plus souvent qu’une organisation disposant d’un environnement stable. Les changements majeurs doivent déclencher une réévaluation, plutôt qu’attendre le cycle annuel de revue.

Mesurer la capacité de résilience numérique

Les indicateurs ne doivent pas se réduire au nombre de plans disponibles ou au taux de réussite des sauvegardes. Ces mesures sont utiles, mais elles ne reflètent pas nécessairement la capacité à préserver une activité critique.

Une mesure pertinente combine plusieurs dimensions : couverture des processus critiques par des stratégies validées, respect des RTO et RPO lors des tests, taux de dépendances critiques qualifiées, délai d’activation de la cellule de crise, traitement des actions correctrices et participation effective des métiers aux exercices. L’enjeu est de rendre visibles les écarts qui exposent réellement l’organisation.

La maturité ne se mesure pas à la quantité de documentation produite. Elle se reconnaît à la capacité des responsables à expliquer les priorités, à produire des preuves de tests, à assumer les arbitrages de risque et à activer des réponses cohérentes lorsque l’incident survient. Cette capacité suppose des compétences partagées et régulièrement entretenues.

Professionnaliser les acteurs de la continuité d’activité, de la gestion de crise, de l’IT et de la cybersécurité permet de créer ce socle commun. Les formations structurées et les référentiels reconnus donnent aux équipes les méthodes nécessaires pour transformer des exigences parfois abstraites en dispositifs opérationnels, auditables et améliorables.

La prochaine perturbation ne respectera probablement pas les limites entre cyber, informatique et métier. La question utile pour chaque organisation est donc concrète : si un service numérique critique devient indisponible demain matin, les équipes savent-elles encore servir leurs clients, respecter leurs obligations et décider ensemble des priorités ?

Cet article est également disponible en :