Une fois par an, un samedi matin, l’exercice de bascule se déroule comme prévu. Les équipes basculent sur le site de secours, vérifient que les applications critiques redémarrent, relèvent les temps, produisent un rapport. Le rapport conclut que le plan fonctionne. Il part au comité des risques, parfois au régulateur, puis il est rangé.

Six mois plus tard, un mardi après-midi, le parcours de souscription en ligne devient inutilisable pendant deux heures. Aucun serveur n’est tombé, aucun site n’a été perdu. Un service tiers d’authentification répondait en plusieurs secondes au lieu de quelques centaines de millisecondes ; les appels se sont accumulés, les pools de connexion se sont saturés, et un back-office sans rapport apparent est devenu inaccessible à son tour. Le plan de reprise n’a jamais été déclenché — il n’y avait rien à reprendre. Le système ne s’était pas arrêté : il avait cessé de fonctionner.

Ces deux scènes racontent la même chose. L’organisation dispose d’un plan pour le sinistre qu’elle ne connaîtra probablement jamais, et d’aucune conception pour l’incident qu’elle vit plusieurs fois par an. C’est la thèse de cet article : la résilience n’est ni un document, ni une option d’infrastructure que l’on achète à part. C’est une propriété du système, qui découle de la façon dont il est structuré — des dépendances qu’il porte, des délais qu’il tolère, et de ce qu’il sait encore faire quand une partie de lui-même est indisponible. Comme la sécurité, elle se décide dans les vues d’architecture. À la différence de la sécurité, elle n’affronte pas un adversaire : la défaillance n’a besoin d’aucune intention pour survenir.

Le plan répond à la mauvaise question

Le plan de continuité et le plan de reprise raisonnent sur un modèle précis de panne : un événement franc, localisé, qui rend indisponible un site, une salle, une infrastructure. La réponse est adaptée à ce modèle — un site de secours, des sauvegardes restaurables, une procédure de bascule, une chaîne de décision. Ce dispositif est nécessaire, souvent exigé, et il n’est pas question de le remettre en cause. Il faut simplement voir ce qu’il ne couvre pas.

Ce modèle suppose une panne binaire : le composant fonctionne ou il ne fonctionne pas. Or la panne franche est le cas facile. Un composant clairement mort est détecté, sorti du service, contourné. Les incidents qui coûtent réellement cher sont d’une autre nature : partiels, progressifs, ambigus. Un stockage qui répond dix fois plus lentement. Une file qui accumule sans jamais rien perdre. Un service qui renvoie des réponses valides mais périmées. Rien de tout cela ne déclenche un plan de reprise, parce que rien n’est tombé.

Le plan raisonne également en infrastructure — des sites, des machines, des sauvegardes — alors que la défaillance, elle, voyage le long d’un parcours métier. Souscrire un contrat, exécuter un virement, ouvrir un dossier : chacun de ces parcours traverse une dizaine de composants, dont plusieurs échappent au périmètre de l’organisation — un service SaaS, une API partenaire, un opérateur, un fournisseur d’identité. Aucun plan de bascule ne prévoit qu’un partenaire ralentisse.

Le plan de continuité est donc un plancher, pas une réponse. Il traite le scénario extrême et rare. La résilience traite le comportement ordinaire du système en conditions dégradées — et celui-là ne se décrète pas dans un document : il se conçoit.

Disponibilité affichée, résilience réelle

Dans la plupart des organisations, la disponibilité se discute composant par composant, sous forme d’engagement contractuel. Chaque brique affiche son taux, chaque fournisseur son niveau de service, et l’ensemble donne l’impression d’un système solide. Cette lecture comporte deux angles morts.

Le premier est arithmétique. Les taux ne s’additionnent pas, ils se multiplient. Un parcours qui a besoin simultanément de huit composants, chacun engagé à 99,9 %, ne peut pas dépasser environ 99,2 % — soit, si les défaillances sont indépendantes, de l’ordre de soixante-dix heures d’indisponibilité par an là où chaque brique, prise isolément, en promettait moins de neuf. Le calcul est trivial, et pourtant il est rarement posé : on négocie la disponibilité des pièces, jamais celle du parcours.

Le second angle mort est plus sérieux, car il rend le calcul précédent optimiste. Il suppose l’indépendance des défaillances. Or les composants d’un système partagent des dépendances : un annuaire, un service d’identité, une résolution de noms, un réseau, un socle de paiement, une plateforme d’orchestration. Deux instances redondées qui s’appuient sur la même dépendance ne sont pas redondées : elles tombent ensemble. La redondance sur le schéma n’est pas la redondance dans les faits.

Il faut ajouter une remarque sur les engagements de service eux-mêmes : un SLA n’est pas une garantie de comportement, c’est un engagement commercial assorti d’une pénalité. Il ne restaure rien, il compense. Une organisation qui fonde sa résilience sur les taux affichés par ses fournisseurs a transféré un risque financier marginal, pas un risque opérationnel.

De cette lecture découlent deux leviers, et un seul est habituellement utilisé. Le premier consiste à fiabiliser chaque composant — utile, coûteux, et à rendement rapidement décroissant. Le second consiste à réduire le nombre de composants strictement nécessaires à un parcours, en rendant les autres optionnels. C’est de loin le plus efficace, et c’est une décision d’architecture, pas d’exploitation.

RTO et RPO : des objectifs qui doivent redescendre en décisions

Deux notions structurent la continuité. Le RTO (recovery time objective) est la durée d’interruption acceptable avant que la conséquence ne devienne inacceptable. Le RPO (recovery point objective) est la quantité de données que l’on accepte de perdre — l’écart entre le dernier état sûr et le moment de la panne.

Ces objectifs sont fixés en atelier, avec le métier. C’est une bonne pratique, et elle échoue presque toujours au même endroit : les valeurs obtenues ne redescendent jamais en contraintes de conception. Interrogé sans contrepartie, le métier répond « zéro » aux deux questions — ce qui est parfaitement rationnel, puisque la réponse est gratuite.

Le travail d’architecture consiste précisément à rendre le prix de la réponse visible, en traduisant chaque objectif en décision technique et en coût.

Un RPO proche de zéro impose une réplication synchrone : aucune écriture n’est confirmée tant qu’elle n’est pas répliquée. Cela contraint la latence de chaque écriture, donc la distance entre les sites, donc la protection réelle contre un sinistre régional. On ne peut pas être à la fois très proche pour la performance et très loin pour la sécurité : l’arbitrage est physique.

Un RPO de quelques minutes autorise une réplication asynchrone, moins contraignante et beaucoup moins chère. Mais il crée une obligation que l’on oublie de concevoir : après reprise, il reste un trou de données. Qui le comble ? Par quel rejeu, quelle réconciliation, quelle double saisie, dans quel délai ? Un RPO non nul est un engagement pris sur un processus métier, pas seulement sur une technologie de réplication.

Un RTO de quelques minutes suppose un dispositif actif ou préchauffé, avec une bascule automatique. Et la bascule automatique doit elle-même être conçue avec méfiance : un système qui bascule à tort — sur un faux positif, ou en se dédoublant faute d’arbitre — vient d’ajouter une panne à son inventaire. Le mécanisme de reprise est un composant critique de plus, souvent le moins éprouvé de tous.

Poser ces objectifs sans les traduire donne une illusion de maîtrise. Les traduire transforme la continuité en ce qu’elle doit être : une série d’arbitrages coût / risque, instruits et assumés.

Quatre modes de défaillance que le plan ne voit pas

La dépendance partagée. C’est le premier réflexe à acquérir : cesser de demander « quels composants sont redondés ? » pour demander « quels composants tombent en même temps ? ». Un service d’authentification, une base de configuration, un bus d’événements, un socle de paiement : ces briques transverses transforment un incident local en incident général, précisément parce que tout le monde s’appuie dessus sans l’avoir décidé.

La défaillance grise. Un composant lent n’est pas un composant mort. Il répond, donc les sondes de santé le déclarent vivant, donc le trafic continue de lui être envoyé, donc la file d’attente grossit en amont. C’est le mode de défaillance le plus destructeur, parce que le système refuse de reconnaître qu’il est en panne. La détection n’est pas une propriété donnée : elle se conçoit — sur des seuils de latence et des taux d’erreur, pas sur la seule question « le service répond-il ? ».

La cascade. Un ralentissement partiel devient une panne générale par amplification. Les appels échouent, les clients relancent, les relances saturent ce qui tenait encore, et une politique de réessai sans limite se met à attaquer le système de l’intérieur. Le trafic de reprise est d’ailleurs souvent plus violent que le trafic nominal : au redémarrage, tout le monde revient en même temps, caches vides. Un système qui n’a pas été conçu pour se protéger de ses propres clients se remet difficilement d’un incident mineur.

Le tiers unique. Externaliser une capacité n’externalise pas la responsabilité. Une dépendance à un prestataire unique — hébergeur, éditeur en mode service, opérateur de paiement — est un point de défaillance que le contrat encadre mais que l’architecture doit instruire : que fait-on pendant l’indisponibilité, et pas seulement combien récupère-t-on après. C’est aujourd’hui l’un des points de vigilance les plus explicites des régulateurs, qui regardent la concentration du risque fournisseur autant que la robustesse interne.

Concevoir pour la panne : quatre décisions structurantes

Cloisonner. La question à trancher au moment de dessiner la cible n’est pas « qu’est-ce qui doit être redondé ? », mais « qu’est-ce qui ne doit pas pouvoir faire tomber quoi ? ». Des ressources partagées — un pool de connexions, une base commune, une file unique, un même socle d’exécution — sont des chemins de propagation. Cloisonner, c’est accepter une part de duplication pour borner le rayon d’impact. Cela se décide sur le schéma d’architecture, pas dans un réglage d’exploitation.

Décider le mode dégradé avant l’incident. C’est la décision la plus importante, et la plus souvent absente. Que fait le parcours quand telle dépendance est indisponible ? Refuser proprement ? Mettre en attente et rejouer ? Servir une donnée un peu ancienne en l’assumant ? Accepter l’opération avec une vérification différée ? Ces options ne sont pas techniques : ce sont des arbitrages métier et risque. Accepter une transaction sans contrôle temps réel, c’est ouvrir une fenêtre de risque assumée ; refuser, c’est un coût commercial et parfois un risque réglementaire. Ce choix appartient au métier, il se documente comme une décision d’architecture. S’il n’est pas fait à froid, il sera fait à trois heures du matin par la personne d’astreinte, seule, sans mandat.

Borner l’attente. Un appel sans délai maximal est une dépendance sans contrat. Les délais d’expiration, les coupe-circuits qui isolent un composant défaillant au lieu de continuer à l’appeler, les réessais espacés et plafonnés : ce sont des instruments de conception, pas des détails d’implémentation. Il vaut la peine de le dire crûment — laisser les valeurs par défaut d’une bibliothèque décider du comportement du système en incident, c’est déléguer une décision d’architecture à un inconnu.

Traiter l’état comme le point dur. Ce qui est sans état se réplique, se redémarre, se déplace ; le problème n’est jamais là. Le point dur est la donnée : sa cohérence, sa reprise, et surtout les effets de bord d’un réessai. Un ordre exécuté deux fois parce que le premier appel a expiré sans que la réponse revienne est un incident bien plus coûteux qu’une indisponibilité. L’idempotence — la garantie qu’une même opération répétée produit le même résultat — doit être une exigence du contrat d’interface, décidée en même temps que l’interface elle-même, et non un correctif ajouté après le premier double débit.

Le niveau de résilience se décide capacité par capacité

Toute cette ingénierie coûte cher. L’appliquer uniformément est une faute d’allocation aussi coûteuse que la sous-protection : on paie partout pour ce qui ne compte qu’à certains endroits, et on manque quand même le chemin critique.

La bonne unité de raisonnement n’est ni le serveur, ni même l’application : c’est la capacité métier. La question à poser est simple et se pose avec le métier : combien de temps cette capacité peut-elle être indisponible avant que la conséquence ne devienne irréversible ? Irréversible au sens réglementaire, financier, ou de réputation. Certaines capacités supportent une journée sans dommage durable. D’autres se comptent en minutes. Cette différence doit se lire dans l’architecture, faute de quoi elle n’existe pas.

Un piège classique guette ici : classer les applications par criticité plutôt que les parcours. Une application jugée secondaire mais située sur le chemin d’un parcours critique est, de fait, critique — et c’est presque toujours par là que l’incident arrive. La criticité se propage le long des dépendances ; elle ne se déclare pas application par application.

Ce qui n’est pas éprouvé n’est pas résilient

Un mode dégradé qui n’a jamais été exercé n’est pas un mode dégradé : c’est une hypothèse. Et la plupart du temps, c’est une hypothèse fausse — non par incompétence, mais parce que le comportement d’un système en défaillance partielle n’est pas déductible de sa documentation.

L’épreuve se construit par paliers, et il n’est pas nécessaire de commencer par le sommet. Le premier palier est une revue de conception qui prend chaque dépendance et demande ce qui se passe si elle ralentit, puis si elle disparaît. Il ne coûte rien d’autre que de la discipline et met déjà au jour des angles morts. Le deuxième est l’exercice de bascule, à condition qu’il porte sur des parcours métier complets et non sur le redémarrage de machines. Le troisième est l’injection contrôlée de défaillances en préproduction — couper une dépendance, ajouter de la latence, observer. Le quatrième, réservé aux organisations qui maîtrisent les trois précédents, consiste à conduire ces expériences en production, sur un périmètre borné.

Un préalable conditionne tout l’édifice : on ne rend pas résilient ce que l’on ne sait pas observer. Si les indicateurs disponibles ne permettent pas de distinguer « lent » de « mort », ni de dire si le parcours fonctionne alors que tous les composants sont déclarés en bonne santé, aucun mécanisme de protection ne se déclenchera au bon moment. Mesurer la disponibilité des composants et ignorer celle des parcours revient à surveiller les organes sans jamais prendre le pouls.

C’est aussi le sens du mouvement réglementaire actuel. Dans le secteur financier européen, le règlement sur la résilience opérationnelle numérique, applicable depuis janvier 2025, déplace explicitement l’exigence : il ne suffit plus de disposer d’un plan, il faut tester sa capacité à absorber une défaillance, y compris celle d’un prestataire tiers. Les régulateurs de la région, Bank Al-Maghrib au premier rang, encadrent de longue date la continuité d’activité des établissements et le recours à l’externalisation. Quel que soit le texte applicable, la direction est la même : la preuve remplace la déclaration.

Ce que la résilience demande vraiment

Rien de ce qui précède n’est un chantier d’infrastructure. La résilience est un ensemble de décisions de conception — quelles dépendances on accepte de porter, ce qu’on garde en fonctionnement quand elles cèdent, ce qu’on renonce délibérément à servir, et où l’on accepte de payer pour ne pas céder du tout. Ces décisions se prennent au moment où l’architecture cible est dessinée. Après, elles coûtent le prix d’une refonte.

Une organisation résiliente ne se reconnaît donc pas à l’épaisseur de son plan de reprise. Elle se reconnaît à ceci qu’elle sait comment son système se comporte quand une partie de lui-même défaille — parce qu’elle l’a décidé à froid, écrit, et éprouvé. Le mardi après-midi, cela fait toute la différence : non pas éviter l’incident, mais savoir d’avance ce que l’on continue de faire, et ce que l’on choisit d’arrêter.