Contexte et limites des approches traditionnelles

Les solutions de reprise après sinistre classiques se concentrent sur la restauration des serveurs, du stockage et des réseaux un composant à la fois. Comme le souligne Bhooshan Thakar, vice‑président senior d’InfoScale, « Running servers and restored data don’t guarantee that a business can safely operate after a disruption ». Cette lacune devient critique lorsque les attaquants utilisent l’IA pour automatiser leurs campagnes et que les entreprises appliquent des correctifs quotidiennement ou chaque semaine, au lieu de planifier un basculement tous les six mois. Le passage d’un scénario « if » à « always » impose de repenser la résilience au niveau du runtime plutôt qu’au niveau de l’infrastructure.

Approche d’InfoScale : protection de l’état opérationnel en temps réel

InfoScale propose une plateforme qui s’exécute en parallèle des applications critiques, suivant les dépendances, l’état d’exécution et l’intégrité des données. Le système crée des réplications en temps réel et des points de contrôle immuables, permettant aux équipes de revenir rapidement à un état « trusted good ». En juin, la société mère Cloud Software Group a rejoint le Project Glasswing d’Anthropic et a intégré le modèle Claude Mythos Preview pour renforcer les fonctions de sécurité, illustrant l’usage de l’IA générative dans la détection d’anomalies opérationnelles.

Implications techniques et mesures de résilience

Le modèle de responsabilité décrit par Thakar indique que les fournisseurs de cloud garantissent la résilience du cloud, mais la résilience dans le cloud reste à la charge du propriétaire de l’application. Ainsi, la perte d’une couche de la pile multitier entraîne l’arrêt du service même si l’infrastructure signale être saine. InfoScale recommande de remplacer la métrique traditionnelle « temps de restauration d’une VM » par le temps nécessaire pour obtenir la première transaction métier validée et propre après une perturbation. Cette mesure lie directement la résilience opérationnelle aux résultats business, incluant les risques réglementaires et la perte de clientèle. Enfin, Thakar rappelle que les budgets des dix dernières années ont été alloués à deux silos : prévention (sécurité) et récupération (sauvegarde). La prévention est décrite comme « leaky », la récupération comme « too slow », justifiant la nécessité d’une solution qui combine continuité et vérification d’état en temps réel.