Résilience

Qu’est-ce qui continue de fonctionner lorsque quelque chose tombe en panne ?

Une organisation fait tout ce que la planification de résilience demande. Deux centres de données. Deux fournisseurs réseau. Une sauvegarde testée. Un plan de continuité validé par le conseil d’administration.

Puis un incident survient. Il apparaît que les deux liaisons réseau passent par la même gaine sous la même route. Les deux centres de données dépendent du même service d’identité, qui tombe avec le système principal. La sauvegarde est intacte, mais la procédure pour l’activer suppose un canal de communication qui a échoué avec tout le reste. Chaque composant était dupliqué. Rien n’était indépendant.

La plupart des organisations avec lesquelles nous parlons ne manquent pas de mesures de résilience. Ce qui leur manque souvent, c’est une réponse claire à une question plus étroite : lorsqu’une dépendance précise disparaît, quelle fonction essentielle continue de fonctionner, pendant combien de temps, à quel niveau, sous quelle autorité et avec quelle voie de retour à la normale ?

C’est là que la résilience cesse d’être une checklist et devient une propriété d’ingénierie.

Notre position est simple. La résilience est une propriété d’une fonction essentielle soumise à une condition de défaillance nommée. « Résilient », pris isolément, n’est pas une affirmation que l’on puisse tester. « Cette fonction continue à ce niveau pendant cette durée lorsque cette dépendance est perdue » en est une.

Commencer par la fonction, pas par l’inventaire

Le travail sur la résilience commence souvent par un inventaire : systèmes, sites, liaisons, sauvegardes, fournisseurs. L’inventaire est utile. Il ne dit pas ce que l’organisation essaie de préserver.

Nous commençons par la fonction qui doit continuer. Effectuer des paiements. Coordonner une réponse d’urgence. Maintenir disponible un service public d’information. Exploiter un processus de traitement de l’eau. Chacune dépend de nombreuses choses à la fois : énergie, communications, identité, données, accès physique, personnes, logistique, connaissances spécialisées et services externes.

Ce n’est qu’une fois la fonction nommée qu’il devient possible de demander lesquelles de ces dépendances comptent, lesquelles peuvent être perdues quelque temps et lesquelles ne peuvent pas être perdues du tout.

La différence est pratique. Un inventaire peut montrer que chaque système possède une sauvegarde. Seule une vue centrée sur la fonction peut montrer que toutes les sauvegardes dépendent de la même chose.

La duplication n’est pas l’indépendance

La redondance est facile à dessiner et facile à surestimer. Un système peut contenir de nombreuses copies et pourtant conserver un seul point où elles échouent toutes ensemble.

Nous appelons domaine de défaillance l’ensemble des éléments qu’un même événement peut supprimer. La première question que nous posons à toute conception de résilience est : quel événement unique pourrait supprimer à la fois le système principal et son repli ? Si la réponse est le même événement, l’organisation possède de la duplication, pas de l’indépendance.

Les domaines de défaillance prennent différentes formes, et les plus dangereux sont les moins visibles.

Physique. Deux routes de fibre dans la même tranchée. Deux installations alimentées par le même transformateur. Deux sites accessibles par le même pont. Des serveurs redondants partageant le même système de refroidissement.

Numérique. Un seul fournisseur d’identité derrière toutes les applications. Une seule autorité DNS. Un seul compte cloud contenant la production et la sauvegarde. Une seule chaîne de déploiement dont dépend toute reprise.

Opérationnel. Une seule équipe qui sait restaurer le système. Un seul fournisseur autorisé à le réparer. Un seul administrateur capable de récupérer les clés.

Institutionnel. Une seule autorité dont l’approbation est nécessaire avant que quiconque puisse agir. Un transfert entre organisations sans solution de repli s’il échoue. Une règle d’achat qui rend une substitution d’urgence impossible.

Une redondance sans séparation des domaines de défaillance n’est pas de la résilience. Le travail n’est pas de compter les copies, mais de découvrir quelles voies apparemment indépendantes peuvent encore échouer ensemble.

Une manière délibérée de se dégrader

La continuité ne signifie pas toujours un service complet. Parfois, le bon résultat est un service réduit qui maintient la fonction essentielle en vie pendant que le reste attend.

Cela ne fonctionne que si l’état dégradé a été conçu à l’avance. Pour chaque fonction essentielle, une organisation résiliente sait :

• quelle capacité doit rester disponible et laquelle peut être suspendue ;
• combien de temps l’état dégradé doit pouvoir durer ;
• quelles décisions peuvent encore être prises, et par qui ;
• quelles données doivent rester fiables ;
• quelles conditions de sûreté ou de sécurité ne peuvent pas être assouplies ;
• qui a l’autorité pour entrer dans l’état dégradé et en sortir.

Sans ces limites, un système peut être déclaré « disponible » alors qu’il n’assure plus la fonction qui compte.

La résilience n’est pas l’absence de dégradation. C’est la capacité à se dégrader délibérément sans perdre la fonction essentielle.

Toute affirmation de résilience a une frontière

Un test de résilience réussi prouve quelque chose. Il prouve rarement autant que ce qu’on lui attribue ensuite.

Un service qui survit à la perte d’un chemin réseau n’a pas montré qu’il survit à une panne électrique. Un site qui fonctionne une heure sur alimentation de secours n’a pas montré qu’il peut fonctionner trois jours. Un exercice de reprise mené alors que les communications normales et les services d’identité restent disponibles n’a pas montré que la reprise fonctionne lorsque ces services font eux-mêmes partie de l’incident.

Nous attachons donc à toute affirmation de résilience les conditions dans lesquelles elle tient. Nous appelons cela l’enveloppe de défaillance : ce qui était disponible au départ, ce qui a été retiré, pendant combien de temps, quel service minimal était attendu, ce qui s’est réellement produit, de quoi le résultat dépendait encore et comment le fonctionnement normal a été rétabli.

Un résultat réussi à l’intérieur d’une enveloppe ne prouve pas la résilience en dehors de celle-ci. Nous préférons une affirmation étroite et reproductible à une étiquette large qui ne l’est pas.

C’est également ici que la résilience dépend du jugement. Les rapports de test, les assurances des fournisseurs et les certifications formulent tous des affirmations sur la résilience. Une organisation capable de les juger pose chaque fois la bonne question : dans quelles conditions cela a-t-il été démontré, et sont-ce les conditions auxquelles nous sommes réellement confrontés ? Une organisation qui ne peut pas poser cette question dépend d’une étiquette, quelle que soit la précision du rapport qui la soutient.

Planifié, testé et démontré sont trois choses différentes

Toutes les preuves de résilience n’ont pas le même poids. Nous distinguons quatre catégories.

Conception. Elle décrit ce qui est prévu : schémas d’architecture, plans de routage, procédures de reprise. Elle est nécessaire, car elle indique ce qu’il faut tester. Elle ne prouve pas que le système se comporte ainsi.

Configuration. Elle décrit comment le système est réellement connecté et paramétré. Elle peut diverger de la conception, et cette divergence constitue elle-même un risque.

Exercice. Il consigne ce qui s’est produit lorsqu’une dépendance réelle a été volontairement retirée ou dégradée. C’est à ce stade qu’une affirmation commence à passer de l’intention à la démonstration.

Incident. Les preuves d’incident montrent ce qui s’est produit lorsqu’une défaillance réelle a eu lieu. Elles révèlent souvent des dépendances qu’aucun exercice n’avait anticipées, mais les conditions ne sont pas contrôlées et les enregistrements peuvent être incomplets.

La réglementation européenne évolue dans la même direction. DORA impose aux entités financières de tester leur résilience opérationnelle numérique, notamment au moyen de tests fondés sur des scénarios, plutôt que de s’appuyer uniquement sur des plans documentés. Le principe vaut bien au-delà de la finance : une capacité planifiée n’est pas une capacité démontrée.

Le test se termine lorsque le fonctionnement normal revient

Un système qui survit à la première phase d’une panne mais ne peut pas revenir proprement à la normale n’a pas achevé le cycle de résilience. La reprise possède ses propres dépendances, souvent celles que personne n’a examinées.

Comment la panne est-elle détectée ? Qui a l’autorité pour agir ? Quel service revient en premier ? Quelles données font autorité après une période d’exploitation divisée ou dégradée, et comment sont-elles réconciliées ? Quels identifiants et quelles clés sont nécessaires, et sont-ils accessibles ? La reprise dépend-elle du même chemin qui a échoué ?

Une sauvegarde qui démarre mais ne peut pas réconcilier ses données peut préserver la disponibilité tout en détériorant l’intégrité. Un site qui peut fonctionner isolément mais ne peut pas se reconnecter en sécurité n’a fait que repousser l’échec.

Le test se termine lorsque la fonction essentielle a retrouvé son état normal défini, pas lorsque le système de repli démarre.

Les défaillances ne respectent pas les organigrammes

Les défaillances les plus lourdes de conséquences franchissent les frontières que les organisations tracent entre leurs services, leurs systèmes et leurs responsabilités.

Une panne électrique devient une panne de communication. Une panne de communication devient une panne d’identité. Une panne d’identité empêche les opérateurs d’accéder aux outils nécessaires à la reprise. La panne électrique de grande ampleur dans la péninsule Ibérique en avril 2025 a montré à quelle vitesse une défaillance dans un système atteint les transports, les télécommunications et les paiements de détail, chacun étant planifié séparément.

C’est pourquoi une carte de dépendances qui s’arrête aux systèmes informatiques est incomplète. Elle doit inclure les personnes, l’autorité, l’énergie, les communications, la logistique et l’accès physique nécessaires pour maintenir une fonction et la rétablir.

Deux conséquences en découlent pour notre manière de travailler.

La corrélation compte davantage qu’un signal isolé. Une anomalie de communication, une irrégularité électrique ou une perturbation logistique peuvent chacune être routinières. Les mêmes trois autour de la même fonction au même moment ne le sont pas. La résilience dépend moins de la collecte de davantage de signaux que de la capacité à voir quand des faiblesses situées dans différents domaines commencent à s’aligner.

La direction compte autant que la position. Un score statique peut masquer le fait qu’un système s’améliore ou se dégrade. Une organisation en état raisonnable mais qui s’affaiblit régulièrement peut être plus exposée qu’une organisation en mauvais état mais qui s’améliore rapidement.

La même logique s’applique aux fonctions qui franchissent les frontières nationales. L’autorité change à la frontière, les procédures diffèrent et les équipements ou les données peuvent traverser plus vite que la responsabilité juridique. La résilience transfrontalière ne peut pas être démontrée entièrement à l’intérieur d’une seule administration. L’exercice doit inclure la frontière elle-même.

La connaissance peut être un point unique de défaillance

La résilience ne concerne pas seulement les actifs. Une fonction peut devenir fragile parce que la capacité à la restaurer repose sur une seule personne, un seul prestataire ou une seule équipe.

Rien ne change visiblement lorsque cette personne prend sa retraite ou que ce contrat prend fin. Le premier signe apparaît généralement lors de l’incident suivant, quand plus personne ne sait pourquoi le système a été configuré ainsi.

Nous incluons donc les connaissances, les capacités spécialisées et la mémoire institutionnelle dans le travail de résilience partout où elles sont essentielles à la continuité ou à la reprise. Qui sait restaurer cette fonction ? Cette connaissance a-t-elle été exercée par plus d’une personne ? L’organisation pourrait-elle la reconstruire si elle la perdait ?

C’est ici que la résilience rejoint notre travail sur le transfert de capacité. Un système qui survit à une panne technique mais pas au départ d’un spécialiste n’est pas résilient. Il a de la chance.

Comment nous travaillons ensemble

Notre approche de la résilience suit la même séquence que le reste de notre travail : comprendre d’abord, puis concevoir, puis tester dans les conditions qui comptent.

Nommer la fonction. S’accorder sur ce qui doit continuer, et à quel niveau minimal.

Cartographier les dépendances. Dans les couches physique, numérique, opérationnelle, institutionnelle et humaine, et identifier les domaines de défaillance qu’elles partagent.

Concevoir l’état dégradé et la voie de reprise. Décider à l’avance ce qui peut être suspendu, ce qui doit tenir, qui décide et comment le fonctionnement normal revient.

Tester dans une enveloppe explicitement définie. Retirer ou dégrader une dépendance réelle, consigner ce qui se produit et préciser exactement ce que le résultat montre et ne montre pas.

Laisser la capacité de juger. L’organisation devrait terminer avec des personnes capables d’évaluer seules le prochain rapport de test, l’assurance d’un fournisseur ou un incident.

Lorsque nous examinons une fonction essentielle avec un partenaire, voici les questions que nous consignons généralement :

La dernière question compte plus qu’il n’y paraît. Un changement de route, de fournisseur d’identité, d’alimentation, de fournisseur ou de procédure peut invalider un résultat antérieur sans modifier le nom du service. Les preuves de résilience ont un cycle de vie et doivent être réexaminées lorsque le système sous-jacent change.

Là où nous sommes prudents

Nous nous imposons quelques engagements quant à ce que nous affirmons.

Nous ne qualifions pas un système de résilient parce qu’il possède une sauvegarde, et nous ne qualifions pas deux systèmes d’indépendants tant que nous ne comprenons pas ce qu’ils partagent.

Nous ne généralisons pas le résultat d’un test de composant réussi à l’ensemble du système, et nous ne traitons pas une simulation comme une preuve d’un comportement physique.

Nous ne présentons pas une capacité planifiée comme une capacité acquise. Lorsqu’une chose a été conçue mais pas encore testée, nous le disons.

Nous ne traitons pas la reprise comme une réflexion tardive et nous ne remplaçons pas le sens de la direction par un score unique.

Et nous ne décrivons rien comme résilient sans nommer la fonction, la condition de défaillance, la frontière et la preuve.

Lectures complémentaires

• Directive (UE) 2022/2557 (CER), relative à la résilience des entités critiques.
• Règlement (UE) 2022/2554 (DORA), relatif à la résilience opérationnelle numérique du secteur financier.

Thèmes associés : Souveraineté · Transfert de capacité · Alerte précoce

Évolution de cette position

• 24 septembre 2026 — Première publication.

Les modifications substantielles sont indiquées ici avec leur date. Les corrections de formulation ou de liens ne le sont pas.