Skip to content

Points clés à retenir

  • Mythos devrait permettre d’accélérer la détection des vulnérabilités à une échelle et à un rythme qui dépasseront ceux des processus de correction traditionnels, menés par des intervenants humains.
  • Les principes fondamentaux de la sécurité, tels que l’application des correctifs, les sauvegardes en environnement isolé et une gestion rigoureuse des vulnérabilités, restent essentiels, mais pourraient ne plus suffire à eux seuls.
  • Le principal défi consiste à passer de la détection à la capacité d’agir, alors que le nombre de vulnérabilités augmente de manière exponentielle et dépasse les limites opérationnelles actuelles.
  • La résilience de l’IA repose sur la capacité à rétablir des systèmes cohérents – et pas seulement des données – à travers les modèles, les pipelines et les autorisations.
  • Les organisations qui s’adaptent de manière proactive dès cette phase initiale auront probablement un avantage considérable par rapport à celles qui tardent à agir.

Il y a quelques semaines, je me trouvais dans une salle avec un groupe de DSI et de RSSI lorsque la conversation a dérivé sur Mythos et le projet Glasswing. L’enthousiasme a été immédiat : ce sont des personnes qui ont déjà connu de nombreux cycles de battage médiatique, et ce sujet a immédiatement retenu leur attention. Les réactions se sont divisées en deux camps. Premièrement : les catégories de menaces ne sont pas nouvelles ; les organisations disposant d’une gestion solide des vulnérabilités et de sauvegardes « air-gapped » fiables seront mieux placées que celles qui n’en disposent pas. Deuxièmement : la vitesse est différente – il ne s’agit pas seulement de ce que Mythos peut détecter, mais aussi de la rapidité avec laquelle les acteurs malveillants pourraient exploiter l’IA pour mener des attaques à la vitesse de la machine, et de l’impact que cela a sur les principes mathématiques sur lesquels reposent la plupart des programmes de gestion des vulnérabilités. Ils avaient tous les deux raison. C’est ce qui a rendu cette conversation digne d’être relatée.

Ce que « Mythos » change… et ce qu’il ne change pas

Mythos est le modèle d’IA développé par Anthropic pour la détection autonome des vulnérabilités. Il est capable d’identifier et d’enchaîner des exploits critiques sur les principaux systèmes d’exploitation, avec un taux de réussite qui, selon toute vraisemblance, est sans précédent dans ce domaine.

Le projet Glasswing – ce consortium d’entreprises chargé de tester et de renforcer la sécurité de leurs systèmes avant que Mythos ou des technologies similaires ne tombent entre les mains d’adversaires – montre clairement que cette menace est bien réelle, qu’elle est déjà là, et que le délai pour prendre les devants est court. Le principe fondamental reste valable : les correctifs sont essentiels, les sauvegardes pratiquement isolées (air-gapped) sont essentielles, la rigueur en matière de gestion des vulnérabilités est essentielle. Rien de tout cela ne change avec Mythos. Ce qui change, c’est le rythme de production de l’autre côté de ces programmes. Après l’affaire Glasswing, la question n’est plus de savoir si vous disposez d’un programme de gestion des vulnérabilités. Il s’agit plutôt de déterminer s’il a été conçu pour faire face à des découvertes qui arrivent au compte-gouttes… ou à un véritable tsunami. La plupart des programmes ont été conçus pour le compte-gouttes. Évaluations périodiques, files d’attente de priorisation basées sur le CVSS, cycles de correctifs et de tests mesurés en semaines. Ce rythme avait du sens lorsque la cadence des découvertes correspondait à celle des processus menés par l’homme. Les capacités de la classe Mythos remettent en cause cette hypothèse : le volume de vulnérabilités exploitables peut dépasser ce que la plupart des organisations sont en mesure de traiter via leurs workflows actuels. Le problème ne réside pas dans la détection. Il s’agit plutôt de la capacité à agir – et de ce qui se passe lorsque l’écart entre la détection et la correction se creuse plus vite que vous ne pouvez le combler.

Lorsque la prévention est mise à mal, la résilience prend le relais

Lorsque les délais de prévention sont raccourcis, la question de la résilience passe au premier plan. Si vous ne pouvez pas garantir que vous aurez appliqué tous les correctifs avant qu’une faille ne soit exploitée – et c’est de plus en plus souvent le cas –, les questions essentielles changent : à quelle vitesse détectez-vous la faille ? Comment la contenez-vous ? Et une fois la situation rétablie, à quel état précis revenez-vous exactement ?

Cette dernière question est plus complexe qu’il n’y paraît, en particulier pour les organisations dont les interactions entre agents sont évolutives. Un système d’IA n’est pas seulement constitué de données. C’est une version de modèle, un pipeline d’entraînement, une base de données vectorielle, un ensemble d’identités et d’autorisations d’agents – qui doivent tous refléter le même état opérationnel pour constituer un ensemble auquel vous pouvez réellement faire confiance. La plupart des organisations sont capables de restaurer des composants individuels. Très peu d’entre elles peuvent prouver que ce qu’elles ont restauré forme un tout cohérent.

La remise en état d’un système d’IA n’est pas un problème de restauration des données. Il s’agit d’un problème de cohérence – et c’est précisément dans cet écart entre ces deux aspects que la plupart des entreprises sont actuellement vulnérables. C’est ce fil conducteur qui relie Mythos au débat plus large sur la résilience de l’IA. Ce n’est pas que Mythos introduise un nouveau type de risque nécessitant un nouveau cadre.

En effet, Mythos condense la chronologie de telle sorte que les failles existantes apparaissent plus rapidement, laissant moins de temps pour les corriger avant qu’un incident ne se produise, ce qui augmente le risque qu’un incident survienne avant qu’une organisation ne puisse remédier correctement à ces vulnérabilités.

La fenêtre est ouverte. Ça ne va pas durer.

Glasswing a été conçu pour donner une longueur d’avance aux défenseurs. Les organisations qui exploitent délibérément cette fenêtre d’opportunité – en soumettant leurs programmes de gestion des vulnérabilités à des tests de résistance en termes de volume, en amenant leur infrastructure de résilience basée sur l’IA à un niveau leur permettant de se défendre, et en considérant la reprise comme un élément qui doit être démontrable avant un incident, et non mis en place pendant celui-ci – se trouveront dans une position nettement plus favorable que celles qui attendent. Les principes fondamentaux restent d’actualité. C’est l’urgence qui est nouvelle.

« L’entreprise agentique : pourquoi la résilience en matière d’IA nécessite un système d’enregistrement » – le dernier rapport « Readiness Report » de Commvault – examine les lacunes de l’infrastructure de résilience en matière d’IA qui déterminent si les organisations sont en mesure de répondre aux questions complexes liées à la reprise lorsque l’intensité des menaces l’exige.

FAQ

Q : Qu’est-ce que Mythos et en quoi est-ce important ?

R : Mythos est un modèle d’IA conçu pour la détection autonome des vulnérabilités, capable d’identifier et d’enchaîner des exploits d’un système à l’autre à une vitesse sans précédent. Son importance réside dans sa capacité à réduire considérablement le délai entre la découverte d’une vulnérabilité et son exploitation potentielle, ce qui rend la tâche des défenseurs d’autant plus difficile.

Q : Mythos modifie-t-il les principes fondamentaux de la cybersécurité ?

R : Non, les pratiques fondamentales telles que l’application de correctifs, les sauvegardes et la gestion des vulnérabilités restent essentielles. Ce qui change, c’est le volume et la vitesse des menaces, ce qui met à rude épreuve les processus existants, conçus pour des flux de travail plus lents et plus prévisibles.

Q : Pourquoi les programmes actuels de gestion des vulnérabilités peuvent-ils rencontrer des difficultés ?

R : De nombreux programmes ont été conçus pour traiter un flux régulier de résultats, et non pour faire face à l’afflux massif de vulnérabilités généré par la détection basée sur l’IA. Par conséquent, les entreprises sont confrontées à un décalage croissant entre l’identification des vulnérabilités et leur correction effective.

Q : Que signifie le terme « résilience » dans le contexte des systèmes d’IA ?

R : La résilience ne se limite pas à la restauration des données : elle implique la remise en état de l’ensemble d’un système d’IA dans un état cohérent et fiable. Cela suppose que les modèles, les pipelines d’entraînement, les bases de données vectorielles et les contrôles d’accès soient tous correctement alignés.

Q : Pourquoi la prise en charge devient-elle plus importante que la prévention ?

R : Les délais de prévention se raccourcissant en raison d’une exploitation plus rapide des failles, il devient irréaliste d’appliquer tous les correctifs à temps. L’accent est donc désormais mis sur la rapidité avec laquelle les organisations sont capables de détecter les incidents, de les contenir et de s’en remettre.

Q : Comment les organisations peuvent-elles commencer à se préparer ?

R : Les organisations peuvent soumettre leurs processus de gestion des vulnérabilités à des tests de résistance, moderniser leurs infrastructures de résilience et valider leurs capacités de reprise. Agir dès cette phase précoce leur confère un avantage stratégique significatif.

Tim Zonca est vice-président chargé de la gestion de portefeuille chez Commvault.

More related posts

Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more

Points clés à retenir

  • L’IA agentique engendre de nouveaux risques de sécurité, car elle planifie, mémorise et agit sur l’ensemble des systèmes, au lieu de s’arrêter après un seul cycle « invite-réponse ».
  • Des données d’entraînement « empoisonnées » peuvent influencer discrètement le comportement d’un modèle à grande échelle, même lorsque celui-ci semble encore fonctionner normalement lors des tests standard.
  • Des bases de données de vecteurs compromises peuvent influencer les décisions des agents en faussant le contexte sur lequel repose le modèle, ce qui donne l’impression que des comportements inappropriés sont légitimes.
  • L’identité des agents non gérés pose un problème de contrôle d’accès à la vitesse des machines que les systèmes d’identité traditionnels, centrés sur l’humain, ne sont pas conçus pour gérer.
  • Des décisions en cascade fondées sur un état erroné peuvent propager la corruption à plusieurs agents et flux de travail, ce qui complique considérablement la restauration et la reprise.

Les outils, contrôles et politiques de gouvernance mis en place par la plupart des entreprises ont été conçus pour des systèmes qui répondent à des questions : outils de recherche, copilotes, assistants génératifs. Des systèmes qui réagissent à une requête, puis s’arrêtent. Lorsqu’un problème survenait, la défaillance était isolée. Il suffisait de corriger la requête, d’ajuster la configuration, puis de passer à autre chose.

L’IA agentique ne fonctionne pas ainsi. Ces systèmes planifient, mémorisent et exécutent des actions à l’échelle de l’entreprise sans instruction humaine étape par étape. Ils conservent un état. Ils se coordonnent avec d’autres agents. Ils agissent sur les systèmes de production : ils écrivent dans des bases de données, déclenchent des workflows, prennent des décisions à la vitesse d’une machine. Cette évolution architecturale introduit quatre vecteurs de menace auxquels les dispositifs de sécurité existants n’ont jamais été conçus pour faire face. Si votre stratégie de gouvernance de l’IA n’en tient pas compte, vous êtes probablement exposé à des risques que vous ne pouvez sans doute pas détecter.

1. Données d’entraînement « empoisonnées »

La fiabilité d’un système d’IA dépend entièrement de la qualité des données sur lesquelles il a été entraîné. Cette affirmation a toujours été vraie. Ce qui a changé, c’est la surface d’attaque.

Dans les déploiements d’IA agentique, les pipelines d’entraînement sont plus volumineux, plus complexes et souvent assemblés à partir de multiples sources : données internes, flux tiers, ensembles de données fournis par des fournisseurs. Chaque dépendance de cette chaîne constitue un point d’injection potentiel. Un acteur malveillant capable d’influencer les données d’entraînement – par le biais d’une compromission de la chaîne d’approvisionnement, d’un accès privilégié ou de la contamination d’une source de données partagée – peut modeler le comportement du modèle à grande échelle. Ce qui rend cette situation particulièrement dangereuse, c’est que les modèles empoisonnés affichent souvent des performances normales lors des tests de performance standard. La manipulation peut être d’une précision chirurgicale : conçue pour produire des résultats spécifiques dans des contextes précis, tout en se comportant correctement dans toutes les autres situations.

Au moment où le problème se manifeste en production, le modèle est déjà utilisé depuis des semaines, voire des mois, et remonter à la source de la contamination nécessite précisément le type de traçabilité relationnelle des données dont la plupart des organisations ne disposent pas. La question à se poser est la suivante : êtes-vous en mesure de fournir un historique complet et vérifiable des données sur lesquelles vos modèles ont été entraînés, à un moment précis ?

2. Bases de données vectorielles compromises

Les bases de données vectorielles constituent la couche mémoire des systèmes agentiques. Avant d’agir, un agent interroge un magasin de vecteurs afin d’extraire le contexte pertinent (interactions passées, connaissances du domaine, données de référence) qui détermine la suite de ses actions. La plupart des équipes de sécurité ne considèrent pas les bases de données vectorielles de la même manière qu’elles considèrent les autres bases de données contenant des informations sensibles. Elles devraient pourtant le faire. Une base de données vectorielle compromise ne se contente pas de renvoyer des réponses erronées. Elle influence les décisions qui s’ensuivent. Des embeddings injectés – du contenu malveillant inséré dans le magasin de vecteurs – peuvent rediriger le comportement de l’agent d’une manière qui semble tout à fait légitime vue de l’extérieur.

Un agent chargé d’approuver une transaction récupère un contexte qui redéfinit subtilement les critères d’approbation. Un agent gérant les communications avec les clients extrait un contexte qui oriente les réponses dans la direction souhaitée par l’attaquant. L’action semble correcte. Le raisonnement semble solide. Mais le contexte sous-jacent a été manipulé.

Ce vecteur d’attaque est particulièrement difficile à détecter car il opère en dessous de la couche du modèle. Une surveillance standard du modèle ne le détectera pas. Le modèle se comporte exactement comme il a été entraîné – c’est le contexte à partir duquel il raisonne qui a été corrompu. La question à se poser est la suivante : votre base de données vectorielle est-elle considérée comme un actif de données sensible et soumis à des règles de gouvernance, avec des contrôles d’accès, une surveillance de l’intégrité et une journalisation des audits comparables à ceux de vos bases de données de production les plus critiques ?

3. Identité d’un agent non régi

Dans une architecture multi-agents, les agents n’interagissent pas seulement avec des données : ils interagissent entre eux. Ils créent des sous-agents, délèguent des tâches, demandent des résultats et synthétisent les résultats provenant d’agents auxquels ils n’ont jamais été explicitement connectés. Pour ce faire, ils s’authentifient, présentent leurs identifiants et établissent une relation de confiance.

L’identité des agents constitue la couche de contrôle d’accès de l’entreprise autonome – et il s’agit là d’une lacune que ni les fournisseurs de solutions de sécurité des identités ni les fournisseurs d’identité (IDP) ne comblent. Leurs cadres de gouvernance sont conçus pour l’identité humaine.

Les identités d’agents créées selon ces mêmes règles semblent tout à fait légitimes : elles ont été correctement provisionnées et respectent la politique en vigueur. L’IDP ne présente pas de défaillance ; il ne dispose tout simplement pas de cadre permettant de déterminer si un agent agit en dehors du contexte pour lequel il a été créé, s’il a bénéficié d’une élévation de privilèges à l’insu de tous, ou s’il coordonne des actions là où il ne devrait pas.

Cette faille présente une nature qualitativement différente de celle des compromissions classiques d’identifiants. Lorsqu’un utilisateur humain se fait voler ses identifiants, le pirate agit dans les limites des autorisations de cet utilisateur, à la vitesse d’un être humain. Lorsque l’identité d’un agent est compromise, l’attaquant accède à la couche de prise de décision autonome : il peut ainsi déclencher des flux de travail, approuver des actions, se coordonner avec d’autres agents et exfiltrer des données à la vitesse de l’ordinateur, à grande échelle, par le biais de canaux qui semblent tout à fait normaux.

Les défaillances au niveau de la couche d’identité comptent également parmi les plus difficiles à détecter a posteriori. Les actions d’un agent effectuées sous une identité compromise ne semblent pas anormales : elles ressemblent à un comportement légitime de l’agent. Et comme elles sont générées par un système plutôt que par un humain, leur volume peut atteindre des proportions énormes avant que quiconque ne s’en aperçoive.

Recovery aggrave le problème. La plupart des guides de Recovery en matière d’IA se concentrent sur la restauration des données : ensembles d’entraînement, poids des modèles, configurations des pipelines. L’identité figure rarement sur la liste. Un système restauré avec des données saines mais dont les configurations d’identité sont mal alignées n’est en réalité pas restauré. Il s’agit d’un système sain doté d’une couche d’accès corrompue. La question à se poser est la suivante : l’identité des agents est-elle gérée avec la même rigueur que celle des personnes, c’est-à-dire avec une gestion du cycle de vie, un accès selon le principe du moindre privilège et une intégration dans les plans de reprise ?

4. Une succession de décisions fondées sur une analyse erronée de la situation

Les trois premiers vecteurs d’attaque sont ponctuels. Celui-ci, en revanche, est systémique – et, à bien des égards, il peut s’avérer le plus difficile à maîtriser. Les architectures multi-agents sont conçues pour la coordination. Les agents partagent le contexte, se transmettent mutuellement leurs résultats et s’appuient sur le travail les uns des autres. C’est cette coordination qui fait leur puissance. C’est aussi ce qui provoque la propagation des défaillances.

Un agent fonctionnant sur une mémoire corrompue ne tombe pas en panne de manière isolée. Il produit des résultats – décisions, actions, données – que d’autres agents exploitent. Ces agents produisent à leur tour leurs propres résultats. Au moment où la corruption initiale se manifeste de manière observable, l’état défectueux peut avoir affecté des dizaines de processus en aval, impliquant plusieurs agents, sans qu’il soit possible de revenir en arrière de manière nette.

C’est ce qui rend le décalage contextuel si important. À tout moment, votre système d’IA se compose d’une version de modèle, d’un ensemble de données d’apprentissage, d’un référentiel d’artefacts, d’une configuration de pipeline et d’un ensemble d’interactions d’agents actifs – qui doivent tous refléter le même état opérationnel pour constituer un système fiable et récupérable. Lorsque ce n’est pas le cas, il ne s’agit pas simplement d’une erreur. Vous avez un système cohérent par fragments, mais incohérent dans son ensemble. Chaque outil ponctuel peut valider sa propre tranche d’informations. Aucun ne peut confirmer que ces éléments s’articulent entre eux. Il ne s’agit pas d’un problème de surveillance que l’on peut résoudre en ajoutant un outil supplémentaire. C’est une lacune structurelle – et la seule façon de la combler est de mettre en place un système qui capture l’état de l’IA de manière relationnelle : ce qui était en cours d’exécution, sur quelles données, avec quelle configuration, à quel moment.

La question à se poser est la suivante : si votre infrastructure d’IA venait à être compromise aujourd’hui, seriez-vous en mesure d’identifier avec précision l’état de chaque composant avant l’incident – et de le prouver ?

Ce que cela implique pour votre stratégie de sécurité

Chacun de ces quatre vecteurs nécessite une réponse défensive différente. Mais ils ont tous une conséquence commune : les cadres de gouvernance et de résilience conçus pour l’ère précédente de l’IA ne couvrent pas les modes de défaillance propres à l’ère des agents. Pour garantir la sécurité d’une IA agentique, il faut étendre votre cadre de travail dans trois directions :

  • Plus en profondeur, au cœur des couches de données et d’identité qui se trouvent sous le modèle.
  • Plus large, afin de couvrir les interactions entre agents qui échappent aux systèmes de surveillance existants.
  • D’un point de vue relationnel, il s’agit de saisir non seulement l’état de chaque composant, mais aussi la manière dont ils s’articulent entre eux à un moment donné.

C’est cette dernière exigence que la plupart des organisations n’ont pas encore prise en compte. Et c’est elle qui déterminera si, en cas de problème, vous disposez d’un système capable de se rétablir ou d’un ensemble de rapports en apparence fiables décrivant quelque chose qui n’existe plus. Lisez l’article « The Agentic Blind Spot : Why AI Resilience Demands a System of Record » pour découvrir pourquoi vous avez besoin d’un système d’enregistrement (SOR) afin de garantir la cohérence et l’exactitude de vos données d’IA.

FAQ

Q : Pourquoi les systèmes d’IA agentique présentent-ils plus de risques que les outils d’IA générative traditionnels ?

R : Les systèmes basés sur des agents ne se contentent pas de répondre à des invites. Ils gèrent l’état du système, coordonnent leurs actions avec d’autres agents et effectuent des opérations dans des environnements de production, ce qui élargit considérablement la surface d’attaque bien au-delà de la simple manipulation d’invites.

Q : Pourquoi les données d’entraînement « empoisonnées » sont-elles si difficiles à détecter ?

R : La manipulation peut être très ciblée, n’affectant que des situations spécifiques tout en laissant intacts les repères normaux. Cela signifie qu’un modèle peut sembler fonctionner correctement jusqu’à ce que le comportement malveillant se manifeste en conditions réelles d’utilisation.

Q : En quoi une base de données vectorielle peut-elle constituer un problème de sécurité ?

R : Une base de données vectorielle définit le contexte sur lequel s’appuie un agent avant d’agir. Si ce contexte est modifié, l’agent peut prendre des décisions qui semblent raisonnables à première vue, mais qui sont en réalité influencées par des données malveillantes.

Q : En quoi l’identité d’un agent diffère-t-elle de l’identité d’un être humain ?

R : L’identité d’un agent est liée aux actions autonomes, à la délégation et à l’exécution à la vitesse d’une machine. La gouvernance traditionnelle de l’identité étant conçue pour les personnes, elle ne permet souvent pas de détecter si un agent agit en dehors du contexte prévu.

Q : Pourquoi la propagation en cascade d’états indésirables constitue-t-elle un problème aussi grave dans les systèmes multi-agents ?

R : Dès qu’un agent utilise des données de sortie corrompues, cette erreur peut se propager aux agents et aux flux de travail en aval. Il n’en résulte pas seulement une mauvaise décision, mais toute une chaîne d’échecs en cascade.

Q : Comment les organisations peuvent-elles renforcer la sécurité de l’IA ?

R : Étendre la gouvernance aux couches de données et d’identité, surveiller les interactions entre agents et suivre l’état de l’IA de manière relationnelle afin de leur permettre de reconstituer le déroulement d’un incident.

Michael Thelander est directeur principal du marketing produit chez Commvault.

Blogs connexes

More related posts

Thumbnail_Blog-Data-Access-Governance-2026

Securing AI with Unified Data Access Governance

Read more
Thumbnail_Blog-Environmental-Footprint-AI-2026

Smarter Data, Greener AI

Read more
Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more
Thumbnail_Blog-AI-Agents-2026

AI Agents Are Everywhere. Do You Know What They’re Doing?

Read more
Thumbnail_Blog-Building-AI-Agents-2026

From Experimentation to Operation: Building AI Agents You Can Actually Trust

Read more

Points clés à retenir

  • Les systèmes d’IA agentique sont des systèmes à état qui fonctionnent en continu, ce qui rend les modèles de récupération traditionnels insuffisants.
  • La couche mémoire (bases de données vectorielles et stockage de contexte) constitue une surface d’attaque critique mais insuffisamment surveillée.
  • Les workflows de prise de décision en temps réel peuvent être modifiés sans déclencher les alertes de sécurité habituelles.
  • Les lacunes en matière d’observabilité dans les interactions entre agents empêchent la plupart des organisations d’avoir une vision complète des risques.
  • Une véritable récupération nécessite un enregistrement unifié et synchronisé dans le temps de toutes les couches du système afin de rétablir un état fiable.

La plupart des entreprises qui entrent dans l’ère de l’IA agentique gèrent la résilience en se basant sur un modèle mental erroné – et les données le confirment : seule une entreprise sur cinq dispose d’un modèle abouti pour régir les agents IA autonomes. Elles envisagent l’IA comme elles envisagent les applications : comme des entités distinctes, sans état, pouvant être remises en état en réintégrant des données saines dans un environnement sain.

L’IA agentique ne fonctionne pas ainsi. Ces systèmes sont avec état, fonctionnent en continu et sont organisés en couches d’une manière qui engendre des modes de défaillance que la plupart des cadres de sécurité et de résilience n’ont pas été conçus pour gérer. Le problème ne réside pas dans les outils. Il réside dans la compréhension de ce qui s’exécute réellement – et de ce que « Recovery » doit signifier pour des systèmes construits de cette manière.

Quatre couches architecturales définissent le problème. Chacune est distincte. Chacune est insuffisamment protégée. Et ensemble, elles expliquent pourquoi un système d’IA agentique peut sembler récupérable tout en restant fondamentalement compromis.

Couche 1 : Mémoire des agents – La surface d’attaque que vous ne surveillez pas

Les applications d’entreprise traditionnelles ne conservent aucune information d’une session à l’autre. Ce n’est pas le cas de l’IA agentique. La couche de mémoire – composée principalement de bases de données vectorielles stockant des représentations vectorielles, mais aussi l’état de la session et le contexte récupéré – est ce qui assure la continuité des agents d’une interaction à l’autre. C’est ce qui permet à un agent de reprendre là où il s’était arrêté, de s’appuyer sur le contexte antérieur et de se forger une vision cohérente d’un flux de travail complexe au fil du temps.

Il s’agit également de l’une des surfaces d’attaque les plus critiques de l’infrastructure moderne des entreprises – et l’une des moins surveillées. Le vecteur d’attaque est suffisamment subtil pour échapper à la plupart des outils de sécurité conventionnels. Un attaquant capable d’influencer ce qui est écrit dans une base de données vectorielle peut façonner ce que l’agent considère comme vrai. Les représentations injectées ou manipulées n’ont pas besoin d’avoir l’air malveillantes – elles doivent simplement paraître fiables.

Une mémoire compromise peut modifier le comportement d’un agent, permettre l’exfiltration de données par le biais des actions de l’agent ou amener ce dernier à prendre des décisions qui semblent légitimes mais qui servent les objectifs d’un attaquant. Aucune de ces actions ne nécessite d’intervenir directement sur le modèle lui-même. Le problème de détection est aggravé par le volume et la vitesse des écritures dans les bases de données vectorielles au sein des déploiements d’agents actifs. Les outils de détection d’anomalies conçus pour les données structurées ne s’adaptent pas bien à l’espace des représentations vectorielles. Le signal est bien là, mais la plupart des organisations ne sont pas équipées pour l’interpréter.

Ce qu’exige la résilience dans ce contexte : une surveillance continue de l’intégrité des bases de données vectorielles, et pas seulement des sauvegardes. Des représentations vectorielles soumises à un contrôle de version avec une chaîne de traçabilité vérifiable. La capacité d’identifier, à tout moment, le contenu exact de la couche mémoire – et de restaurer un état vérifié et propre, et pas seulement un état récent.

Couche 2 : Contrôle à l’exécution – Lorsque le flux de travail constitue une menace

L’IA agentique n’exécute pas de scripts prédéfinis. Elle planifie. Au moment de l’exécution, un agent reçoit un objectif, détermine les étapes nécessaires pour l’atteindre, sélectionne les outils dont il a besoin, puis passe à l’action – en créant souvent des sous-agents pour gérer des flux de travail parallèles. Le flux de travail est dynamique, construit à la volée et s’étend souvent sur une longue durée.

C’est ce qui rend l’IA agentique véritablement utile. C’est aussi ce qui rend sa protection véritablement difficile. Dans un environnement d’automatisation classique, un flux de travail « compromis » est limité. Il exécute les tâches pour lesquelles il a été configuré, puis s’arrête. Un flux de travail « agentique » compromis est différent : il s’adapte.

Si un attaquant parvient à influencer la couche de planification – par le biais d’une invite piégée, d’une réponse manipulée d’un outil ou d’un modèle de planification corrompu –, l’agent poursuivra l’objectif de l’attaquant en utilisant tous les outils et accès légitimes dont il dispose. Cela ressemblera à un fonctionnement normal. Les journaux, dans la mesure où ils existent, feront état d’appels d’outils autorisés. Prenons l’exemple d’un agent des achats chargé de valider les factures des fournisseurs au regard des clauses contractuelles. En fonctionnement normal, il vérifie les montants des factures, recoupe les seuils d’approbation et signale les exceptions pour qu’elles soient examinées par un humain. Un attaquant capable d’influencer la couche de planification – en manipulant la réponse d’un outil issue de la base de données des contrats – n’a pas besoin d’intervenir directement sur la logique d’approbation. Il lui suffit de fournir à l’agent un enregistrement de contrat dont les seuils ont été modifiés. L’agent planifie correctement à partir de données d’entrée corrompues. Chaque appel d’outil qu’il effectue est légitime. Chaque décision qu’il prend est erronée. Au moment où l’anomalie apparaît lors d’un rapprochement comptable, le workflow a déjà traité plusieurs semaines de factures et la piste d’audit ne fait état que d’actions autorisées.

Dans ces scénarios, le délai entre la compromission et la détection ne se mesure pas en secondes. Les workflows basés sur des agents fonctionnent en continu. Au moment où des résultats anormaux apparaissent, le workflow a peut-être déjà interagi avec des dizaines de systèmes, pris des centaines de décisions et laissé des modifications dans les environnements de production qui sont difficiles à recenser et encore plus difficiles à annuler.

Ce qu’exige la résilience dans ce cas : une surveillance en temps réel qui observe ce que les agents décident, et pas seulement ce qu’ils font. Des mécanismes d’intervention capables d’arrêter proprement un workflow en cours d’exécution sans provoquer de défaillances en cascade. Des guides de Recovery conçus pour les processus agentiques de longue durée – et pas seulement pour des transactions ponctuelles.

Couche 3 : Observabilité agentique – Le déficit de journalisation à la vitesse des machines

L’infrastructure de journalisation d’entreprise a été conçue pour des opérations à l’échelle humaine. Elle enregistre les activités des systèmes avec un niveau de détail et une latence adaptés à une analyse humaine. L’IA agentique fonctionne à une vitesse tout à fait différente.

Dans un déploiement multi-agents actif, les agents créent des sous-agents, se transmettent le contexte entre eux, appellent des outils et synthétisent des résultats – de manière continue, en parallèle, à un rythme plus rapide que celui pour lequel les pipelines de journalisation classiques ont été conçus. Les interactions qui revêtent le plus d’importance pour la sécurité – les communications entre agents, les transferts de contexte, les appels d’outils qui franchissent les frontières de confiance – sont précisément celles que les cadres de surveillance existants négligent le plus.

Aujourd’hui, seuls 17 % des entreprises surveillent en permanence les interactions entre agents. Les 83 % restants gèrent l’IA agentique en se basant sur une vision partielle : celle-ci rend compte des actions menées par chaque agent pris isolément, mais passe à côté de la couche d’interaction où se produisent les événements de sécurité les plus graves.

Ce n’est pas une lacune que l’on peut combler en augmentant le volume des données d’audit. Le problème ne réside pas dans la quantité de données collectées, mais dans le fait que les structures de données et les exigences en matière de latence des interactions agentiques ne s’intègrent pas bien dans les frameworks d’observabilité conçus pour des systèmes plus lents et plus structurés. Pour combler cette lacune, il faut soit disposer d’outils d’observabilité agentique spécialement conçus à cet effet, soit procéder à une adaptation en profondeur de l’infrastructure existante.

Ce qu’exige la résilience dans ce contexte : une visibilité de bout en bout sur les interactions entre agents, et pas seulement sur les résultats individuels de chaque agent. Des architectures de journalisation capables de fonctionner à la vitesse des agents sans perdre d’événements. La capacité de reconstituer a posteriori la séquence complète des décisions et des interactions des agents pour un flux de travail donné.

Couche 4 : Coordination multi-agents – Où se cachent les défaillances émergentes

Le risque le plus novateur sur le plan architectural dans le domaine de l’IA agentique ne provient pas d’un agent compromis en particulier. Il tient à la manière dont les agents dépendent les uns des autres – et à la façon dont les défaillances se propagent à travers ces dépendances avant que quiconque ne se rende compte qu’il y a un problème. Dans une architecture multi-agents, les agents partagent un contexte commun. Un agent orchestrateur transmet un cahier des charges à un sous-agent ; ce dernier renvoie un résultat que l’agent orchestrateur intègre dans sa décision suivante.

Si la sortie du sous-agent est corrompue – que ce soit en raison d’une couche mémoire compromise, d’une réponse d’outil manipulée ou d’un modèle de planification corrompu –, l’orchestrateur ne dispose d’aucun moyen natif pour le détecter. Il considère cette sortie comme faisant autorité. Il l’intègre. Il agit en conséquence. Et il transmet en aval sa propre sortie, désormais compromise.

Il s’agit là d’un mode de défaillance émergent : une corruption qui prend naissance dans une couche, se propage à travers les interactions entre agents et se manifeste sous la forme d’un résultat anormal dans un système situé à plusieurs étapes de la compromission initiale. Au moment où elle devient visible, la chaîne causale est longue et le rayon d’action est considérable.

Imaginons un pipeline de renseignements sur les menaces dans lequel un agent de collecte de données ingère des flux provenant de sources externes, un agent de classification les catégorise et leur attribue une note, et un orchestrateur intègre ces renseignements notés dans des recommandations relatives à la posture de sécurité transmises aux équipes en aval. Si la couche mémoire de l’agent de collecte de données est compromise – de manière subtile, par l’injection d’embeddings qui l’amènent à considérer certains acteurs malveillants comme présentant un faible risque –, l’agent de classification reçoit des données qu’il n’a aucune raison de remettre en question. Il effectue une classification précise sur la base des informations qui lui sont fournies.

L’orchestrateur intègre les résultats en toute confiance. Les équipes de sécurité en aval relèguent au second plan la catégorie de menace concernée, en se fondant sur ce qui semble être un consensus cohérent issu de plusieurs sources. La défaillance a pris naissance au niveau de la couche 1. Elle s’est manifestée au niveau de la couche 4. Aucun élément intermédiaire n’a signalé d’anomalie, car aucun élément intermédiaire ne disposait d’une visibilité sur l’ensemble de la chaîne.

Les cadres de gouvernance que la plupart des entreprises appliquent à l’IA ont été conçus pour les résultats des modèles – c’est-à-dire ce que dit l’IA. Les défaillances de coordination entre agents multiples ne sont pas des défaillances des résultats des modèles. Il s’agit de défaillances systémiques, découlant de la couche d’interaction entre les modèles, qui nécessitent un autre type de gouvernance : une gouvernance qui surveille et contrôle non seulement le comportement de chaque agent, mais aussi les relations de confiance entre les agents, l’intégrité du contexte lors de son transfert entre eux, ainsi que les droits d’accès qui régissent ce qu’un agent peut demander à un autre.

Ce qu’exige ici la résilience : une gestion de l’identité des agents qui considère la confiance inter-agents comme une préoccupation de sécurité de premier ordre. Une vérification de l’intégrité du contexte à mesure qu’il traverse les frontières entre les agents. Des politiques de gouvernance qui couvrent le comportement des agents autonomes – et pas seulement les résultats des modèles individuels.

Le problème relationnel qui relie ces quatre éléments entre eux

Ces quatre couches présentent des modes de défaillance distincts, mais elles partagent une vulnérabilité commune : aucune d’entre elles ne dispose d’un enregistrement commun indiquant comment elles s’articulent les unes par rapport aux autres à un moment donné.

Le registre des modèles sait quelle version est en cours d’exécution. La base de données vectorielle sait ce qui se trouve en mémoire. La couche d’orchestration sait quel flux de travail est actif. Le système d’identité sait quels agents disposent de quels accès. Chacun peut confirmer sa propre partie du tableau. Aucun ne peut confirmer si ces parties s’articulent entre elles – si elles reflètent le même état opérationnel, le même instant, la même configuration fiable.

C’est là que réside le fossé contextuel. Et c’est pourquoi la récupération après une compromission par une IA agentique n’est pas un problème de restauration des données. Il s’agit d’un problème de cohérence – un problème qui nécessite un enregistrement unifié des relations entre les couches, et pas seulement des composants eux-mêmes. Comblez cette lacune avant qu’un incident ne se produise, ou passez le temps nécessaire à essayer de la combler une fois l’incident survenu.

Les défis architecturaux abordés ici ne constituent qu’une partie de ce que les responsables de la sécurité et de la résilience doivent comprendre au sujet des risques liés à l’IA agentique. « L’angle mort de l’IA agentique : pourquoi la résilience de l’IA exige un système d’enregistrement » va plus loin en examinant où en sont réellement la plupart des entreprises en matière de préparation à la résilience de l’IA, à quoi ressemblent concrètement les lacunes de gouvernance, et ce qu’il faut pour que l’affirmation « notre IA est fiable » devienne une réalité démontrable, et non une simple déclaration.

FAQ

Q : Pourquoi la reprise après sinistre traditionnelle ne fonctionne-t-elle pas pour l’IA agentique ?

R : Les procédures de restauration traditionnelles partent du principe que les systèmes sont sans état et peuvent être restaurés à partir de sauvegardes « propres ». Les systèmes d’IA agentique conservent leur mémoire, évoluent au fil du temps et reposent sur des interactions à plusieurs niveaux, ce qui rend une simple restauration insuffisante pour rétablir la confiance.

Q : Qu’est-ce qui rend la couche de mémoire de l’IA agentique vulnérable ?

R : La couche mémoire stocke les représentations et les données contextuelles qui influencent les décisions de l’agent. Si elle est compromise, les attaquants peuvent subtilement manipuler ce que « croit » l’agent, ce qui conduit à des actions erronées mais apparemment légitimes.

Q : Comment les pirates peuvent-ils exploiter les flux de travail d’exécution dans l’IA agentique ?

R : Les attaquants peuvent influencer les données d’entrée de planification, les invites ou les réponses des outils, ce qui conduit les agents à exécuter des actions malveillantes en utilisant des processus légitimes. Ces actions apparaissent souvent comme normales dans les journaux, ce qui rend leur détection difficile.

Q : Pourquoi l’observabilité constitue-t-elle un défi dans les systèmes multi-agents ?

R : Les systèmes basés sur des agents fonctionnent à la vitesse de la machine et impliquent des interactions continues entre les agents. Les systèmes de journalisation traditionnels ne sont pas conçus pour capturer ni traiter ce niveau d’activité dynamique et à haute fréquence.

Q : Qu’entend-on par « défaillances émergentes » dans les environnements multi-agents ?

R : Les défaillances émergentes surviennent lorsqu’une petite faille au niveau d’un agent ou d’une couche se propage à l’ensemble des agents interconnectés, entraînant des problèmes à grande échelle dont il est difficile de remonter à la source d’origine.

Q : À quoi ressemble une récupération efficace pour une IA agentique ?

R : Une restauration efficace ne se limite pas à la récupération des données : elle nécessite un instantané cohérent de toutes les couches du système, y compris la mémoire, les flux de travail, les identités et les interactions, aligné sur un état vérifié et fiable.

Tim Zonca est vice-président chargé de la gestion de portefeuille chez Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Il est difficile de développer une entreprise axée sur les données. Mais en développer une tout en respectant les exigences du RGPD, en gérant des milliers de clients, en donnant les moyens d’agir aux équipes d’analyse et en mettant en place une nouvelle infrastructure en moins de deux semaines ? C’est un tout autre niveau de complexité.

Dans un épisode récent de STRIVE, j’ai rencontré Asif Dromi de monday.com et Ben Herzberg de Commvault pour décortiquer ce qu’il faut réellement pour mettre en œuvre la sécurité des données à grande échelle – non pas en théorie, mais dans la pratique. Il ne s’agit pas d’une conversation théorique sur les meilleures pratiques. C’est un aperçu concret de la manière dont les décisions en matière de sécurité, de conformité, d’automatisation et d’infrastructure s’entrecroisent lorsque le temps presse.

Regardez l’épisode dans son intégralité. Si vous êtes RSSI, responsable des données, architecte ou responsable de la conformité, cet épisode vous apporte bien plus qu’une simple théorie. Il vous montre comment :

  • Une entreprise en pleine croissance a su faire face aux exigences du RGPD sans freiner l’innovation.
  • L’approche « Infrastructure as Code » peut simplifier les audits.
  • L’automatisation réduit les risques au lieu d’accroître la complexité.
  • La sécurité et l’agilité opérationnelle ne sont pas nécessairement incompatibles.

Il est rare d’entendre directement le témoignage d’opérateurs qui ont mené ce type de projet dans des conditions réelles. C’est ce qui fait toute la différence de cette discussion STRIVE.

Points clés : Mise en œuvre de la sécurité des données à grande échelle

  • La conformité et la croissance ne sont pas nécessairement incompatibles. Monday.com montre comment les exigences du RGPD et une expansion rapide peuvent coexister lorsque la sécurité est intégrée dès le départ dans l’architecture.
  • Les autorisations manuelles ne sont pas évolutives. L’automatisation, oui. L’infrastructure en tant que code et les contrôles d’accès pilotés par API peuvent transformer la gouvernance, qui passe alors d’un goulot d’étranglement à un multiplicateur de force.
  • Les droits d’accès basés sur les rôles doivent évoluer au rythme de l’utilisation des données. À mesure que de plus en plus d’équipes s’appuient sur l’analyse de données, la visibilité et les contrôles précis deviennent essentiels pour éviter la prolifération des autorisations.
  • Une sécurité opérationnelle, c’est avant tout une question de visibilité. Il ne s’agit pas seulement de définir des politiques, mais aussi de surveiller, d’auditer et d’adapter les contrôles de manière dynamique à mesure que les environnements évoluent.
  • La rapidité est possible lorsque l’architecture est mûrement réfléchie. Un entrepôt de données conforme aux normes européennes a pu être mis en place en moins de deux semaines, car la gouvernance, l’automatisation et les outils avaient été conçus pour s’adapter à une évolutivité croissante.
  • La maturité en matière de sécurité favorise l’innovation. Lorsque les autorisations, l’infrastructure et la conformité sont programmables, les entreprises peuvent agir plus rapidement.

Le véritable défi : croissance, conformité et rapidité

Pour monday.com, le défi ne consistait pas seulement à stocker les données européennes en Europe. Il s’agissait plutôt de :

  • Assurer la conformité au RGPD et la résidence régionale des données.
  • Veiller à ce que les employés n’accèdent qu’aux données pertinentes.
  • Garantir la transparence et la traçabilité.
  • Accompagner les analystes et les développeurs qui avaient besoin d’un accès rapide.
  • Tout cela dans le cadre de délais très serrés.

Comme l’explique Asif dans cet épisode, le fait de devenir une organisation axée sur les données implique une expansion rapide des accès en interne. Plus les équipes s’appuient sur l’analyse des données, plus la gestion des autorisations devient complexe. Et c’est là que de nombreuses organisations se heurtent à un mur. La sécurité devient manuelle, les autorisations perdent de leur solidité et la conformité devient réactive. Ce n’est pas de la sécurité opérationnelle. C’est un château de cartes.

Intégrer la sécurité dès la conception de l’architecture 

L’un des aspects les plus intéressants de cet épisode réside dans la manière dont monday.com a abordé le problème d’un point de vue architectural. Au lieu d’intégrer la conformité a posteriori, l’entreprise a développé :

  • Un entrepôt de données européen dédié.
  • Des contrôles d’accès clairs, basés sur les rôles.
  • Modèles d’autorisation très détaillés.
  • Niveaux de gouvernance automatisés.

Ben décrit ce qui se passe dans de nombreuses grandes entreprises : au fil du temps, les autorisations s’accumulent en couches, souvent sans visibilité centrale. Au final, plus personne ne sait vraiment qui a accès à quoi. Rendre la sécurité opérationnelle, c’est éviter cette dérive. Cela implique de mettre en place des systèmes où la gouvernance s’adapte automatiquement à mesure que l’utilisation augmente.

L’automatisation est un multiplicateur de force

S’il y a un thème récurrent dans cet épisode, c’est bien l’automatisation. Au lieu de traiter les autorisations comme des tickets et des mises à jour manuelles, monday.com a intégré son infrastructure dans du code. Les bases de données, les rôles et les politiques d’accès pouvaient être créés et modifiés par programmation.

Le résultat ? Un environnement conforme et évolutif a été mis en place en moins de deux semaines. Ce n’est pas de la chance. C’est une question d’architecture. Et cela nous rappelle avec force que la sécurité ne vous ralentit pas lorsqu’elle est correctement mise en place. Elle favorise la rapidité.

Ce que signifie réellement la mise en œuvre de la sécurité des données

On utilise beaucoup le terme « opérationnalisation ». Dans cet épisode, il est défini comme suit :

  • Une visibilité permanente sur les données sensibles.
  • Gestion centralisée et automatisée des autorisations.
  • Suivi des accès.
  • Intégration avec des outils de collaboration.
  • Des politiques qui s’adaptent à mesure que le nombre d’utilisateurs et le volume de données augmentent.

Les contrôles statiques ne sont pas évolutifs. Les workflows manuels ne sont pas évolutifs. La sécurité doit devenir dynamique et s’intégrer au cœur même du fonctionnement de l’organisation. Et c’est précisément cette transition qui pose aujourd’hui problème à de nombreuses entreprises.

Regardez l’épisode complet de STRIVE

Au cours de cette discussion, vous en apprendrez davantage sur :

  • Comment monday.com a structuré son entrepôt de données européen.
  • Les principaux enseignements tirés de cette mise en œuvre rapide.
  • Pourquoi l’automatisation était une condition sine qua non.
  • Ce que les entreprises sous-estiment souvent à propos de la prolifération des autorisations.
  • Comment envisager la mise en œuvre de la gouvernance avant que les initiatives en matière d’IA ne prennent de l’ampleur.

Regardez-le dès maintenant.

FAQ 

Q : Comment les petites équipes peuvent-elles mettre en place une sécurité des données évolutive ?

R : Commencez par mettre en place un modèle d’autorisations clair et des outils d’« infrastructure as code ». Automatisez dès le départ la gestion des autorisations afin d’éviter les goulots d’étranglement liés aux opérations manuelles à mesure que votre entreprise se développe.

Q : Quel rôle joue l’automatisation dans la conformité ?

R : L’automatisation permet d’assurer la cohérence, de réduire les erreurs et de simplifier les audits. Grâce aux API et aux scripts, vous pouvez surveiller et ajuster les autorisations de manière dynamique.

Q : Combien de temps faut-il généralement pour mettre en place un environnement de données conforme et évolutif ?

R : Grâce à une bonne planification et à des outils adaptés, des entreprises comme monday.com y sont parvenues en moins de deux semaines. La rapidité dépend de l’ampleur du projet et de l’infrastructure existante.

Q : Quelles sont les meilleures pratiques pour mettre en œuvre la sécurité des données ?

R : Mettez en place des contrôles d’accès basés sur les rôles, automatisez la gestion des autorisations, surveillez régulièrement les journaux d’accès et intégrez des outils de sécurité aux plateformes de collaboration afin d’assurer une surveillance en temps réel.

Chris Mierzwa est directeur principal du marketing de portefeuille chez Commvault.

More related posts

Thumbnail_Blog-GoogleWorkspace-2026

Expanding Google Workspace Protection with Commvault eDiscovery

Read more
Thumbnail_Blog-Data-Leakage-Loops-2026

Are You Ready for Data Leakage Loops?

Read more
Thumbnail_Blog-Tornado-2025-Linkedin

The Trust Tightrope: Why New Yorkers Demand More from Businesses Than They Do from Themselves

Read more
Thumbnail_Blog_FinServ-Cybersecurity-2025

Modernizing Financial Cybersecurity: From Reactive to Resilient

Read more

Points clés à retenir

  • Les cadres de conformité codifient les enseignements tirés des échecs survenus dans la réalité et aident les organisations à renforcer leur résilience, leur gouvernance et leur stabilité opérationnelle.
  • Les organisations qui considèrent la conformité comme un moyen de renforcer la confiance peuvent contribuer à consolider la confiance des clients, les relations avec leurs partenaires et la crédibilité de leur marque.
  • L’harmonisation réglementaire et la mise en place de contrôles rigoureux en matière de risques peuvent contribuer à améliorer les résultats dans le secteur de l’assurance en démontrant une posture de sécurité mature et résiliente.
  • En établissant un lien entre les exigences de conformité et des résultats commerciaux mesurables, les organisations peuvent relier directement leurs investissements en matière de résilience à la protection de leur chiffre d’affaires et à la continuité de leurs activités.
  • Les capacités de cyber-résilience, telles que les sauvegardes immuables, la reprise rapide et les cadres de gouvernance, aident les organisations à transformer la conformité en avantage concurrentiel.

Dans les salles de réunion à travers l’Europe et au-delà, le terme « conformité » est devenu un mot chargé de sens. Il évoque des images de paperasserie sans fin, de pression réglementaire croissante et de la menace constante d’amendes.

RGPD. NIS2. DORA. Les acronymes se multiplient, et pour de nombreuses organisations, on a parfois l’impression d’étouffer sous le poids de la réglementation. Mais et si nous avions abordé la conformité sous le mauvais angle ? Et si la conformité ne consistait pas seulement à éviter les sanctions, mais aussi à bâtir une entreprise meilleure, plus solide et plus résiliente ?

L’analogie avec l’assurance : des règles qui existent pour une bonne raison

Il existe un parallèle intéressant entre la conformité et l’assurance. Lorsque vous assurez votre voiture, l’assureur fixe certaines conditions. Vos freins doivent fonctionner. Vos pneus ne doivent pas être usés. Un système d’alarme peut être exigé. Vous pouvez vous plaindre des inconvénients ou du coût, mais fondamentalement, ces règles existent parce qu’elles contribuent à réduire les risques. Elles contribuent à diminuer la probabilité d’accidents. Elles contribuent à vous protéger, vous et les autres.

Et voici le point essentiel : ces conditions sont généralement judicieuses, que vous souscriviez ou non à l’assurance. La réglementation fonctionne à peu près de la même manière. Les gouvernements et les régulateurs ne créent pas de cadres réglementaires par simple plaisir. Les réglementations sont des réponses à des défaillances concrètes : violations de données, perturbations opérationnelles, risques systémiques. Elles codifient des leçons apprises à la dure.

Vous pouvez trouver cela contraignant. Vous pouvez trouver cela frustrant. Mais quand on examine de près ce qu’exigent ces cadres, il est difficile de contester la validité de leurs principes fondamentaux.

  • Protéger les données des clients.
  • Renforcer la résilience opérationnelle.
  • Connaissez les risques liés à votre chaîne d’approvisionnement.
  • Être capable de se remettre d’incidents cybernétiques.
  • Faire preuve de bonne gouvernance et de responsabilité.

Aucune de ces idées n’est mauvaise.

De la prévention des amendes à l’instauration de la confiance

Trop souvent, la conformité est abordée sous un angle défensif : « Faites cela pour éviter une amende. » « Faites cela pour éviter la prison. » C’est un objectif bien modeste. Et c’est une occasion manquée. Quand on change de perspective, la conformité prend une dimension bien plus importante. Elle devient un vecteur de confiance.

Prenons l’exemple du RGPD. Fondamentalement, il s’agit de protéger les données à caractère personnel. Si votre organisation met en œuvre des pratiques solides en matière de protection des données – non pas simplement pour cocher une case, mais parce que vos systèmes protègent véritablement les informations de vos clients –, cela renforce la confiance. Les clients sont plus à l’aise pour faire affaire avec vous. Les partenaires sont plus disposés à s’associer à vous. Les autorités de régulation vous considèrent comme présentant moins de risques. La confiance n’est pas le résultat d’une réglementation. C’est un avantage commercial.

Il en va de même pour la loi sur la résilience opérationnelle numérique. Il ne s’agit pas seulement de signaler les incidents ; il s’agit d’être capable de résister aux perturbations et de s’en remettre. Dans un monde où les cyberattaques sont inévitables, la résilience n’est pas facultative. Elle est fondamentale pour la continuité, la réputation et la valeur à long terme. Lorsque la conformité favorise la résilience, celle-ci assure la stabilité de l’entreprise, et cette stabilité est le moteur de la croissance.

Réglementation et assurance : une boucle de rétroaction

Il existe également une complémentarité naturelle entre la réglementation et les marchés de l’assurance. Lorsque les régulateurs imposent certaines normes, les assureurs s’y conforment rapidement. Les organisations qui font preuve de conformité et de solides contrôles des risques sont plus attractives pour les assureurs. Elles peuvent bénéficier de meilleures conditions, d’une couverture plus étendue ou de primes plus avantageuses. Cela crée un cercle vicieux :

  • La réglementation fixe des normes minimales.
  • Les organisations renforcent leurs contrôles.
  • Les assureurs récompensent les attitudes plus prudentes face au risque.
  • Les marchés gagnent en stabilité et en résilience.

Dans ce contexte, la conformité devient un signal adressé au marché : nous prenons le risque au sérieux.

Le chaînon manquant : établir un lien entre la conformité et les résultats de l’entreprise

L’une des principales opportunités pour les organisations – en particulier les fournisseurs de technologies – consiste à mettre clairement en évidence le lien entre la conformité et la valeur ajoutée pour l’entreprise. Par exemple :

  • Si un produit permet de créer des sauvegardes inaltérables, cela contribue au respect des exigences réglementaires en matière d’intégrité des données.
  • Si cela permet une reprise rapide après des incidents cybernétiques, cela contribue à respecter les exigences en matière de résilience opérationnelle.
  • Si le système offre des pistes d’audit et des rapports clairs, cela contribue à répondre aux exigences en matière de gouvernance et de contrôle.

Mais il ne faut pas s’arrêter là. L’étape suivante consiste à mettre en avant les avantages pour l’entreprise :

  • Les sauvegardes immuables permettent de réduire l’impact des ransomware et de protéger le chiffre d’affaires.
  • Une reprise plus rapide permet de réduire au minimum les temps d’arrêt et de préserver la confiance des clients.
  • Une gouvernance solide contribue à réduire la surveillance réglementaire et renforce la crédibilité de la marque.

Cette mise en correspondance est essentielle. La conformité n’est pas un objectif en soi ; c’est le mécanisme qui permet d’atteindre les résultats qui comptent pour les entreprises : la continuité, la réputation, la confiance des clients et la différenciation concurrentielle.

La conformité comme source d’innovation, et non comme une simple obligation

On a souvent tendance à considérer la conformité comme une simple formalité à accomplir. Un centre de coûts. Un mal nécessaire. Mais si l’on se penche sur l’histoire, on constate que bon nombre de bonnes pratiques aujourd’hui considérées comme fondamentales pour l’informatique et la sécurité modernes trouvent leur origine dans des exigences réglementaires ou en matière d’assurance. Au fil du temps, elles se sont intégrées dans le mode de fonctionnement des organisations bien gérées. Le chiffrement. Les contrôles d’accès. La planification de la réponse aux incidents. Les tests de continuité d’activité. Gestion des risques liés aux tiers. À une certaine époque, ces éléments pouvaient être considérés comme des contraintes réglementaires. Aujourd’hui, ils constituent la condition sine qua non pour toute entreprise qui se respecte. Les organisations qui considèrent la conformité comme un catalyseur d’innovation – plutôt que comme une simple formalité administrative – sont souvent celles qui prennent une longueur d’avance. Elles intègrent la résilience dans leur architecture. Elles conçoivent leurs solutions en tenant compte de la gouvernance. Elles transforment les exigences réglementaires en fonctionnalités de produits et en propositions de valeur pour les clients.

Cyber-résilience : là où la conformité et la stratégie se rejoignent

C’est là que la cyber-résilience prend toute son importance. Les réglementations modernes reconnaissent de plus en plus une vérité simple : la prévention ne suffit pas. Des incidents se produiront inévitablement. Ce qui fait la différence, c’est la capacité d’une organisation à réagir et à se remettre sur pied.

La cyber-résilience – c’est-à-dire la capacité à résister aux perturbations cybernétiques, à s’en remettre et à s’y adapter – n’est plus seulement une question de sécurité. C’est un impératif stratégique. Elle favorise certes la conformité réglementaire, mais surtout, elle garantit la continuité opérationnelle et la confiance des entreprises. Lorsque les organisations investissent dans des architectures résilientes, des données immuables, des capacités de reprise rapide et des cadres de gouvernance solides, elles ne se contentent pas de satisfaire les exigences des autorités de régulation. Elles bâtissent des entreprises pérennes.

Une autre approche de la conformité

Il est peut-être temps de changer de discours. Au lieu de nous demander : « Quel est le minimum à faire pour nous conformer à la réglementation ? », nous devrions plutôt nous demander :

  • En quoi cette réglementation nous rend-elle plus forts ?
  • Quelle bonne pratique est codifiée ici ?
  • Comment pouvons-nous tirer parti de cela pour renforcer la confiance de nos clients et partenaires ?
  • En quoi cela constitue-t-il un avantage concurrentiel ?

Une bonne gestion de la conformité ne repose pas sur la peur, mais sur la prévoyance. Elle tient compte des enseignements tirés dans tous les secteurs d’activité. Elle intègre les meilleures pratiques dans les opérations quotidiennes. Et lorsqu’elle est clairement mise en relation avec les fonctionnalités des produits et les résultats commerciaux, elle devient un argumentaire commercial percutant.

Oui, la réglementation peut sembler contraignante. Oui, les acronymes se multiplient. Mais derrière toute cette paperasse se cache quelque chose de bien plus précieux : un cadre permettant de mieux gérer son entreprise. La conformité ne se résume pas à éviter les sanctions. Elle vise à renforcer la résilience. Et c’est cette résilience, en fin de compte, qui est le moteur d’une réussite durable. Découvrez ici comment Commvault assure la protection des données pour aider votre entreprise à respecter les exigences de conformité.

FAQ

Q : Pourquoi les organisations devraient-elles considérer la conformité comme bien plus qu’une simple obligation réglementaire ?

R : Les cadres de conformité reflètent souvent les meilleures pratiques élaborées en réponse à des incidents cybernétiques réels, à des défaillances opérationnelles et à des défis en matière de gouvernance. Les organisations qui adoptent une approche stratégique de la conformité peuvent contribuer à renforcer leur résilience, à améliorer la confiance et à créer de la valeur commerciale à long terme.

Q : En quoi la conformité contribue-t-elle à renforcer la confiance des clients ?

R : La mise en place de pratiques rigoureuses en matière de conformité démontre qu’une organisation prend au sérieux la protection des données, la gouvernance et la continuité des activités. Cela peut contribuer à renforcer la confiance des clients, à consolider les relations avec les partenaires et à positionner l’organisation comme une entreprise présentant moins de risques.

Q : Quel est le lien entre la conformité et la cyber-résilience ?

R : La réglementation actuelle met de plus en plus l’accent sur la capacité d’une organisation à se remettre des perturbations plutôt que sur leur simple prévention. Les investissements dans des infrastructures résilientes, des sauvegardes immuables et des capacités de reprise rapide peuvent aider les organisations à assurer la continuité de leurs activités en cas de cyberincidents.

Q : En quoi la conformité peut-elle avoir un impact positif sur l’assurance et la gestion des risques ?

R : Les assureurs ont souvent une opinion plus favorable des organisations dotées de programmes de conformité bien établis et de contrôles de sécurité rigoureux. Cela peut se traduire par de meilleures options de couverture, des conditions de contrat plus avantageuses et, éventuellement, des primes moins élevées.

Q : Pourquoi est-il important de relier les initiatives de conformité aux résultats de l’entreprise ?

R : Les efforts en matière de conformité sont particulièrement efficaces lorsque les organisations démontrent clairement en quoi les contrôles contribuent à la réalisation d’objectifs plus larges, tels que la protection du chiffre d’affaires, la réduction des temps d’arrêt et le maintien de la confiance des clients. Cela aide les dirigeants à considérer la conformité comme un investissement stratégique plutôt que comme un centre de coûts.

Q6 : Comment les organisations peuvent-elles transformer la conformité en avantage concurrentiel ?

R : Les entreprises qui intègrent la résilience, la gouvernance et la sécurité dans leurs produits et leurs activités peuvent se démarquer sur le marché. En s’alignant de manière proactive sur les exigences réglementaires, les organisations peuvent renforcer leur réputation et susciter davantage de confiance auprès de leurs clients et parties prenantes.

Darren Thomson est directeur technique sur le terrain chez Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Points clés à retenir

  • La souveraineté opérationnelle porte sur les personnes autorisées à accéder aux systèmes et sur les juridictions dont relèvent ces derniers.
  • L’accès des fournisseurs, les flux de télémétrie et les canaux d’assistance peuvent créer des failles cachées en matière de souveraineté.
  • La souveraineté opérationnelle est plus difficile à certifier, car elle nécessite une visibilité et un contrôle permanents.
  • Les organisations doivent être en mesure de démontrer et de documenter chaque voie d’accès aux environnements souverains.

Demandez à la plupart des organisations où se situe la plus grande force de leur programme de souveraineté, et la réponse reviendra généralement à l’une ou l’autre de ces deux notions : la localisation des données et le chiffrement. Elles savent où se trouvent leurs données principales. Elles ont mis en place des dispositifs de « bring-your-own-key » (apportez votre propre clé) ou de « hold-your-own-key » (conservez votre propre clé). Elles peuvent présenter des certifications.

Demandez-leur qui a accédé à leur environnement souverain au cours des quatre-vingt-dix derniers jours, depuis quels pays et sous quelles juridictions – et la confiance a tendance à s’évaporer. La souveraineté opérationnelle est le pilier le plus difficile à auditer, le plus susceptible d’être sous-estimé, et le domaine où, le plus souvent, une posture de souveraineté qui semble solide sur le papier s’effondre dans la pratique. Le rapport « Digital Sovereignty Readiness Report » la désigne comme l’un des quatre piliers – cet article va plus loin. La question à laquelle la plupart des organisations ne peuvent pas répondre : « Qui a accédé à votre environnement souverain au cours des 90 derniers jours, depuis quels pays et sous quelles juridictions ? »

Ce que signifie réellement la « souveraineté opérationnelle »

La souveraineté opérationnelle ne dépend pas de l’emplacement des données. Elle dépend de qui gère l’environnement – et de qui y a accès. Elle recouvre trois aspects que la plupart des programmes de souveraineté traitent comme des détails de mise en œuvre plutôt que comme des enjeux prioritaires :

  • Accès du personnel et juridiction. Toute personne ayant accès à votre environnement souverain – que ce soit à des fins d’assistance, de maintenance, de surveillance ou de gestion des incidents – relève d’une juridiction légale bien définie. Si un ingénieur d’assistance basé dans un pays soumis à une législation étrangère en matière d’accès aux données peut accéder à vos systèmes, la souveraineté de votre infrastructure n’est pas plus solide que ne l’est la protection juridique dont bénéficie cet ingénieur.

La plupart des organisations, lorsqu’elles procèdent à un audit de ce type pour la première fois, découvrent au moins un parcours d’accompagnement qui franchit une frontière territoriale qu’elles n’avaient pas répertoriée.

  • Accès des tiers et des fournisseurs. La limite de votre souveraineté s’étend à tous les fournisseurs, prestataires de services gérés et platform logicielles platform accès à votre environnement souverain. Plateformes ITSM, outils de surveillance, systèmes SIEM : si ceux-ci se situent en dehors de la limite de votre souveraineté mais ont accès à des données ou métadonnées qui s’y trouvent, il existe une faille que les contrôles de localisation des données ne peuvent combler.
  • Télémétrie, facturation et trafic du plan de contrôle. Les programmes de souveraineté des données se concentrent sur les données primaires. La souveraineté opérationnelle nécessite de cartographier la destination de toutes les autres données : la télémétrie générée par votre infrastructure, les métadonnées collectées par vos systèmes de surveillance, les données de facturation traitées par votre fournisseur. Ces flux peuvent franchir les frontières juridictionnelles même lorsque les données primaires ne le font pas – et ils sont rarement cartographiés.

Pourquoi ce pilier est plus difficile à certifier – et pourquoi cela a de l’importance

La localisation des données est relativement simple à documenter. Vous pouvez citer une région de stockage, un accord de résidence des données, un audit réalisé par un tiers. La souveraineté opérationnelle ne dispose pas de la même trace écrite. Il n’existe aucune certification garantissant le statut juridictionnel de chaque ingénieur de support susceptible d’accéder à votre environnement.

C’est précisément ce qui en fait à la fois le pilier le plus difficile à auditer et le plus important à mettre en place correctement. Cela est également directement lié au défi de la « souveraineté minimale viable » : pour appliquer les contrôles opérationnels adaptés aux charges de travail concernées, il faut savoir en quoi consistent ces contrôles – et c’est justement dans le domaine de la souveraineté opérationnelle que cette connaissance fait le plus souvent défaut.

La dimension « chaîne d’approvisionnement »

La directive NIS2, qui étend les obligations en matière de cybersécurité aux secteurs de l’énergie, des transports, de la santé et des infrastructures numériques, impose désormais aux organisations d’évaluer les pratiques de cybersécurité de leurs fournisseurs de technologies. Pour les programmes de souveraineté, cela a une implication directe : la posture des fournisseurs en matière de souveraineté n’est plus une simple considération dans le cadre des marchés publics. Il s’agit désormais d’une exigence soumise à audit.

Cela implique de poser de nouvelles questions à chaque fournisseur relevant de votre périmètre de souveraineté : Où se trouve votre personnel d’assistance ? Sous quelle juridiction opère-t-il ? Qu’adviendra-t-il de ses droits d’accès à mon environnement si votre entreprise est rachetée par une entité non européenne ?

À quoi ressemble la qualité ?

Un environnement opérationnel souverain présente quatre caractéristiques qui peuvent être démontrées, et pas seulement documentées :

  • Chaque voie d’accès à l’environnement souverain est répertoriée : il ne s’agit pas seulement des accès principaux, mais aussi des accès des fournisseurs, des services d’assistance et des systèmes de surveillance.
  • Le statut juridictionnel de chaque personne ou système disposant de cet accès est consigné et fait l’objet d’un audit à une fréquence définie.
  • Les flux de télémétrie, de métadonnées et du plan de contrôle sont recensés et soit confinés à l’intérieur des limites de la souveraineté, soit explicitement évalués et considérés comme hors champ.
  • L’organisation est en mesure de répondre à la question concernant l’accès dans un délai de quatre-vingt-dix jours – et ce, de manière précise, en s’appuyant sur des éléments de preuve.

Une dernière chose : la souveraineté opérationnelle ne se limite pas au contrôle d’accès. Si la reprise des activités nécessite l’intervention de personnel opérant en dehors de vos limites de souveraineté, votre dispositif échoue dès la survenue d’un incident. C’est le sujet du quatrième article de cette série. Le rapport sur l’état de préparation en matière de souveraineté numérique comprend une question d’évaluation directe portant sur la souveraineté opérationnelle.

FAQ

Q : Qu’est-ce que la souveraineté opérationnelle ?

R : La souveraineté opérationnelle concerne les personnes qui gèrent un environnement et y ont accès, notamment le personnel, les prestataires et les systèmes d’assistance. Elle va au-delà du simple lieu de stockage des données.

Q : Pourquoi la souveraineté opérationnelle est-elle souvent négligée ?

R : De nombreuses organisations se concentrent principalement sur l’emplacement et le chiffrement des données. Les voies d’accès, le personnel d’assistance et les flux de télémétrie ne font souvent pas l’objet d’un audit complet.

Q : Quel est l’impact des fournisseurs sur la posture en matière de souveraineté ?

R : Les fournisseurs et les prestataires de services gérés peuvent avoir accès à des systèmes sensibles ou à des métadonnées. Leurs juridictions et leurs pratiques opérationnelles peuvent avoir une incidence sur la conformité globale en matière de souveraineté.

Q : Pourquoi la télémétrie et les métadonnées sont-elles importantes ?

R : Même si les données primaires restent stockées localement, les données de télémétrie et les métadonnées peuvent franchir les frontières juridictionnelles. Ces flux peuvent entraîner des risques en matière de conformité s’ils ne sont pas gérés.

Q : En quoi consiste un modèle de souveraineté opérationnelle solide ?

R : Cela comprend les voies d’accès cartographiées, les contrôles réglementaires documentés, l’accès des fournisseurs soumis à des audits, ainsi qu’une visibilité sur l’ensemble des flux de télémétrie et de métadonnées.

Alex Zinin est vice-président et directeur général de la division « Fournisseurs de services gérés » chez Commvault.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Points clés à retenir

  • Les architectures souveraines privilégient souvent les audits et les contrôles d’accès au détriment de la préparation à la reprise après sinistre.
  • Le personnel chargé de la reprise après sinistre, les systèmes de secours et les modèles de conservation des données clés peuvent entraîner des failles en matière de souveraineté lors d’incidents.
  • Il est essentiel de mettre en place des contrôles cohérents entre les environnements de production et de reprise.
  • Une résilience adaptée aux exigences de souveraineté nécessite des procédures de reprise testées dans des conditions réalistes.

Imaginez la situation. L’attaque a déjà eu lieu. L’équipe d’intervention en cas d’incident se met en place. Quelqu’un doit décider quels systèmes rétablir en premier, dans quel ordre, en utilisant les points de reprise appropriés.

C’est alors que quelqu’un se rend compte que le personnel ayant accès au système de reprise est basé dans un autre pays. Pire encore, l’environnement de reprise lui-même (hébergé dans une cloud , un centre de données partenaire ou un site secondaire) n’a jamais été soumis aux mêmes contrôles de souveraineté que les données principales. Cette pratique n’était pas soumise aux mêmes contrôles de souveraineté que les données primaires. L’autorité de régulation demande des informations sur l’état d’avancement. Le temps presse.

C’est le scénario pour lequel la plupart des architectures souveraines n’ont pas été conçues – et celui que le rapport sur l’état de préparation à la souveraineté numérique met directement en évidence : la plupart des applications souveraines sont conçues pour l’audit, et non pour la gestion des incidents. La plupart des applications de sécurité sont conçues pour l’audit, et non pour la gestion des incidents. C’est au pire moment possible que cette différence se fait sentir.

L’angle mort de la relance dans l’architecture de la dette souveraine

Les programmes de souveraineté s’articulent autour du contrôle d’accès : qui peut accéder aux données, en vertu de quelle autorité, par quel chemin. Cette architecture est nécessaire. Elle n’est pas suffisante. Et elle est directement liée aux lacunes opérationnelles en matière de souveraineté abordées dans le troisième article de cette série : si les personnes qui gèrent votre environnement opèrent en dehors de vos limites de souveraineté, ce problème ne disparaît pas lors d’un incident. Il devient le problème.

Ce que le contrôle d’accès ne permet pas de résoudre, c’est la question la plus épineuse : que se passe-t-il après un incident, lorsque la reprise des activités n’est pas seulement une opération technique, mais aussi une procédure soumise à des contraintes juridiques ?

Ransomware visant une organisation européenne soumise à une réglementation ne se résume pas à un simple problème de restauration. Elle engendre un problème de restauration qui doit être résolu dans le cadre d’une juridiction donnée, par du personnel disposant des autorisations appropriées, à partir de points de restauration dont il peut être démontré qu’ils sont sains et n’ont pas été compromis. L’architecture souveraine conçue pour protéger les données peut compliquer la restauration si la résilience n’a pas été intégrée dès la conception initiale.

Les modes de défaillance spécifiques

Les causes d’échec des architectures de reprise souveraines sont prévisibles – et courantes :

  • Du personnel de Recovery situé en dehors des limites de la souveraineté. Les ingénieurs qui connaissent les systèmes de Recovery peuvent opérer dans une juridiction différente. Sous pression, faire appel à eux est la solution la plus simple. C’est également une violation de la souveraineté au moment où il est le moins opportun d’en commettre une.
  • Infrastructure de sauvegarde dépourvue de contrôles adaptés. Les environnements souverains principaux font l’objet d’un contrôle rigoureux. L’infrastructure de sauvegarde – en particulier les environnements plus anciens ou secondaires – n’est souvent pas soumise aux mêmes exigences en matière de souveraineté. Si les points de restauration sont stockés ou traités en dehors du périmètre, il n’est pas possible d’effectuer une restauration conforme à partir d’une infrastructure conforme.
  • La gestion des clés en situation de crise. Les dispositifs de gestion des clés par les utilisateurs eux-mêmes sont conçus pour un fonctionnement normal. En situation de crise – lorsque les systèmes principaux sont compromis et que le temps presse –, le modèle de gestion des clés qui fonctionne pendant une fenêtre de maintenance de routine peut devenir un obstacle à la reprise des activités. Si ce modèle n’a pas été testé, il s’agit d’une hypothèse, et non d’un dispositif de contrôle.
  • Lacunes de gouvernance entre les environnements. Les organisations opérant à plusieurs niveaux de souveraineté – c’est-à-dire la plupart d’entre elles – disposent souvent de contrôles rigoureux dans leurs environnements principaux, mais de contrôles moins stricts dans leurs environnements secondaires, qui font pourtant également partie du chemin de reprise. Les auditeurs s’attacheront à vérifier la cohérence sur l’ensemble du parc informatique. C’est précisément lorsque cette cohérence est la plus importante que les lacunes dans les environnements secondaires apparaissent au grand jour.

Pourquoi les contrôles de souveraineté peuvent compliquer la reprise

Les mêmes contrôles qui rendent un environnement souverain défendable face à un auditeur peuvent rendre la reprise plus difficile. Les restrictions de circulation des données qui empêchent l’exfiltration non autorisée limitent également l’orchestration de la reprise. Les accords de conservation clés qui garantissent qu’aucun fournisseur ne puisse accéder à vos données sans autorisation ajoutent également des frictions lorsque vous devez effectuer une restauration rapide.

Cela ne signifie pas pour autant que ces contrôles soient inadaptés. Cela signifie simplement qu’ils doivent être conçus dès le départ en tenant compte de la reprise après sinistre, et non pas ajoutés à une architecture où la reprise après sinistre n’a été envisagée qu’après coup. C’est là le cœur du principe de « souveraineté minimale viable » : l’adaptation des contrôles aux besoins réels inclut les exigences en matière de reprise après sinistre, et pas seulement celles relatives au contrôle d’accès.

Ce qu’implique une résilience adaptée à la souveraineté

  • Validation de la récupération propre. Prouver que les points de restauration ne sont pas compromis avant de restaurer l’environnement de production – qu’ils soient non seulement récents, mais aussi intacts. Dans un scénario de ransomware, une sauvegarde récente peut elle-même être compromise. La capacité à identifier et à restaurer à partir d’un point de restauration dont l’intégrité est avérée, validé avant d’être utilisé, est une exigence de souveraineté, et pas seulement une exigence de reprise après sinistre.
  • Gouvernance inter-environnements. Des contrôles de souveraineté et des preuves d’audit cohérents sur l’ensemble du parc informatique – et pas seulement au niveau du déploiement souverain principal. Chaque environnement du chemin de reprise doit répondre aux mêmes exigences que l’environnement principal.
  • Testé dans des conditions réalistes. Des exercices réguliers qui valident la reprise d’activité dans les conditions qui prévaudront réellement lors d’un incident : les contraintes juridiques applicables, le personnel disponible, les points de reprise d’activité opérationnels. Un test annuel de reprise après sinistre qui ne tient pas compte des contraintes liées à la souveraineté n’est pas un exercice adapté à la souveraineté.

La question à ajouter à votre bilan de souveraineté

Il existe un moyen simple de vérifier si votre architecture de reprise répond aux mêmes exigences de souveraineté que votre environnement de données principal : posez la question et exigez une réponse honnête. Êtes-vous en mesure de récupérer vos données souveraines, de manière propre, dans les limites de tolérance définies, en faisant appel à du personnel opérant à l’intérieur de vos frontières souveraines, dès maintenant – dans des conditions réelles, et non pas dans le cadre d’un exercice contrôlé ?

Pour la plupart des organisations, une réponse honnête met en évidence une lacune. Celles qui l’identifient dès maintenant – avant qu’un incident ne se produise – seront les mieux préparées à fournir des preuves lorsque l’autorité de régulation les leur demandera. Celles qui ne le font pas devront les constituer sous pression, devant les personnes qu’elles souhaitent le moins décevoir. Le rapport sur l’état de préparation à la souveraineté numérique comprend une question portant directement sur l’évaluation de l’architecture de reprise après sinistre.

FAQ

Q : Pourquoi la récupération est-elle importante pour la souveraineté numérique ?

R : La souveraineté est incomplète si les organisations ne peuvent pas récupérer les données dans le cadre des mêmes limites juridiques et opérationnelles que celles utilisées pour les protéger.

Q : Quelles sont les défaillances courantes en matière de Recovery souveraine ?

R : Parmi les défaillances courantes, on peut citer le fait que le personnel chargé de la reprise après sinistre opère en dehors des limites territoriales, l’absence de contrôles adaptés au niveau des infrastructures de secours, ainsi qu’une gouvernance incohérente d’un environnement à l’autre.

Q : En quoi la gestion des clés peut-elle compliquer la Recovery ?

R : Les modèles de gestion autonome des clés renforcent la sécurité en conditions normales d’exploitation, mais ils peuvent ralentir les opérations de reprise en cas d’incident s’ils ne sont pas correctement testés.

Q : Qu’est-ce que la validation de la Recovery « propre » ?

R : La validation de la restauration « Clean Recovery » permet de s’assurer que les points de restauration n’ont pas été compromis avant la restauration des systèmes. Cela revêt une importance particulière dans ransomware .

Q : Comment les organisations devraient-elles tester leur résilience en matière de souveraineté ?

R : Ils devraient mener des exercices réalistes tenant compte des contraintes juridiques, de la disponibilité opérationnelle et des points de reprise validés – et pas seulement des tests standard de reprise après sinistre.

Alex Zinin est vice-président et directeur général de la division « Fournisseurs de services gérés » chez Commvault.

More related posts

Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Points clés à retenir

  • La souveraineté minimale viable (MVS) consiste à appliquer le niveau de contrôle adéquat aux charges de travail concernées.
  • Traiter toutes les charges de travail de la même manière peut entraîner une complexité et des coûts inutiles, ou une protection insuffisante.
  • Les organisations se répartissent généralement en trois profils de souveraineté : les entités véritablement souveraines, les entreprises réglementées et les environnements hybrides multicloud.
  • Assurer une gouvernance cohérente dans des environnements mixtes constitue l’un des principaux défis opérationnels.

Il existe une version du débat sur la souveraineté numérique qui conduit les organisations vers une solution coûteuse, lourde sur le plan opérationnel et – si l’on est honnête – allant bien au-delà de ce qu’exigent leurs obligations réelles. La « souveraineté maximale » semble être une approche responsable. En pratique, il s’agit souvent d’un mauvais dosage.

Il existe une autre approche tout aussi courante qui conduit à une situation dangereusement précaire : des contrôles qui cochent toutes les cases d’une liste de contrôle, mais qui ne résisteraient pas à un audit, à un incident ou à un régulateur qui ne se contente plus d’une intention documentée comme preuve d’un contrôle effectif.

Les organisations qui gèrent correctement leur souveraineté ont tendance à adopter une approche plus rigoureuse et plus pratique que ces deux extrêmes : elles se demandent ce qu’elles doivent réellement, à qui et dans quel but. Elles s’organisent ensuite selon cette norme – ni plus, ni moins.

C’est là la discipline du MVS, présentée dans le rapport « Digital Sovereignty Readiness Report » et développée en détail ici.

Le MVS n’est pas un raccourci. C’est la reconnaissance que l’objectif est le bon niveau de contrôle, appliqué de manière cohérente à toutes les charges de travail qui le nécessitent.

Toutes les charges de travail ne se valent pas

Le point de départ d’une approche MVS est la classification des charges de travail – et la plupart des organisations l’ignorent complètement.

Un système de négociation traitant des données financières réglementées implique des obligations de souveraineté fondamentalement différentes de celles d’un outil interne de collaboration RH. Une base de données contenant des données à caractère personnel de citoyens de l’UE est soumise à un régime juridique et réglementaire différent de celui d’un environnement de développement exécutant des données de test anonymisées.

Traiter toutes ces charges de travail de la même manière – soit en appliquant systématiquement des contrôles de souveraineté maximaux, soit en partant du principe qu’un modèle de déploiement unique couvre tous les cas de figure – conduit les organisations soit à une architecture surdimensionnée, soit à une protection insuffisante.

La bonne question à se poser avant toute décision de déploiement est la suivante : quels sont les besoins de cette charge de travail au regard de chacun des quatre piliers de la souveraineté ? Le rapport Readiness comprend une auto-évaluation structurée autour de cette question précise.

Les trois profils – et ce dont ils ont réellement besoin

Les entreprises réglementées se répartissent en trois profils distincts, chacun ayant des motivations principales et des priorités d’investissement différentes.

  • Le véritable défenseur de la souveraineté. Les agences gouvernementales, les sous-traitants du secteur de la défense et les opérateurs d’infrastructures nationales critiques. Pour ces organisations, la souveraineté n’est pas une simple exigence de conformité : c’est un impératif opérationnel. Un contrôle maximal sur chaque dimension de la pile technologique est souvent imposé par la loi, et les compromis en termes de coûts sont acceptés car l’alternative ne l’est pas.
  • L’organisation réglementée. Les sociétés de services financiers, les organismes de santé, les entreprises du secteur de l’énergie. Ces organisations sont soumises à des exigences contraignantes issues de la DORA, de la directive NIS2, du RGPD et de cadres réglementaires spécifiques à leur secteur. Les obligations de conformité peuvent également s’inscrire dans le cadre de programmes de certification de l’UE – notamment EUCS, EUCC, BSI C5 et SecNumCloud – en fonction du secteur et du contexte de déploiement.

Ces exigences sont non négociables dans certains domaines – notamment en matière de résidence des données, de contrôles d’accès opérationnels et de Recovery dans les limites juridictionnelles. Mais toutes les charges de travail ne sont pas soumises aux mêmes obligations.

  • L’organisation hybride multi-cloud. Les organisations ayant déjà investi dans des hyperscalers et confrontées à une pression croissante en matière de souveraineté de la part des clients, des régulateurs ou des exigences d’approvisionnement. Leur défi ne réside pas dans une migration en bloc, mais dans la mise en place de contrôles souverains au sein d’un environnement mixte et le maintien d’une gouvernance cohérente à l’échelle de celui-ci.

Le coût d’un mauvais équilibrage

Une approche excessive de la souveraineté engendre ses propres risques opérationnels. Les organisations qui appliquent un maximum de contrôles souverains à des charges de travail qui n’en ont pas besoin supportent des coûts et une complexité qui ne servent aucun objectif réglementaire ou commercial.

La sous-ingénierie est le mode de défaillance le plus courant, et le plus dangereux. Elle ne se révèle généralement qu’au moment de l’audit – ou, plus grave encore, lorsqu’un incident survient et que Recovery devient un problème soumis à des contraintes juridiques. (Ce mode de défaillance fait l’objet du quatrième article de cette série.)

Un point de départ pratique

Une approche MVS suit trois étapes :

  1. Classez les charges de travail en fonction de leurs exigences réelles en matière de souveraineté pour chaque pilier – ne partez pas des modèles de déploiement.
  2. Associez chaque classe de charge de travail au niveau de déploiement qui répond à ces exigences, sur l’ensemble du spectre allant des régions des hyperscalers publics au cloud public souverain, en passant par les environnements gérés sur site.
  3. Gérer de manière cohérente l’environnement mixte ainsi constitué : les contrôles, les preuves d’audit et les capacités de Recovery doivent être démontrables dans l’ensemble de l’environnement, et pas seulement au niveau le plus souverain.

C’est à la troisième étape que la plupart des programmes rencontrent des difficultés. Le maintien de contrôles de souveraineté cohérents dans un environnement mixte constitue un défi de gouvernance opérationnelle – et relève plus particulièrement du domaine de la souveraineté opérationnelle –, sujet du troisième article de cette série, le pilier que la plupart des stratégies traitent comme une considération secondaire.

Utilisez l’auto-évaluation du Rapport sur l’état de préparation à la souveraineté numérique pour évaluer votre situation actuelle sur l’ensemble des quatre piliers.

FAQ

Q : Qu’est-ce que la souveraineté minimale viable (MVS) ?

R : La MVS consiste à appliquer des contrôles de souveraineté en fonction des besoins réels de l’entreprise et des exigences réglementaires. Elle vise à éviter à la fois une ingénierie excessive et une protection insuffisante.

Q : Pourquoi la classification des charges de travail est-elle importante ?

R : Les différentes charges de travail entraînent des obligations réglementaires et opérationnelles différentes. La classification des charges de travail aide les organisations à appliquer le niveau approprié de contrôles de souveraineté.

Q : Quels sont les trois profils de souveraineté courants ?

R : Les trois profils sont les organisations pleinement souveraines, les organisations réglementées et les organisations hybrides multi-cloud. Chacun d’entre eux présente des exigences opérationnelles et de conformité distinctes.

Q : Quels sont les risques liés à une conception trop complexe de la souveraineté ?

R : Des contrôles excessifs peuvent accroître la complexité opérationnelle et les coûts sans pour autant apporter de valeur ajoutée significative en matière de conformité ou d’activité.

Q : Pourquoi les environnements mixtes posent-ils des défis en matière de gouvernance ?

R : Les organisations opèrent souvent sur plusieurs modèles de cloud et d’infrastructure. Il est difficile de maintenir des contrôles, des preuves d’audit et des normes de Recovery cohérents dans tous les environnements.

Ruben Renders est directeur des solutions MSP chez Commvault.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

Points clés à retenir

  • La « résidence des données » désigne le lieu où celles-ci sont stockées, mais la souveraineté numérique implique également le contrôle de l’accès et des opérations, ainsi qu’une bonne compréhension des implications juridictionnelles.
  • La souveraineté opérationnelle est souvent l’élément le plus fragile et le moins contrôlé de la plupart des programmes de souveraineté.
  • Une approche globale en matière de souveraineté repose sur quatre piliers : la localisation des données, la souveraineté technologique, la souveraineté opérationnelle et la souveraineté juridictionnelle.
  • La souveraineté n’est pas une notion binaire ; les organisations doivent définir une approche adaptée à leurs obligations réglementaires et opérationnelles.

Voici une question qui mérite réflexion : lorsque votre organisation a pris sa décision en matière de souveraineté, qu’a-t-elle décidé exactement ? Pour la plupart, la réponse revient au même. Choisir une région. Déplacer les charges de travail. Choisir un fournisseur de cloud disposant de centres de données dans le pays. Cocher la case. La question de l’emplacement des données a trouvé une réponse, et le débat sur la souveraineté a été considéré comme clos.

Mais ce n’était pas fini. Ça venait à peine de commencer. La localisation des données répond à une question : « Où ? ». La souveraineté numérique en pose trois autres : « Qui ? », « Comment ? » et « Dans quelles conditions ? ». L’amalgame entre résidence et souveraineté est compréhensible. Les hyperscalers ont donné l’impression que le choix d’une région relevait d’une décision de souveraineté. Les listes de contrôle de conformité demandent où les données sont stockées. Les recommandations réglementaires, du moins dans leurs premières versions, mettaient fortement l’accent sur la géographie.

Le choix d’une cloud souverain est une décision importante : elle a des implications opérationnelles et constitue une première étape indispensable. Mais ce n’est qu’une première étape. Et la plupart des entreprises s’en sont tenues là.

Ce à quoi « Residency » ne répond pas

Voyez les choses ainsi : choisir une région cloud souveraine, c’est comme acheter un coffre-fort. Cela vous indique où vos objets de valeur sont stockés. Cela ne dit rien sur qui détient une copie de la combinaison, qui a fabriqué le coffre-fort, quelles lois régissent le fabricant, ni si vous pouvez l’ouvrir en cas de contrainte.

Le choix de la région répond à une question. Trois autres restent entièrement en suspens – et ce sont précisément ces questions que les autorités de régulation, les comités d’appel d’offres et les auditeurs posent désormais avec une précision croissante :

  • Qui peut exploiter votre environnement, et depuis où ? La question de savoir si le personnel d’assistance de votre fournisseur de cloud est soumis à une juridiction étrangère est une question de souveraineté que la résidence des données ne peut résoudre. Une fenêtre de maintenance de routine effectuée par un ingénieur d’assistance dans une juridiction différente constitue une voie d’accès que votre politique de résidence ne couvre pas. C’est là le domaine de la souveraineté opérationnelle – le pilier le plus difficile à auditer et le plus souvent négligé.
  • Dans le cadre de quel régime juridique vos données peuvent-elles être consultées ? Le fait qu’un fournisseur de technologies étranger exploite une infrastructure sur le territoire national ne le soustrait pas automatiquement à l’application de la législation de son pays d’origine. La portée extraterritoriale des régimes juridiques étrangers constitue un risque que la seule situation géographique ne suffit pas à éliminer.
  • Pouvez-vous récupérer vos données en cas de problème ? La plupart des programmes de souveraineté s’articulent autour du contrôle d’accès. Très peu abordent la question de la récupération : vos données peuvent-elles être restaurées proprement, dans des limites définies, par du personnel opérant à l’intérieur de vos frontières de souveraineté ? C’est sur cette lacune que les stratégies de souveraineté échouent le plus souvent dans la pratique.

Le cadre qui comble cette lacune

Une stratégie globale en matière de souveraineté repose sur quatre piliers interdépendants. Le rapport sur l’état de préparation à la souveraineté numérique – disponible sur readiverse.com – les passe en revue en détail. En bref :

  • La localisation des données désigne les chemins empruntés par les données et les métadonnées.
  • La souveraineté technologique englobe le contrôle du chiffrement, de la conservation des clés et de la portabilité de l’architecture.
  • La souveraineté opérationnelle concerne la question de savoir qui gère l’environnement et depuis quel endroit.
  • La souveraineté juridictionnelle définit le cadre juridique qui régit et influe sur tous les éléments susmentionnés.

Aucun pilier ne suffit à lui seul. Une stratégie solide en matière de localisation des données, associée à des contrôles opérationnels insuffisants, ne constitue pas une souveraineté : il s’agit d’une résidence comportant des risques non évalués.

Ce qui rend ce cadre utile, ce n’est pas sa complexité, mais les questions qu’il suscite. Lorsqu’une organisation évalue pour la première fois sa situation actuelle à l’aune de ces quatre piliers, elle constate presque toujours des lacunes dont elle ignorait l’existence – non pas parce que les contrôles font défaut, mais parce que ces questions n’avaient jamais été posées.

La souveraineté est une notion relative

Une dernière chose mérite d’être soulignée : la souveraineté n’est pas un état binaire. Il n’existe aucune certification qui l’accorde ni aucun modèle de déploiement unique qui la garantisse. C’est une posture – un ensemble de décisions délibérées et vérifiables. Et le niveau adéquat de cette posture varie selon l’organisation, la charge de travail et ce que vous devez réellement aux régulateurs et aux clients.

C’est précisément ce qu’implique la « souveraineté minimale viable » – thème abordé dans le deuxième article de cette série. La confiance des autorités de régulation se construit bien avant l’audit proprement dit, grâce à des exigences clairement définies, et non à des hypothèses liées à la situation géographique. Téléchargez le rapport « Digital Sovereignty Readiness Report » pour découvrir le cadre en quatre piliers et un outil pratique d’auto-évaluation.

FAQ

Q : Quelle est la différence entre la résidence des données et la souveraineté numérique ?

R : La « résidence des données » porte sur le lieu où les données sont physiquement stockées. La souveraineté numérique va plus loin en s’intéressant aux personnes autorisées à accéder aux données, au mode de fonctionnement des systèmes et aux juridictions susceptibles de présenter un risque juridique.

Q : Pourquoi le choix d’une région ne suffit-il pas à garantir la souveraineté ?

R : Le choix d’une cloud ne concerne que l’aspect géographique. Il ne résout pas les problèmes liés à l’accès opérationnel, à l’exposition aux risques juridiques ou aux capacités de reprise après sinistre.

Q : Quels sont les quatre piliers de la souveraineté numérique ?

R : Ces quatre piliers sont la localisation des données, la souveraineté technologique, la souveraineté opérationnelle et la souveraineté juridictionnelle. Ensemble, ils constituent, selon nous, un cadre plus complet pour évaluer l’état de préparation en matière de souveraineté.

Q : Pourquoi la souveraineté opérationnelle est-elle difficile à gérer ?

R : La souveraineté opérationnelle implique de contrôler qui peut accéder aux systèmes, depuis quel endroit ces personnes opèrent et sous quel régime juridique. Ces contrôles sont plus difficiles à vérifier que de simples exigences relatives à la localisation des données.

Q : La souveraineté numérique est-elle une certification figée ?

R : Non. La souveraineté est une démarche continue qui repose sur des décisions mûrement réfléchies et vérifiables, lesquelles varient en fonction de l’organisation, de la charge de travail et du cadre réglementaire.

Ruben Renders est directeur des solutions MSP chez Commvault.

More related posts

Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more

Points clés à retenir

  • Les attaques par « vishing » ont connu une forte recrudescence, des groupes organisés ayant industrialisé l’ingénierie sociale pour obtenir un accès initial via les services d’assistance.
  • Les attaquants passent rapidement des comptes humains compromis à des identités machine persistantes, telles que les jetons OAuth et les comptes de service.
  • La plupart des organisations manquent de gouvernance et de visibilité sur les identités non humaines (NHI), ce qui crée un angle mort majeur en matière de sécurité.
  • Une Readiness efficace repose sur la corrélation des signaux d’identité et sur le traitement des identités machine comme des actifs à haut risque.
  • Une véritable résilience nécessite la capacité à détecter et à annuler les modifications non autorisées des privilèges avant que les attaquants ne parviennent à s’implanter durablement.

Votre service d’assistance vient de recevoir un appel téléphonique. L’appelant connaissait le nom de l’employé, celui de son responsable et les quatre derniers chiffres de son numéro de badge. Il a demandé une réinitialisation de mot de passe. Procédure standard. Le technicien informatique a accédé à sa demande.

Cet appel était une fraude. Et l’attaquant est désormais à l’intérieur.

Le hameçonnage vocal (ou « vishing ») a bondi de 449 % en 2025. Les groupes malveillants ont transformé l’ingénierie sociale en une opération à grande échelle : ils recrutent des appelants, rédigent des scripts et versent entre 500 et 1 000 dollars par usurpation d’identité réussie auprès d’un service d’assistance. Ils ne cherchent pas à s’emparer de vos données. Ils cherchent à prendre pied dans votre système.

Une fois à l’intérieur, les attaquants ne s’attardent pas sur le compte de l’utilisateur. Ils se déplacent latéralement : ils volent des jetons OAuth, créent de nouveaux comptes de service administratifs, intègrent des accès dans des identifiants au niveau des machines que personne ne surveille. Contrairement aux mots de passe humains, ces identifiants sont rarement renouvelés. Ils ne déclenchent pas d’alertes de connexion. Ils peuvent survivre à une remédiation complète du compte utilisateur initialement compromis.

Au moment où votre équipe de sécurité clôt le ticket relatif à l’incident du service d’assistance, l’attaquant peut déjà être présent discrètement et de manière persistante dans votre environnement depuis des semaines. Les lacunes en matière de gouvernance aggravent encore la situation.

Moins de 25 % des organisations disposent de politiques formelles pour la création ou la mise hors service des NHI — ces comptes de service, clés API et jetons OAuth qui sont désormais 144 fois plus nombreux que les utilisateurs humains. Presque tous disposent d’autorisations bien supérieures à ce que leur fonction exige.

La plupart des organisations n’ont pratiquement aucune confiance en leur capacité à détecter une attaque ciblant cette couche. Il ne s’agit pas d’un échec de prévention, mais d’un échec de planification de la Recovery.

À quoi ressemble la Readiness ?

La prévention au niveau du service d’assistance est importante : formation, vérification par rappel, confirmation hors bande. Mais elle ne suffit pas à elle seule. Les attaquants s’industrialisent plus vite que les programmes de sensibilisation ne peuvent suivre le rythme.

Readiness, c’est mettre en corrélation les signaux : une interaction avec le service d’assistance suivie immédiatement d’une réinitialisation de l’authentification multifactorielle (MFA) ou de la création d’un nouveau jeton est un indicateur hautement probable d’une compromission.

Cela signifie traiter les identités des machines comme des actifs de niveau 0 : régir leur création, définir l’étendue de leurs autorisations et surveiller toute escalade non autorisée. Et cela signifie être capable de détecter et d’annuler rapidement les modifications malveillantes des privilèges, avant qu’elles ne deviennent la nouvelle norme.

Découvrez comment la résilience des identités de Commvault prend en charge la détection rapide, l’annulation et la Recovery de votre environnement d’identités.

FAQ

Q : Qu’est-ce qu’une attaque par « vishing » dans le contexte de la sécurité d’entreprise ?

R : Le vishing (hameçonnage vocal) utilise des appels téléphoniques pour usurper l’identité d’employés et manipuler les services d’assistance informatique afin qu’ils accordent un accès, généralement via la réinitialisation de mots de passe ou d’authentification multifactorielle (MFA). Cette pratique est de plus en plus industrialisée, avec des groupes organisés qui recrutent des appelants et utilisent des scripts pré-rédigés pour maximiser leurs taux de réussite.

Q : Pourquoi les attaquants se tournent-ils vers les identités machines après s’être introduits par vishing ?

R : Les comptes humains font l’objet de mesures correctives. Les identités machine (NHI) – jetons OAuth, comptes de service, clés API – sont plus persistantes et rarement renouvelées, et souvent invisibles pour les systèmes de surveillance traditionnels. La migration de l’accès vers la couche machine permet aux attaquants de maintenir cette persistance longtemps après que la violation initiale des identifiants humains a été détectée et corrigée.

Q : Que signifie concrètement la « résilience des identités » ?

R : Cela signifie que votre organisation est en mesure de détecter en temps quasi réel les modifications non autorisées des privilèges et de rétablir rapidement un état de confiance dans l’environnement des identités. La détection seule ne suffit pas : c’est la capacité à annuler les activités malveillantes et à vérifier que les identités des machines n’ont pas été altérées (ou, si elles l’ont été, à les rétablir à un état antérieur valide) qui fait la différence entre une organisation préparée et une organisation exposée.

Vidya Shankaran est directrice technique sur le terrain chez Commvault.

More related posts

Thumbnail_Blog-Identity-Resilience-MachineID-2026-Linkedin

The Machine Identity Blind Spot Is Now a Primary Attack Surface

Read more
Thumbnail_Blog-Help-Desk-2026-Linkedin

When the Help Desk Becomes the Front Door to Your Entire Network

Read more
Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Points clés à retenir

  • L’ingénierie sociale visant les services d’assistance est désormais l’un des principaux points d’entrée, les attaques de « vishing » (hameçonnage vocal) se multipliant rapidement et entraînant la compromission des identifiants.
  • Les identités non humaines, telles que les comptes de service et les jetons, constituent un angle mort majeur en matière de sécurité ; elles sont souvent laissées sans surveillance et largement exploitées à des fins de déplacement latéral.
  • Active Directory (AD) constitue une cible de choix en raison de son contrôle centralisé et des risques de mauvaise configuration.
  • La prévention à elle seule ne suffit pas ; les organisations doivent disposer de solides capacités de détection et de reprise rapide afin de limiter les dégâts.
  • Des mesures opérationnelles immédiates – telles que l’audit des comptes et la mise en corrélation entre l’activité du service d’assistance et les changements d’identité – peuvent réduire considérablement les risques.

Active Directory (AD) reste une cible privilégiée des pirates, car il est au cœur de la gestion des identités en entreprise. Des études récentes montrent que 67 % des incidents impliquent désormais une compromission liée aux identités, les pirates s’attaquant à des systèmes critiques tels qu’AD dans les heures qui suivent leur accès initial. Une fois le système compromis, la restauration peut prendre plusieurs jours, voire plusieurs semaines, ce qui entraîne une perturbation importante de l’activité.

La question qu’il convient de se poser n’est pas de savoir si l’AD est une cible. Il s’agit plutôt de comprendre comment les pirates y parviennent – et pourquoi le chemin est bien plus court que ne le penseraient les équipes de sécurité.

3 étapes pour parvenir à un compromis global

Des groupes malveillants tels que ShinyHunters et Scattered Spider ont fait de l’ingénierie sociale une opération à grande échelle. Le hameçonnage vocal (ou « vishing ») a bondi de 449 % en 2025. Les appelants sont recrutés, reçoivent un script à suivre et sont rémunérés jusqu’à 1 000 dollars en fonction de leur succès et de leur taux de réussite.

En d’autres termes, il suffit d’une seule étape pour lancer une attaque : obtenir une réinitialisation de mot de passe ou modifier les paramètres d’authentification multifactorielle (MFA). C’est tout.

À partir de cette seule information d’identification, l’attaquant se déplace latéralement vers les environnements cloud et virtualisés. Il récupère des jetons OAuth, crée de nouveaux comptes de service administratifs et intègre des droits d’accès dans les identifiants au niveau des machines. Ces identités non humaines – comptes de service, clés API, jetons – sont désormais 144 fois plus nombreuses que les utilisateurs humains. La prolifération et la charge opérationnelle rendent la rotation des identifiants et les audits difficiles. Ce déplacement latéral a une destination : Active Directory.

La publicité est la cible

AD est le système nerveux central de l’identité d’entreprise. En le contrôlant, on contrôle tout : les comptes utilisateurs, les stratégies de groupe et l’accès à tous les systèmes joints au domaine au sein du réseau. La raison pour laquelle il est si attractif pour les attaquants – et si difficile à défendre – est d’ordre structurel. Tout utilisateur authentifié peut lire l’intégralité de l’annuaire. Chaque système joint au domaine hérite de sa confiance.

Les objets de stratégie de groupe liés à la tête du domaine peuvent être utilisés comme une arme pour désactiver purement et simplement les contrôles de sécurité. Les protocoles hérités restés activés pour des raisons de compatibilité applicative offrent un accès direct. La documentation de Microsoft indique que « la plupart des attaques liées à l’identité exploitent des erreurs de configuration courantes dans Active Directory ». Lorsqu’un pirate parvient jusqu’à l’AD, il n’a pas besoin de forcer l’entrée. La porte est généralement ouverte.

La prévention est nécessaire, mais pas suffisante

La pile de sécurité standard – authentification multifactorielle (MFA), détection au niveau des terminaux, filtrage des e-mails – s’articule autour du comportement humain. Elle n’a pas été conçue pour contrôler la couche d’identité des machines ni pour détecter le type d’escalade de privilèges progressive et d’apparence légitime qui caractérise les attaques AD modernes. Un attaquant qui, en l’espace de 72 heures, passe d’un compte utilisateur compromis à un compte de service, puis à un compte d’administrateur de domaine, peut ne déclencher aucune alerte.

C’est pourquoi il faut passer d’une approche axée sur la prévention à une approche axée sur le rétablissement. La prévention reste essentielle. L’accès selon le principe du « privilège minimal », l’audit des modifications apportées à Active Directory, le renforcement des configurations par défaut, la désactivation des comptes inactifs : toutes ces mesures peuvent contribuer à réduire la surface d’attaque. Mais étant donné que la moitié des entreprises ont déjà été victimes d’une attaque visant Active Directory, se contenter de miser uniquement sur la prévention revient à se condamner à l’échec.

Une véritable résilience des identités nécessite la capacité de détecter les élévations de privilèges non autorisées en temps quasi réel, d’annuler les modifications malveillantes avant qu’elles ne se propagent et de rétablir rapidement l’environnement d’identités dans un état connu et fiable – non pas en quelques jours ou semaines, mais suffisamment vite pour limiter l’ampleur de l’incident. Cela implique de traiter Active Directory et la couche d’identités non humaines comme des actifs de niveau 0, en y consacrant les mêmes efforts de gouvernance et de reprise que ceux que vous consacreriez à tout autre système critique.

Que faire dès maintenant pour renforcer la résilience identitaire ?

L’écart entre la situation actuelle de la plupart des organisations et ce qu’elles devraient être en matière de résilience des identités est bien réel. Mais il est possible de le combler. Les priorités immédiates sont peu glamour et de nature opérationnelle :

  1. Vérifiez le contenu de votre Active Directory.
  2. Identifiez les comptes qui ne devraient plus exister.
  3. Renouvelez les identifiants qui n’ont pas été utilisés depuis des années.
  4. Établir une corrélation entre l’activité du service d’assistance et les événements liés à la création de jetons et de comptes.

Une interaction avec le service d’assistance suivie d’une réinitialisation de l’authentification à deux facteurs (MFA), puis de la création d’un nouveau compte de service, constitue un signal d’attaque très fiable – et celui-ci est détectable si l’on y prête attention.

Le travail à plus long terme est d’ordre architectural : intégrez des capacités de reprise à votre programme de gestion des identités afin que, lorsqu’une attaque aboutit – et il s’agit généralement d’une question de « quand », et non de « si » –, vous puissiez la contenir, en inverser les effets et tenter de rétablir la confiance plus rapidement que l’attaquant ne peut consolider sa position.

Les attaquants comptent sur le fait que votre AD n’est pas gouverné, que vos identités de machines sont invisibles et que votre plan de Recovery est purement théorique. Comblez l’une de ces lacunes ce trimestre. Comblez-les toutes les trois et vous aurez fondamentalement changé la donne. Découvrez comment Commvault Cloud une protection complète de l’Active Directory, de l’évaluation des vulnérabilités à la restauration en un clic, en passant par la récupération complète de la forêt.

J’ai récemment rejoint Vidya Shankaran dans le podcast STRIVE pour discuter du déficit de gouvernance concernant les identités non humaines. Écoutez notre épisode ici. Et n’oubliez pas de lire le blog de Vidya, intitulé « Le point aveugle des identités de machines est désormais une surface d’attaque majeure ».

FAQ

Q : Pourquoi les services d’assistance constituent-ils désormais un risque majeur pour la sécurité ? R : Les services d’assistance sont souvent chargés de réinitialiser les mots de passe et de modifier les paramètres d’authentification multifactorielle (MFA), ce qui en fait des cibles de choix pour les attaques d’ingénierie sociale. Les pirates exploitent cette confiance pour obtenir un accès initial sans rencontrer de résistance notable. Q : Quel rôle les identités non humaines jouent-elles dans les attaques ?

R : L’étendue du réseau et la charge opérationnelle compliquent la rotation et l’audit des identités non humaines, telles que les comptes de service et les clés API. Les attaquants s’en servent pour maintenir leur présence et se déplacer à l’insu de tous d’un système à l’autre. Q : Pourquoi Active Directory (AD) est-il une cible si critique ? R : AD gère l’authentification et les accès sur l’ensemble du réseau. En prenant le contrôle de ce système, les attaquants peuvent gérer les utilisateurs, les politiques et les systèmes à grande échelle. Q : L’authentification multifactorielle (MFA) et la sécurité des terminaux ne suffisent-elles pas à stopper ces attaques ? R : Ces outils se concentrent sur le comportement humain et peuvent ne pas détecter les tentatives d’escalade de privilèges progressives et d’apparence légitime. Les attaquants peuvent agir en respectant les schémas habituels et éviter ainsi de déclencher des alertes. Q : Que signifie une approche de sécurité axée sur la restauration ? R : Cela signifie se préparer à la réalité que des violations se produiront et donner la priorité à la capacité de les détecter, de les contenir et de les résoudre rapidement. Cette approche contribue à réduire les temps d’arrêt et peut aider à limiter l’impact global. Q : Quelles sont les mesures les plus importantes à prendre immédiatement ? R : Commencez par effectuer un audit de votre Active Directory, en supprimant les comptes inutiles, en renouvelant les identifiants obsolètes et en surveillant les séquences suspectes d’activités liées au service d’assistance et à l’identité. Dan Conrad est technologue principal et directeur technique sur le terrain chez Commvault.

More related posts

Thumbnail_Blog-Okta-Early-Access-2026

Commvault® Extends Identity Resilience to Okta

Read more
Thumbnail_Blog-Lateral-Access-2026

Staying Resilient Against Lateral Access Exploits

Read more
Thumbnail_3_AD_Blogs_2025

Active Directory Forest Recovery: Why Manual Methods Are No Longer Viable

Read more
Thumbnail_6_AD_Blogs_2025

AD Recovery Testing: How to Know Your Recovery Plan Will Actually Work

Read more

Points clés à retenir

  • Les identités non humaines (NHI) sont désormais bien plus nombreuses que les utilisateurs humains et leur nombre augmente à un rythme bien plus rapide, ce qui crée une surface d’attaque importante et insuffisamment contrôlée.
  • Les pirates ont de plus en plus souvent recours à l’ingénierie sociale, comme le hameçonnage vocal (vishing), pour contourner les défenses humaines et accéder aux identifiants au niveau de la machine.
  • La plupart des systèmes d’assurance maladie nationaux fonctionnent avec des autorisations excessives et ne disposent pas d’une gestion adéquate du cycle de vie, ce qui contribue à l’accumulation d’une « dette identitaire ».
  • Les outils de sécurité traditionnels ne parviennent pas à détecter les menaces au niveau de la couche matérielle, car les NHI se comportent différemment des utilisateurs humains.
  • Les organisations doivent passer de stratégies axées en priorité sur la prévention à des approches axées en priorité sur la restauration, en accordant la priorité à la détection rapide et à la neutralisation des attaques ciblant l’identité.

Au cours de la dernière décennie, les investissements en sécurité des entreprises ont été axés sur l’humain. Une meilleure authentification. Une authentification multifactorielle (MFA) plus solide. La simulation d’hameçonnage. Une architecture centrée sur l’identité. Ces investissements constituaient la réponse adéquate au paysage des menaces de l’époque. Le paysage des menaces a évolué.

Aujourd’hui, les attaquants les plus sophistiqués ne cherchent pas à contourner votre MFA. Ils s’en servent comme d’une porte d’entrée. Un appel téléphonique convaincant à votre service d’assistance informatique, une réinitialisation de la MFA et un compte humain compromis : voilà comment ils s’introduisent. Ce qu’ils recherchent en réalité, c’est ce qui se cache derrière : la couche tentaculaire et insuffisamment contrôlée des NHI qui relie tous les systèmes de votre environnement.

L’ampleur du problème est stupéfiante

Comptes de service, clés API, jetons OAuth, agents IA : les NHI sont désormais 144 fois plus nombreux que les utilisateurs humains, et leur croissance est 4 à 10 fois plus rapide que celle des comptes humains. Pourtant, moins de 25 % des organisations disposent de politiques formelles régissant leur création ou leur mise hors service. Presque tous sont dotés d’autorisations excessives – des droits qui dépassent de loin ce qu’exige leur fonction.

Ce n’est pas un risque nouveau qui est apparu du jour au lendemain. Il s’agit d’une dette d’identité accumulée au fil des années : des années de provisionnement sans gouvernance, d’automatisation sans obligation de rendre des comptes, cloud sans visibilité. Et les attaquants l’ont remarqué.

Le « vishing » est le point d’entrée

Des groupes tels que ShinyHunters et Scattered Spider – opérant au sein de ce que les chercheurs appellent le cluster Scattered LAPSUS$ Hunters (SLH) – ont industrialisé l’ingénierie sociale pour exploiter précisément cette faille. Le hameçonnage vocal a augmenté de 449 % en 2025. Il ne s’agit pas d’appels opportunistes. Ce sont des opérations coordonnées : des scripts spécialement conçus, des appelants recrutés, des incitations financières pouvant atteindre 1 000 dollars par usurpation d’identité réussie auprès d’un service d’assistance.

L’appel n’est pas l’attaque en soi. L’appel correspond à la réinitialisation des identifiants qui permet à un attaquant de franchir le périmètre humain. L’attaque commence lorsqu’il passe à la couche machine : vol de jetons OAuth, création de comptes de service administratifs, intégration des droits d’accès dans des identifiants rarement surveillés et dont les mots de passe ne sont presque jamais renouvelés. Le compte humain est corrigé. L’accès à la couche machine persiste. L’attaquant est déjà passé à autre chose.

Trois vulnérabilités que les mesures de sécurité traditionnelles ne détectent pas

Les outils de sécurité standard sont conçus autour du comportement humain. Ils signalent les connexions anormales, les géolocalisations inhabituelles, le trafic e-mail suspect. Les NHI fonctionnent différemment, et cette différence constitue l’angle mort.

L’abus d’OAuth, par exemple, ressemble à un trafic API normal – même après une réinitialisation de mot de passe. Des milliers de comptes de service non documentés opèrent dans les grandes entreprises avec des privilèges administratifs, souvent bien après la fin des projets qui les ont créés. Les clés API à longue durée de vie intégrées dans les pipelines DevOps confèrent un accès étendu, sans contexte d’appareil ni alerte de connexion. Le MFA ne les couvre pas. La détection au niveau des terminaux ne les repère pas. Le filtrage des e-mails ne s’applique pas à eux.

Le changement de paradigme : passer d’une approche axée sur la prévention à une approche axée sur le rétablissement

La réponse logique face à une menace qui échappe souvent aux systèmes de détection traditionnels consiste à cesser de croire qu’il est possible d’empêcher toutes les intrusions et à commencer à mettre en place des mesures permettant une reprise rapide après celles qui ont abouti. Cela implique de considérer les NHI comme des actifs de niveau 0, en leur appliquant les mêmes contrôles de gouvernance que ceux utilisés pour les administrateurs de domaine ou les plans cloud gérés à l’aide d’identités humaines. Cela signifie également de remplacer les secrets statiques par des jetons à durée de vie limitée et de mettre en place une rotation automatique.

Cela implique également de mettre en corrélation des signaux provenant de différents domaines : une interaction avec le service d’assistance suivie d’une réinitialisation de l’authentification multifactorielle (MFA), puis de la création d’un nouveau jeton, constitue un indicateur de compromission très fiable, et le fait de le détecter à un stade précoce fait toute la différence entre une maîtrise de l’incident et une violation prolongée. Cela implique de faire correspondre les identifiants de réseau (NHI) aux identités humaines à des fins de responsabilisation.

Avant tout, cela implique d’être capable de détecter en temps réel les élévations de privilèges non autorisées et d’annuler les modifications malveillantes apportées aux identités, afin de rétablir l’environnement dans un état connu et fiable avant que les dégâts ne s’aggravent.

La prévention reste importante. Mais compte tenu des lacunes en matière de gouvernance dont souffrent de nombreuses organisations, la rapidité de reprise devient un indicateur clé de la résilience. Les organisations doivent mettre en place des programmes de gestion des identités adaptés aux attaques actuelles, et non à celles qui étaient courantes il y a cinq ans. Rendez-vous sur Readiverse et découvrez notre livre numérique intitulé « The Non-Human Identity Crisis », qui explore l’étendue de la surface d’attaque des machines et le cadre permettant d’assurer la résilience des identités.

FAQ

Q1 : Que sont les identités non humaines (NHI) ?

R : Les NHI comprennent des comptes de service, des clés API, des jetons OAuth et des agents IA qui permettent aux systèmes et aux applications d’interagir. Contrairement aux utilisateurs humains, ils fonctionnent souvent de manière automatique et à grande échelle, ce qui les rend plus difficiles à surveiller et à contrôler.

Q2 : Pourquoi les NHI sont-ils considérés comme un risque pour la sécurité ?

R : Les NHI disposent souvent de droits d’accès excessifs et ne sont pas soumis à une gouvernance adéquate, ce qui en fait des cibles de choix pour les pirates. Comme ils font rarement l’objet d’une surveillance ou d’une rotation des identifiants, les identifiants compromis peuvent rester indétectés pendant de longues périodes.

Q3 : Comment les pirates exploitent-ils les NHI ?

R : Les pirates obtiennent généralement un accès initial par le biais de techniques d’ingénierie sociale, telles que le « voice phishing », puis s’orientent vers la couche matérielle. Ils volent des jetons, créent de nouveaux comptes de service ou intègrent un accès persistant dans des identifiants qui ne font pas l’objet d’une surveillance étroite.

Q4 : Pourquoi les outils de sécurité traditionnels ne détectent-ils pas ces menaces ?

R : La plupart des outils de sécurité sont conçus pour détecter les comportements humains, tels que les anomalies de connexion ou les tentatives d’hameçonnage. Les NHI génèrent un trafic système d’apparence normale, ce qui permet aux activités malveillantes de se fondre parmi les opérations légitimes.

Q5 : Qu’entend-on par une approche de sécurité axée sur la « restauration en priorité » ?

R : Une approche axée sur la restauration vise à détecter rapidement les intrusions et à rétablir les systèmes dans un état fiable, plutôt que de partir du principe que toutes les attaques peuvent être évitées. Cela implique notamment d’identifier les modifications non autorisées et de les annuler en temps réel.

Q6 : Comment les organisations peuvent-elles renforcer la sécurité du régime national d’assurance maladie ?

R : Les organisations peuvent considérer les NHI comme des actifs critiques, mettre en œuvre des politiques de gouvernance strictes, remplacer les identifiants statiques par des jetons à durée de vie limitée et établir des corrélations entre les signaux provenant de différents systèmes. Le fait d’associer les NHI à des responsables humains permet également d’améliorer la responsabilité et la supervision.

Vidya Shankaran est directrice technique sur le terrain chez Commvault.

More related posts

Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog-Unified-Resilience-2026

Why AI Is Breaking Your Resilience Strategy (And What to Do About It)

Read more
Thumbnail_Blog-SHIFT-Sanjay-2025-Linkedin

Re-envisioning Resilience for the Age of AI

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Aujourd’hui, les entreprises développent des applications plus rapidement, automatisent leurs flux de travail à grande échelle et transforment leurs données en informations exploitables, grâce à des plateformes telles que Microsoft Power Platform. Ce qui n’était au départ qu’une couche de productivité « low-code » est rapidement devenu un élément essentiel à leur activité, intégré aux processus qui soutiennent la génération de chiffre d’affaires, les opérations quotidiennes et la prise de décision stratégique.

Mais à mesure que le recours à ces outils d’intelligence d’affaires s’intensifie, les risques associés augmentent également. La même platform l’innovation peut aussi amplifier l’impact des erreurs opérationnelles, des erreurs de configuration et des actions malveillantes. Un workflow mal configuré, un rapport supprimé ou une application défaillante peuvent perturber les processus métier, compromettre la prise de décision et éroder la confiance dans les systèmes sur lesquels repose l’entreprise. Et lorsqu’un problème survient, la remise en état est rarement simple.

Commvault contribue à relever ces défis en proposant des solutions de protection et de restauration des données de niveau entreprise pour Microsoft Power Platform, à commencer par Power BI. Les organisations peuvent ainsi garantir la protection et la restauration rapide des analyses, des flux de travail et des applications qu’elles développent. 

Power BI : le fossé entre l’analyse et la reprise

Au cœur de nombreux Platform Power Platform se trouve Microsoft Power BI, qui offre des fonctionnalités d’analyse et d’intelligence économique, permettant de transformer les données en rapports, en prévisions et en visibilité opérationnelle. Lorsque les ressources Power BI sont perdues ou compromises, les équipes peuvent rapidement se retrouver privées d’accès à des informations fiables, ce qui perturbe les cycles de reporting et retarde la prise de décision au sein de l’entreprise.

Dans la pratique, cependant, les stratégies de protection ne sont pas à la hauteur de l’importance de ces ressources. De nombreuses entreprises s’appuient sur des exportations manuelles de fichiers ou sur des fonctionnalités natives limitées qui n’ont pas été conçues pour une restauration complète. En cas de panne, les équipes sont souvent contraintes de tout reconstruire manuellement, sans pouvoir restaurer exactement ce dont elles ont besoin. La Recovery devient alors lente, source d’erreurs et difficile à mettre à l’échelle.

Commvault Cloud Backup & Recovery Microsoft Power Platform

Désormais disponible pour tous, la solution Commvault Cloud Backup & Recovery Microsoft Power Platform les entreprises Platform protéger et Platform restaurer leurs ressources stratégiques, telles que les rapports, en cas de suppression accidentelle, de corruption ou d’activité malveillante.

  • Protection automatisée basée sur des règles : mettez en place des sauvegardes basées sur des règles pour l’ensemble des ressources de l’espace de travail Power BI, afin d’assurer une couverture cohérente et évolutive sans intervention manuelle.
  • Restauration rapide et granulaire : restaurez des rapports ou des dossiers individuels à un moment précis, ce qui évite les recréations manuelles et contribue à réduire au minimum les temps d’arrêt et les perturbations.
  • Sauvegardes isolées et immuables : contribuez à protéger vos données contre ransomware les modifications non autorisées grâce à des sauvegardes conçues pour empêcher toute modification ou suppression non autorisée.
  • Conformité simplifiée : assurez la conservation à long terme (jusqu’à 10 ans) des données, la centralisation des journaux d’audit et la génération de rapports afin de répondre aux exigences réglementaires et internes.

Platform unifiée Platform la résilience

Commvault Cloud une platform unifiée platform protéger les charges de travail SaaS, cloud et sur site, notamment Microsoft 365, Dynamics 365, Salesforce, les machines virtuelles, les bases de données et les terminaux. Grâce à Platform Microsoft Power Platform , les clients peuvent rationaliser la protection, la restauration et la résilience d’un plus grand nombre de charges de travail, ce qui contribue à réduire la prolifération des outils et à simplifier les opérations.

Comment commencer

Commvault Cloud Backup and Recovery for Power Platform est fourni sous forme de solution SaaS, conçue pour un déploiement rapide et une charge opérationnelle minimale. Les entreprises peuvent connecter leur environnement Power BI, appliquer une protection basée sur des politiques et commencer à sauvegarder leurs données critiques en quelques étapes seulement.

La détection automatisée protège les nouveaux rapports et dossiers à mesure que les environnements évoluent, tandis que la gestion centralisée offre un point unique pour surveiller, gérer et restaurer les données à grande échelle.

Prochaines étapes : étendre notre présence sur Power Platform

Nous avons l’intention d’étendre la protection et la résilience à l’ensemble de Platform Microsoft Power Platform Power Apps et Power Automate, afin de couvrir les applications et les flux de travail qui sont au cœur de votre activité. Les plans, les calendriers et les fonctionnalités sont susceptibles d’être modifiés et ne doivent pas être pris en compte dans vos décisions d’achat.

Protégez ce qui fait tourner votre entreprise

À mesure que l’utilisation de Microsoft Power Platform , le besoin d’une protection robuste et adaptée aux entreprises s’accroît également. Avec Commvault Cloud, vous pouvez :

  • Protéger les ressources critiques contre la suppression, la corruption et les attaques
  • Récupérez rapidement exactement ce dont vous avez besoin, sans avoir à tout reconstruire
  • Préserver la confiance dans les données, les décisions et l’automatisation
Prêt à renforcer la résilience de votre investissement dans Microsoft Power BI ?

Pour en savoir plus et découvrir Commvault Cloud action, rendez-vous sur commvault.platform.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Points clés à retenir

  • La migration des machines virtuelles vers Red Hat OpenShift Virtualization est un processus par étapes qui nécessite une protection cohérente dans tous les environnements hybrides.
  • platform de protection des données unifiée et native de Kubernetes platform réduire la complexité et d’éviter d’avoir recours à des outils ou des processus distincts.
  • Une résilience fiable – comprenant notamment des sauvegardes immuables et la détection des menaces – est essentielle pendant la migration, moment où les risques sont les plus élevés.
  • Des options de reprise flexibles permettent aux organisations de s’adapter rapidement en cas d’échec des étapes de migration ou de modification des délais.
  • La consolidation de la protection des machines virtuelles et des conteneurs permet de réduire la prolifération des outils et d’assurer une gouvernance cohérente.

Si vous occupez aujourd’hui un poste de responsable informatique, il y a de fortes chances que votre stratégie de virtualisation fasse actuellement l’objet d’un réexamen approfondi. La hausse des coûts, les incertitudes liées aux licences et la dépendance à long terme vis-à-vis d’un fournisseur poussent de nombreuses entreprises à réévaluer leur recours aux hyperviseurs traditionnels. Parallèlement, Kubernetes s’est imposé comme la base opérationnelle des applications modernes.

Ces deux réalités convergent – et pour de nombreuses entreprises, Red Hat OpenShift Virtualization s’impose comme la solution privilégiée pour exécuter des machines virtuelles dans le cadre d’un modèle d’exploitation natif de Kubernetes. Cette transition s’accélère dans tous les secteurs d’activité. Alors que les entreprises modernisent leur infrastructure à leur rythme, Red Hat OpenShift Virtualization est de plus en plus considéré comme un moyen de moderniser la platform avoir à refactoriser les applications. Cette dynamique soulève une question cruciale :

Comment migrer des machines virtuelles tout en garantissant une protection, une résilience et une capacité de reprise constantes tout au long du processus ? Pour y répondre, il faut analyser comment se déroulent concrètement la plupart des migrations d’entreprise – et à quel moment la protection et la résilience deviennent essentielles.

La migration est un parcours, pas un événement ponctuel

Les responsables informatiques chevronnés savent que les transitions en matière d’infrastructure se font rarement d’un seul coup. Pour les entreprises qui choisissent de passer d’hyperviseurs tels que VMware à Red Hat OpenShift Virtualization, la transition s’effectue généralement par étapes. Pendant cette période, les organisations se retrouvent inévitablement dans une situation mixte :

  • Les machines virtuelles basées sur VMware continuent de soutenir les activités principales de l’entreprise.
  • Les machines virtuelles qui fonctionnent désormais sur Red Hat OpenShift Virtualization.
  • Applications conteneurisées partageant les mêmes clusters Red Hat OpenShift.

Cette période de coexistence est source de complexité et de risques. Les données sont en mouvement, les environnements évoluent, et des failles de sécurité peuvent apparaître si les outils et les processus ne s’adaptent pas au rythme des charges de travail.

Il est essentiel de garantir une protection fiable

Commvault propose depuis longtemps des solutions de protection et de restauration des données tant pour les environnements VMware que pour les charges de travail Kubernetes exécutées sur Red Hat OpenShift. Ce même modèle de protection natif de Kubernetes et basé sur des règles s’étend désormais aux machines virtuelles exécutées sur Red Hat OpenShift Virtualization. Ce qui touche vraiment les clients, c’est la cohérence :

  • Une platform unique platform la protection et la restauration.
  • Des opérations basées sur des règles appliquées de manière uniforme à l’ensemble des charges de travail.
  • Conçu pour s’adapter à vos outils et processus existants à mesure que les environnements évoluent.

Les machines virtuelles exécutées sur Red Hat OpenShift Virtualization sont protégées à l’aide des mêmes workflows et mécanismes de gouvernance que les applications conteneurisées. Cette approche unifiée est adoptée par les entreprises qui standardisent leurs environnements sur Red Hat OpenShift et qui recherchent une méthode plus simple et plus cohérente pour gérer les données dans l’ensemble de leurs environnements.

Cette fonctionnalité est disponible dès aujourd’hui. Commvault Cloud prend en charge la protection des environnements Red Hat OpenShift Virtualization conformes à la version 11.40 (support à long terme) et à la version 11.42 (Innovation), ce qui signifie que les clients peuvent dès à présent mettre ces fonctionnalités en production.

Vous ne devriez pas avoir à gérer la protection différemment

Une fois que les machines virtuelles auront été migrées vers Red Hat OpenShift Virtualization, elles ne devraient plus nécessiter de traitement particulier en matière de protection. Commvault Cloud et protège les machines virtuelles Red Hat OpenShift Virtualization ainsi que les applications conteneurisées, offrant ainsi aux équipes une visibilité centralisée, une application cohérente des politiques et des opérations de restauration simplifiées. Les charges de travail virtualisées et conteneurisées sont gérées conjointement, sans créer de cloisonnement opérationnel.

Pour les organisations qui gèrent des portefeuilles d’applications variés, cette gestion des machines virtuelles au sein de Kubernetes permet de réduire les frictions opérationnelles tout en conservant des contrôles de niveau entreprise.

La cyber-résilience est essentielle lorsque la migration accroît les risques.

Les périodes de migration constituent une phase particulièrement vulnérable. Le changement engendre de la complexité, et cette complexité accroît le risque de perte de données et ransomware. Commvault Cloud maintenir la résilience tout au long de cette phase grâce à :

  • Sauvegardes isolées physiquement et immuables pour les charges de travail Red Hat OpenShift Virtualization.
  • Des données de sauvegarde qui facilitent la recherche de menaces et l’analyse forensic, aidant ainsi les équipes à vérifier que tout est prêt pour la restauration avant de rétablir les charges de travail.
  • Des fonctionnalités avancées de reprise d’activité conçues pour aider les organisations à minimiser les perturbations opérationnelles.

Que les charges de travail soient en phase de pré-migration, en cours de transition ou pleinement opérationnelles sur Red Hat OpenShift Virtualization, leur résilience reste intacte.

La flexibilité en matière de reprise inspire confiance

Toute initiative de modernisation doit laisser une marge de manœuvre pour s’adapter. Commvault prend en charge la restauration sur site et hors site des machines virtuelles Red Hat OpenShift Virtualization, y compris l’intégralité du contexte et de la configuration de ces machines. Si une étape de migration ne se déroule pas comme prévu – ou si les délais doivent être modifiés –, les équipes peuvent restaurer rapidement les données et poursuivre leurs opérations sans compromettre la disponibilité ni l’intégrité des données.

Une protection native de Kubernetes allant au-delà des machines virtuelles

Pour de nombreuses entreprises, la virtualisation ne constitue qu’un élément parmi d’autres d’une stratégie plus large de modernisation des applications. Commvault Cloud offre Cloud une protection centrée sur les applications et native à Kubernetes pour les charges de travail conteneurisées, y compris les volumes persistants et les métadonnées des applications, sur l’ensemble des distributions Kubernetes certifiées par la CNCF. Cela permet d’assurer la mobilité et la reprise des applications cloud, tout en contribuant à maintenir la cohérence opérationnelle entre les différents environnements.

Réduire la prolifération des outils à mesure que l’infrastructure évolue

Platform s’accompagnent souvent de nouveaux outils, de nouveaux processus… et d’une complexité accrue. En utilisant Commvault Cloud platform de protection unifiée platform :

  • Machines virtuelles VMware.
  • Machines virtuelles Red Hat OpenShift Virtualization.
  • Applications en conteneurs.

Les organisations peuvent contribuer à réduire la prolifération des outils, à simplifier la gestion et à maintenir une gouvernance cohérente, même à mesure que les stratégies d’infrastructure évoluent.

Comment tout cela s’articule

Lors d’une migration, il est utile de comprendre comment les différents éléments s’articulent entre eux. La boîte à outils de migration pour la virtualisation de Red Hat se charge de transférer les machines virtuelles de VMware vers Red Hat OpenShift Virtualization. Commvault Cloud garantir une protection et une résilience qui accompagnent vos charges de travail tout au long du processus, afin que vos données restent protégées avant, pendant et après la migration. Cela permet d’éviter que la capacité de restauration ne prenne du retard à mesure que les charges de travail sont déplacées.

Poursuivre la discussion lors du Red Hat Summit

Nous travaillons déjà avec des clients qui migrent activement leurs machines virtuelles vers OpenShift Virtualization, et nous poursuivrons ces discussions lors du Red Hat Summit, qui se tiendra du 11 au 14 mai à Atlanta. Sur le stand de Commvault, nous allons :

  • Entretiens avec des responsables informatiques sur les défis concrets en matière de résilience.
  • Partager des conseils pratiques pour migrer en toute confiance.
  • Présentation de la solution Commvault Cloud pour Red Hat OpenShift Virtualization.

Si le maintien de la résilience et de la capacité de reprise dans le cadre de votre stratégie de virtualisation est une priorité, nous serions ravis de pouvoir échanger avec vous.

Aller de l’avant en toute confiance

Red Hat OpenShift Virtualization est en passe de devenir un élément fondamental de l’infrastructure d’entreprise moderne. Cependant, il ne faut pas précipiter la migration à tout prix ; il est indispensable d’intégrer dès le départ des mesures de protection, de résilience et de reprise dans le processus.

Avec Commvault Cloud, la protection des charges de travail Red Hat OpenShift Virtualization n’est pas un objectif d’avenir. C’est déjà une réalité pour nos clients, qui utilisent une platform unifiée platform moderniser leurs systèmes en toute confiance, tout en garantissant leur résilience et leur capacité de reprise.

« Red Hat OpenShift Virtualization offre aux entreprises une base fiable et cohérente pour prendre en charge l’ensemble de leur parc virtualisé », explique Steve Gordon, directeur senior de la gestion des produits pour Cloud hybride chez Red Hat. « En tirant parti d’une intégration optimisée telle que celle de Commvault Cloud Red Hat OpenShift Virtualization, nos clients peuvent aller de l’avant avec davantage de confiance, sachant que leurs charges de travail sont protégées de manière cohérente avant, pendant et après la migration. »

FAQ

Q : Pourquoi la migration des machines virtuelles est-elle considérée comme un processus en plusieurs phases ?

R : La plupart des entreprises ne peuvent pas migrer toutes leurs charges de travail en une seule fois ; elles fonctionnent donc en mode hybride, avec des environnements existants et nouveaux fonctionnant simultanément. Cette approche progressive introduit une certaine complexité, ce qui rend indispensables une protection et une visibilité cohérentes tout au long de la transition.

Q : Quel rôle joue la résilience lors de la migration d’une machine virtuelle ?

R : La résilience permet aux organisations d’assurer la protection des données, de se remettre rapidement des pannes et de se prémunir contre les menaces telles que ransomware. Lors d’une migration, alors que les systèmes sont en pleine transition, des mesures de résilience solides peuvent contribuer à prévenir la perte de données et les perturbations opérationnelles.

Q : Comment Commvault Cloud -t-il la protection dans tous les environnements ?

R : Commvault Cloud une platform unique platform une protection basée sur des règles pour les machines virtuelles VMware, les machines virtuelles OpenShift Virtualization et les applications conteneurisées. Cette approche unifiée permet d’assurer la cohérence des opérations sans avoir à mettre en place de nouveaux outils ni de nouveaux flux de travail.

Q : En quoi la protection native de Kubernetes est-elle importante ?

R : La protection native de Kubernetes s’adapte aux modes de déploiement et de gestion des applications modernes, en couvrant à la fois les conteneurs et les machines virtuelles. Elle permet une gestion simplifiée des données, ainsi que la mobilité et la reprise au sein d’environnements cloud.

Q : En quoi la flexibilité en matière de reprise après sinistre renforce-t-elle la confiance dans la migration ?

R : Des options de restauration flexibles, telles que les restaurations sur site et hors site, peuvent aider les équipes à rétablir rapidement leurs charges de travail en cas de problème. Cette adaptabilité contribue à réduire les temps d’arrêt et permet aux entreprises d’ajuster leurs plans de migration sans compromettre l’intégrité des données.

Q : Comment les organisations peuvent-elles réduire la complexité lors des transitions d’infrastructure ?

R : En adoptant une platform unifiée de protection des données, les entreprises peuvent gérer l’ensemble de leurs charges de travail – virtualisées et conteneurisées – via une interface unique. Cette approche permet de réduire la prolifération des outils, de simplifier l’administration et d’assurer une gouvernance cohérente dans des environnements en constante évolution.

Jason Giza est responsable senior du marketing des partenaires de contenu à l’international chez Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Points clés à retenir

  • La Readiverse Academy a mis en place un parcours de certification structuré et à plusieurs niveaux, allant des connaissances de base à l’expertise avancée cloud .
  • Les certifications sont adaptées aux postes réels, ce qui permet aux apprenants d’acquérir des compétences en adéquation avec leurs responsabilités au sein Cloud Commvault Cloud .
  • Le programme comprend quatre niveaux – Praticien, Spécialiste, Professionnel et Expert – dont chacun offre un niveau croissant d’approfondissement et de compétences opérationnelles.
  • L’apprentissage repose sur trois piliers fondamentaux : platform , la cyber-résilience et l’expertise en matière de charges de travail.
  • Des options de formation flexibles, comprenant notamment des formats en autoformation et animés par un formateur, permettent aux professionnels de progresser en fonction de leur emploi du temps et de leurs objectifs.

Les environnements que vous protégez avec Commvault Cloud de plus en plus complexes, et les attentes envers vos équipes chargées de leur exploitation sont plus élevées que jamais. Il ne s’agit plus seulement de connaître la platform. Il s’agit d’être capable de l’exploiter, de la protéger et de la restaurer, souvent sous pression.

Si vous avez déjà commencé votre parcours d’apprentissage à la Readiverse Academy, bienvenue à nouveau. Et si vous êtes nouveau ici, vous arrivez au bon moment. Aujourd’hui, nous lançons une approche de certification structurée et à plusieurs niveaux qui offre aux apprenants un parcours clair, axé sur les compétences, allant platform de base platform jusqu’à une expertise avancée cloud.

Nous créons du contenu pour vous

Les environnements Commvault Cloud exigent des compétences couvrant plusieurs domaines de responsabilité, souvent au sein d’un même poste. Les administrateurs, les spécialistes de la sécurité, cloud et les responsables de charges de travail doivent posséder des connaissances plus ou moins approfondies et étendues. Et tout le monde n’a pas besoin d’apprendre les mêmes choses, dans le même ordre, pour être efficace.

Les nouveaux niveaux de certification de la Readiverse Academy reflètent cette réalité. Les apprenants progressent à travers des niveaux clairement définis qui s’enchaînent les uns après les autres, afin que votre certification corresponde à ce que vous faites réellement et valide ces compétences auprès des équipes avec lesquelles vous travaillez.

  • Commvault Cloud – connaissances fondamentales sur platform la résilience.
  • Cloud Commvault – expertise approfondie en matière d’exploitation et de sécurité.
  • Commvault Cloud – expertise avancée en matière de restauration et de charges de travail.
  • Commvault Cloud – expertise complète cloud et leadership en matière de résilience.

Chaque niveau s’obtient grâce à une combinaison de cours théoriques, d’activités pratiques en laboratoire et d’évaluations validées. À mesure que les apprenants progressent, l’étendue et la profondeur des compétences opérationnelles démontrées augmentent en conséquence.

Un parcours clair : de la pratique à l’expertise

Le programme de certification s’articule autour de trois piliers de compétences fondamentales qui se retrouvent à tous les niveaux :

  • platform fondamentales platform
  • Concepts de cyber-résilience
  • Charge de travail et expertise fonctionnelle

Chaque niveau ajoute des exigences spécifiques à ces axes. Les apprenants peuvent suivre des cours individuels ou combiner certaines exigences pour atteindre leurs objectifs de certification.

Vous faites déjà partie de la Readiverse Academy ? Voici ce que cela signifie pour vous.

Avec une nouvelle structure comme celle-ci, la question la plus importante est de savoir ce que cela implique pour les progrès que vous avez déjà réalisés. Si vous avez déjà suivi des formations ou obtenu des certifications au sein de la Readiverse Academy, félicitations ! Votre investissement compte, et nous tenons à vous expliquer clairement la suite du processus.

Ces certifications témoignent de votre parcours et de vos réalisations au sein de Commvault. Ce nouveau programme s’inscrit dans le cadre de notre gamme élargie de fonctionnalités de cyber-résilience pour Commvault Software, Commvault SaaS et les environnements hybrides. À mesure que vos besoins évoluent et que vous attendez davantage de Commvault, ces formations et certifications vous aideront à configurer, gérer et optimiser Commvault afin de répondre aux besoins spécifiques de votre organisation.

Il n’existe pas de passage direct des anciens parcours de certification vers le nouveau programme, mais vos certifications existantes valident votre expertise sur les anciennes versions des produits. À mesure que ces versions seront retirées, ces certifications arriveront également en fin de vie. Les apprenants qui se sont déjà engagés dans la Readiverse Academy sont bien placés pour progresser rapidement.

À qui s’adressent les formations et certifications de Readiverse Academy ?

Les certifications de Readiverse Academy s’adressent aux professionnels travaillant avec Commvault SaaS, les logiciels Commvault et les environnements hybrides.

  • Platform chargés de la gestion des opérations quotidiennes.
  • Des spécialistes de la sécurité chargés de protéger les données et de renforcer la sécurité des environnements.
  • Cloud chargés de la configuration du plan de contrôle et de la résilience avancée.
  • Les responsables de charges de travail qui doivent maîtriser des domaines de données spécifiques.

Toutes les formations sont accessibles en autoformation, certaines d’entre elles étant également proposées sous forme de cours animés par un formateur, afin que les apprenants puissent progresser selon un rythme adapté à leur fonction et à leur emploi du temps.

Comment se lancer ou poursuivre son parcours d’apprentissage

Que vous partiez de zéro ou que vous poursuiviez votre parcours, la prochaine étape est simple et conçue pour s’adapter à votre situation actuelle.

  • Connectez-vous ou inscrivez-vous sur commvault.com.
  • Vous découvrez Commvault ? Commencez par suivre la formation « Commvault Cloud ».
  • Vous êtes chargé de la gestion de la charge de travail ? Découvrez notre catalogue de formations qui couvre pratiquement tous les domaines.
  • Vous cherchez des stratégies pour faciliter la reprise après une cyberattaque ? La formation « Cyber-résilience » est le point de départ idéal.

Ce qui va suivre

Notre objectif est de rendre la progression prévisible, transparente et en adéquation avec les métiers du monde réel, afin d’aider les apprenants à savoir quelle est la prochaine étape et comment s’y préparer. Nous nous engageons à fournir à chaque Cloud de Commvault Cloud les connaissances nécessaires pour exploiter, protéger et restaurer son environnement en toute confiance. Car lorsque cela compte le plus, la certification ne se résume pas à un simple titre. Il s’agit avant tout de faire preuve de résilience et d’être prêt à restaurer ses données.

FAQ

Q : Quel est l’objectif du programme de certification de la Readiverse Academy ?

R : Ce programme propose un parcours d’apprentissage structuré et axé sur les compétences, qui aide les professionnels à passer platform de base platform à une expertise avancée cloud . Il adapte la formation aux responsabilités concrètes rencontrées sur le terrain afin de permettre aux apprenants de mettre efficacement en pratique leurs connaissances dans des environnements complexes.

Q : Quels sont les différents niveaux de certification disponibles ?

R : Il existe quatre niveaux : Commvault Cloud , Specialist, Professional et Expert. Chaque niveau s’appuie sur le précédent, avec une expertise technique, un champ d’application opérationnel et des compétences en leadership de plus en plus approfondis.

Q : À qui s’adressent les formations de la Readiverse Academy ?

R : Ces formations s’adressent aux platform , aux spécialistes de la sécurité, cloud et aux responsables de charges de travail évoluant dans des environnements SaaS, logiciels et hybrides. Chaque profil peut suivre un parcours de formation sur mesure, adapté à ses responsabilités.

Q : Comment obtient-on ces certifications ?

R : Les certifications s’obtiennent grâce à une combinaison de cours théoriques, de travaux pratiques en laboratoire et d’évaluations validées. Au fur et à mesure de leur progression, les apprenants démontrent des niveaux d’expertise croissants dans les domaines platform, de la sécurité et des charges de travail.

Q : Qu’advient-il des certifications existantes de la Readiverse Academy ?

R : Les certifications existantes restent valables en tant que preuve d’une expertise acquise par le passé, mais elles sont liées à des versions antérieures du produit. À mesure que ces versions seront retirées, les certifications arriveront en fin de vie, ce qui incitera les apprenants à passer au nouveau programme.

Q : Comment peut-on commencer à utiliser ce nouveau programme ?

R : Les nouveaux apprenants peuvent commencer par la formation « Commvault Cloud », tandis que les utilisateurs existants peuvent se connecter pour poursuivre leur parcours. D’autres formations sont disponibles en fonction d’objectifs spécifiques, tels que la gestion des charges de travail ou les stratégies de cyber-résilience.

Suzanne Klausner est directrice de la stratégie d’accompagnement client chez Commvault.

More related posts

Thumbnail_Blog-Ready-or-Not-2026

Why Every CIO Needs a ‘Ready. Or Not.’ Mindset

Read more
Thumbnail_Blog_Readiness-Update-2024

Boost Your Cyber Resilience and Readiness

Read more
Social_Readiverse_Blog_LinkedIn-1

The Readiverse: Your Go-To Learning Resource for Cyber Resilience and Readiness

Read more

Points clés à retenir

  • Les workflows de restauration traditionnels peuvent entraîner un décalage de l’infrastructure dans les environnements gérés par Terraform, en provisionnant de nouvelles ressources en dehors de l’état.
  • Clumio Backtrack est conçu pour restaurer les données directement dans les buckets S3 et les tables DynamoDB existants, ce qui permet de préserver l’identité des ressources.
  • La restauration sur site permet de réduire le recours aux importations manuelles de Terraform, à la reconfiguration des points de terminaison et au rapprochement des états en cas d’incident.
  • L’alignement des processus de reprise sur les principes de l’« Infrastructure as Code » (IaC) permet de préserver l’intégrité de la configuration et la prévisibilité opérationnelle.
  • La conception de la restauration est tout aussi cruciale que celle de la sauvegarde pour les équipes qui gèrent des environnements de production via Terraform.

L’IaC apporte cohérence, reproductibilité et contrôle des versions aux cloud. Terraform devient la référence absolue concernant ce qui existe, comment cela est configuré et comment cela doit fonctionner. La restauration pose un nouveau défi.

Les opérations de restauration classiques créent souvent de nouvelles ressources : de nouveaux compartiments S3, de nouvelles tables DynamoDB, de nouveaux points de terminaison. Du point de vue de Terraform, ces ressources n’ont pas été définies dans le code. Elles n’existent pas dans l’état. Cela crée un écart. Dans le cadre des opérations courantes, cet écart reste gérable. Lors d’un incident, il s’aggrave. C’est là que la conception de la reprise revêt autant d’importance que celle de la sauvegarde.

Le problème de la dérive de l’IaC

Dans un modèle de restauration classique :

  • Une ressource protégée est restaurée en tant que nouvelle ressource.
  • La ressource d’origine reste dans un état corrompu, écrasé ou défaillant.
  • L’état Terraform ne reconnaît pas la nouvelle ressource.
  • Les équipes doivent importer manuellement les ressources dans State.
  • Il se peut que les configurations des applications doivent être mises à jour.

Pour platform qui gèrent l’infrastructure de production via Terraform, cela crée des frictions au pire moment possible. Le défi ne réside pas dans la fiabilité des sauvegardes en soi, mais dans la manière dont les workflows de restauration s’intègrent aux pratiques d’« infrastructure as code ».

Présentation de la restauration sur site avec Clumio Backtrack

Clumio Backtrack est une fonctionnalité de restauration qui permet de restaurer des données directement dans des ressources AWS existantes, sans avoir à provisionner une infrastructure de remplacement. Lorsqu’elle est configurée via le fournisseur Clumio Terraform, Backtrack permet de mettre en place des workflows de restauration conformes à l’infrastructure définie par code.

Clumio Backtrack prend en charge à la fois Amazon S3 et Amazon DynamoDB. Pour une analyse technique plus approfondie des workflows de restauration spécifiques à DynamoDB, consultez notre article de blog consacré à Clumio Backtrack pour DynamoDB.

Au lieu de mettre en place des ressources de remplacement, Backtrack facilite la restauration :

  • Les objets S3 sont stockés directement dans le compartiment d’origine.
  • Les données DynamoDB directement dans la table d’origine.

Du point de vue de Terraform, l’infrastructure est censée rester inchangée, les ressources définies continuant à correspondre à la configuration déclarée. Cela permet de réduire le recours aux importations manuelles de ressources, aux tables de restauration temporaires, à la reconfiguration des points de terminaison et au rapprochement des états en situation de pression.

Un exemple concret

Imaginons un environnement de production entièrement géré via Terraform. Une table DynamoDB gère les stocks ; un compartiment S3 stocke les ressources de l’application ; les rôles et les politiques de gestion des identités et des accès sont codifiés ; et les politiques de protection sont définies via Terraform. Si une corruption survient avant un pic de trafic important, les méthodes de restauration traditionnelles peuvent créer de nouvelles ressources qui devront être réintégrées dans Terraform.

Avec Backtrack, la restauration est conçue pour s’effectuer dans les limites des ressources existantes, ce qui permet de préserver l’intégrité de l’infrastructure définie et de conserver l’identité des ressources. Cette approche vise à éviter d’avoir à mettre à jour Terraform pour prendre en charge un bucket ou une table nouvellement créé(e), en considérant la restauration comme une opération au niveau de la couche de données plutôt que comme un processus de remplacement de l’infrastructure.

Pourquoi est-ce important pour Platform ?

Pour les équipes qui ont adopté l’IaC, les workflows de reprise doivent préserver l’identité des ressources, l’alignement des états, l’intégrité de la configuration et la prévisibilité opérationnelle. La restauration sur place contribue à la réalisation de ces objectifs en limitant les modifications apportées à l’infrastructure lors des opérations de reprise.

Récupération à Cloud

Backtrack est conçu pour fonctionner à cloud , qu’il s’agisse de restaurer un petit nombre d’objets ou de grands ensembles de données. Les performances de restauration varient en fonction de la taille de la charge de travail et de la configuration de l’environnement, mais l’objectif architectural reste le même : restaurer les données sans entraîner de nouveaux écarts au niveau de l’infrastructure. Pour les environnements gérés par Terraform, cette distinction est importante.

Dans quel contexte cette approche s’inscrit-elle ?

La restauration sur site est particulièrement indiquée dans les cas suivants :

  • Charges de travail DynamoDB à haut débit
  • Compartiments S3 contenant un grand nombre d’objets
  • Systèmes de production entièrement gérés via Terraform
  • dans des environnements complexes où il est difficile de rediriger les dépendances des applications vers de nouvelles ressources

Lorsque l’infrastructure est définie de manière déclarative, les processus de reprise doivent s’aligner sur cette même approche.

Pour commencer

Pour découvrir Clumio Backtrack et son intégration avec Terraform :

Définir la protection sous forme de code n’est qu’une partie du processus. La conception de workflows de reprise qui préservent l’intégrité de l’infrastructure vient compléter ce modèle.

FAQ

Q : Quels problèmes les restaurations traditionnelles posent-elles dans les environnements gérés par Terraform ?

R : Les restaurations traditionnelles créent souvent de nouvelles ressources, telles que des compartiments S3 de remplacement ou des tables DynamoDB, qui ne sont pas définies dans l’état Terraform. Cela peut entraîner une dérive de l’infrastructure et obliger les équipes à importer manuellement des ressources et à harmoniser les configurations lors d’incidents critiques.

Q : En quoi Clumio Backtrack se distingue-t-il des méthodes de restauration classiques ?

R : Au lieu de déployer une nouvelle infrastructure, Clumio Backtrack est conçu pour restaurer les données directement dans la ressource AWS existante. Cette approche permet de préserver l’identité de la ressource et de maintenir l’état de Terraform en adéquation avec la configuration déclarée.

Q : Quels sont les services AWS pris en charge par Clumio Backtrack ?

R : Clumio Backtrack prend en charge Amazon S3 et Amazon DynamoDB. Il est conçu pour restaurer les objets S3 dans le compartiment d’origine et les données DynamoDB dans la table d’origine, ce qui permet de garantir la cohérence avec l’infrastructure définie par code.

Q : Pourquoi la restauration sur site est-elle importante pour platform ?

R : Platform s’appuient sur l’infrastructure en tant que code pour garantir la cohérence et le contrôle. La restauration sur place permet de maintenir l’alignement des états, l’intégrité de la configuration et la prévisibilité opérationnelle sans introduire de modifications supplémentaires au niveau de l’infrastructure lors des opérations de restauration.

Q : Dans quels cas la restauration sur site s’avère-t-elle particulièrement utile ?

R : Cette solution est particulièrement utile pour les charges de travail DynamoDB à haut débit, les compartiments S3 contenant un grand nombre d’objets et les systèmes de production entièrement gérés via Terraform. Elle peut également s’avérer avantageuse dans les environnements où la redirection des dépendances des applications vers des ressources nouvellement créées s’avérerait complexe ou risquée.

Q : Comment les équipes peuvent-elles se lancer dans l’intégration de Clumio Backtrack et de Terraform ?

R : Les équipes peuvent consulter la documentation du fournisseur Clumio Terraform, explorer le code source du fournisseur sur GitHub et visionner la vidéo de démonstration « Backtrack » mentionnée dans l’article de blog pour comprendre les détails de la mise en œuvre et du flux de travail.

Lawrence Chang est directeur technique chez Clumio et Vir Choksi est responsable principal du marketing produit chez Commvault.

More related posts

Thumbnail_Blog-AWS-Data-Protection-Terraform-Clumio-2026

Automating AWS Data Protection with Terraform and Clumio

Read more
Thumbnail_Blog_Clumio-Tech-2025

Restore only what matters: Clumio Backtrack for DynamoDB

Read more
Thumbnail_Blog-GoogleWorkspace-2026

How the Move to Clumio Delivered 66.7% Savings on AWS Backups

Read more
Thumbnail_Blog_AWS-Marketplace-AI

Commvault Featured in New AI Agent Solutions in AWS Marketplace

Read more
Man-and-woman-working-on-laptops-profile-Crocus-Thumbnail

Protecting Your Amazon S3 Data with Clumio: A Comprehensive Solution

Read more

Clumio

Read more

Points clés à retenir

  • La plupart des exercices sur table servent à valider les performances plutôt qu’à mettre en évidence les véritables lacunes dans la gestion des incidents.
  • Pour que les exercices soient efficaces, ils doivent intégrer des éléments de friction, d’ambiguïté et de pression afin de refléter des situations réelles.
  • Limiter la portée de l’exercice à quelques scénarios critiques et considérer que le succès consiste à identifier des problèmes plutôt qu’à faire bonne figure peut permettre d’obtenir des enseignements plus pertinents et plus exploitables.
  • La participation de différents services, et pas seulement celle des équipes techniques, est essentielle pour évaluer avec précision la capacité de réaction de l’organisation.
  • C’est par des tests de reprise réels, et non par de simples scénarios théoriques, que l’on peut démontrer une véritable résilience.

Il y a un moment que la plupart des responsables de la sécurité reconnaissent, même s’ils ne le disent pas à voix haute. L’exercice sur table vient de s’achever. L’équipe se disperse. Tout le monde semble raisonnablement satisfait. Et quelque part, au fond de votre esprit, une question silencieuse surgit : avons-nous réellement appris quelque chose ?

Si vous êtes honnête, la réponse est souvent « non ».

Ce n’est pas parce que les exercices sur table sont une mauvaise idée. Ils constituent l’un des outils les plus précieux dont dispose un responsable de la sécurité. Le problème réside dans la manière dont la plupart des organisations les mènent – et dans ce qu’elles mesurent réellement lorsqu’elles le font.

Le piège de la performance

L’erreur la plus courante dans les exercices sur table n’a rien à voir avec le scénario. Elle concerne l’objectif. La plupart des équipes, consciemment ou non, conçoivent des exercices destinés à démontrer leurs compétences plutôt qu’à mettre au jour des lacunes.

Le scénario suit généralement un déroulement sans heurts. Les informations arrivent dans un ordre logique. Les bonnes personnes disent ce qu’il faut. Tout le monde se sent prêt. Et ce sentiment – de confiance, de maîtrise, presque de collégialité – est précisément le problème. Les incidents réels ne se déroulent pas selon un scénario parfait. Ils se manifestent avec des informations incomplètes, des signaux contradictoires, des personnes injoignables et une entreprise qui exige des réponses plus rapidement que ne le permettent les faits. Si votre exercice sur table ne reproduit pas ce genre de difficultés, c’est que vous n’avez pas testé la réponse aux incidents. Vous vous êtes contenté de vous entraîner à mener une conversation.

Lorsque l’exercice est conçu pour valider plutôt que pour mettre à l’épreuve, un deuxième problème apparaît : les gens cessent d’être honnêtes. Personne ne dit : « Je ne sais pas à qui revient cette décision » ou « Nous n’avons en réalité jamais testé ce plan de Recovery ». Ils disent ce qui semble correct. Et les lacunes qui devraient apparaître dans un environnement contrôlé restent cachées jusqu’à ce qu’elles se manifestent dans un environnement réel.

Ce qu’un bon exercice permet réellement d’évaluer

Avant de créer un scénario, vous devez répondre à une question plus simple : que souhaitez-vous réellement apprendre ? Pas 20 choses. Trois ou quatre.

Votre équipe est-elle capable de prendre une décision d’arrêt suffisamment rapidement, et tout le monde sait-il qui a le pouvoir de la prendre ? Lorsque les services de sécurité, informatique, juridique et de communication sont tous réunis dans une même pièce avec des priorités contradictoires, parviennent-ils réellement à prendre des décisions ensemble ? Pouvez-vous expliquer l’impact métier d’un incident de manière suffisamment claire pour que la direction agisse – et pas seulement comprenne ? Et si vous deviez restaurer un système critique dans les quatre prochaines heures, seriez-vous vraiment capable de le faire ?

Une fois que vous savez ce que vous testez, élaborez un scénario comportant de réelles difficultés. Rendez une personne clé indisponible en cours d’exercice. Introduisez une escalade de la part d’un client. Faites en sorte qu’un régulateur pose une question à laquelle l’équipe ne peut pas répondre à partir du manuel d’intervention.

Donnez aux participants des informations incomplètes et observez comment ils prennent quand même des décisions. L’intérêt ne réside pas dans le fait de voir les gens réussir sous pression. Il réside dans l’identification des points de rupture du processus tant que les enjeux sont encore suffisamment faibles pour pouvoir y remédier.

Dites ceci à voix haute dès le début : « Aujourd’hui, réussir, c’est identifier les problèmes, pas faire bonne impression. » Cette simple phrase change la façon dont les gens s’expriment dans la salle.

Le problème des personnes

Une simulation qui se limite aux services de sécurité et informatiques relève d’une discussion technique, et non d’un exercice de gestion d’incident. Si le service juridique n’est pas présent, si le service de communication n’est pas présent, si les responsables métier et la direction générale sont absents, vous ne testez pas la manière dont votre organisation réagit réellement à une crise. Vous testez simplement la façon dont un groupe de personnes compétentes analyse un scénario hypothétique. Les incidents réels sont gérés à tous les niveaux de l’entreprise. L’exercice doit refléter cette réalité.

Il ne suffit pas d’en parler

C’est là que la plupart des organisations s’arrêtent. Un exercice théorique est important, mais il ne suffit pas à inspirer confiance. Discuter d’un scénario de Recovery vous apporte certaines informations. Restaurer concrètement un système vous en apporte d’autres. Pouvez-vous rétablir l’identité à un moment précis où le système était sain ? Pouvez-vous valider que ce que vous restaurez est fiable ? Pouvez-vous restaurer une application de niveau 1 et confirmer qu’elle redémarre correctement, sans propager l’infection ?

Ce ne sont pas des questions auxquelles on peut répondre dans une salle de réunion. À un moment donné, le projet doit être confronté à son environnement – et il faut savoir s’ils sont compatibles.

Une fois l’exercice terminé

Le débriefing vous indique si l’exercice a eu un intérêt. Si le débriefing à chaud est silencieux, vague ou truffé de « bons rappels », c’est que l’exercice n’a pas été suffisamment poussé. Un exercice sur table bien mené devrait vous laisser une liste concise de constats concrets, des responsables clairement identifiés et des échéances précises. Si vous ne pouvez pas répondre aux questions suivantes : qu’est-ce qui a échoué, qui va y remédier et dans quel délai ?, c’est que vous avez organisé un événement, pas un exercice.

Le but n’a jamais été de réussir cet exercice. Il s’agissait d’apprendre quelque chose d’important alors que le prix à payer en cas d’erreur n’était encore que du temps. Écoutez notre dernier épisode du podcast STRIVE, dans lequel je m’entretiens avec mon collègue Chris Mierzwa, directeur senior du marketing de portefeuille, pour une discussion approfondie sur les exercices sur table.

FAQ

Q : Pourquoi la plupart des exercices sur table ne parviennent-ils pas à apporter une réelle valeur ajoutée ?

R : De nombreux exercices sont conçus pour donner l’impression que les équipes sont bien préparées, plutôt que pour mettre en évidence leurs faiblesses. Cela conduit à des discussions « scénarisées » qui ne reflètent ni l’imprévisibilité ni la pression des incidents réels.

Q : Quel devrait être l’objectif d’un exercice sur table ?

R : Il convient de se concentrer sur un petit nombre de questions essentielles, telles que la rapidité de la prise de décision, la clarté des responsabilités et la capacité de reprise. Cette approche permet aux équipes de mettre en évidence des lacunes significatives plutôt que de se contenter d’observations superficielles.

Q : Comment les organisations peuvent-elles rendre leurs exercices plus réalistes ?

R : Introduisez des éléments d’incertitude, des informations manquantes et des perturbations imprévues au cours du scénario. Ces éléments obligent les équipes à faire preuve d’esprit critique et à agir sous pression, dans des conditions plus proches de celles d’un incident réel.

Q : Qui devrait participer à un exercice sur table ?

R : Outre les équipes chargées de la sécurité et de l’informatique, les équipes juridiques et de communication, ainsi que les responsables opérationnels et les cadres dirigeants, devraient y participer. Cela permet à l’exercice de refléter la manière dont les incidents réels sont gérés à l’échelle de l’organisation.

Q : Pourquoi ne suffit-il pas de parler de son rétablissement ?

R : Les discussions peuvent mettre en évidence les plans, mais seuls des tests concrets permettent de vérifier si les systèmes peuvent réellement être restaurés de manière propre et rapide. Une validation pratique est nécessaire pour confirmer que la reprise est prête.

Q : Qu’est-ce qui permet de considérer qu’un exercice sur table a été couronné de succès ?

R : Un exercice efficace débouche sur des conclusions claires, la désignation de responsables et la définition d’un calendrier précis pour la mise en œuvre des mesures correctives. Si ces éléments font défaut, c’est que l’exercice n’a probablement pas suffisamment mis l’équipe à l’épreuve.

Chris Bevil est directeur du département « Cyber-résilience mondiale et IA » chez Commvault.

More related posts

Thumbnail_Blog-Commvault-Enhancements-Cyber-Recovery-2026

Commvault Enhancements in Cyber Recovery

Read more
Readiverse-Featured-Image-888-x-500

Ready Is Good. Resilient Is Better.

Read more
Thumbnail_5_MV_Blogs_2025

Recovery Testing: The Missing Piece in Most Cyber Resilience Programs

Read more
Urgent-Need-for-Cyber-Resilience

The Urgent Need for Cyber Resilience

Read more
Thumbnail_Blog_Modern-Playbook-2025

Your Modern Playbook for Rapid Response and Clean Recovery

Read more

Points clés à retenir

  • La gouvernance de l’accès aux données de Commvault, optimisée par Satori, unifie la visibilité, le contrôle d’accès et la traçabilité pour les données structurées, les fichiers non structurés, SaaS et les charges de travail d’IA.
  • Une politique d’accès unique et cohérente peut s’appliquer à la fois aux utilisateurs humains et aux modèles d’IA, ce qui contribue à réduire les cloisonnements et à limiter la surexposition des données sensibles.
  • La détection, la classification et l’évaluation continue des risques permettent d’identifier de manière hiérarchisée où se trouvent les données sensibles et où le risque d’exposition est le plus élevé.
  • Le masquage et la caviardage dynamiques, régis par des règles, contribuent à faire respecter le principe du « privilège minimal », permettant ainsi une utilisation autorisée des données tout en contribuant à protéger les champs sensibles.
  • Des journaux d’audit centralisés et en temps quasi réel offrent une visibilité complète sur les requêtes des utilisateurs, les invites d’IA et les événements d’accès régis, afin de faciliter la conformité et la responsabilisation.

L’IA étant désormais intégrée à tous les flux de travail, des copilotes aux assistants de chat en passant par les outils d’analyse, tous ces terminaux ont un appétit insatiable pour les données. Les fonctionnalités de gouvernance de l’accès aux données de Commvault, optimisées par Satori, sont conçues pour répondre à cet appétit insatiable de l’IA en unifiant la visibilité, le contrôle d’accès et l’auditabilité à l’échelle de votre environnement de données.

Une base unifiée pour la gouvernance des données à l’ère de l’IA

Les fonctionnalités de gouvernance de l’accès aux données de Commvault regroupent les bases de données structurées, les fichiers non structurés SaaS et les charges de travail d’IA au sein d’un modèle de gouvernance unique, au lieu de les traiter comme des silos distincts. Les entreprises peuvent désormais appliquer une politique d’accès unique tant aux utilisateurs humains qu’aux modèles d’IA, de sorte que les mêmes règles déterminent qui ou quoi peut consulter les informations sensibles, quel que soit leur emplacement.

Grâce à l’intégration de Satori au Commvault Command Center, ces fonctionnalités étendent la protection traditionnelle de Commvault aux données en temps réel et à l’utilisation de l’IA, et ne se limitent plus aux seules sauvegardes et instantanés. Cela permet aux équipes chargées de la sécurité et de la protection des données de passer d’une réponse réactive aux incidents à un contrôle proactif de la manière dont les données sont identifiées, consultées et utilisées en temps réel.

Détection, classification et évaluation des risques en continu

L’un des piliers fondamentaux de nos capacités en matière de gouvernance des données réside dans la découverte et la classification unifiées des données sur l’ensemble des environnements cloud et SaaS. À mesure que les entreprises se connectent à des environnements tels qu’AWS, Azure, Google Cloud, Snowflake, Databricks et bien d’autres, Commvault cartographie automatiquement les référentiels de données et les classe en continu, qu’il s’agisse de données structurées ou non structurées.

Une note de risque est attribuée à chaque ressource, ce qui permet aux équipes d’identifier, par ordre de priorité, les emplacements où se trouvent les informations sensibles et ceux où le risque d’exposition est le plus élevé. Plutôt que de s’appuyer sur des analyses périodiques, la platform en temps réel les mouvements de données, les nouveaux emplacements de stockage et les changements de classification, aidant ainsi les équipes à détecter les problèmes plus tôt et à se concentrer en priorité sur les zones présentant le plus grand risque.

Accès selon le principe du « privilège minimal » avec masquage et expurgation dynamiques

La protection traditionnelle des données se limite souvent à savoir où se trouvent les données sensibles ; les fonctionnalités de Commvault mettent l’accent sur le contrôle de la manière dont ces données sont divulguées. Grâce au masquage et à la caviardage basés sur des règles, les entreprises peuvent appliquer le principe du « privilège minimal » en matière d’accès, de sorte que les utilisateurs, les services et les modèles d’IA n’aient accès qu’aux informations spécifiques qu’ils sont autorisés à consulter, les champs sensibles étant anonymisés ou masqués selon les besoins.

Étant donné que les mêmes politiques de masquage et de suppression s’appliquent à tous les environnements connectés, les entreprises peuvent garantir une protection cohérente des accès, plutôt que de recourir à des règles fragmentées, définies application par application. Cela permet de réduire le risque de surexposition des données, c’est-à-dire le fait qu’un trop grand nombre de personnes ou de systèmes aient accès à davantage de données qu’ils n’en ont légitimement besoin.

Sécurité et gestion rapide et sûre

L’une de ses fonctionnalités phares est la sécurité IA basée sur des politiques, qui intervient dès la saisie de la requête et de la réponse. Avant même que les données ne soient transmises à un modèle d’IA, Commvault, grâce à la technologie Satori, peut intercepter l’interaction, détecter les champs sensibles (tels que les données personnelles soumises à une réglementation) et appliquer un masquage ou une expurgation en ligne, conformément aux politiques d’accès aux données en vigueur.

Contrairement aux solutions qui se contentent de bloquer des invites entières ou qui s’appuient uniquement sur la prévention de la perte de données en aval (laissant ainsi la sécurité à la charge d’autrui), cette approche permet aux employés de continuer à utiliser les assistants IA de manière productive tout en maintenant les données sensibles sous contrôle. La masquage des données ayant lieu avant que le modèle ne traite celles-ci, cela contribue également à empêcher que des informations sensibles n’influencent ou ne contaminent les ensembles de données d’entraînement de l’IA, protégeant ainsi à la fois les utilisateurs et l’environnement global de l’IA.

Les pistes d’audit centralisées facilitent la mise en conformité

Le dernier élément de nos capacités de gouvernance de l’accès aux données est un système complet et centralisé de journalisation des audits. Chaque interaction – qu’il s’agisse d’une requête utilisateur, d’une instruction donnée à l’IA ou d’un événement d’accès régulé – est enregistrée en temps quasi réel, avec des détails tels que l’identité de la personne ayant accédé aux données, la politique appliquée et les expurgations effectuées.

Cette visibilité unifiée sur les audits couvre à la fois les données en temps réel, les invites générées par l’IA et les événements liés à la gouvernance des accès, offrant ainsi aux responsables de la sécurité, de l’informatique et de la conformité un registre unique faisant autorité, plutôt que des journaux disparates provenant d’outils ponctuels. Pour les RSSI et les DSI, cela se traduit par des contrôles de conformité plus rapides et la preuve tangible que la gouvernance n’est pas seulement documentée sur papier, mais qu’elle est activement appliquée dans l’ensemble de l’environnement.

Aider les organisations à adopter l’IA en toute sécurité

Prises dans leur ensemble, ces nouvelles fonctionnalités offrent aux organisations une approche cohérente pour gouverner les données dans un monde où l’IA est omniprésente : une visibilité unifiée sur les clouds, le SaaS et l’IA ; une politique unique pour les utilisateurs et les modèles ; un masquage et une expurgation dynamiques pour un accès selon le principe du moindre privilège ; et une protection des invites d’IA respectueuse des politiques, étayée par des pistes d’audit complètes. Il en résulte une transition des contrôles réactifs vers une gouvernance proactive de l’accès aux données, prête pour l’IA, qui aide les équipes à adopter l’innovation en matière d’IA tout en conservant le contrôle de leurs informations les plus sensibles.

FAQ

Q : En quoi l’approche de Commvault en matière de gouvernance des données par l’IA se distingue-t-elle de la protection traditionnelle des données ?

R : La protection traditionnelle des données se concentre souvent sur les sauvegardes et la réponse aux incidents après qu’une exposition s’est produite. Commvault étend la gouvernance aux environnements en production et aux interactions avec l’IA, permettant ainsi un contrôle proactif sur la manière dont les données sont découvertes, consultées et utilisées en temps réel. Cette évolution aide les organisations à gérer les risques avant qu’ils ne se transforment en violation de données.

Q : En quoi la recherche et la classification unifiées améliorent-elles la sécurité ?

R : La découverte et la classification continues cartographient et étiquettent automatiquement les données structurées et non structurées sur l’ensemble des clouds et des plateformes SaaS. En attribuant des scores de risque à chaque ressource, les équipes bénéficient d’une vue hiérarchisée de l’exposition des données sensibles. Cela permet d’identifier plus rapidement les zones à haut risque et de mener des efforts de correction plus ciblés.

Q : Qu’est-ce que le masquage dynamique, et pourquoi est-il important pour les charges de travail liées à l’IA ?

R : Le masquage et la caviardage dynamiques limitent ce que les utilisateurs, les services et les modèles d’IA peuvent voir, en fonction de politiques prédéfinies. Les champs sensibles peuvent être anonymisés ou masqués tout en autorisant un accès légitime aux données pertinentes. Cette approche favorise la productivité tout en contribuant à réduire le risque de surexposition.

Q : Comment fonctionne la protection des invites d’IA tenant compte des politiques ?

R : La sécurité IA basée sur des politiques intercepte les invites et les réponses avant que les données n’atteignent le modèle d’IA. Elle permet de détecter les informations sensibles et d’appliquer un masquage ou une expurgation en ligne conformément aux politiques existantes. Cela permet aux employés de continuer à utiliser les outils d’IA tout en garantissant que les données réglementées restent sous contrôle et ne figurent pas dans les ensembles de données d’entraînement.

Q : En quoi les pistes d’audit centralisées contribuent-elles aux efforts de mise en conformité ?

R : Une journalisation d’audit complète enregistre des détails sur les personnes ayant accédé à quelles données, les politiques appliquées et les expurgations effectuées. Cette visibilité unifiée couvre à la fois les données en temps réel et les interactions avec l’IA, offrant ainsi aux responsables de la sécurité et de la conformité un historique clair et faisant autorité. Elle permet d’accélérer les examens et de démontrer que les contrôles de gouvernance sont activement appliqués.

Q : En quoi ces fonctionnalités aident-elles les entreprises à adopter l’IA en toute sécurité ?

R : En associant une visibilité unifiée, une application cohérente des politiques, un masquage dynamique et des pistes d’audit complètes, les fonctionnalités de gouvernance des données de Commvault offrent aux organisations un cadre cohérent pour gérer les données à l’ère de l’IA. Ces contrôles favorisent l’innovation tout en permettant de garder la maîtrise des informations sensibles. Il en résulte un parcours plus sûr et plus serein vers l’adoption de l’IA.

Nico Guerrera est responsable marketing technique senior chez Commvault.

More related posts

Social_Blog_Satori_GigaOm_Leader_2026_Linkedin

Satori Named Leader in GigaOm’s Data Access Governance Radar Report

Read more
Thumbnail_Blog-Conversational-Resilience-2025-Linkedin

Conversational Resilience: The New Way to Manage and Protect Enterprise Data

Read more
Thumbnail_Blog_Satori-Acquisition-2025

Commvault Closes Acquisition of Satori, Strengthening Data and AI Security Platform

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more