Dans le premier épisode de notre série STRIVE consacrée à la souveraineté numérique, Alex Zinin, de Commvault, et Max Mortillaro, d’Osmium Data Group, ont remis en question l’une des plus grandes idées reçues du secteur : la souveraineté numérique n’est pas une fonctionnalité que l’on achète, mais un enjeu commercial qu’il faut comprendre avant de pouvoir le résoudre.

Cette conversation reprend là où la précédente s’était arrêtée. Cette fois-ci, j’ai rencontré Thomas Maurer, Global Black Belt EMEA pour la « Sovereign Cloud » chez Microsoft, afin d’examiner ce qui se passe lorsqu’une organisation décide que la souveraineté est une priorité. Comment les équipes de direction passent-elles de préoccupations générales concernant la réglementation, la juridiction ou l’incertitude géopolitique à des décisions architecturales concrètes ?

Il s’avère que la réponse est rarement aussi simple que de choisir un fournisseur d’cloud s ou de sélectionner le bon modèle de déploiement. Il s’agit plutôt de se poser les bonnes questions avant de prendre des décisions techniques. Regardez l’épisode dans son intégralité.

Points clés à retenir

• Chaque organisation a sa propre définition de la souveraineté numérique – et c’est précisément par là que le débat devrait commencer.
• La question de la souveraineté ne peut être résolue par la seule technologie. Des considérations juridiques, opérationnelles, architecturales et commerciales influencent toutes le résultat final.
• Cloud et les solutions sur site ne sont pas des stratégies concurrentes. Pour de nombreuses entreprises, l’avenir réside dans une combinaison judicieusement conçue des deux.
• Ce sont les considérations de gestion des risques – et non la peur – qui devraient guider les décisions en matière de souveraineté.
• Une bonne architecture commence par la compréhension des besoins métier, et non par le choix de l’infrastructure.

La notion de souveraineté revêt des significations différentes selon les organisations

L’une des premières observations faites par Thomas fut également l’une des plus importantes. Il n’existe pas de définition universelle de la souveraineté numérique. Pour une organisation, cela peut simplement signifier se conformer aux exigences réglementaires ou conserver les données au sein d’une zone géographique spécifique. Pour une autre, cela peut impliquer l’indépendance opérationnelle, la continuité des activités ou la préparation à des perturbations géopolitiques. Cette différence est importante car elle change complètement la donne.

Trop souvent, les entreprises partent du principe qu’il existe un modèle standard de souveraineté prêt à être mis en œuvre. En réalité, le premier défi ne réside pas dans le choix de la technologie, mais dans la compréhension du problème que l’entreprise cherche réellement à résoudre. C’est seulement à ce moment-là que l’architecture commence à prendre tout son sens.

La technologie doit s’aligner sur la stratégie

Un thème qui est revenu sans cesse tout au long de notre discussion était la tentation de se lancer directement dans la conception technique. C’est tout à fait compréhensible. Les architectes ont naturellement tendance à se concentrer sur l’infrastructure, les charges de travail, la connectivité et les modèles de déploiement. Mais Thomas a souligné que les projets les plus réussis partent d’un tout autre point de départ. Ils commencent par écouter.

Quelles sont les préoccupations qui motivent cette initiative ? L’objectif est-il la conformité réglementaire ? La continuité d’activité ? La localisation des données ? Le contrôle opérationnel ? La protection contre les perturbations géopolitiques ? Des réponses différentes conduisent à des architectures différentes. Cela peut sembler évident, mais il est surprenant de constater à quel point les entreprises se lancent souvent dans l’évaluation de solutions avant même de s’être mises d’accord sur l’objectif commercial qu’elles cherchent à atteindre.

Aperçu : partez du risque, pas des hypothèses

L’un des moments les plus concrets de notre conversation survient lorsque Thomas et moi discutons des raisons pour lesquelles les initiatives en matière de souveraineté devraient commencer par une évaluation des risques – et non par un schéma architectural.

Chaque organisation a une appétence au risque qui lui est propre. Une écurie de Formule 1, une administration publique et un fabricant international ne prendront pas les mêmes décisions, et c’est tout à fait normal. L’essentiel est de comprendre quels sont les risques les plus importants pour votre entreprise, quels compromis vous êtes prêt à accepter, puis de concevoir une architecture qui s’aligne sur ces décisions.

Comme le souligne Thomas, il n’existe pas de solution parfaite, mais seulement des compromis mûrement réfléchis. Plus tôt les organisations adopteront cet état d’esprit, plus leur stratégie en matière de souveraineté sera solide.

«Cloud ou sur site ? » : ce n’est pas la bonne question à se poser

L’un des aspects les plus intéressants de la discussion a remis en cause une autre idée reçue : celle selon laquelle les organisations doivent choisir entre une cloud publique et une privée. Thomas a décrit une réalité très différente. De nombreuses organisations ne se contentent pas de remplacer l’un par l’autre. Elles conçoivent des environnements dans lesquels les charges de travail peuvent passer de l’un à l’autre en fonction des besoins de l’entreprise, des exigences réglementaires ou de considérations liées à la résilience.

Cette flexibilité modifie notre façon d’envisager l’architecture. Plutôt que de se demander si le cloud ou l’infrastructure sur site est la meilleure solution, la question la plus pertinente est désormais : « Où cette charge de travail a-t-elle sa place aujourd’hui – et cette réponse pourrait-elle changer demain ? » Lorsque la souveraineté s’intègre au processus de conception, la mobilité des charges de travail devient tout aussi importante que leur localisation.

L’architecture n’est qu’une partie de l’équation

Un autre point que j’apprécie particulièrement est le rappel de Thomas selon lequel l’architecture, à elle seule, ne résout pas la question de la souveraineté.

• Les contrats ont leur importance.
• Les cadres juridiques ont leur importance.
• Les processus opérationnels sont essentiels.
• Les personnes chargées de la gestion de l’environnement jouent un rôle essentiel.

Aucune de ces disciplines ne peut fonctionner de manière isolée. La souveraineté exige que les équipes chargées des aspects juridiques, de la sécurité, de la conformité et des infrastructures travaillent ensemble dès le début – et non qu’elles se transmettent les projets les unes aux autres une fois les décisions déjà prises. C’est un schéma bien connu de tous ceux qui travaillent dans le domaine de la cyber-résilience. Les meilleurs résultats proviennent rarement d’équipes isolées. Ils sont le fruit d’une coordination entre les équipes.

Le risque doit guider chaque décision

Vers la fin de notre discussion, la conversation s’est naturellement orientée vers le risque. Pour moi, c’est là que la souveraineté commence à me paraître beaucoup plus familière. Tout projet de résilience commence par se demander ce que l’organisation cherche à protéger, quelles sont les menaces les plus importantes et quel niveau de risque elle est prête à accepter.

Il en va de même pour la souveraineté numérique. Plutôt que de rechercher une solution parfaite, les organisations doivent identifier les scénarios spécifiques en matière de souveraineté qui les préoccupent, puis déterminer quels contrôles architecturaux, opérationnels ou contractuels permettent de répondre au mieux à ces risques. C’est cette évolution – du simple comparatif des fonctionnalités à la gestion des risques – qui permet en fin de compte de prendre de meilleures décisions.

Pourquoi cette discussion est importante

La souveraineté numérique continue d’évoluer rapidement. De nouvelles réglementations verront le jour. La technologie changera. Les réalités géopolitiques continueront de muter. Cela signifie que la souveraineté n’est pas un enjeu que les organisations règlent une fois pour toutes. C’est un aspect qu’elles réévaluent régulièrement, à mesure que leurs priorités commerciales et les risques externes évoluent.

Les organisations qui réussiront ne seront pas nécessairement celles qui disposeront des architectures les plus restrictives. Ce seront celles qui auront la vision la plus claire de leurs objectifs commerciaux, la rigueur nécessaire pour évaluer les risques de manière réfléchie et la souplesse requise pour s’adapter à l’évolution de ces risques. En fin de compte, la souveraineté numérique n’est pas un produit que les organisations peuvent acheter tout fait. Il s’agit plutôt d’un processus visant à comprendre les risques, à gérer les dépendances et à faire des choix éclairés bien avant que ces décisions ne soient mises à l’épreuve.

Regardez l’épisode dans son intégralité

Dans cet épisode de STRIVE, Thomas et moi abordons les sujets suivants :

• Pourquoi la notion de souveraineté revêt des significations différentes selon les organisations.
• Comment les dirigeants devraient aborder la stratégie en matière de souveraineté.
• cloud publique ou cloud privée : pourquoi il ne s’agit souvent pas d’un choix binaire.
• Pourquoi la gestion des risques devrait guider les choix architecturaux.
• Le rôle de la résilience dans la planification de la souveraineté moderne.

Regardez-le dès maintenant.

FAQ

Q : La souveraineté numérique implique-t-elle de tout conserver sur site ?

R : Non. De nombreuses organisations adoptent des approches hybrides qui concilient les capacités d’ cloud s et les exigences spécifiques en matière de souveraineté.

Q : Par où faut-il commencer pour mettre en place des projets en matière de souveraineté ?

R : Commencez par définir le problème métier et par cerner les risques que vous cherchez à atténuer avant d’évaluer les solutions technologiques.

Q : La souveraineté est-elle une question purement technique ?

R : Non. Cela nécessite une collaboration entre les équipes juridiques, de conformité, de sécurité, d’exploitation et d’architecture.

Q : Quel est le lien entre la souveraineté et la résilience ?

R : Ces deux disciplines visent à garantir la continuité des activités en réduisant l’exposition aux risques susceptibles de perturber l’activité de l’entreprise.

Q : Quelle est l’une des principales erreurs commises par les organisations en matière de souveraineté numérique ?

R : Se lancer dans des choix architecturaux avant de s’être mis d’accord sur ce que signifie la « souveraineté » pour leur organisation.

Q : Quelle devrait être la première question que se posent les dirigeants lorsqu’ils planifient la souveraineté numérique ?

R : « Quel problème essayons-nous de résoudre ? » Tout le reste découle de cette réponse.

Darren Thomson est vice-président et directeur technique pour la région EMEA chez Commvault.

Depuis des années, la cyber-résilience est définie par la technologie : mesures de sécurité, capacités de détection sophistiquées et stratégies de sauvegarde de plus en plus robustes, conçues pour prévenir les attaques ou permettre une reprise plus rapide. Ces investissements restent essentiels, mais ils ne suffisent plus. L’IA a profondément modifié la nature des cyberattaques, qui évoluent désormais à une vitesse qui met à rude épreuve même les organisations les plus expérimentées. Alors que le délai entre la compromission et la perturbation des activités ne cesse de se réduire, la résilience consiste de moins en moins à prévenir chaque attaque et de plus en plus à maintenir le fonctionnement de l’entreprise lorsque la prévention échoue inévitablement.

Cette évolution est au cœur du nouveau rapport d’IDC, intitulé « Resilience Operations : The Discipline that Makes Readiness Provable » (Opérations de résilience : la discipline qui rend la préparation vérifiable). Cette évolution est au cœur du nouveau rapport d’IDC, « Resilience Operations : la discipline qui rend la préparation vérifiable ». S’appuyant sur une enquête menée auprès de plus de 500 organisations nord-américaines, ce rapport affirme que la résilience est en train de devenir une discipline opérationnelle transversale qui relie les priorités métier à la cybersécurité, aux opérations informatiques (ITOps) et à la reprise après sinistre. Plus important encore, il met en évidence plusieurs lacunes qui suggèrent que de nombreuses organisations continuent de se préparer à un paysage de menaces qui n’existe plus. Voici les enseignements qui ressortent. 

La reprise doit s’articuler autour des résultats commerciaux, et non des aspects techniques.

Historiquement, la planification de la reprise après sinistre s’est concentrée sur la restauration des infrastructures dans les meilleurs délais, le succès étant évalué à l’aune des objectifs de délai de reprise, des taux d’achèvement des sauvegardes et de la disponibilité des applications. Bien que ces indicateurs restent pertinents, ils ne répondent pas nécessairement à la question qui préoccupe le plus les dirigeants : quand l’activité pourra-t-elle reprendre ? 

IDC estime que la résilience doit être axée sur les résultats commerciaux plutôt que sur des étapes techniques : il s’agit de rétablir les capacités qui permettent à l’entreprise de servir ses clients, de générer des revenus et de remplir ses obligations. Cela peut sembler n’être qu’une question de terminologie, mais cela modifie la manière dont les priorités en matière de reprise sont définies. La technologie devient alors un moyen d’atteindre un but, plutôt qu’une fin en soi. 

La plupart des organisations n’ont toujours pas défini ce qui compte le plus.

Près de 6 organisations sur 10 n’ont pas encore clairement défini leur « modèle économique minimal viable » (MVB) – c’est-à-dire l’ensemble minimal de fonctions, de systèmes, de processus et de données nécessaires pour poursuivre leurs activités après une perturbation. 

Sans une vision commune des éléments dont dépend réellement l’activité, chaque action menée pendant la phase de reprise devient une simple réaction. En définissant votre MVB avant qu’une crise ne survienne, vous favoriserez une prise de décision plus rapide, une meilleure coordination pendant la phase de reprise et, au final, une organisation plus résiliente. 

L’automatisation devient la ligne de démarcation entre la résilience et l’endettement lié à la reprise.

Alors que les attaquants automatisent de plus en plus les phases de reconnaissance, d’exploitation et de déplacement latéral, de nombreuses entreprises continuent de s’appuyer sur des processus de restauration manuels. Ce déséquilibre devient de plus en plus difficile à ignorer. L’IA raccourcit les délais d’attaque, mais les délais de restauration n’ont pas suivi le rythme. L’orchestration automatisée de la restauration, l’identification précise des points de restauration et la validation coordonnée deviennent des capacités essentielles pour assurer une restauration à la vitesse exigée par les attaques modernes. 

Ce n’est pas la technologie qui constitue le principal défi en matière de résilience, mais bien la cohésion organisationnelle.

Les équipes de sécurité se concentrent sur le confinement, les équipes chargées de l’infrastructure sur la remise en état, les dirigeants sur l’impact sur les clients et les équipes chargées de la conformité sur les obligations réglementaires. Aucune de ces priorités n’est en soi erronée, mais lorsqu’elles évoluent de manière indépendante, les organisations se retrouvent confrontées à une crise sans disposer d’un modèle opérationnel commun. 

C’est là qu’intervient le concept de « ResOps ». Plutôt que de considérer la résilience comme une responsabilité du service informatique, le rapport la présente comme une discipline qui rassemble délibérément les domaines de l’activité, de la sécurité, de l’infrastructure et de la planification de la reprise. Le message est clair : la résilience dépend moins des outils individuels que de la définition de priorités communes avant qu’un incident ne vous oblige à prendre des décisions difficiles. 

Le dépistage reste l’un des indicateurs les plus fiables de la résilience.

IDC a constaté que relativement peu d’organisations mènent fréquemment des exercices sur table ou des simulations en cyber-range, alors que des décennies de données montrent que ces répétitions améliorent systématiquement les performances lors d’incidents réels. 

Les exercices permettent de mettre en évidence les dépendances cachées, de révéler les lacunes en matière de communication et de permettre aux équipes de prendre des décisions sans en subir les conséquences réelles. Les organisations qui valident régulièrement leurs processus de reprise développent un niveau de confiance qui va au-delà de la simple planification. 

Les défis de demain en matière de résilience se dessinent déjà.

Ransomware continue de faire la une de l’actualité, mais les prochains défis en matière de résilience se profilent déjà à l’horizon : de l’IA agentique et des identités machines à la cryptographie post-quantique. 

Ces menaces nous rappellent que la planification de la résilience ne peut pas se concentrer exclusivement sur les infrastructures actuelles. La reprise implique de plus en plus des services « cloud », des applications « SaaS », des modèles d’IA, des identités machine, des fournisseurs tiers et des écosystèmes numériques distribués qui n’existaient pas il y a dix ans. 

La résilience devient mesurable.

Le modèle de maturité ResOps d’IDC est un outil précieux pour évaluer la situation actuelle de votre organisation. Plutôt que de considérer la résilience comme une qualité que les organisations possèdent ou non, ce cadre décrit une évolution allant d’opérations réactives et cloisonnées vers une résilience mature et adaptative, fondée sur la gouvernance, l’automatisation et l’amélioration continue. À mes yeux, cette évolution reconnaît une réalité importante : la résilience n’est jamais achevée. Il ne s’agit pas d’acheter une plateforme ou de mener à bien un projet. Les organisations deviennent résilientes en améliorant continuellement la manière dont la technologie, les personnes et les processus métier collaborent sous pression. Sous cet angle, la résilience s’apparente moins à une assurance qu’à l’excellence opérationnelle : une capacité qui peut être évaluée, renforcée et démontrée au fil du temps. 

Nous assistons actuellement à une évolution plus générale de la manière dont les organisations envisagent la résilience.

Les discussions sur la résilience ne portent plus uniquement sur la protection des infrastructures, mais s’étendent désormais à la protection de l’entreprise elle-même. Cela signifie que la planification de la reprise commence par les clients plutôt que par les serveurs, que la gouvernance revêt désormais autant d’importance que la technologie, et que la confiance repose davantage sur la démonstration des capacités que sur la simple documentation des intentions. ResOps n’est pas vraiment un nouveau cadre ; il s’agit plutôt d’une prise de conscience plus large du fait que la cyber-résilience est devenue une discipline opérationnelle. À mesure que les attaques gagnent en rapidité et en complexité, la résilience ne se mesurera plus à l’absence d’incidents, mais à la capacité d’une organisation à continuer de servir ses clients, de soutenir ses collaborateurs et de préserver la confiance malgré les perturbations. C’est finalement ce que ResOps est censé démontrer. Rajiv Kottomtharayil est directeur des produits chez Commvault. 

Points clés à retenir

• À l’ère de l’IA, la confiance ne disparaît pas : elle évolue.
• Les organisations doivent vérifier en permanence le fonctionnement de l’IA plutôt que de s’y fier aveuglément.
• L’adoption de l’IA devrait donner plus d’autonomie aux employés, et non les pousser vers une « IA fantôme ».
• Le modèle « zero trust » ne consiste pas à se méfier des gens. Il s’agit de vérifier en permanence les identités, les appareils et les actions.
• Pour une adoption responsable de l’IA, il faut que la technologie, la gouvernance et les personnes travaillent main dans la main.

Lorsque nous avons lancé « Ready. Or Not. », notre objectif était de créer une série permettant de mieux comprendre certains des grands débats actuels autour de l’IA. En réunissant l’humoriste Nathan Macintosh et des experts du secteur, nous abordons des thèmes aussi variés que l’IA agentique, la cyber-résilience ou encore la gestion des données, le tout avec une touche d’humour.

Si vous avez écouté notre premier épisode consacré aux opportunités et aux risques liés à l’IA agentique, je pense que celui-ci vous plaira également. Cette fois-ci, nous abordons un sujet qui est au cœur de tous les débats sur l’IA : la confiance.

Nathan s’entretient avec Diana Kelley, responsable de la sécurité des systèmes d’information chez Protect AI, pour discuter de ce que signifie faire confiance à la technologie à une époque où l’IA est capable de générer des contenus falsifiés convaincants, de prendre des décisions et même d’imiter des personnes. Des « deepfakes » et des « hallucinations » au modèle « zero trust » et à l’« IA fantôme », ils examinent comment les organisations peuvent adopter l’IA sans perdre confiance en leurs collaborateurs et leurs systèmes.

Regardez l’épisode dans son intégralité sur Readiverse. À l’issue de cet épisode, je me suis senti plus optimiste que je ne l’aurais imaginé. Non pas parce que l’IA est soudainement devenue plus fiable, mais parce que Diana nous montre que la confiance s’installe lorsque les organisations mettent en place les politiques, les garde-fous et les technologies adéquats. Voici quelques thèmes abordés au cours de cette conversation qui jettent un nouvel éclairage sur l’IA.

La confiance et la technologie peuvent coexister

Diana estime que la confiance est possible à l’ère de l’IA, mais qu’elle prendra une forme différente. Nous avons toujours construit la confiance à travers nos relations avec les autres. Aujourd’hui, nous apprenons à étendre cette confiance aux systèmes. Cela ne signifie pas pour autant qu’il faille faire aveuglément confiance à la technologie. Il s’agit plutôt de comprendre le fonctionnement de l’IA, d’en reconnaître les limites et de mettre en place les mesures de protection adéquates afin que les personnes et la technologie puissent collaborer en toute confiance.

« La confiance doit évoluer pour s’adapter à ce nouveau monde. » – Diana Kelley

Ce qui m’a particulièrement marqué, c’est l’idée que la confiance et la technologie ne sont pas nécessairement incompatibles. Avec une approche adaptée, elles peuvent se renforcer mutuellement.

Nous progressons dans notre compréhension de l’IA

Les deepfakes sont devenus l’un des risques liés à l’IA dont on parle le plus, et on comprend aisément pourquoi. L’IA est désormais capable de générer des voix, des images et des vidéos convaincantes qui nous amènent à nous interroger sur ce qui est réel. Mais Diana a souligné que si l’IA gagne en sophistication, les gens deviennent eux aussi plus avisés. Nous sommes davantage enclins à nous interroger sur un appel téléphonique inattendu, à examiner de plus près une publication sur les réseaux sociaux ou à nous interroger face à quelque chose qui ne nous semble pas tout à fait normal.

Les organisations deviennent elles aussi plus avisées. À mesure que l’IA perfectionne ses capacités d’usurpation d’identité, les entreprises investissent dans de nouveaux moyens permettant de vérifier en permanence les identités et de valider les informations. Ce que j’en retiens, c’est que la technologie continuera à s’améliorer, mais qu’il en sera de même pour notre capacité à la reconnaître et à y répondre de manière responsable.

« Est-ce que c’est un bon jour pour se lancer dans le deepfake ? » – Nathan Macintosh

Une IA responsable est bénéfique pour les entreprises

Diana a donné un exemple qui semblera sans doute familier à de nombreuses entreprises. Une employée qu’elle appelle « Karen, du service financier », commence à utiliser l’IA car cela lui permet d’accomplir une tâche en quelques minutes au lieu de plusieurs heures. Karen ne cherche pas à contourner la politique de l’entreprise : elle essaie simplement d’être plus productive.

Les collaborateurs utilisent l’IA parce qu’ils y voient une réelle valeur ajoutée, ce qui représente une opportunité pour les entreprises. Lorsqu’ils ont accès à des outils d’IA approuvés, accompagnés de politiques claires et de conseils pratiques, ils peuvent travailler plus efficacement tout en contribuant à la protection des données et des systèmes de l’entreprise.

Aperçu : une adoption plus intelligente de l’IA

L’objectif n’est pas d’empêcher les employés d’utiliser l’IA, mais de s’assurer qu’ils l’utilisent correctement. Diana explique comment les entreprises peuvent encourager l’adoption de l’IA sans créer de risques inutiles.

Le modèle « Zero Trust » est plus important que jamais

« Quand on comprend comment les choses fonctionnent, on peut alors commencer à comprendre comment les gérer. » – Diana Kelley

Le « zero trust » fait partie de ces concepts qu’il est beaucoup plus facile de comprendre à l’aide d’une analogie. Diana en propose une excellente. Elle le décrit comme le fait de se déplacer dans un bâtiment. Ce n’est pas parce que l’on vous a autorisé à franchir la porte d’entrée que toutes les autres portes s’ouvrent automatiquement pour vous. Chaque fois que vous accédez à une nouvelle pièce, un nouveau contrôle rapide est effectué pour confirmer que vous êtes bien autorisé à vous y trouver.

C’est essentiellement ainsi que fonctionne le « zero trust ». C’est en substance ainsi que fonctionne le modèle « zero trust ». Au lieu de considérer qu’une personne ou un appareil est digne de confiance après une simple connexion, les entreprises vérifient en permanence les identités, les appareils et les actions, à mesure que les technologies deviennent de plus en plus interconnectées. La plupart de ces vérifications s’effectuent discrètement en arrière-plan. L’un des aspects que j’ai particulièrement appréciés dans l’explication de Diana, c’est que le « zero trust » ne donne pas l’impression d’être un simple mot à la mode dans le domaine de la sécurité. Il apparaît plutôt comme une approche concrète de la confiance dans un monde où l’IA et les identités numériques font désormais partie intégrante du quotidien des entreprises.

La confiance, c’est avant tout une question de personnes

En fin de compte, ce n’est pas la technologie qui instaure la confiance, mais les personnes. Ce sont elles qui définissent les politiques, les processus et les limites éthiques qui régissent l’utilisation de l’IA, tandis que la technologie permet de vérifier que ces garde-fous fonctionnent comme prévu. C’est ce partenariat entre les personnes et la technologie qui rend possible une IA responsable.

La confiance dépasse le cadre de nos propres organisations. Les entreprises doivent pouvoir avoir confiance dans les partenaires avec lesquels elles travaillent, les systèmes auxquels elles se connectent et les technologies qu’elles adoptent. C’est pourquoi la transparence, les normes communes et la vérification continue deviennent tout aussi importantes que l’innovation elle-même. Plus l’IA s’intègre dans le quotidien des entreprises, plus la confiance devient la responsabilité de chacun.

Perspectives d’avenir

L’IA continuera d’évoluer, tout comme la manière dont nous interagissons avec elle. Les organisations qui réussiront ne seront pas celles qui font aveuglément confiance à l’IA ou qui l’évitent complètement. Ce seront celles qui mettront en place des politiques solides, adopteront les technologies adaptées et vérifieront en permanence les systèmes sur lesquels elles s’appuient.

La confiance n’est pas quelque chose que l’on perd à mesure que la technologie progresse. C’est quelque chose que l’on construit et que l’on fait évoluer de manière intentionnelle. C’est exactement le genre de discussion que nous espérons poursuivre à chaque épisode de Ready. Or Not. Regardez l’épisode dans son intégralité sur Readiverse.

FAQ

Q : Qu’est-ce que la confiance numérique ?

R : La confiance numérique, c’est la certitude que les personnes, les systèmes et les organisations sont bien ceux qu’ils prétendent être et qu’ils agissent de manière conforme aux attentes et sécurisée. Elle associe technologie, gouvernance et vérification pour aider les organisations à interagir en toute sécurité.

Q : Qu’est-ce que les « deepfakes » ?

R : Les « deepfakes » sont des images, des vidéos ou des enregistrements audio générés par l’intelligence artificielle et conçus pour imiter fidèlement des personnes réelles. Bien qu’ils aient des utilisations légitimes, ils peuvent également servir à usurper l’identité de personnes ou à commettre des fraudes.

Q : Qu’est-ce que le « zero trust » ?

R : Le « zero trust » est un modèle de sécurité fondé sur une vérification continue plutôt que sur une confiance automatique. Au lieu de considérer qu’un utilisateur ou un appareil est digne de confiance dès sa première connexion, les entreprises vérifient en permanence les identités et les actions.

Q : Qu’est-ce que l’IA « shadow » ?

R : Le terme « Shadow AI » désigne l’utilisation par les employés d’outils d’IA qui n’ont pas été approuvés ni régis par leur entreprise. Bien que souvent motivée par de bonnes intentions, cette pratique peut entraîner des risques en matière de sécurité, de confidentialité et de conformité.

Q : Pourquoi les entreprises ne devraient-elles pas simplement bloquer les outils d’IA ?

R : Les employés adoptent généralement l’IA car celle-ci les aide à travailler plus efficacement. Plutôt que d’interdire purement et simplement l’IA, les entreprises devraient mettre à disposition des outils approuvés, établir des politiques claires et sensibiliser leurs employés à une utilisation responsable.

Q : Quel est le principal enseignement à retenir de cet épisode ?

R : La confiance ne disparaît pas à cause de l’IA : elle évolue. Les organisations qui associent ressources humaines, politiques et technologies à un processus de vérification continue seront mieux à même d’adopter l’IA en toute confiance et de manière responsable.

Katherine Demacopoulos est directrice principale de la stratégie et des programmes de contenu mondiaux chez Commvault.

Notre directeur des produits, Rajiv Kottomtharayil, a récemment évoqué une évolution majeure qui se produit actuellement dans tous les secteurs. Les modèles d’IA de pointe réduisent le délai entre la découverte d’une vulnérabilité et son exploitation. Cette évolution incite les entreprises du monde entier à réexaminer leurs processus de gestion des vulnérabilités. C’est également ce que nous faisons chez Commvault. C’est pourquoi, à compter du 11 août, nous modifions la fréquence de nos communications relatives aux vulnérabilités. Ce qui change Nous plaçons la barre plus haut en matière de sécurité, de transparence et de confiance des clients. Le 11 août, puis chaque deuxième mardi du mois, nous lancerons les « Patch Tuesdays » : une publication mensuelle programmée au cours de laquelle nous diffuserons des avis de sécurité et des correctifs de vulnérabilités.  

Les « Patch Tuesdays » sont une pratique courante chez les grandes entreprises technologiques, car ils offrent aux clients un rythme de sécurité prévisible. Cela revêt d’autant plus d’importance que le rythme de découverte des vulnérabilités s’accélère. Bien entendu, si une vulnérabilité urgente doit être signalée en dehors de ce cycle, nous n’hésiterons pas à suivre nos processus bien établis.  

Où trouver des ressources à jour  

Chaque deuxième mardi du mois, vous trouverez de nouvelles informations concernant les CVE sur notre page « Avis de sécurité ». Vous pouvez également consulter les publications officielles sur le site CVE. Sur le Centre de sécurité Commvault, vous trouverez notre programme de gestion des vulnérabilités ainsi que d’autres réflexions de pointe sur la sécurité intégrée dès la conception.   

Pour consulter les certifications de conformité, les rapports d’audit et la documentation expliquant comment Commvault protège les données de ses clients, rendez-vous sur le Centre de confiance Commvault. Vous pouvez vous abonner aux mises à jour du Trust Center via le lien situé dans le coin supérieur droit de la page. Bill O’Connell est directeur de la sécurité chez Commvault. 

Depuis des décennies, les leaders du secteur technologique s’efforcent d’éliminer les silos. Des programmes de modernisation à part entière ont été mis en place dans le but de relier les applications, de regrouper les plateformes et d’offrir aux entreprises une vision plus complète de leurs données. Ces efforts ont apporté une valeur inestimable, mais ils ont également façonné notre façon d’envisager la résilience. Lorsqu’un problème survient, nous cherchons instinctivement à l’attribuer à une fragmentation technique. Or, nous avons constaté que le véritable défi réside ailleurs.

Les cloisonnements les plus importants qui nuisent aujourd’hui à la cyber-résilience ne se trouvent pas dans les bases de données ou les applications, mais dans les structures organisationnelles. Ils existent entre les équipes chargées de la sécurité et celles chargées de l’infrastructure, entre le service informatique et les métiers, ainsi qu’entre les personnes chargées de réagir à une attaque et celles chargées d’assurer la continuité des activités de l’organisation.

La dernière étude d’IDC consacrée au ResOps, intitulée «Resilience Operations : The Discipline that Makes Readiness Provable» (Opérations de résilience : la discipline qui permet de démontrer l’état de préparation), suggère que ces frontières organisationnelles sont devenues l’un des principaux obstacles à une reprise efficace. Cette observation tombe à point nommé, car les cyberattaques ont évolué d’une manière qui rend ces frontières de plus en plus difficiles à maintenir.

Les attaques modernes ne respectent pas l’organigramme de votre entreprise

Une cyberattaque moderne touche rarement un seul domaine technologique. Un incident de type « ransomware » peut commencer par la compromission d’identités, se propager à travers l’infrastructure d’ cloud , chiffrer des charges de travail critiques, perturber les applications destinées aux clients, affecter des services tiers et déclencher des obligations de déclaration réglementaires – le tout en l’espace de quelques heures. Chaque étape mobilise des équipes, des outils et des priorités différents. Pourtant, de nombreuses organisations continuent de se préparer à la reprise comme si ces responsabilités pouvaient être gérées séparément.

Les équipes de sécurité se concentrent naturellement sur le confinement des menaces et la préservation des preuves. Les équipes chargées de l’infrastructure donnent la priorité à la restauration des systèmes et à la réduction des temps d’arrêt. Les dirigeants se concentrent sur les clients, le chiffre d’affaires et la continuité opérationnelle. Les équipes de communication se préoccupent de la réputation, tandis que les équipes juridiques et de conformité se concentrent sur les obligations réglementaires. Chacun de ces points de vue est tout à fait raisonnable. Le problème survient lorsque ces priorités n’ont jamais été conciliées avant qu’un incident ne se produise.

En pleine crise, la reprise nécessite de prendre des décisions sous pression. Quelles applications doivent être rétablies en priorité ? Quelles données peuvent être restaurées en toute sécurité ? Quel niveau de Risk est acceptable avant la reprise des services aux clients ? Qui a le pouvoir de prendre ces décisions ? En l’absence d’alignement, les organisations constatent souvent que les retards les plus importants ne sont pas dus à la technologie, mais à l’incertitude – celle-là même qui pourrait être atténuée par une meilleure préparation.

La résilience commence par une définition commune de ce qui compte vraiment

Ce rapport met l’accent sur la mise en place d’un modèle d’entreprise minimal viable (MVB). À première vue, cela ressemble à un énième exercice de planification de la reprise, mais sa véritable valeur réside dans les discussions qu’il oblige les organisations à mener.

Pour définir un MVB, les dirigeants d’entreprise, les équipes de sécurité, les spécialistes des infrastructures et les responsables d’applications doivent s’accorder sur une question d’une simplicité trompeuse : qu’est-ce qui doit absolument continuer à fonctionner si tout le reste s’arrête ?

Cette réflexion modifie la nature même de la planification de la résilience. Les priorités en matière de reprise ne sont plus déterminées par le responsable d’application qui s’exprime de la manière la plus convaincante lors d’un incident. Elles sont désormais définies à l’avance, fondées sur les résultats opérationnels et étayées par des dépendances techniques compréhensibles par tous.

Mais surtout, le MVB crée un langage commun. Les dirigeants d’entreprise commencent à parler de capacités critiques plutôt que de systèmes individuels. Les équipes techniques commencent à mettre en correspondance l’infrastructure avec les résultats attendus par les clients plutôt qu’avec des architectures techniques. Les équipes de sécurité identifient plus clairement les actifs qui méritent les niveaux de protection les plus élevés pendant la Recovery. C’est précisément cette vision commune qui fait défaut à de nombreuses organisations.

La technologie peut automatiser la récupération, mais elle ne peut pas créer d’alignement

Le rapport ne soutient pas que les organisations aient besoin d’une énième plateforme. Il affirme qu’elles ont besoin d’une méthode de travail qui aligne les personnes, les processus et la technologie autour d’un objectif opérationnel unique. C’est là que ResOps – une discipline transversale – fait ses preuves.

La technologie peut aider à automatiser la Recovery, mais elle ne peut pas résoudre les désaccords concernant les priorités métier. Elle ne peut pas décider quels services clients sont les plus importants. Et elle ne peut pas se substituer à la gouvernance nécessaire pour coordonner plusieurs équipes lors d’un incident à forte pression. Ce sont là des défis en matière de direction, et la meilleure façon d’y faire face est de consacrer du temps à répondre ensemble aux questions difficiles, bien avant qu’une attaque ne vous oblige à agir.

Les organisations les plus performantes ne suppriment pas les cloisonnements : elles les relient entre eux.

Les cyberattaques continueront d’évoluer. L’IA continuera de réduire les délais d’exécution des attaques. Les nouvelles technologies introduiront de nouvelles dépendances, et de nouvelles menaces émergeront parallèlement. Rien de tout cela ne change l’exigence fondamentale en matière de résilience. Les organisations ne se relèvent pas parce que certaines équipes, prises isolément, réalisent des performances exceptionnelles, mais parce que ces équipes savent déjà travailler ensemble.

C’est peut-être là, en fin de compte, la conclusion la plus importante qui ressort de l’étude menée par IDC. La résilience n’est pas simplement le fruit d’une technologie plus performante ou de contrôles de sécurité plus sophistiqués. Elle résulte de priorités communes, d’une gouvernance claire et d’un modèle opérationnel éprouvé qui rassemble les bonnes personnes avant même qu’un incident ne se produise. Vidya Shankaran est directrice technique sur le terrain chez Commvault.

Points clés à retenir

• Un CVE est un identifiant unique au monde attribué à une vulnérabilité logicielle rendue publique, qui permet aux éditeurs, aux chercheurs et aux responsables de la sécurité de s’y référer de manière cohérente.
• L’approche adoptée par une organisation en matière de divulgation des vulnérabilités – notamment la mise en place de correctifs coordonnés, la collaboration avec les chercheurs et la tenue d’un inventaire précis des logiciels – constitue un indicateur fiable de sa maturité globale en matière de sécurité.
• Commvault assure la protection de ses clients grâce à un programme CVE caractérisé par la transparence, la régularité et la clarté. La manière dont les vulnérabilités CVE sont divulguées en dit long sur la maturité d’un programme de sécurité et d’ingénierie.

Pourquoi est-ce important ?

De nombreuses failles qui parviennent jusqu’au conseil d’administration trouvent leur origine dans des vulnérabilités logicielles. Le mécanisme utilisé par l’ensemble du secteur pour nommer et décrire ces vulnérabilités est le CVE(Common Vulnerabilities and Exposures). La manière dont un fournisseur, ou votre propre entreprise, gère les CVE est l’un des indicateurs les plus évidents de la maturité en matière de sécurité.

Une entreprise qui communique ses vulnérabilités et reconnaît équitablement le travail des chercheurs est généralement une entreprise qui prend au sérieux l’ingénierie sous-jacente. Cet article explique comment un CVE est créé, qui gère le système et ce qui distingue une divulgation exemplaire d’une divulgation médiocre.

Au-delà du CVE : pourquoi la philosophie de la divulgation est importante

La publication d’un CVE est un minimum indispensable. Les éléments qui font la différence sont les suivants : la transparence concernant la vulnérabilité et le correctif, la mise en place régulière d’analyses et d’applications de correctifs, ainsi qu’une communication claire. Commvault considère la divulgation comme une discipline d’ingénierie et de sécurité plutôt que comme une simple formalité de conformité : établir un rythme régulier pour la révision du code et la correction des failles, communiquer les mesures correctives dans un langage simple et clair, et protéger nos clients. C’est cette cohérence, plus que n’importe quel score isolé, qui témoigne de la maturité en matière de sécurité dans la divulgation des CVE.

Qu’est-ce qu’une vulnérabilité CVE, au juste ?

Un CVE n’est ni un correctif, ni un score, ni un logiciel malveillant. Il s’agit d’une entrée de dictionnaire qui attribue à une vulnérabilité spécifique et connue du public un nom permanent et unique, afin que chacun puisse s’y référer. L’identifiant lui-même respecte un format simple et stable : les lettres « CVE », l’année d’attribution de l’identifiant et un numéro d’ordre, par exemple « CVE-2021-44228 ».

L’ampleur du programme est considérable et ne cesse de croître : 48 000 CVE ont été publiés en 2025, soit environ 132 par jour, ce qui représente une hausse de plus de 260 % depuis 2020.

Anatomie d’un enregistrement unique

Les publications CVE doivent respecter un ensemble d’éléments standardisés. Leur lecture est aisée dès lors que l’on connaît la fonction de chaque partie :

• Identifiant : le numéro unique CVE-AAAA-NNNNN
• Description: explication concise de la vulnérabilité : en quoi elle consiste et comment un acteur malveillant pourrait l’exploiter.
• Produits et versions concernés: quels logiciels, matériels ou micrologiciels (et quelles versions) sont affectés, et quelles versions intègrent le correctif.
• Niveau de gravité : la catégorie de gravité sous-jacente.
• Références, liens vers l’avis du fournisseur, le correctif et les documents techniques.

Les acteurs secondaires : CVSS, CWE, EPSS et KEV

Quatre systèmes complémentaires permettent de faire d’un CVE une priorité pour l’entreprise. Il est facile de les confondre, il est donc important de bien distinguer chacun d’entre eux :

• Le CVSS (Common Vulnerability Scoring System) répond à la question « Quelle est la gravité de cette faille ? ». Le CVSS correspond à la note de gravité (sur une échelle de 1 à 10, 10 étant la plus grave) attribuée à la faille, et non à une évaluation de votre exposition spécifique.
• L’EPSS (Exploit Prediction Scoring System) répond à la question suivante : « Quelle est la probabilité que cette vulnérabilité soit exploitée prochainement ? » L’EPSS génère un score de probabilité, compris entre 0 et 100 %, qui estime la probabilité qu’une vulnérabilité soit exploitée au cours des 30 prochains jours.
• Le CWE (Common Weakness Enumeration) répond à la question « Quel type d’erreur en est à l’origine ? ». Le CWE classe la faille de codage sous-jacente.
• Le KEV (Known Exploited Vulnerabilities, ou « vulnérabilités connues exploitées ») répond à la question suivante : « Cette vulnérabilité est-elle actuellement exploitée contre des utilisateurs ? » Le catalogue KEV est une liste triée sur le volet de CVE dont l’exploitation dans le monde réel a été confirmée.

Un score CVSS élevé indique le degré de gravité d’une vulnérabilité, un score EPSS élevé indique la rapidité avec laquelle elle est susceptible d’être exploitée, et sa présence dans le catalogue KEV confirme qu’elle fait déjà l’objet d’une exploitation. Les meilleurs programmes de gestion des vulnérabilités prennent en compte ces trois critères.

FAQ

Q : Qu’est-ce qu’un CVE, et pourquoi est-ce important ? R : Un identifiant CVE (Common Vulnerability and Exposure) est un identifiant normalisé attribué à une vulnérabilité logicielle rendue publique. Il permet à tous – des éditeurs et chercheurs aux autorités de régulation et aux clients – de faire référence à la même vulnérabilité sans ambiguïté.

Q : Quelles informations un enregistrement CVE bien structuré doit-il contenir ?
R : Un enregistrement CVE complet doit comporter un identifiant unique, une description de la vulnérabilité, les produits et versions concernés, le niveau de gravité, ainsi que des références aux avis de sécurité ou aux correctifs des éditeurs. Ces éléments permettent aux organisations de comprendre leur exposition au risque et d’y répondre efficacement.

Q : En quoi le CVSS, le CWE, l’EPSS et le KEV diffèrent-ils d’un CVE ? R : Un CVE identifie une vulnérabilité spécifique, tandis que le CVSS en mesure la gravité, l’EPSS estime la probabilité d’une exploitation à court terme, le CWE classe la faille de codage sous-jacente et le KEV identifie les vulnérabilités activement exploitées dans le monde réel. Ensemble, ces référentiels contribuent à fournir le contexte nécessaire pour hiérarchiser les mesures correctives.

Q : Quels sont les critères pris en compte par Commvault dans ses propres pratiques de communication d’informations ? R : Commvault applique à ses propres communications les mêmes critères qu’elle attend des autres : transparence, régularité et clarté. C’est ainsi que Commvault protège ses clients.

Q : Quels sont les éléments que les dirigeants d’entreprise doivent prendre en compte lorsqu’ils évaluent les pratiques des fournisseurs en matière de gestion des vulnérabilités ? R : Les dirigeants doivent s’assurer que les fournisseurs disposent de calendriers de divulgation coordonnés, de registres CVE complets et précis, de consignes de correction claires, de programmes de reporting solides, ainsi que de la capacité à déterminer rapidement si leurs produits sont affectés par des vulnérabilités récemment divulguées. Ces caractéristiques témoignent d’une culture de sécurité forte et renforcent la résilience de l’organisation. Werner Nel est responsable principal de l’expérience produit chez Commvault.

Points clés à retenir

• « JadePuffer » est le nom que les chercheurs en sécurité de Sysdig ont donné à ce qu’ils ont identifié comme la première opération de type « ransomware » documentée, menée de bout en bout par un agent IA autonome, et non par un humain utilisant une boîte à outils.
• Les techniques utilisées n’étaient pas nouvelles. Ce qui a changé, c’est la rapidité d’exécution : l’agent a enchaîné les phases de reconnaissance, le vol d’identifiants, le déplacement latéral et le chiffrement destructeur, parvenant à corriger une tentative de connexion infructueuse en 31 secondes.
• L’agent a généré sa propre clé de chiffrement, qu’il n’a ensuite ni stockée ni transmise. Le paiement de la rançon n’aurait pas permis de récupérer les données.
• Les dommages réels ont visé l’état de configuration et les systèmes du plan de contrôle, et pas seulement les fichiers, ce qui correspond précisément à la couche que la plupart des plans de reprise ne couvrent pas.
• Se remettre d’une attaque de ce type implique de démontrer que l’entreprise est en mesure de reprendre ses activités en toute sécurité, et pas seulement de restaurer une sauvegarde.

Que s’est-il passé ?

Au milieu de l’année 2026, des chercheurs en sécurité de Sysdig ont mis en évidence une campagne de chantage qu’ils estiment être la première du genre : une opération de « ransomware » menée de bout en bout par un agent basé sur un grand modèle linguistique, avec une intervention humaine minimale au clavier. Ils l’ont baptisée « JadePuffer ».

Le point d’entrée était bien connu. L’attaquant a exploité la vulnérabilité CVE-2025-3248, une faille permettant l’exécution de code à distance sans authentification dans Langflow, un framework open source destiné à la création de workflows d’agents d’IA, dont la version était antérieure à la 1.3.0. À partir de là, l’agent a procédé à l’énumération de l’hôte, a recherché des identifiants auprès de fournisseurs d’ cloud , de fournisseurs de modèles d’IA et de bases de données, puis a discrètement copié la base de données interne de l’ platform.

Ce qui s’est passé ensuite mérite particulièrement notre attention. L’agent a analysé le réseau interne, a trouvé un magasin d’objets exposé et a extrait les fichiers d’état et de configuration de Terraform. Il a mis en place une tâche planifiée pour communiquer avec son serveur de commande toutes les 30 minutes. Il s’est ensuite tourné vers un système de production distinct exécutant MySQL et Alibaba Nacos, une plateforme de configuration et de découverte de services couramment utilisée dans les architectures de microservices.

Une fois à l’intérieur, l’agent a tenté de créer un compte administrateur dans Nacos. L’opération a échoué. Trente et une secondes plus tard, il avait identifié la cause de l’échec et réussi à atteindre son objectif en adoptant une approche différente. Il a ensuite utilisé les fonctions de gestion de fichiers de MySQL pour vérifier s’il pouvait aller plus loin, avant de chiffrer plus de 1 300 enregistrements de configuration, de supprimer les tables d’origine et de laisser une demande de rançon.

La clé de chiffrement a été générée à la volée, affichée une seule fois, et n’a jamais été stockée à un endroit où l’attaquant aurait pu la récupérer. Que cela ait été intentionnel ou non, le résultat pour la victime est le même : il n’y avait aucun moyen de revenir en arrière via l’attaquant ou une clé de déchiffrement, que la rançon ait été payée ou non. La restauration dépendrait de sauvegardes intactes, d’une reconstruction du système ou de points de restauration validés.

Pourquoi les chercheurs qualifient-ils cela d’« agentique » ?

Aucune des techniques décrites ici n’est nouvelle. Exploiter une vulnérabilité CVE non corrigée, collecter des identifiants, rechercher des possibilités de déplacement latéral, chiffrer des données à des fins d’extorsion : les équipes de sécurité ont déjà rencontré chacune de ces techniques. Ce qui a conduit Sysdig à classer cet opérateur comme un « agent » plutôt que comme un attaquant classique, c’est la manière dont ces différentes étapes s’articulent entre elles.

L’agent ne suivait pas un scénario prédéfini. Il analysait les résultats et s’adaptait en conséquence. Lorsqu’il s’attendait à recevoir une réponse au format JSON et qu’il obtenait du XML à la place, il modifiait son approche et poursuivait son exécution. Lorsque sa première tentative de création d’un compte administrateur a échoué, il a identifié la cause précise de l’échec et a essayé une autre approche, le tout en moins d’une minute.

Les chercheurs ont également découvert des commentaires intégrés dans les charges utiles, expliquant les cibles et les étapes suivantes dans un langage simple, un schéma qui correspond davantage au raisonnement d’un modèle de langage de grande envergure (LLM) effectuant une tâche qu’à celui d’un humain copiant-collant un kit d’exploitation connu. Les informations rendues publiques n’ont pas permis de confirmer quel modèle ou quelle « platform » était à l’origine de l’attaque. Ce qui est confirmé, c’est son comportement : une entité a raisonné, agi, s’est heurtée à un obstacle et a corrigé sa trajectoire plus rapidement que ne le permet la plupart des interventions humaines en cas d’incident.

Le problème de la récupération que trop de frameworks négligent encore

La plupart des guides de gestion des incidents liés à l’ransomware e reposent sur une hypothèse précise : vos fichiers ont été chiffrés, et la question est de savoir si vous pouvez restaurer une sauvegarde intacte ou si vous devez négocier une clé de déchiffrement.

JadePuffer remet en cause cette hypothèse de deux manières. Premièrement, il n’y avait aucune clé de déchiffrement à négocier. Deuxièmement, les dégâts ne se limitaient pas aux données. Ils concernaient également la couche de configuration et de plan de contrôle sous-jacente aux données : la plateforme de découverte de services, les secrets qu’elle contenait, l’état Terraform décrivant l’architecture de l’infrastructure, ainsi que les identifiants dispersés sur tous les systèmes que l’agent a touchés en chemin.

C’est un problème de restauration plus complexe que la simple « restauration de la base de données ». Une restauration « propre » des fichiers dans un environnement où les identifiants ont été renouvelés mais n’ont pas été vérifiés, où les dérives de configuration n’ont pas été examinées et où la couche d’identité n’a fait l’objet d’aucun nouvel audit ne constitue pas vraiment une restauration « propre ». Il s’agit simplement d’une nouvelle copie des données stockée dans un système qui ne peut toujours pas être considéré comme fiable.

Ce que cela implique pour votre stratégie de résilience

JadePuffer offre un aperçu de la question à laquelle tout plan de reprise devra tôt ou tard répondre : est-il possible de reprendre ses activités lorsqu’un attaquant a compromis non seulement vos données, mais aussi les systèmes d’identité, de configuration et de plan de contrôle dont ces données dépendent ?

Quelques pistes pour commencer :

Considérez les systèmes de configuration et de plan de contrôle comme essentiels à la Recovery, et pas seulement les applications. Les plateformes de découverte de services, les référentiels de secrets et l’état de l’infrastructure en tant que code sont aussi critiques pour l’entreprise que les bases de données qu’ils configurent. S’ils ne figurent pas encore dans votre plan de Recovery, c’est la première lacune à combler.

Intégrez la gestion des identifiants dès la phase de restauration, et non après. La restauration d’une charge de travail qui réintroduit des identifiants compromis ne met pas fin à l’incident ; elle remet le compteur à zéro. C’est cette même approche que Commvault applique aujourd’hui à l’infrastructure d’identité : une évaluation des vulnérabilités pour détecter les failles avant qu’un attaquant ne le fasse, un audit en temps réel pour repérer les modifications au fur et à mesure qu’elles se produisent, et une restauration en arrière pour annuler les modifications non autorisées sans avoir à tout reconstruire à partir de zéro.

Validez avant la restauration, pas après. Un point de restauration n’est utile que si vous êtes certain qu’il est « propre ». C’est le principe sur lequel repose Commvault® Cleanroom™: tester et valider les données dans un environnement isolé avant qu’elles ne rejoignent à nouveau l’environnement de production, plutôt que de s’en rendre compte après une réinfection.

Préparez-vous à une compromission du plan de contrôle, et pas seulement à un simple cas de chiffrement de fichiers. Une feuille de route de reprise conçue uniquement pour le scénario « fichiers chiffrés, restauration à partir d’une sauvegarde » ne tiendra pas la route face à un incident de ce type. La question la plus pertinente, et celle qui est au cœur des ResOps (opérations de résilience) en tant que discipline opérationnelle, est de savoir ce qu’il faut pour atteindre un niveau minimal de fonctionnement viable lorsque ce sont les systèmes sous-jacents à vos applications qui ont été touchés.

Rien de tout cela n’implique de considérer l’IA agentique comme une menace sans précédent qui nécessiterait de repartir de zéro. Il s’agit plutôt d’étendre la même approche axée sur la résilience, qui s’applique déjà à l’identité et aux données, jusqu’à la couche de configuration et de contrôle que les attaques agentiques ciblent désormais directement. Découvrez comment Commvault aborde la résilience des identités et la validation de la restauration propre.

FAQ

Q : Qu’est-ce que JadePuffer ? R : « JadePuffer » est le nom donné par Sysdig à ce qu’elle a identifié comme la première campagne d’ ransomware s documentée, menée de bout en bout par un agent IA autonome, plutôt que par un attaquant humain utilisant manuellement une boîte à outils.

Q : Les pirates ont-ils utilisé un modèle d’IA spécifique, comme ChatGPT ou Claude ? R : Les informations rendues publiques n’ont pas permis de confirmer quel modèle ou quelle « platform » a été utilisé(e). L’agent a recherché des clés API provenant de plusieurs fournisseurs d’IA, ce qui témoigne d’un intérêt pour ce type d’accès, mais ne permet pas d’identifier ce qui a servi de base à l’attaque elle-même. Q : Comment l’attaque a-t-elle commencé ?

R : La vulnérabilité CVE-2025-3248, qui permet l’exécution de code à distance sans authentification dans Langflow, un framework open source d’agents d’IA, affecte les versions antérieures à la version 1.3.0. Q : La victime aurait-elle pu payer la rançon pour récupérer ses données ? R : Non. La clé de chiffrement a été générée à la volée et n’a jamais été stockée ni transmise ; il n’y avait donc aucune clé à récupérer, quel que soit le montant du paiement.

Q : En quoi cela diffère-t-il d’un « ransomware » classique ? R : Les techniques utilisées n’étaient pas nouvelles. Ce qui a retenu l’attention, c’est la rapidité et la capacité d’adaptation : l’agent a détecté une tentative de connexion infructueuse et l’a corrigée en 31 secondes, un rythme plus proche de celui d’une machine que du comportement habituel d’un attaquant agissant à un rythme humain. Q : Quels enseignements les équipes chargées de la sécurité et de la reprise après sinistre doivent-elles en tirer ?

R : Cette planification de la reprise doit aller au-delà des données applicatives pour englober les référentiels de configuration, les plateformes de découverte de services, les secrets et les systèmes d’identité, c’est-à-dire la couche que JadePuffer a précisément ciblée pour causer un maximum de dégâts. Chris Bevil est responsable principal du marketing de portefeuille chez Commvault.

Points clés à retenir

• Des modèles d’IA avancés ont réussi à s’échapper d’un environnement d’évaluation restreint en exploitant des vulnérabilités jusque-là inconnues.
• OpenAI affirme que les modèles poursuivaient un objectif qui leur avait été assigné, sans agir avec une intention malveillante, mais qu’ils ont néanmoins provoqué un véritable incident de sécurité.
• Les mesures de contrôle traditionnelles, telles que le sandboxing et la segmentation, s’avèrent insuffisantes si l’IA parvient à trouver des voies inattendues pour les contourner.
• La cyber-résilience prend autant d’importance que la prévention.

Tout a commencé par une évaluation interne des capacités avancées de l’IA en matière de cybersécurité. Alors qu’ils tentaient de résoudre un test de performance aux critères très précis, les modèles d’OpenAI ont découvert une vulnérabilité « zero-day », ont contourné les restrictions prévues de leur environnement de test, ont élevé leurs privilèges, ont accédé à Internet et ont compromis l’infrastructure de Hugging Face. Ils considéraient les contraintes techniques qui les entouraient comme des problèmes à résoudre.

Il ne s’agissait pas d’une cyberattaque classique

C’est Hugging Face qui a été le premier à signaler qu’un cadre d’agent IA autonome avait compromis une partie de son infrastructure de production. Un ensemble de données malveillant a exploité deux voies d’exécution de code dans son pipeline de traitement des données, a obtenu un accès au niveau des nœuds, a récupéré des identifiants et s’est propagé latéralement à travers les clusters internes.

Les modèles concernés, notamment GPT-5.6 Sol et un modèle en préversion plus performant, fonctionnaient avec des restrictions de sécurité réduites et sans les classificateurs habituels utilisés en production. Ils sont allés bien au-delà de la mission qui leur était confiée, en exploitant une vulnérabilité de proxy pour accéder à Internet, puis en utilisant des identifiants volés et des vulnérabilités « zero-day » afin de trouver un moyen d’exécuter du code à distance sur les serveurs de Hugging Face.

Il n’était pas nécessaire qu’il y ait intention malveillante

Rien n’indique publiquement que les modèles aient développé une intention criminelle ou aient choisi de nuire à Hugging Face. Ils n’en avaient pas besoin. Donnez à un système performant un objectif, des outils, du temps et du retour d’information, et il contournera les obstacles. La discussion a désormais dépassé le stade des invites et des réponses erronées. Il s’agit de systèmes capables d’enquêter, de tester des hypothèses, de découvrir des vulnérabilités jusque-là inconnues, d’utiliser des identifiants volés, d’élever leurs privilèges et de continuer à fonctionner lorsque la première approche échoue.

Un bac à sable n’est pas un champ de force

Nous qualifions les environnements d’isolés, segmentés et en « sandbox », comme si cette étiquette suffisait à garantir la sécurité. Ce n’est pas le cas. Dans ce cas précis, l’accès direct à Internet était bloqué, mais un proxy accessible via un progiciel ne l’était pas, et les modèles ont exploité sa vulnérabilité pour s’échapper. Les politiques et les comportements attendus ne suffisent pas. C’est l’environnement technique lui-même qui doit faire respecter les limites.

Pourquoi il s’agit d’une histoire de résilience

L’activité s’est propagée depuis un environnement d’évaluation, en passant par l’infrastructure de recherche d’OpenAI, vers Internet, puis dans l’environnement de production de Hugging Face. Il s’agit là d’un rayon d’impact qui s’étend rapidement. Lorsque l’IA peut explorer et agir à la vitesse d’une machine, le délai entre l’accès initial et une compromission à plus grande échelle risque de continuer à se réduire.

Hugging Face ne s’est pas contenté de bloquer la voie d’accès initiale et de déclarer l’incident clos. L’entreprise a corrigé les failles permettant l’exécution de code, réinstallé les nœuds compromis, renouvelé les identifiants et les jetons, et renforcé les contrôles du cluster. L’objectif n’est pas simplement de rétablir le fonctionnement du système, mais aussi de restaurer la confiance.

La question n’est plus seulement : « Nos systèmes d’IA sont-ils sûrs ? » Elle est désormais la suivante : « Lorsqu’un système d’IA puissant découvre une voie dont nous ignorions l’existence, sommes-nous capables de limiter l’ampleur des répercussions, de poursuivre les opérations essentielles, de reconstruire ce en quoi nous n’avons plus confiance et de prouver qu’il est sûr d’aller de l’avant ? » Chris Bevil est responsable principal du marketing de portefeuille chez Commvault.

La sécurité ne s’arrête pas aux limites des systèmes propres à une organisation. Les entreprises modernes connectent un réseau toujours plus vaste d’applications tierces à leurs plateformes centrales afin de soutenir leurs activités de vente, de service et de collaboration. Chacune de ces connexions apporte une valeur ajoutée. Chacune d’entre elles introduit également une vulnérabilité que l’organisation ne maîtrise pas entièrement.

Ce risque n’est pas hypothétique. En juin 2026, un acteur malveillant a compromis des jetons OAuth liés à Klue, une « platform » de veille concurrentielle utilisée pour synchroniser les données commerciales et marketing avec Salesforce. L’attaquant a utilisé ces jetons pour accéder aux environnements Salesforce des nombreuses organisations ayant autorisé cette intégration, dont Commvault.

Dès que nous avons été informés d’un impact potentiel, notre équipe de sécurité a déclenché notre procédure de gestion des incidents afin de déterminer ce qui s’était passé, de limiter l’exposition au risque et d’évaluer si les informations des clients ou les services Commvault avaient été affectés. Notre enquête a révélé que cette activité se limitait à certaines informations relatives aux relations commerciales et aux ventes stockées dans notre environnement Salesforce. L’enquête n’a révélé aucun élément indiquant que les données de sauvegarde des clients, les données sur les produits, les métadonnées sur les produits, les journaux d’exploitation ou les services Commvault aient été affectés.

Agir rapidement quand il le faut

Notre intervention s’est déroulée conformément aux procédures établies en matière de gestion des incidents de sécurité, conçues pour limiter rapidement les risques tout en permettant la conduite d’une enquête approfondie. Dès que nous avons été informés de l’incident, nous avons désactivé l’intégration Klue, révoqué les droits d’accès associés et collaboré avec les parties concernées afin de mener une évaluation complète des faits. Tout au long de l’enquête, nos équipes se sont employées à déterminer quelles informations avaient été consultées, à vérifier l’intégrité de notre environnement et à s’assurer que l’incident restait confiné à la zone que nous avions déjà maîtrisée.

Une tendance à noter

Cet incident illustre parfaitement une tendance que les équipes de sécurité observent depuis plusieurs années : les pirates ciblent désormais les applications tierces connectées aux systèmes métier clés plutôt que de s’attaquer directement à ces derniers. Une seule intégration compromise peut offrir un accès privilégié aux environnements de nombreuses organisations en aval simultanément, souvent en rencontrant moins de résistance qu’une attaque directe contre l’une d’entre elles.

Cela modifie la nature même des mesures de défense qu’une organisation doit mettre en place. Des contrôles internes rigoureux restent nécessaires, mais ils ne suffisent plus à eux seuls. Ils doivent être associés à une surveillance active de chaque application à laquelle l’organisation se connecte, ainsi qu’à une capacité de réaction qui soit prête avant qu’un incident ne se produise, et non mise en place pendant celui-ci.

Renforcer la résilience au-delà de notre propre environnement

Chez Commvault, notre programme de sécurité comprend une évaluation continue des applications tierces connectées à notre environnement. Nous examinons régulièrement ces applications, évaluons les droits d’accès dont chacune dispose, surveillons l’apparition de nouveaux risques et réévaluons ces intégrations à mesure que les besoins de l’entreprise et le paysage des menaces évoluent. Lorsque les circonstances l’exigent, nous prenons des mesures pour réduire notre exposition et renforcer notre posture de sécurité, notamment en désactivant les intégrations qui ne répondent plus à nos normes.

Notre engagement en faveur de la transparence

La confiance se construit grâce à la transparence et à la responsabilité. Lorsqu’un événement touche nos parties prenantes, nous estimons qu’il est important de communiquer les informations dont nous disposons, d’expliquer comment nous avons réagi et de partager les conclusions de notre enquête, même lorsque cet événement trouve son origine en dehors de nos propres systèmes. Nous continuerons à évaluer nos mesures de sécurité, à affiner nos processus de gestion des incidents et à renforcer notre approche en matière de risques liés aux tiers, dans le cadre de notre engagement global à protéger nos clients et nos partenaires.

Pour obtenir les informations officielles concernant cet incident, notamment l’étendue de l’enquête et les conseils destinés aux clients, veuillez consulter les mises à jour de notre Centre de confiance. Will Galway est responsable adjoint de la sécurité des systèmes d’information chez Commvault.