Pendant des années, la résilience technologique se mesurait à deux chiffres : RTO (le temps nécessaire pour que l’entreprise reprenne ses activités) et RPO (la quantité d’informations pouvant être perdue). Aujourd’hui, ces indicateurs ne suffisent plus. La pression réglementaire — ainsi que celles des clients, auditeurs et assureurs cyber — pousse vers une nouvelle norme : revenir rapidement ne suffit plus ; il faut pouvoir expliquer, avec traçabilité et preuves, ce qui est arrivé aux données, quels contrôles ont agi et comment le service a été relancé sans « taches » dans les registres.

On peut nommer cette évolution : résilience basée sur l’explicabilité. Il ne s’agit pas simplement d’un concept, mais d’une approche concrète, intégrant un « mode audit » : processus reproductibles, enregistrements propres, preuves automatisées, et une chaîne de garde des données capable de répondre à des questions difficiles.

Le déclencheur : réglementation + risque + confiance

Ce changement ne vient pas uniquement d’Europe. Un modèle global se dessine :

• Les régulateurs exigent des contrôles vérifiables, la gestion du risque lié aux tiers, des tests réguliers et la notification des incidents.
• Les clients entreprise réclament des garanties contractuelles (et de plus en plus, des questionnaires de sécurité avec des preuves à l’appui).
• Les assureurs veulent moins de promesses et plus de « preuves de vie » : copies immuables, tests de restauration, inventaires d’actifs, et procédures documentées.

L’Europe a franchi une étape avec des cadres comme DORA, applicable dès le 17 janvier 2025, qui standardise les obligations de résilience numérique dans le secteur financier et pour la chaîne de fournisseurs.

Parallèlement, des cadres comme le NIST Cybersecurity Framework 2.0 (très utilisés comme langage commun lors des audits et pour les programmes de sécurité) renforcent le concept de gouvernance et d’évidence, en ajoutant la fonction Govern au noyau du cadre.

Aux États-Unis, même si on ne parle pas explicitement de « résilience » de façon abstraite, la divulgation réglementaire est exigée : la SEC impose de déclarer les incidents matériels dans un Form 8-K sous 4 jours ouvrables après que la société en a déterminé la matérialité.

Qu’est-ce que la « résilience explicable » exactement ?

Ce n’est pas un produit, mais une approche. Elle consiste à passer de « faire des copies » à gérer un système de restauration vérifiable. Elle inclut, au minimum :

1. Traçabilité des données (data lineage) : pouvoir reconstruire tout le parcours : origine → transformations → accès → stockage → sauvegardes → restauration.
2. Auditabilité par conception : logs cohérents, centralisés, avec une durée de conservation définie, garantissant l’intégrité et la gestion des changements.
3. Récupération répétable : runbooks, automatisation, et tests réguliers avec stockage des résultats comme preuve.
4. Contrôles démontrables : identité, privilèges minimaux, segmentation, chiffrement, gestion des clés, et responsabilités clairement définies avec des tiers.

La différence clé avec le « DR classique » réside dans la question : non plus « sommes-nous revenus ? », mais :

• Quels données ont été affectées ?
• Quels contrôles ont empêché ou non la propagation ?
• Quelle preuve montre que la restauration est complète et non manipulée ?
• Comment justifier, lors d’un audit, que l’activité est revenue à un état fiable ?

Tableau récapitulatif des réglementations et cadres : où s’appliquent-ils et ce qu’ils exigent concrètement

Note pratique : en dehors de « la loi », de nombreuses industries ajoutent des couches sectorielles (finance, santé, infrastructure critique) avec des guides et standards qui, lors d’audits, deviennent presque aussi exigeants que des normes officielles.

La partie difficile : l’évidence devient un « produit »

Dans un audit moderne, ou lors d’un incident grave, l’entreprise ne se limite pas à une course technologique. Elle doit aussi pouvoir démontrer qu’elle opère avec contrôle.

Concrètement, les équipes ont besoin d’un « paquet » d’évidences récurrentes :

• Inventaire dynamique des systèmes, données et dépendances (incluant SaaS et tiers).
• Carte des flux : quels données transitent, vers où, et pourquoi.
• Tests de restauration avec procès-verbaux : quand ont-ils été faits, ce qui a été récupéré, le délai, les échecs et leur correction.
• Immuabilité réelle sur les copies critiques (et preuve qu’elles ne peuvent pas être effacées accidentellement).
• Chaîne de garde durant incidents : qui a accédé, ce qui a été changé, quand.
• Contrôle des changements (infra et configuration) avec traçabilité.

L’essentiel est que ces preuves ne doivent pas être « fabriquées » après coup. Elles doivent sortir automatiquement du système de l’organisation.

Comment élaborer une stratégie de résilience en privilégiant la conformité

1) Commencer par les données, pas par l’infrastructure

La première question n’est pas « Quelle sauvegarde utilisons-nous ? », mais :

• Quels sont les données critiques, personnelles ou réglementées ?
• Quelles ensembles de données supportent des processus vitaux (facturation, ERP, identité, opérations) ?
• Quelles dépendances externes peuvent bloquer la récupération (DNS, IdP, référentiels, licences, APIs) ?

Ce qui conduit à une classification utile pour la résilience : criticité + sensibilité + dépendance.

2) Définir une « récupération fiable », pas seulement « rapide »

Une restauration qui relance le service mais soulève des doutes (intégrité, manipulation, incohérences) peut poser de sérieux problèmes légaux ou réputationnels.

Pour cela, trois contrôles « anti-discussion » sont recommandés :

• Restaurations vérifiées : contrôles d’intégrité, validations d’applications, reconciliation des données.
• Environnements de quarantaine : pour restaurer sans réinfecter (ransomware, mouvements latéraux).
• Runbooks avec points de contrôle : étapes à valider avant de déclarer le service « OK ».

3) Faire des logs un atout réglementaire

Si les logs sont incomplets, dispersés ou peu fiables, l’organisation se retrouve sans récit crédible.

Pratiques recommandées dans cette optique :

• Centralisation (SIEM / logs) avec retenue définie.
• Intégrité (sous seal, WORM ou mécanismes équivalents).
• Corrolation avec l’identité (qui a fait quoi).
• Preuve des alertes et réponses (qu’est-ce qui a été détecté, contenu, leçons).

4) Considérer les fournisseurs comme partie intégrante du périmètre

DORA, NIS2 et la réalité terrain convergence ici : si un acteur critique dépend d’un fournisseur, sa résilience devient la tienne.

Cela implique :

• Contrats avec SLA de récupération et exigences de preuves.
• Droit à l’audit / rapports (SOC, ISO, etc.).
• Plan de sortie (portabilité, restauration alternative).

5) Faire des tests une routine (et conserver les preuves)

Le test annuel « pour faire joli » n’est plus suffisant. Les bonnes pratiques actuelles incluent :

• Des tests courts et fréquents (systèmes par systèmes).
• Un test « réaliste » périodique (simulations de perte, ransomware, défaillance d’un fournisseur).
• Archivage des résultats pour preuves : délais, échecs, actions correctives.

Le message final : la résilience, c’est la confiance vérifiable

Le mouvement global tend vers un modèle où la continuité d’activité fait l’objet d’audits. Ce n’est plus seulement une mise en œuvre, mais une gouvernance. Et cela illustre l’essence de la résilience explicable : concevoir pour récupérer, oui, mais surtout pour pouvoir démontrer que cette récupération a été correcte, intégrale et maîtrisée.