Skip to content
IA et innovation

La résilience plutôt que la panique : quatre étapes pour l’ère de l’IA de pointe

Accélérer le délai moyen de Recovery après sinistre dans l’ère post-Mythos.


Pendant des années, le principe fondamental en matière de sécurité d’entreprise était qu’une infrastructure de prévention bien rodée pouvait tenir le coup suffisamment longtemps pour permettre aux défenseurs d’intervenir. L’IA de pointe remet cette hypothèse en question, car les derniers modèles réduisent le délai nécessaire à la détection et à l’exploitation des vulnérabilités, passant de plusieurs jours ou semaines à un délai quasi instantané.

Lancée pour évaluer les risques potentiels en matière de sécurité posés par son propre modèle Mythos, l’initiative « Project Glasswing » d’Anthropic compte déjà près de 200 entreprises participantes et a mis au jour environ 10 000 vulnérabilités critiques ou à haut niveau de gravité. Parallèlement, le GPT-5.5 d’OpenAI fait preuve de capacités comparables.

Lors d’un récent webinaire, Pranay Ahlawat, directeur de la technologie et de l’IA chez Commvault, et Vidya Shankaran, directrice technique sur le terrain, se sont joints à moi pour aborder le nouveau calendrier de gestion des vulnérabilités, l’importance croissante de la validation de la reprise après sinistre, ainsi que la manière dont les équipes devraient aujourd’hui envisager la résilience. Inscrivez-vous au webinaire à la demande.

Points clés à retenir

  • Alors que les capacités de pointe en matière d’IA doublent à un rythme de plus en plus soutenu, les fonctionnalités avancées permettant de réduire le délai entre la découverte d’une vulnérabilité et son exploitation seront à la portée des attaquants d’ici six à neuf mois.
  • La remise en état d’un système d’IA agentique nécessite la synchronisation simultanée des sources de données, des configurations des agents et des identités non humaines ; la restauration isolée d’un seul élément peut créer des lacunes qui n’apparaissent que lorsqu’un dysfonctionnement survient en aval.
  • La sauvegarde et la restauration répondent à des besoins différents : la sauvegarde garantit que les données sont conservées en lieu sûr, tandis que la restauration permet à une entreprise de retrouver effectivement un état propre et opérationnel.
  • ResOps™ (opérations de résilience) considère la reprise comme une discipline transversale. Cette approche rassemble les équipes chargées de la sécurité, des opérations et de la technologie autour d’une définition commune de ce que signifie réellement « propre ».
  • Un cadre en quatre étapes – définir une « entreprise minimale viable », isoler et tester les charges de travail stratégiques, évaluer les risques liés à la reprise d’activité et mener des exercices complets de reprise d’activité – offre aux organisations un point de départ concret.

Frontier AI révolutionne la gestion des vulnérabilités

La puissance de l’IA de pointe double désormais environ tous les quatre mois, à un rythme bien plus rapide qu’il y a encore quelques années. Bien que les modèles de type Mythos n’aient pas encore été rendus publics, les acteurs malveillants pourraient bientôt avoir accès, via l’open source, à des capacités similaires à celles de Mythos, notamment :

  • Une fenêtre contextuelle pratiquement illimitée.
  • La capacité à mettre au point un dispositif d’attaque en décompilant du code et en créant des conteneurs afin d’identifier des vecteurs d’attaque.
  • L’enchaînement de vulnérabilités, qui consiste à relier entre elles des failles mineures prises isolément pour en faire une faille grave.

Cela a de graves conséquences. Deux organisations sur trois présentent actuellement plus de 100 000 vulnérabilités non corrigées, avec un délai moyen de correction d’environ 240 jours. Par le passé, les équipes de sécurité considéraient que de nombreuses vulnérabilités étaient trop difficiles à exploiter en chaîne pour un attaquant lambda, mais l’automatisation a rendu ce point de vue pratiquement obsolète.

Parallèlement, l’utilisation de l’IA pour la création de code – environ 41 % du nouveau code est désormais généré par l’IA, et GitHub a enregistré une hausse de 25 % des commits par rapport à l’année précédente – élargit la surface d’exposition aux vulnérabilités à un rythme plus rapide que ne le permettent les mesures correctives. La capacité à détecter à grande échelle de nouvelles vulnérabilités « zero-day » ne fait qu’aggraver le problème. Lorsque le délai entre la découverte et l’exploitation tend vers zéro, la marge de manœuvre pour mener une action défensive disparaît de fait.

Aperçu : l’avenir en pleine mutation de l’IA

Cette vidéo met en lumière une réalité cruciale : les capacités avancées en matière d’IA restent rarement l’apanage d’une poignée d’acteurs pendant longtemps. À mesure que les innovations de pointe en matière d’IA se diffusent dans des écosystèmes plus larges, les organisations doivent se préparer à un avenir où des capacités offensives de plus en plus sophistiquées seront accessibles à un public plus large.

Le nouvel indicateur de résilience : le délai moyen de retour à la normale

La sauvegarde et la restauration répondent à des problèmes fondamentalement différents. La sauvegarde se contente de confirmer que les données ont bien été copiées dans un endroit sûr, mais elle ne permet pas de savoir si l’entreprise sera réellement en mesure de reprendre ses activités. Et c’est là que les choses peuvent se compliquer. Deux obstacles se dressent souvent entre la réussite d’une sauvegarde et celle d’une restauration.

  1. La restauration d’un environnement complexe implique de rétablir l’application, les machines virtuelles, la configuration réseau, Active Directory et les bases de données transactionnelles qui le prennent en charge, le tout dans le bon ordre.
  2. Vous devez vous assurer que les données que vous restaurez ne contiennent ni logiciels malveillants ni portes dérobées – ce que sept organisations sur dix, en phase de reprise après un cyberincident, ne sont actuellement pas en mesure de vérifier.

Une reprise respectant les délais fixés tout en réintroduisant une menace active peut s’avérer pire que l’absence totale de reprise. Pour bénéficier d’une visibilité plus claire sur leur résilience, les organisations ont commencé à utiliser l’indicateur « Mean Time to Clean Recovery » (MTCR), qui combine l’objectif de délai de reprise (RTO), le temps nécessaire pour valider que les données récupérées sont effectivement saines, et une étape finale de validation humaine avant que les systèmes ne reprennent leur fonctionnement en production. L’objectif de reprise pour le MTCR correspond à la « société minimale viable » : les quelque 30 % d’un environnement, classés par ordre de dépendance, qui doivent être remis en ligne pour que l’organisation continue de fonctionner.

La salle blanche comme outil de test

Les tests de reprise, qui constituent la dernière étape de validation humaine dans le cadre du MTCR, impliquent généralement la mise en place d’un environnement distinct des systèmes de production – une tâche chronophage alors que chaque minute compte. Si les « salles blanches » sont parfois considérées comme un simple élément de secours, une solution de type « cloud » (cleanroom) peut également jouer un rôle proactif dans la reprise en fournissant un environnement isolé permettant d’orchestrer et de tester des reprises complexes avant leur restauration en production.

Cet environnement isolé peut également servir d’outil d’analyse, en permettant aux équipes de comparer côte à côte deux versions d’une sauvegarde afin de mieux comprendre ce qui a changé au cours d’un incident. Et comme il s’agit d’une solution native du cloud, facturée à l’utilisation, les entreprises peuvent éviter de mettre en place une infrastructure dédiée uniquement pour tester la restauration.

Quatre étapes pour garantir la résilience opérationnelle

Le cadre en quatre étapes proposé par Commvault pour renforcer la résilience opérationnelle de manière mesurable s’appuie sur ces principes.

  • Étape 1 : Définir l’« entreprise minimale viable » : une vision axée sur l’activité, qui précise ce qui doit être rétabli, dans quel ordre et avec quelles dépendances, pour que l’organisation puisse à nouveau fonctionner, plutôt qu’un simple inventaire des bases de données et des machines virtuelles.
  • Étape 2 : Assurez-vous que les systèmes prenant en charge cette « entreprise minimale viable » se trouvent dans un environnement physiquement isolé, immuable et segmenté en réseaux, pouvant être déployé et démantelé rapidement. Pour les charges de travail stratégiques, ces tests doivent être effectués tous les 45 jours.
  • Étape 3 : Évaluez les risques liés à la restauration avant de la déclarer terminée, car la réintroduction d’une porte dérobée ou d’un logiciel malveillant pendant la restauration va à l’encontre de l’objectif de l’opération et ne laisse que peu de temps pour une deuxième tentative.
  • Étape 4 : Ne considérez pas la reprise d’activité comme un simple exercice théorique. Menez ces exercices avec les mêmes personnes et selon les mêmes procédures que celles qui seraient mises en œuvre en cas d’incident réel, en tirant parti des mécanismes d’automatisation sous-jacents.

Quand l’IA devient un obstacle à la reprise

Une grande partie des entreprises exploitent déjà des systèmes d’IA en production, mais seules environ 20 % d’entre elles ont réellement testé leur capacité de reprise, ce qui les rend vulnérables en cas d’incident. Cela revêt une importance particulière au regard des trois façons dont l’IA modifie l’architecture de résilience.

Tout d’abord, l’IA élargit l’étendue des éléments à protéger, depuis les bases de données de vecteurs et les poids des modèles jusqu’aux configurations des agents et aux terminaux, tels que Claude Cowork ou Google Antigravity, sur lesquels les employés interagissent concrètement avec les agents. Cela pose également un problème de propagation en cascade : une simple mise à jour effectuée par un agent peut se propager à travers un maillage de systèmes connectés d’une manière bien moins prévisible que dans le cas d’une application traditionnelle à trois niveaux.

Enfin, l’IA rend la restauration elle-même plus complexe, car la remise en état d’un système agentique implique de synchroniser simultanément la mémoire, l’état, les données transactionnelles et les identités non humaines (NHI) – c’est-à-dire les identifiants et les autorisations attribués aux agents IA plutôt qu’aux personnes.

Les clients les plus avancés dans le déploiement d’agents ont déjà intégré ces systèmes à leur « entreprise minimale viable ». À chaque stade de maturité, l’accent est mis sur la restauration conjointe des sources de données, des configurations d’agents et des éléments de soutien tels que les poids et les biais, plutôt que sur des efforts distincts, car un décalage entre l’un de ces éléments peut entraîner un risque qu’un point de restauration unique ne permettrait pas de détecter.

Agir pour renforcer la résilience après « Mythos »

Pour commencer à réduire les risques liés à l’IA de pointe, recensez les systèmes phares de votre organisation et assurez-vous qu’ils se trouvent dans un environnement isolé (air-gapped). Une fois votre « entreprise minimale viable » définie, menez des exercices en « salle blanche » afin d’établir une base de référence en matière de récupérabilité et de MTCR pour l’ensemble des charges de travail de premier niveau. Cela doit constituer votre indicateur phare de résilience au niveau du conseil d’administration, montrant clairement à quelle vitesse votre entreprise peut reprendre ses opérations essentielles à la suite d’un incident.

Les tests sont essentiels pour mettre en évidence les lacunes dans la compréhension des activités, des technologies et des processus. Souvent, certains des problèmes les plus importants sont d’ordre organisationnel. ResOps™ (opérations de résilience) permet d’y remédier.

Plus qu’un simple produit, ResOps est un cadre qui rassemble les équipes de sécurité, d’exploitation et de technologie autour d’une vision commune de ce à quoi devraient ressembler une conception résiliente et une validation de la reprise. ResOps formalise la prise de conscience croissante du secteur selon laquelle la Recovery après un incident cybernétique est un enjeu transversal qui nécessite l’implication de parties prenantes issues de l’ensemble de l’entreprise, chacune ayant un intérêt direct dans le résultat. À l’ère post-Mythos, cette coordination est essentielle tant pour maintenir la préparation opérationnelle que pour permettre une réponse rapide et efficace en cas d’incident. Frontier AI impose comme exigence fondamentale un processus de restauration propre, éprouvé et bien défini.

Regardez l’intégralité du webinaire

Regardez la session « Resilience Over Panic » dans son intégralité à la demande pour découvrir plus en détail notre cadre en quatre étapes, notamment les conditions nécessaires à la récupération d’une IA agentique. Inscrivez-vous ici au webinaire.

FAQ

Q : Qu’est-ce que le « mean time to clean Recovery » (MTCR) ?

R : Le temps moyen de reprise sans risque (MTCR) mesure le temps nécessaire à une organisation pour revenir à un état de fonctionnement vérifié et sans risque après un incident. Il s’agit d’une mesure plus large que le simple temps nécessaire à la restauration des données. Elle combine l’objectif de temps de reprise (RTO) traditionnel avec le temps supplémentaire nécessaire pour confirmer que les données restaurées sont exemptes de logiciels malveillants ou de portes dérobées, ainsi qu’une étape finale de validation humaine avant que les systèmes ne reprennent leur fonctionnement en production.

Les organisations considèrent de plus en plus le MTCR, plutôt que la seule vitesse de reprise, comme l’indicateur de résilience de référence au niveau du conseil d’administration, car une reprise rapide qui réintroduit une menace active peut causer plus de dégâts qu’une reprise plus lente, mais vérifiée.

Q : En quoi le MTCR diffère-t-il du RTO ?

R : Le RTO mesure la rapidité avec laquelle les systèmes et les données peuvent être restaurés après une interruption. Le MTCR inclut le RTO parmi ses composantes, mais y ajoute le temps nécessaire pour vérifier que les données restaurées sont intactes, ainsi que le temps consacré à la validation humaine avant que les systèmes ne soient remis en production. Dans le cas spécifique d’un cyberincident, un système peut respecter son RTO tout en ne faisant pas preuve d’une véritable résilience si l’environnement restauré est réinfecté peu de temps après.

Q : Qu’est-ce qu’une « entreprise minimale viable » (MVC) et en quoi diffère-t-elle d’un plan complet de reprise après sinistre ?

R : Une « entreprise minimale viable », parfois appelée « activité minimale viable », désigne l’ensemble réduit, axé sur les activités métier, des systèmes, des données et des dépendances qu’une organisation doit remettre en service pour continuer à fonctionner après un incident, plutôt que l’ensemble de son infrastructure informatique.

Un plan complet de reprise après sinistre vise généralement à tout rétablir en temps voulu ; la définition d’une « entreprise minimale viable » oblige une organisation à déterminer à l’avance ce qui doit absolument être rétabli en priorité, et dans quel ordre, afin d’éviter une interruption des activités.

Q : Quelle est la différence entre un exercice sur table et un exercice de reprise en conditions réelles ?

R : Un exercice sur table est une simulation sur papier d’un plan d’intervention en cas d’incident, généralement utilisée pour tester la prise de décision et la communication entre les parties prenantes sans mettre réellement en œuvre de mesures techniques de reprise.

Un exercice de reprise d’activité en conditions réelles va plus loin en mettant effectivement en œuvre la reprise, avec les outils, les processus automatisés et les personnes concernées, afin de vérifier que le processus fonctionne dans la pratique, au-delà de ce que peut révéler un simple exercice théorique. Les organisations qui se contentent d’exercices sur table peuvent disposer d’un plan de résilience qui semble solide à première vue, mais qui n’a pas été testé au regard des détails opérationnels qui font souvent que les incidents réels prennent plus de temps que prévu.

Q : Que sont les identités non humaines (NHI) et pourquoi compliquent-elles la récupération des données issues de l’IA ?

R : Les NHI correspondent aux identifiants, autorisations et droits d’accès attribués à des composants logiciels, tels que les agents d’IA, plutôt qu’à des personnes physiques. À mesure que les organisations déploient davantage d’IA agentique, le nombre de NHI dans un environnement augmente, et chacun d’entre eux doit être pris en compte lors d’une reprise, au même titre que des éléments plus courants tels que les bases de données et les systèmes transactionnels.

La remise en service d’un système d’IA agentique nécessite généralement de synchroniser les NHI avec le reste de la pile d’IA, car la restauration des données ou des configurations sans rétablir les autorisations appropriées des agents peut entraîner des lacunes difficiles à détecter tant qu’un dysfonctionnement ne survient pas en aval.

Q : Comment une organisation peut-elle se lancer dans le ResOps™ (opérations de résilience) ?

R : Le ResOps est un cadre interfonctionnel qui rassemble les équipes chargées de la sécurité, des opérations et de la technologie autour d’une définition commune de la conception résiliente, indépendante de tout produit spécifique.

Les organisations peuvent commencer par identifier un petit nombre d’applications clés et réaliser un premier test de reprise afin d’établir un MTCR de référence, plutôt que d’essayer de formaliser l’ensemble de la discipline d’un seul coup. Cette référence initiale offre aux équipes chargées de la sécurité, des opérations et de la gouvernance un point de repère concret pour suivre les progrès réalisés. Elle contribue également à ancrer, au fil du temps, les habitudes inter-équipes dont dépend le ResOps.

Michael Thelander est directeur principal du marketing produit chez Commvault.

Plus d'articles sur le sujet


Thumbnail_Blog_Ready-or-Not-Ep5-Data

Les données : quand « beaucoup trop » devient « jamais assez »

En savoir plus sur « Données : quand trop devient jamais assez »
Thumbnail_Blog_Ready-or-Not-Ep5-Data

Les données : quand « bien trop » devient « jamais assez »

En savoir plus sur « Les données : quand trop devient jamais assez »
Thumbnail_Blog_Ransomware-Trends-2025-1

Pourquoi les risques cybermodernes exigent une cyber-résilience de A à Z

En savoir plus sur « Pourquoi les risques cybernétiques modernes exigent une cyber-résilience de A à Z »