Modèle de maturité pour la résilience informatique opérationnelle

La résilience informatique est un sujet traité sous de nombreux angles, dont certains cadres de référence comme le Cyber Resilience Capability Maturity Model (CR-CMM) qui proposent une vision globale et stratégique. Ces modèles sont précieux pour situer une organisation sur des axes organisationnels, humains et governanceaux. Cependant, lorsqu’il s’agit d’évaluer les pratiques opérationnelles des équipes de la DSI, ils restent parfois trop abstraits pour être directement actionnables sur le terrain.

C’est dans cette optique qu’est née l’idée de ce modèle de maturité plus opérationnel. L’objectif est simple : donner aux équipes techniques un repère concret pour évaluer leur niveau de préparation face à une perte de service, qu’il s’agisse d’une panne matérielle, d’une corruption de données ou d’un sinistre majeur. Chaque niveau représente une capacité supplémentaire à absorber un choc et à rétablir le service.

Niveau 1 — Sauvegarde du disque

Copie des données sur un support externe

C’est le point d’entrée de toute démarche de résilience. À ce stade, l’équipe effectue des copies de ses données sur un support distinct : disque externe, serveur de fichiers, solution de stockage en ligne. En cas de panne ou de suppression accidentelle, il est possible de restaurer les données depuis cette copie.

Ce niveau couvre le besoin le plus fondamental : ne pas tout perdre. Toutefois, il présente des limites importantes. La restauration est souvent manuelle, longue et sujette à des erreurs humaines. De plus, la continuité de service n’est pas garantie pendant la phase de restauration.

Niveau 2 — Redondance du matériel

Load balancing et haute disponibilité

L’organisation franchit ici un cap important : plutôt que de compter uniquement sur la capacité à restaurer, elle cherche à éviter l’interruption de service. La mise en place de load balancers, de clusters actifs-actifs ou actifs-passifs permet de basculer automatiquement sur un nœud sain en cas de défaillance d’un composant.

À ce niveau, la sauvegarde reste présente en filet de sécurité, mais elle n’est plus le seul rempart. L’accent est mis sur la continuité : les utilisateurs ne doivent pas percevoir la panne. Le RTO descend significativement, parfois à quelques secondes.

Niveau 3 — Sauvegarde immuable

Protection contre la corruption et les ransomwares

Les sauvegardes traditionnelles ont un talon d’Achille : elles peuvent elles-mêmes être corrompues ou chiffrées par un attaquant. La sauvegarde immuable répond à ce problème en garantissant que les données sauvegardées ne peuvent pas être modifiées ou supprimées pendant une période définie, y compris par un administrateur.

Ce niveau est particulièrement critique dans les contextes de ransomware. Même si l’infrastructure principale est compromise, les sauvegardes restent intègres et exploitables. C’est une exigence devenue incontournable dans tout plan de reprise d’activité (PRA) sérieux.

Niveau 4 — Virtualisation et snapshots

Sauvegarder un état complet, pas seulement des données

La virtualisation ouvre une nouvelle dimension dans la résilience : la capacité à capturer et restaurer un état complet d’un système — système d’exploitation, configuration, applications et données — en un seul artefact : le snapshot.

Là où les niveaux précédents se concentrent sur les données, la virtualisation permet de sauvegarder l’environnement d’exécution. En cas d’incident, on ne reconstruit pas le système, on revient à un état connu et fonctionnel. Cette approche réduit drastiquement le RPO et le RTO pour les environnements complexes. Elle est également très efficace pour tester des restaurations en environnement isolé avant de les appliquer en production.

Niveau 5 — Reconstruction applicative from scratch

Recompiler, redéployer, reconstruire

Ce niveau marque un changement de philosophie : plutôt que de restaurer une image figée, l’organisation est capable de reconstruire une application complète depuis ses sources. Cela implique la maîtrise du code source, des dépendances logicielles, des configurations d’infrastructure et des procédures de build.

L’intérêt est double. D’abord, cela garantit une reconstruction propre, sans résidu potentiellement compromis d’un ancien état. Ensuite, cela force les équipes à documenter et maintenir à jour l’ensemble de la chaîne de déploiement, ce qui améliore en parallèle la qualité opérationnelle au quotidien. Ce niveau est souvent atteint avec la mise en place de pipelines CI/CD matures et d’une gestion rigoureuse des dépendances.

Niveau 6 — Perte simultanée de plusieurs applications

Résilience à l’échelle du datacenter

Jusqu’ici, les niveaux précédents s’appliquaient principalement à une application ou un service isolé. Ce niveau aborde la résilience à grande échelle : que se passe-t-il si plusieurs applications tombent en même temps ? Comment gérer la perte d’un datacenter entier, qu’elle soit due à un incident physique (incendie, coupure réseau), à une cyberattaque ou à un sinistre naturel ?

Ce scénario requiert une coordination entre équipes, des priorités de reconstruction définies en amont (quelle application relancer en premier ?), des dépendances inter-applicatives documentées et des infrastructures géo-distribuées. Les plans de continuité d’activité (PCA) et de reprise d’activité (PRA) atteignent ici leur pleine dimension. La résilience n’est plus un problème purement technique, elle devient un enjeu de gouvernance et d’arbitrage.

Niveau 7 — Reconstruction automatisée par IaC

Supprimer la contrainte humaine, passer à la contrainte CPU

Le niveau le plus avancé du modèle repose sur l’Infrastructure as Code (IaC). L’ensemble de l’infrastructure — réseaux, machines virtuelles, conteneurs, configurations, droits d’accès — est décrit dans des fichiers de code versionnés (Terraform, Pulumi, Ansible, etc.). La reconstruction de l’environnement complet peut être déclenchée et exécutée de manière entièrement automatisée.

À ce stade, le facteur limitant n’est plus la disponibilité des équipes ni leur connaissance des procédures : c’est la capacité de calcul disponible. Une infrastructure entière peut être recréée en quelques minutes, sans intervention manuelle, à partir d’un état zéro. Ce niveau représente l’état de l’art de la résilience opérationnelle et s’inscrit pleinement dans les principes du chaos engineering et du DevSecOps.

Tableau récapitulatif

Conclusion

Ce modèle n’a pas vocation à remplacer les référentiels existants, mais à compléter l’évaluation là où ils restent abstraits : au niveau des équipes qui en ont la charge au quotidien. Savoir à quel niveau se situe chaque application ou domaine du SI permet de prioriser les investissements, de préparer des scénarios de crise réalistes et de progresser méthodiquement.

La résilience opérationnelle n’est pas un état que l’on atteint, c’est un chemin que l’on parcourt collectivement. Si ce sujet vous parle, que vous souhaitiez partager votre expérience, challenger ce modèle ou simplement en discuter, je serais ravi d’échanger avec vous sur LinkedIn.