Points clés à retenir

• ResOps n’est pas un produit technologique. Il s’agit d’une discipline opérationnelle transversale qui contribue à renforcer la cyber-résilience de l’organisation.
• Elle complète la sauvegarde, la reprise après sinistre, la cybersécurité, la continuité d’activité et la réponse aux incidents en alignant ces fonctions sur des objectifs de Recovery de bout en bout.
• ResOps se concentre sur les services critiques et les seuils d’impact définis par l’entreprise, plutôt que sur des composants d’infrastructure isolés.
• Il s’appuie sur la production continue de preuves, notamment des résultats de Recovery testés, des indicateurs de résilience des services et un registre interne des lacunes.
• ResOps est un processus continu. Ni l’élaboration d’un plan, ni la réalisation d’un exercice ponctuel réussi ne suffisent à établir une capacité de Recovery durable.

Le nouveau défi de la résilience

La plupart des organisations investissent dans la cybersécurité, la sauvegarde, la reprise après sinistre et la continuité des activités. Pourtant, de nombreux dirigeants sont toujours confrontés à trois questions cruciales : Pouvons-nous nous rétablir ? Combien de temps la Recovery prendra-t-elle ? Et pouvons-nous le prouver ?

Une partie du défi réside dans le fait que la responsabilité de la résilience est répartie entre des équipes qui opèrent souvent en silos. La sécurité gère les menaces. L’informatique assure la maintenance des systèmes. Les équipes de Backup and Recovery restaurent les données et l’infrastructure. Les équipes chargées de la continuité des activités s’attachent à maintenir le fonctionnement de l’organisation. Chacune joue un rôle important, mais la responsabilité de la reprise peut rester fragmentée.

ResOps rassemble ces fonctions autour de priorités, d’objectifs de Recovery et de preuves communs. Il en résulte une approche plus concrète de la résilience : savoir ce qui importe le plus, comprendre ce qu’il faut pour le rétablir, tester si la Recovery fonctionne et agir sur les lacunes identifiées.

Qu’est-ce que ResOps ?

ResOps est la discipline opérationnelle qui rassemble la sécurité, l’infrastructure, les opérations informatiques, la continuité des activités et les responsables métier autour des services critiques, d’une conception résiliente et d’une validation continue. En termes simples, ResOps aide les équipes à se préparer aux perturbations, à rétablir les services critiques dans les limites des tolérances d’impact définies par l’entreprise, et à démontrer de manière factuelle que la reprise fonctionne.

Quatre caractéristiques définissent ResOps. Il est :

1. Une approche transversale par nature. Le ResOps relie des responsabilités dispersées grâce à un modèle opérationnel partagé, une attribution claire des responsabilités et une gouvernance au niveau de la direction.
2. Axé sur les services critiques. Il donne la priorité aux services que l’organisation doit rétablir pour offrir sa valeur fondamentale, servir ses clients et générer des revenus ; il contribue également à respecter les obligations urgentes en matière de législation, de réglementation, de sécurité et de mission.
3. Validé en continu. La résilience est une posture que les équipes doivent exercer et améliorer – et non un état établi par un test annuel.
4. Mesuré par des preuves. Le ResOps génère un score de posture de résilience (RPS) : un score par service, étayé par des preuves, qui mesure le degré de récupérabilité d’un service critique donné en fonction des résultats de validation, de l’état des dépendances et du niveau de confiance en une Recovery sans incident.

Qu’est-ce que ResOps n’est pas ?

Ce n’est pas une catégorie de produits.

Aucune plateforme ne peut à elle seule créer le ResOps. Les technologies de protection des données, de Recovery informatique, d’automatisation, d’observabilité et de tests peuvent soutenir cette discipline, mais le ResOps est d’ordre organisationnel. Il dépend de la gouvernance, de la responsabilité partagée, des priorités métier, des pratiques opérationnelles et d’une norme commune en matière de preuves.

Ce n’est pas un substitut à Backup and Recovery, ni à la reprise après sinistre.

Le ResOps ne remplace pas des capacités solides de Backup and Recovery : il en dépend. Le Backup permet de vérifier l’existence de copies récupérables. La reprise après sinistre fournit les procédures et les capacités techniques nécessaires à la restauration des systèmes et de l’infrastructure.

Mais le ResOps pose alors une question plus large : le service critique peut-il être rétabli complètement, proprement et dans les limites de tolérance, y compris ses identités, ses applications, ses données, son infrastructure, ses services cloud, ses tiers, ses collaborateurs et ses processus décisionnels ?

Il ne s’agit pas d’un autre nom pour désigner la continuité des activités ou la réponse aux incidents.

La continuité d’activité définit la manière dont l’entreprise fonctionne en cas de perturbation. La réponse aux incidents détecte, contient et gère l’événement. ResOps relie ces disciplines au résultat de Recovery. Il crée un rythme opérationnel permettant aux équipes de s’accorder sur ce qui importe, de valider Recovery dans des conditions réalistes, de mesurer les résultats et de combler les lacunes révélées par les tests.

Il ne s’agit ni d’un simple exercice de conformité ni d’un projet ponctuel.

Un programme ResOps abouti peut aider à fournir des preuves aux conseils d’administration, aux autorités de régulation, aux assureurs, aux clients et aux auditeurs. Mais la documentation est un sous-produit, pas l’objectif. L’objectif est de démontrer la capacité de reprise.

Et comme les systèmes, les dépendances, les menaces et les priorités métier ne cessent d’évoluer, le ResOps n’est jamais « terminé ». Il fonctionne en continu, à l’instar de la planification financière ou des opérations de sécurité.

Qu’est-ce qui change avec le ResOps ?

Le ResOps déplace l’attention de la simple question de savoir si les systèmes et processus individuels fonctionnent vers celle de savoir si le service critique dans son ensemble peut être restauré. Cela modifie les questions que les dirigeants peuvent se poser.

Une sauvegarde réussie est importante. Disposer d’un plan de restauration l’est tout autant. Mais ni l’un ni l’autre ne vous indique si un service critique peut réellement être restauré lorsque vous en avez besoin. Le ResOps adopte une vision d’ensemble :

• Avons-nous effectué la reprise à partir d’un point de Recovery valide et vérifié ?
• Combien de temps cela a-t-il pris ?
• La restauration s’est-elle effectuée dans les délais fixés par l’entreprise ?
• Et quels sont les points qui nécessitent encore une attention particulière ?

C’est pourquoi le ResOps est essentiel. Il offre aux organisations un moyen d’aller au-delà des hypothèses de résilience pour parvenir à des démonstrations programmatiques et fiables de leur capacité à se rétablir. Et elles y parviennent grâce à la production continue de preuves et à la traçabilité. Ainsi, lorsqu’une perturbation survient, la question n’est pas de savoir si chaque équipe a fait sa part ou qui a échoué dans quelle tâche. Il s’agit de savoir si l’entreprise est capable de rétablir les services critiques dont dépendent ses clients.

En savoir plus

Commvault a publié « ResOps : un guide à l’intention des dirigeants » afin de fournir aux RSSI, DSI et responsables de l’informatique, de la sécurité, de la résilience et de la gestion des risques un cadre pratique pour la mise en œuvre de ResOps au sein de leurs organisations.

Les dirigeants apprendront à identifier les services les plus importants, à valider l’état de Readiness à la reprise à l’aide de preuves concrètes et à tester en permanence la résilience. Ainsi, les organisations peuvent mettre en place un modèle opérationnel unique qui rassemble les responsables de la sécurité, de l’infrastructure, des opérations informatiques et des activités autour d’une capacité de reprise fondée sur des preuves.

Téléchargez le guide ici. 

FAQ

Q : Le ResOps est-il simplement un nouveau nom pour la reprise après sinistre ?

R : Non. La Recovery est un élément essentiel du ResOps, mais le ResOps examine l’ensemble du service critique – y compris les dépendances techniques, vis-à-vis de tiers, humaines et décisionnelles – et détermine s’il peut être rétabli dans les limites d’une tolérance d’impact définie par l’entreprise.

Q : Le ResOps nécessite-t-il l’achat d’une nouvelle plateforme ?

R : Non. La technologie peut faciliter la cartographie, les tests, Recovery et la collecte de preuves, mais le ResOps repose avant tout sur la responsabilité, la gouvernance, les priorités métier et les pratiques opérationnelles.

Q : À qui incombe la responsabilité du ResOps ?

R : Le ResOps nécessite un responsable désigné, doté d’une autorité transversale et bénéficiant du soutien de la direction. Les responsables de services individuels restent redevables de leurs services, tandis que les équipes chargées de la sécurité, de l’informatique, de la continuité d’activité et des métiers contribuent à l’objectif commun de Recovery.

Q : Comment mesure-t-on le succès de ResOps ?

R : Le succès repose sur des preuves concrètes démontrant que les services critiques peuvent se rétablir sans heurts dans les limites de tolérance d’impact définies – et non pas simplement sur la réalisation d’un plan ou l’exécution réussie d’une sauvegarde.

Un score de résilience (RPS) constitue également un outil de mesure utile. En tant que score par service, étayé par des preuves, le RPS permet de démontrer le degré de récupérabilité d’un service critique donné, sur la base des résultats de validation, de l’état des dépendances et du niveau de confiance dans une reprise sans incident.

Q : Comment les organisations peuvent-elles se lancer dans le ResOps ?

R : Commencez par identifier les services critiques dont dépend l’entreprise, qui en est responsable, de quoi ils dépendent et dans quel délai ils doivent être restaurés. À partir de là, les équipes peuvent valider la Recovery, identifier les lacunes et hiérarchiser les actions nécessaires pour renforcer la résilience.

Michael Thelander est directeur principal du marketing produit chez Commvault.

Points clés à retenir

• La résilience dépend de la rapidité et de la confiance avec lesquelles l’entreprise peut se remettre d’un incident – et non pas uniquement de sa capacité à repousser toutes les menaces.
• Transformez les plans de Recovery en preuves tangibles : des résultats testés sont plus crédibles aux yeux des conseils d’administration, des régulateurs et des assureurs que de simples objectifs ou hypothèses.
• Faites de ResOps un modèle opérationnel partagé pour les responsables de la sécurité, de l’infrastructure, de la continuité d’activité et des services.
• Mesurez ce qui compte : les équipes doivent savoir si les services critiques peuvent être rétablis, combien de temps la Recovery prend réellement et si elles sont en mesure de le prouver.
• Sélectionnez un ou deux services critiques, définissez ce qu’est une Recovery réussie, menez un exercice réaliste et consignez les résultats.
• Vingt ans passés à diriger des équipes de sécurité vous apprennent très tôt une chose : l’attaque que vous avez stoppée ne fait jamais l’objet d’une discussion en conseil d’administration. Celle que vous n’avez pas réussi à contrer est la seule dont tout le monde se souvient. À un moment donné, j’ai cessé d’évaluer mon équipe uniquement en fonction du nombre d’attaques que nous avions encaissées et j’ai commencé à nous évaluer également en fonction de la rapidité avec laquelle nous nous remettions sur pied.
• C’est la raison pour laquelle je souhaite que tous les RSSI, DSI et membres de conseil d’administration que je connais lisent ce nouveau livre, *ResOps : An Executive Guide*. Commvault l’a parrainé, mais je le recommanderais de toute façon.

Le mur n’a jamais été le seul objectif

Pendant la majeure partie de ma carrière, mon travail a consisté à ériger des murs plus hauts. Une meilleure détection, des contrôles plus stricts, une réponse plus rapide. Ce travail reste important, et le sera toujours. Mais un mur ne répond qu’à une seule question, et ce n’est plus celle que pose votre conseil d’administration.

En septembre dernier, une attaque par rançongiciel a contraint Jaguar Land Rover à interrompre sa production mondiale. Les chaînes de montage se sont arrêtées. Les chaînes d’approvisionnement se sont figées. Le Cyber Monitoring Centre britannique a estimé le coût pour l’économie dans son ensemble à environ 1,9 milliard de livres sterling, et JLR a enregistré son plus faible volume de production mensuel en 73 ans. JLR disposait de défenses. Ce que cet incident a mis à l’épreuve, ce n’était pas la solidité du mur, mais la capacité de l’entreprise à se remettre sur pied une fois que celui-ci avait cédé.

Je l’ai déjà dit et je continuerai à le dire : la question n’est pas de savoir si une perturbation se produira, mais quand elle se produira. Les RSSI qui dorment sur leurs deux oreilles ne sont pas ceux qui croient pouvoir tout empêcher ; ce sont ceux qui se sont entraînés à se remettre sur pied tant de fois que cet entraînement lui-même est source de confiance.

Trois questions que je pose à ma propre équipe

Le livre structure l’ensemble du problème en trois questions, et j’ai pris l’habitude de commencer chaque revue de résilience par celles-ci :

• Si nous étions touchés ce soir, pourrions-nous nous remettre sur pied ?
• Combien de temps cela prendrait-il réellement ?
• Pouvons-nous le prouver, avec des preuves, au conseil d’administration ?

La plupart des organisations répondent aux deux premières questions en présentant un plan, et à la troisième par le silence. Ce silence correspond au déficit de résilience, et il est plus important et plus coûteux que ne le pensent la plupart des dirigeants.

Des preuves, pas des promesses

Voici une distinction que le livre met en avant mieux que je ne l’ai jamais entendue ailleurs : un objectif de temps de reprise (RTO) est une cible. Il vous indique ce que vous visez, mais il ne vous dit pas si vous allez l’atteindre.

Comparez « nous pensons pouvoir rétablir le service de paiement en quatre heures » à « nous l’avons rétabli en 3,2 heures au dernier trimestre, à partir d’un point de reprise propre et vérifié, avec une tolérance de quatre heures ». La première phrase est un plan. La seconde est une preuve. Une seule de ces deux affirmations tiendra la route lorsque votre conseil d’administration, votre autorité de régulation ou votre assureur cybercommenceront à poser des questions plus pointues, ce qu’ils ne manqueront pas de faire.

Nous appelons cette discipline « ResOps », abréviation de « resilience operations » (opérations de résilience). Ce n’est ni un produit que l’on achète, ni un dossier que l’on classe. C’est un modèle opérationnel qui relie la sécurité, l’infrastructure, la continuité d’activité et les responsables métier qui dépendent de ces services, tous travaillant à partir des mêmes données factuelles plutôt que de plans distincts.

Ce qui devrait inquiéter tout RSSI

Le livre met également le doigt sur un phénomène que je ressens depuis un certain temps et pour lequel j’ai enfin trouvé les mots : le paradoxe de l’IA. La même capacité d’IA qui nous aide à détecter plus rapidement les vulnérabilités aide les attaquants à combler l’écart entre la découverte et l’exploitation tout aussi rapidement, voire plus vite. Détecter davantage de problèmes ne vous rend pas plus en sécurité si vous ne pouvez pas vous remettre de ceux qui parviennent à passer. La vitesse de détection n’a jamais été la ligne d’arrivée. C’est la capacité de Recovery qui l’est.

Commencez par un seul service

Rien de tout cela ne nécessite de vouloir tout changer d’un seul coup, et je mentirais si je disais que ma propre équipe a réussi du premier coup. Le livre propose un parcours de 90 jours : choisissez un ou deux de vos services les plus critiques, définissez ce que « récupéré » signifie réellement pour chacun d’eux, menez un exercice de Recovery en toute honnêteté, et produisez votre première preuve concrète. C’est un projet que n’importe quelle équipe peut lancer ce trimestre, y compris la mienne.

Des preuves plutôt que des promesses. Readiness plutôt que la perfection. C’est la norme que j’impose à mon équipe, et c’est celle vers laquelle ce livre vous guide concrètement.

Procurez-vous votre exemplaire de « ResOps : An Executive Guide » ici.

FAQ

Q : Qu’est-ce que ResOps ?

R : ResOps, abréviation de « resilience operations » (opérations de résilience), est un modèle opérationnel qui rassemble les responsables de la sécurité, de l’infrastructure, de la continuité d’activité et des services autour de pratiques de reprise communes et fondées sur des preuves.

Q : En quoi ResOps diffère-t-il de la reprise après sinistre traditionnelle ?

R : La reprise après sinistre traditionnelle est souvent axée sur des plans et des objectifs techniques. ResOps met l’accent sur la validation continue, la prise en charge transversale et la preuve mesurable que les services critiques peuvent être restaurés dans les limites de tolérance de l’entreprise.

Q : Pourquoi les preuves de Recovery sont-elles importantes ?

R : Les preuves de Recovery montrent ce qu’une organisation a réellement testé et réalisé. Elles contribuent à donner aux conseils d’administration, aux régulateurs, aux assureurs et aux dirigeants d’entreprise une plus grande confiance que ne le feraient à eux seuls les plans ou les objectifs de Recovery.

Q : Que doivent mesurer les organisations dans le cadre d’un programme ResOps ?

R : Les organisations doivent évaluer si les services critiques peuvent être rétablis, combien de temps la reprise prend réellement, si les points de reprise sont valides et vérifiés, et si les résultats respectent les seuils de tolérance définis par l’entreprise.

Q : Qui devrait être impliqué dans les ResOps ?

R : Le programme ResOps doit rassembler les responsables de la sécurité, de l’infrastructure, de la continuité d’activité, ainsi que les responsables des applications et des services, et les parties prenantes au sein de la direction, afin que les priorités de Recovery et les preuves reflètent les besoins de l’entreprise.

Q : Comment une organisation peut-elle se lancer dans le ResOps ?

R : Commencez par un ou deux services critiques. Définissez ce que signifie une reprise réussie, menez un exercice de Recovery en toute transparence, documentez les résultats et utilisez ces données pour améliorer le prochain test.

Bill O’Connell est directeur de la sécurité chez Commvault.

Points clés à retenir 

• Le rapport fédéral mis à jour fait état de nouvelles tactiques et techniques utilisées par Medusa, ainsi que de plus de 500 victimes dans divers secteurs d’infrastructures critiques. 
• Les attaquants ne se contentent pas de cibler les données de production ; ils perturbent également les sauvegardes, les systèmes d’identité, de virtualisation et d’autres systèmes dont dépendent les organisations pour leur Recovery. 
• L’avis invite les organisations à prouver leur résilience par des tests et des validations face aux comportements observés chez les attaquants, et non à se contenter de supposer cette résilience sur la base de plans ou de tâches de sauvegarde réussies.  

La dernière alerte fédérale concernant le ransomware Medusa a été mise à jour pour une raison simple : l’adversaire a changé. 

L’avis fédéral mis à jour, publié le 18 août 2026 par le FBI, l’Agence pour la cybersécurité et la sécurité des infrastructures (CISA) et le ministère américain de la Santé et des Services sociaux (HHS), décrit un adversaire qui recrute de nouveaux courtiers en accès, agit plus rapidement une fois infiltré et s’est perfectionné pour s’assurer que les dommages qu’il cause soient irréversibles.  

L’attaque ne vise pas uniquement vos données

Les acteurs de Medusa agissent rapidement. Les enquêteurs signalent que ces acteurs ont exploité des failles récemment annoncées dans les 24 heures et, dans certains cas, ont utilisé des exploits jusqu’à une semaine avant la divulgation publique de la vulnérabilité.

Une fois à l’intérieur, ils se fondent dans le système en utilisant des outils de gestion à distance légitimes, le vol d’identifiants et des techniques de « living-off-the-land ». 

Mais la conclusion la plus importante de l’avis de sécurité est que Medusa s’attaque au processus de restauration lui-même.

L’avis de sécurité associe cette activité à la technique MITRE ATT&CK T1490, « Inhibit System Recovery » (Empêcher la restauration du système). Il documente le fait que le rançongiciel met fin aux services associés aux sauvegardes, à la sécurité, aux bases de données, aux communications, au partage de fichiers et aux sites web. Il supprime également les clichés instantanés et arrête et chiffre à distance les machines virtuelles. 

Si un attaquant cible délibérément les systèmes, les identités et l’infrastructure dont une organisation pourrait avoir besoin pour se rétablir, le problème dépasse le cadre de la protection des données pour s’étendre à la cyber-résilience et à la cyber-Recovery. 

Le rôle des ResOps (opérations de résilience)

Le terme « ResOps » n’est pas simplement un autre nom pour désigner la sauvegarde. Il s’agit d’une discipline opérationnelle qui rassemble la sécurité, l’informatique, l’infrastructure, les applications, les opérations et l’activité autour d’un seul objectif : maintenir les services critiques en fonctionnement et les restaurer dans les délais que l’entreprise peut tolérer.

La note de conseil Medusa n’utilise jamais le terme « ResOps », mais la réflexion sous-jacente est bien présente. Elle recommande aux organisations d’exercer, de tester et de valider leurs programmes de sécurité à la lumière des comportements observés chez les attaquants, d’aligner les technologies de sécurité sur les techniques d’attaque, de les tester à grande échelle, de mesurer leurs performances et d’ajuster les personnes, les processus et les technologies en fonction des preuves recueillies.

Une sauvegarde ne prouve pas qu’elle est intacte. Un objectif de temps de reprise indiqué dans un tableur ne prouve pas que l’activité fonctionnera dans ce délai. La résilience doit passer de l’hypothèse à la preuve. 

Commencez par l’activité, pas par le serveur

L’ajout du HHS (ministère américain de la Santé et des Services sociaux) dans l’avis rend celui-ci particulièrement pertinent pour le secteur de la santé, qui, selon le FBI, a souvent été la cible de Medusa. La réflexion sur la reprise commence par trois questions : 

• Qu’est-ce qui doit continuer à fonctionner, et à quoi ressemble un fonctionnement minimal viable ? 

• Quelles identités, applications, infrastructures et données prennent en charge ces services ? 

• À quels points de reprise pouvons-nous nous fier, et quels éléments doivent être rétablis en priorité ? 

Dans un hôpital, laisser l’une de ces questions sans réponse peut entraîner le report d’une intervention chirurgicale, empêcher un pharmacien de vérifier un dosage ou rendre un système de diagnostic inutilisable pour un clinicien. Aucune équipe ne peut y répondre seule, et c’est précisément cette lacune que ResOps est conçu pour combler. 

Utilisez Medusa pour tester vos hypothèses

Utilisez Medusa comme scénario de test pour vos hypothèses de Recovery. Un attaquant peut-il accéder aux systèmes qui prennent en charge la Recovery ? Que se passe-t-il si Active Directory est compromis ? Pouvez-vous identifier un point de Recovery sain, restaurer les services critiques dans le bon ordre et déterminer combien de temps cela prendra ? 

Les acteurs malveillants s’adaptent lorsque les défenseurs s’adaptent. Les programmes de résilience doivent fonctionner de la même manière : testés en permanence, validés en permanence et améliorés en permanence.

Car le cœur d’un incident est le pire moment pour découvrir que le plan de Recovery semblait plus efficace sur le papier qu’il ne l’est dans la réalité. 

FAQ

Q : Qu’est-ce que le ransomware Medusa ? 

R : Medusa est un ransomware-as-a-service identifié pour la première fois en 2021. Ses développeurs et ses affiliés utilisent un modèle de double extorsion : ils chiffrent les systèmes tout en menaçant de publier les données volées si la rançon n’est pas payée. 

Q : Pourquoi l’avis fédéral sur Medusa a-t-il été mis à jour ? 

R : La mise à jour d’août 2026 intègre les conclusions d’enquêtes du FBI menées jusqu’en avril 2026. Elle élargit la liste des tactiques, techniques et procédures documentées, des vulnérabilités exploitées, des activités des affiliés et des indicateurs de compromission, tout en ajoutant les analyses du HHS concernant les attaques visant le secteur de la santé. 

Q : En quoi Medusa menace-t-il les capacités de Recovery d’une organisation ? 

R : Medusa peut interrompre les services liés aux sauvegardes, à la sécurité, aux bases de données, aux communications et à d’autres fonctions critiques. Elle peut également supprimer des clichés instantanés, modifier les politiques relatives à l’identité et arrêter ou chiffrer des machines virtuelles, mettant ainsi en péril le processus de Recovery lui-même. 

Q : Que doivent faire les organisations pour réduire le risque lié à Medusa ? 

R : Les organisations doivent corriger rapidement les vulnérabilités connues, segmenter leurs réseaux, restreindre l’accès aux services à distance, renforcer l’authentification, surveiller les mouvements latéraux et appliquer le principe du moindre privilège. Elles doivent également conserver des copies de récupération distinctes, hors ligne, chiffrées et immuables, et tester régulièrement leurs workflows de récupération. 

Q : Qu’est-ce que le ResOps, et en quoi diffère-t-il de la sauvegarde ? 

R : Le ResOps, ou « opérations de résilience », est une discipline opérationnelle transversale – et non un produit de sauvegarde. Il coordonne la sécurité, l’informatique, l’infrastructure, les applications, les opérations, la continuité d’activité et les responsables métier autour de la restauration des services critiques, dans les limites de la perturbation que l’entreprise peut tolérer. 

Q : Comment une organisation peut-elle démontrer qu’elle est prête à se rétablir ? 

R : Commencez par les services métier critiques, cartographiez les identités, les applications, l’infrastructure, les données, les personnes et les tiers dont ils dépendent, puis définissez ce que constitue une reprise réussie. Organisez ensuite des exercices réalistes permettant d’identifier des points de reprise clairs, de restaurer les services dans le bon ordre, de mesurer le temps de reprise réel et de transformer toute lacune en un programme d’améliorations à mettre en œuvre. Chris Bevil est responsable principal du marketing de portefeuille chez Commvault. 

Key Takeaways 

• Roughly 1,200 supposedly isolated agents communicated through an unauthorized message board, and about 700 participated in Hugging Face-related activity. 
• Agents exchanged over 70,000 messages and files, combining discoveries across sessions meant to remain separate. 
• Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.  
• Immutable, isolated backups alone are insufficient: Organizations need a validated, trustworthy recovery point before restoring to production. 

The forensic reports are finally here, and they changed the way I think about this incident. 

About a month ago, I wrote about the OpenAI and Hugging Face security incident because I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.  

At the time, the story sounded fairly straightforward: An AI agent found a way outside the environment designed to contain it and ultimately reached Hugging Face. 

That is not really what happened. 

The Story Is Bigger Than One Rogue Agent 

The forensic reports reveal that about 1,200 agents, supposed to be operating in isolation, discovered a way to communicate through an unauthorized message board. They exchanged more than 70,000 messages and files, and roughly 700 agents participated in activity associated with Hugging Face. 

None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.  

Among the new details: GPT-5.6 Sol agents reproduced an exploit and copied private evaluation data into a public Hugging Face dataset, a concrete escalation beyond what initial reports described. 

The Reward-Hacking Problem 

The independent investigation conducted by METR and Redwood Research, published alongside OpenAI’s own report on August 26, found that agents researched ways to spoof, edit or delete portions of their own evaluation transcripts because they incorrectly believed the grader would inspect how they completed the task. Researchers found successful tool-call spoofing in about 7% of the transcripts they evaluated, though the manipulation they observed was small-scale. 

The finding is not that agents are “deceptive” in a human sense. It is that a sufficiently capable agent can search for ways around controls when those controls stand between it and the outcome it has been optimized to achieve. 

OpenAI calls the incident a “warning shot.” I think that is a fair description. 

What Happens When Containment Fails 

Most of the conversation about this incident will rightly focus on alignment, sandboxing and monitoring. But there’s a resilience question underneath it: If 700 agents can find a side door around containment, what’s the plan for when a single compromised workload does the same in your environment? 

OpenAI’s own conclusion points at the answer: Security architecture should assume an individual workload or compute node eventually can be compromised. That means air-gapped, immutable recovery data, and a way to validate what you’re restoring before it touches production again. 

But immutability alone does not prove the data was clean when it was captured. If the data was already compromised at the time of capture, immutability preserves the compromise just as faithfully as it preserves anything else. 

The practical version of that question is simple to ask and hard to answer: If this happened to us, could we prove which recovery point predates the compromise? 

We cover this operating model under ResOps (resilience operations) on the Readiverse. 

The Lesson for Every Organization 

OpenAI has since tightened workload and network isolation, expanded monitoring, and revised its model-development practices. The lesson applies beyond OpenAI: Contain the impact, preserve what you can trust, and prove you can recover before you need to. 

FAQs 

Q: What was the OpenAI-Hugging Face incident? 

During internal cybersecurity evaluations, OpenAI agents bypassed controls intended to isolate them, accessed the internet and reached third-party systems, including Hugging Face. The activity was driven primarily by an internal research model operating with reduced safeguards. 

Q: How did supposedly isolated agents communicate? 

A: They discovered an unauthorized message board in shared infrastructure. About 1,200 agents used it to exchange more than 70,000 messages and files, allowing information and tactics to carry across sessions that were designed to remain independent. 

Q: Were the agents instructed to attack Hugging Face? 

A: No. They were attempting to complete a difficult cybersecurity benchmark. When the intended route appeared blocked, some agents searched for alternative ways to achieve the evaluated outcome, and that activity expanded beyond the environment’s intended boundaries. 

Q: What does “reward hacking” mean in this context? 

A: Reward hacking occurs when an agent finds an unintended way to satisfy a metric or obtain a desired result without completing the task as intended. Investigators found agents researching ways to spoof tool calls and alter or delete portions of evaluation transcripts because they believed the grader might inspect their process. 

Q: Why are immutable backups not enough on their own? 

A: Immutability prevents stored data from being altered, but it does not prove the data was clean when it was captured. If a backup already contains compromised data, immutability preserves that compromise. Organizations therefore need isolated copies, trustworthy recovery points and validation before restoration. 

Q: What should organizations do differently after this incident? 

A: Strengthen workload and network isolation, restrict unnecessary internet and credential access, monitor agent behavior and escalation signals, and assume that prevention may fail. Pair those controls with air-gapped, immutable recovery data and a tested process for identifying and validating a clean recovery point. 

Chris Bevil is Principal Portfolio Marketing Manager at Commvault. 

Points clés à retenir

• La durée de vie des certificats passera de 398 à 47 jours d’ici mars 2029, la « réutilisation de la validation de domaine » étant réduite à seulement 10 jours, ce qui rendra le renouvellement manuel obsolète et rendra nécessaire la gestion automatique du cycle de vie des certificats (CLM).
• Des opérations de type « Harvest Now, Decrypt Later » (collecter maintenant, décrypter plus tard) sont déjà en cours pour stocker des données à longue durée de vie en vue d’un décryptage futur à l’aide d’ordinateurs quantiques, ce qui représente une menace immédiate pour les données sensibles chiffrées dont la durée de conservation est plus longue.
• L’inventaire des certificats et des clés cryptographiques est un élément crucial que les entreprises doivent commencer à mettre en place dès maintenant, car un inventaire continu et automatisé constitue la première étape vers une cyber-résilience et une agilité cryptographique à long terme.

Le problème qui se cache en arrière-plan

La plupart des réseaux d’entreprise modernes s’appuient sur une couche cachée composée de certificats numériques et de cryptographie que la plupart des gens ne voient jamais. Cette couche vérifie la fiabilité des machines et sécurise les flux de données, mais comme les identités de machines dépassent désormais celles des humains dans un rapport de plus de 80 pour 1 dans une entreprise moyenne, selon l’étude de CyberArk sur les identités de machines, il est facile de sous-estimer l’importance de la couche cryptographique et des certificats.

Une façon utile d’envisager un certificat numérique est de le considérer comme un badge d’identification pour une machine. Si le badge est valide, les portes s’ouvrent automatiquement et personne n’y prête attention, mais dès que ce badge expire ou est mal configuré, la porte cesse de s’ouvrir, quelle que soit la légitimité de la machine qui se trouve derrière. Un seul certificat expiré peut mettre hors service des sites web, perturber les API qui permettent aux applications de communiquer entre elles, interrompre des transactions et entraîner des violations de conformité, tout en érodant la confiance des utilisateurs.

Pendant des années, les organisations ont géré les certificats manuellement, mais deux changements vont rendre cette gestion manuelle impossible à maintenir. Premièrement, la durée de vie maximale des certificats TLS (Transport Layer Security) publics, le protocole qui sécurise votre navigateur, va être réduite à seulement 47 jours d’ici 2029. Deuxièmement, l’arrivée prochaine d’ordinateurs quantiques suffisamment puissants pour briser le chiffrement actuel impose une transition vers la cryptographie post-quantique. Ces deux enjeux convergent vers une même solution : une approche de la gestion du cycle de vie des certificats (CLM) régie, automatisée et « crypto-agile ».

La feuille de route derrière la réduction de la durée de vie des certificats

La durée de validité des certificats TLS publics ne cesse de se réduire depuis une décennie. Début 2023, Google a publié pour la première fois sa feuille de route intitulée « Moving Forward, Together », qui proposait de réduire la durée de validité des certificats de 398 à 90 jours dans l’espoir d’inciter le secteur à s’orienter vers l’automatisation. Apple a accéléré ce calendrier en octobre 2024 en soumettant un projet de vote au CA/Browser Forum, l’organisme sectoriel au sein duquel les autorités de certification et les éditeurs de navigateurs établissent des règles communes. La proposition d’Apple, soutenue par Sectigo, Google Chrome et Mozilla, a été approuvée en avril 2025 sous la référence SC-081v3.

Cette réduction s’effectue par étapes. La durée maximale, qui était auparavant de 398 jours, est déjà passée à 200 jours en mars 2026 ; elle sera ramenée à 100 jours en mars 2027, puis finalement à 47 jours en mars 2029. Concrètement, une organisation qui renouvelle actuellement chaque certificat environ une fois par an devra bientôt renouveler tous ses certificats à peu près tous les mois et demi ; à l’étape finale, tout processus reposant sur la demande et l’installation manuelles des certificats par une personne échouera.

Les éditeurs de navigateurs prônent ces durées de vie plus courtes afin d’imposer l’automatisation, ce qui élimine l’erreur humaine à l’origine de la plupart des interruptions de service liées aux certificats. Elles permettent également à l’ensemble du Web d’adopter de nouvelles normes cryptographiques en quelques semaines plutôt qu’en plusieurs années, puisque les anciens certificats sont rapidement remplacés. De plus, elles contribuent à réduire la dépendance vis-à-vis des anciens systèmes de révocation, qui souffrent de problèmes de performances et de confidentialité. Enfin, si un journal de transparence des certificats (un registre public des certificats émis) venait à être invalidé, les certificats à courte durée de vie réduiraient considérablement le nombre de certificats devant être remplacés dans l’urgence.

Le casse-tête de la validation

Si la limite de 47 jours fait la une des journaux et retient l’attention, le changement le plus perturbateur pourrait bien concerner la validation du contrôle de domaine (DCV). La DCV est le processus consistant à prouver à une autorité de certification (CA) que vous contrôlez le domaine pour lequel vous demandez un certificat. Historiquement, une fois qu’une organisation avait prouvé sa propriété, l’AC pouvait réutiliser cette preuve pendant 398 jours maximum ; or, selon la norme SC-081v3, cette période de réutilisation sera réduite à 200 jours en 2026, puis à seulement 10 jours d’ici mars 2029.

Cela crée un réel déséquilibre, car même une organisation ayant entièrement automatisé l’installation des certificats se retrouvera bloquée si elle ne peut pas prouver à nouveau la propriété du domaine tous les 10 jours. Tout retard dans la validation interrompt l’ensemble du processus d’émission et entraîne directement des interruptions de service.

La solution pratique à ce problème consiste à adopter le protocole ACME (Automatic Certificate Management Environment) avec validation automatisée via l’API DNS-01, afin que la preuve de propriété s’effectue de manière programmatique plutôt que d’attendre l’intervention d’une personne.

La menace quantique et le calendrier

Alors que la durée de vie des certificats diminue, les algorithmes qu’ils contiennent sont confrontés à une menace quantique. Les infrastructures à clé publique (PKI) traditionnelles s’appuient sur la cryptographie asymétrique pour sécuriser les signatures numériques, les échanges de clés et les connexions TLS. Un ordinateur quantique suffisamment puissant exécutant l’algorithme de Shor pourrait complètement contourner ces systèmes. Attendre que l’informatique quantique soit suffisamment puissante pour déchiffrer n’est pas une option viable ; comme l’a écrit Vidya Shankaran, directrice technique sur le terrain chez Commvault : « La date exacte du Q-Day reste peut-être incertaine. Mais la direction prise ne l’est pas. »

Selon les estimations, le Q-Day, c’est-à-dire le moment où un ordinateur quantique pourra briser le chiffrement à clé publique, devrait survenir dans les 5 à 10 prochaines années. Cependant, ce serait une erreur de considérer cela comme un problème futur. Les acteurs malveillants mènent déjà des opérations de type « Harvest Now, Decrypt Later » (HNDL) : ils interceptent et stockent dès aujourd’hui le trafic chiffré dans l’intention de le déchiffrer une fois que l’informatique quantique aura atteint sa maturité. Les données qui doivent rester confidentielles pendant des années, telles que les dossiers médicaux, la propriété intellectuelle et les informations financières, sont de fait exposées dès le moment où elles sont collectées.

Le gouvernement fédéral américain a réagi en conséquence : en juin 2026, la Maison Blanche a publié le décret présidentiel n° 14412, intitulé « Securing the Nation Against Advanced Cryptographic Attacks » (Protéger la nation contre les attaques cryptographiques avancées), qui fixe des échéances bien en avance sur l’objectif initial du NIST pour 2035 : les systèmes fédéraux de grande valeur doivent adopter l’établissement de clés post-quantiques d’ici fin 2030 et les signatures numériques post-quantiques d’ici fin 2031.

Malgré cette urgence, les progrès réels vers une « crypto-agilité » au niveau des entreprises ont été lents. Le rapport « DigiCert Quantum Readiness Outlook » a révélé que plus de la moitié des organisations interrogées s’attendent à ce que le chiffrement asymétrique classique soit piraté d’ici cinq ans, mais que seules 7 % ont déployé une cryptographie quantique ou hybride sur l’ensemble de leur parc de certificats, et que le niveau de Readiness global n’a progressé que de 2 points de pourcentage au cours de l’année écoulée.

Pourquoi la « crypto-agilité » est-elle importante ?

Le pont le plus pratique entre la cryptographie classique et la cryptographie post-quantique est le certificat composite hybride, qui combine un algorithme classique (RSA ou ECC) avec un algorithme post-quantique (ML-DSA, le schéma de signature normalisé basé sur les treillis) au sein d’un seul certificat X.509. La combinaison des deux dans un seul certificat est conçue pour que celui-ci reste valide aussi longtemps que l’un ou l’autre des algorithmes, ce qui est essentiel, car les algorithmes post-quantiques sont récents et n’ont pas encore résisté à d’innombrables tentatives d’attaques comme l’a fait le RSA.

Cependant, les clés et signatures post-quantiques pèsent plusieurs kilo-octets plutôt que quelques centaines d’octets, ce qui augmente la latence du réseau, présente un risque de fragmentation des paquets lors de la négociation TLS et ajoute une surcharge de calcul pouvant nécessiter des mises à niveau matérielles pour les appareils aux ressources limitées. C’est précisément pour cette raison que la « crypto-agilité » est essentielle ; les organisations doivent pouvoir tester, déployer et faire tourner les algorithmes sans avoir à reconfigurer leur infrastructure sous-jacente à chaque évolution des normes.

Gestion automatisée du cycle de vie des certificats

La gestion manuelle des certificats n’est pas seulement inefficace ; c’est un véritable handicap opérationnel. Lorsque les certificats sont stockés dans des feuilles de calcul, hors de vue, les organisations perdent toute visibilité, ce qui se traduit par des identifiants périmés, des tailles de clés insuffisantes, des algorithmes de signature obsolètes et des configurations non conformes que personne ne remarque jusqu’à ce qu’un problème survienne. Les interruptions de service qui en résultent peuvent semer la confusion chez les utilisateurs, perturber le chiffre d’affaires et retomber sur l’équipe la moins préparée à les expliquer.

Une plateforme CLM complète résout ce problème tout au long du cycle de vie d’un certificat :

• Détection : analyse continue des environnements cloud, des centres de données, des conteneurs et des domaines externes afin d’identifier tous les certificats en cours d’utilisation.
• Surveillance : suivi en temps réel des dates d’expiration, des algorithmes, de la force des clés et de la conformité aux politiques de sécurité.
• Validation : utilisation d’une intégration API directe avec les autorités de certification publiques et privées, tout en automatisant la validation et les validations de domaines
• Installation : déploiement programmatique des certificats et clés renouvelés via ACME ou des API sécurisées, sans intervention manuelle.
• Révocation : il est nécessaire d’effectuer une révocation rapide, guidée par des politiques, afin qu’un certificat compromis puisse être remplacé ou révoqué partout simultanément, plutôt que d’être recherché machine par machine.

L’étape de découverte recèle également un avantage : l’inventaire des certificats géré par une plateforme CLM constitue, en effet, le point de départ de l’inventaire cryptographique requis pour la planification de la migration post-quantique, ce qui peut transformer une corvée de conformité en une longueur d’avance.

Identités non humaines et IA agentique

Le problème d’échelle est aggravé par la manière dont les applications modernes sont conçues. Les conteneurs, les pods Kubernetes, les machines virtuelles, les appareils de l’Internet des objets (IoT) et les API ont tous besoin de leurs propres identifiants, et bon nombre de ces charges de travail n’existent que pendant quelques minutes ou quelques heures avant de prendre fin. Aucune équipe humaine ne peut émettre et retirer des certificats à une telle vitesse.

Pour suivre ce rythme effréné, des agents d’IA peuvent être utilisés pour détecter, émettre, renouveler et gérer les certificats de manière autonome, tout en restant dans le cadre des garde-fous existants tels que les politiques de sécurité, le contrôle d’accès basé sur les rôles (RBAC) et les pistes d’audit centralisées. Il en résulte une automatisation à la vitesse des machines sans renoncer à la gouvernance d’entreprise.

Par où commencer

1. La première étape vers la « crypto-agilité » et la résilience à l’échelle de l’entreprise est d’ordre organisationnel plutôt que technique. Conformément aux recommandations du NIST, les entreprises doivent mettre en place une équipe centrale chargée des services d’identité des machines, qui gère la plateforme CLM, normalise les modèles de certificats et assure les intégrations avec les autorités de certification (CA) publiques et privées. Les responsables d’applications individuels et les équipes DevOps, quant à eux, doivent être chargés d’intégrer les renouvellements automatisés dans leurs propres pipelines de déploiement, en utilisant la plateforme centrale comme un service partagé. Cette répartition des responsabilités garantit la cohérence de la gouvernance tout en éliminant les transferts manuels qui provoquent des interruptions de service.
2. Les organisations doivent dès à présent remplacer les techniques et workflows de validation manuels par ACME et la validation automatisée DNS-01, bien avant l’arrivée de la fenêtre de 10 jours prévue pour la validation par certificat (DCV), tout en supprimant progressivement chaque processus manuel de renouvellement et de validation.
3. 1. 1. En parallèle, les organisations doivent réaliser un inventaire complet de leurs actifs cryptographiques afin d’identifier les clés codées en dur, les algorithmes obsolètes et les chemins de confiance de longue durée protégeant les données sensibles.
      2. La préparation post-quantique doit débuter dans un environnement contrôlé plutôt qu’en production. Un laboratoire de test dédié doit être mis en place pour permettre aux équipes de tester des certificats composites hybrides et des mises à niveau « crypto-agiles » dans un bac à sable. En développant des applications sur des bibliothèques cryptographiques modulaires connectées à une plateforme CLM dynamique, les entreprises peuvent acquérir une véritable « crypto-agilité » : la capacité à faire tourner les clés, les chiffrements et les algorithmes à travers leur infrastructure à mesure que les normes évoluent, sans avoir à tout reconstruire.

Le fil conducteur qui relie toutes ces recommandations est l’inventaire. L’étape de découverte d’une plateforme CLM n’est pas une simple formalité préalable à la véritable mise en œuvre ; c’est la même rigueur dont les organisations auront besoin à chaque niveau de Readiness quantique. Les certificats sont des identités non humaines, et les mêmes questions s’appliquent aux comptes de service, aux agents d’IA, aux dépendances open source et aux algorithmes enfouis dans le code des applications : que possédons-nous, que protège-t-il et quels éléments sont les plus importants pour l’entreprise ?

Les entreprises qui renforcent dès maintenant leurs capacités d’inventaire, en commençant par les certificats, trouveront le reste de la transition bien moins intimidant, car la hiérarchisation des priorités deviendra un calcul plutôt qu’une supposition. Considérer les prochaines années comme une fenêtre de planification plutôt que comme un délai de grâce aidera les entreprises à effectuer cette transition selon leurs propres conditions, au lieu de laisser une panne prendre la décision à leur place.

Caitlin Dodson est stagiaire pour l’été 2026 au sein de la division FCTO – Amériques chez Commvault.

Points clés à retenir

• Remplacer les affirmations subjectives concernant la « facilité d’utilisation » par un ratio de protection des données mesurable : la capacité protégée divisée par le nombre d’administrateurs à temps plein.
• La mesure de la capacité protégée par ETP offre une vision plus pertinente de l’efficacité opérationnelle que les indicateurs traditionnels, tels que le nombre de tâches de sauvegarde par administrateur.
• Le ratio de protection des données doit servir de référence avant la migration vers une nouvelle plateforme, puis être mesuré à nouveau après celle-ci afin de valider les améliorations opérationnelles.
• Des facteurs tels que les environnements multicloud, les exigences en matière de reprise après sinistre informatique et les obligations de conformité peuvent influencer ce ratio ; il convient donc de l’évaluer dans le contexte propre à chaque environnement.
• Les entreprises devraient demander aux fournisseurs de s’engager à atteindre des résultats opérationnels mesurables plutôt que de se fier à des affirmations qualitatives concernant la simplicité.

Toutes les évaluations de fournisseurs auxquelles j’ai participé finissent par aboutir au même impasse. D’un côté, on affirme que la plateforme est simple à utiliser. De l’autre, on prétend que c’est la sienne qui est la plus simple.

Personne ne peut prouver l’une ou l’autre de ces affirmations ; la conversation dérive alors vers la démonstration, l’entretien de référence ou l’intuition générale qui règne dans la salle. Ce n’est pas ainsi que vous devriez prendre une décision qui déterminera la manière dont votre équipe passera les cinq prochaines années.

J’ai géré des environnements de protection des données en production. J’ai vu des équipes crouler sous le poids d’outils fragmentés qui promettaient l’automatisation et ne faisaient que générer des tickets d’incident.

La « complexité réduite » n’est pas une impression que vous devriez accepter sur la foi de paroles. C’est quelque chose que vous devriez pouvoir calculer.

L’indicateur qui manquait au secteur

Nous avons commencé à utiliser un ratio simple en interne et auprès de nos clients : la capacité totale protégée divisée par le nombre d’employés à temps plein nécessaires à son fonctionnement. Nous l’appelons le « ratio de rentabilité de la protection des données ».

Capacité protégée (PB) / ETP = Ratio de rentabilité de la protection des données

C’est tout. Pas de questions d’enquête sur la satisfaction. Pas d’adjectifs. Un chiffre, calculé à partir des données dont vous disposez déjà.

Voici pourquoi cet indicateur est plus pertinent que ceux qu’il remplace. Calculer le nombre de tâches de sauvegarde par personne avait du sens il y a dix ans, lorsqu’une tâche représentait une unité distincte d’effort manuel. Cela ne reflète pas le fonctionnement des plateformes modernes d’aujourd’hui, où l’automatisation prend en charge le travail routinier et où un seul administrateur peut être responsable de pétaoctets, et non plus d’un nombre de tâches.

Mesurer le nombre de tâches par personne dans un environnement automatisé ne vous indique en rien si l’automatisation fonctionne réellement.

Concrètement

Une précision avant de passer aux chiffres, car cela prête souvent à confusion. La « capacité protégée » désigne la taille totale, non compressée et non dédupliquée, des applications protégées, et non celle du disque physique qui les héberge.

Cette distinction est importante, car c’est là tout l’intérêt. L’environnement de production de Commvault protège 42,39 PB de données d’applications sur 9,26 PB de disques physiques, soit un gain d’espace de 81,91 % grâce à la déduplication et à la compression.

Ce ratio ne se limite pas à mesurer le nombre de pétaoctets qu’une personne peut superviser. Il mesure la part du travail effectuée par l’architecture avant même que les effectifs n’entrent en ligne de compte.

Dans cette optique : Commvault exploite son propre environnement de sauvegarde en production sur une capacité protégée de 42,39 PB avec deux ETP. Cela correspond à un ratio de 21,20 PB par ETP. Les références du secteur pour les plateformes modernes se situent généralement entre 5 et 25 PB par ETP, en fonction de la complexité de l’environnement ; ce chiffre se situe donc dans le haut de la fourchette de ce qui est réalisable aujourd’hui.

Ratio de protection des données = 42,39 PB / 2 ETP = 21,20 PB par ETP

Je tiens à préciser clairement ce que ce chiffre ne reflète pas. Il ne tient pas compte d’une infrastructure multicloud, des exigences en matière de Recovery après cyberattaque, ni d’un ensemble d’applications soumises à de strictes contraintes de conformité, autant de facteurs qui feront baisser ce ratio pour des raisons n’ayant rien à voir avec la qualité de la plateforme.

Un ratio pris isolément ne constitue pas un verdict. En revanche, un ratio mesuré avant et après une migration en est un.

C’est là le véritable cas d’utilisation. Établissez une base de référence de votre environnement actuel à l’aide de vos outils actuels. Fixez un ratio cible en fonction de vos prévisions de croissance et de la capacité de votre équipe. Puis veillez à ce que votre fournisseur s’y conforme une fois la mise en œuvre terminée, et pas seulement pendant le cycle de vente.

Les implications au niveau du conseil d’administration

Si vous êtes chargé de valider la migration vers une nouvelle plateforme, on ne vous demande pas simplement de croire que cette nouvelle plateforme est plus facile à gérer. On vous demande de financer un résultat opérationnel spécifique. Un objectif de ratio de protection des données vous permet d’intégrer ce résultat dans l’analyse de rentabilité et de le vérifier 12 mois plus tard.

C’est la même rigueur que nous appliquons au temps moyen de récupération après nettoyage (MTCR). La capacité de récupération ne se revendique pas, elle se mesure et se remet à l’épreuve jusqu’à ce que les chiffres reflètent la réalité. L’efficacité opérationnelle mérite d’être évaluée selon les mêmes critères.

Le défi

Demandez à votre fournisseur actuel quel est le ratio de rentabilité de votre propre environnement aujourd’hui. S’il ne peut pas vous le fournir, cela en dit long sur sa compréhension de ce que signifie « simple à gérer » pour votre équipe.

Et si vous évaluez une nouvelle plateforme, ne vous contentez pas d’une réponse du type « plus facile à utiliser ». Demandez quel ratio le fournisseur s’engage à atteindre, et posez à nouveau la question au bout d’un an.

FAQ

Q : Qu’est-ce que le ratio de protection des données ?

R : Le ratio de protection des données mesure la quantité de capacité de données protégées gérée par chaque administrateur à temps plein. Il offre un moyen objectif d’évaluer l’efficacité opérationnelle plutôt que de se fier à des impressions subjectives sur la facilité d’utilisation de la plateforme.

Q : Pourquoi cet indicateur est-il plus utile que le nombre de tâches de sauvegarde par administrateur ?

R : Les plateformes modernes de protection des données automatisent une grande partie du travail de routine qui nécessitait auparavant une intervention manuelle. Par conséquent, le décompte des tâches de sauvegarde ne reflète plus la charge de travail réelle ni l’efficacité d’une équipe opérationnelle.

Q : Que signifie « capacité protégée » dans ce calcul ?

R : La capacité protégée désigne la taille totale, non compressée et non dédupliquée, des données d’application protégées. Cette mesure reflète la charge de travail réelle gérée par la plateforme plutôt que l’espace de stockage physique consommé après optimisation.

Q : Un ratio de démultiplication plus élevé est-il toujours le signe d’une meilleure plateforme ?

R : Pas nécessairement. La complexité de l’environnement, notamment les déploiements multicloud, les exigences en matière de cyber-résilience et les obligations réglementaires, peut réduire ce ratio même lorsque la plateforme fonctionne bien. Cet indicateur est particulièrement utile pour comparer un même environnement avant et après une migration.

Q : Comment les entreprises doivent-elles utiliser le ratio de protection des données lors de l’évaluation des fournisseurs ?

R : Les entreprises doivent établir une base de référence à partir de leur environnement actuel, définir un ratio cible en adéquation avec leur croissance future et demander aux fournisseurs de s’engager à réaliser des améliorations mesurables après la mise en œuvre. Cette approche permet de déplacer le débat des arguments marketing vers des résultats commerciaux vérifiables.

Q : Quelle est la valeur métier globale de cet indicateur ?

R : Le ratio de protection des données permet aux dirigeants de quantifier les gains d’efficacité opérationnelle attendus et de les intégrer dans l’analyse de rentabilité d’un investissement dans une plateforme. Il fournit également un point de référence pouvant être examiné après le déploiement afin de confirmer que les résultats promis ont bien été atteints.

Rajiv Kottomtharayil est directeur des produits chez Commvault.