Depuis des années, le stockage de type S3 est devenu le point central de tout : exportation de bases de données, dumps d’applications, snapshots de services SaaS, datasets analytiques… et, de plus en plus, de données liées à des projets d’Intelligence Artificielle. Le problème réside souvent dans cette commodité, qui s’accompagne d’une « petite écriture » : buckets dispersés, politiques incohérentes, rétentions mal définies et gouvernance des données reposant davantage sur une discipline humaine que sur une conception réfléchie.

Dans ce contexte, Commvault a annoncé le Commvault Cloud Unified Data Vault, un service cloud native conçu pour pallier précisément cette faille : protéger de façon automatique et centralisée les données écrites “via S3” dans un cadre résilient comprenant des politiques, l’inimmutabilité et un isolement via air gap, sans obliger les équipes à déployer des agents ni à créer des silos supplémentaires.

L’approche est simple à expliquer mais difficile à mettre en œuvre efficacement : au lieu d’« appliquer une protection après coup » (quand la donnée est déjà dispersée), le Unified Data Vault propose un point de terminaison S3 compatible géré par Commvault. Autrement dit, pour le développeur ou l’équipe de plateforme, le flux ressemble à un simple « écriture dans S3 » ; mais, en coulisses, la donnée entre déjà dans un environnement où elle hérite immédiatement de chiffrement, de déduplication, de contrôles de rétention, de gouvernance par politiques et d’inimmutabilité.

La nuance clé : le chaos ne réside pas dans la donnée elle-même, mais dans l’opérationnel

La majorité des organisations croit déjà avoir “quelque chose en place” sur S3 : règles de cycle de vie, Object Lock, configurations par compte, scripts de rétention, nomenclatures, réplications… Le problème, c’est qu’en cas d’incidents réels (rançongiciels, suppressions accidentelles, erreurs de configuration, compromissions de credentials), la récupération commence souvent par une étape peu glamour : identifier le bucket fiable, la politique réellement appliquée, qui a touché quoi et quand, et si la donnée critique était sous protection inaltérable.

Commvault commercialise le Unified Data Vault comme une solution pour réduire cette incertitude, en déplaçant le contrôle « vers l’entrée » : si la donnée est écrite à cet endpoint, elle est protégée dans un cadre résilient dès le départ. L’objectif n’est pas de remplacer S3 en tant que concept, mais d’éviter que la protection ne dépende de configurations fragmentées et difficilement auditable.

Pourquoi cela concerne autant les équipes data que la sécurité

Le Unified Data Vault vise à lever une friction très courante entre profils :

• Développement/Équipe Data : recherchent des flux S3 “natifs”, automatisables, intégrables dans CI/CD et pipelines de données.
• SecOps/IT : veulent des garanties de rétention, d’inimmutabilité, d’isolation et de traçabilité, sans dépendre de “bonnes pratiques” dispersées sur des milliers de comptes et régions.

La promesse est que chacun y gagne : l’équipe technique conserve un modèle familier (S3), tandis que l’équipe de résilience peut appliquer des politiques et des contrôles sans devoir auditer ses buckets un par un.

Comparatif rapide : ce qui change face à d’autres approches

Un exemple pratique : écrire vers un endpoint S3 compatible (sans “inventer” une nouvelle infrastructure)

Si votre application exporte déjà des backups ou datasets vers S3, une simple modification opérationnelle consiste à pointer vers un endpoint S3 compatible différent (en fonction des paramètres et des credentials fournis par le service) :

AWS CLI (exemple générique) :

aws s3 cp backup.dump s3://mon-bucket-protege/exports/backup.dump 
  --endpoint-url https://ENDPOINT_S3_COMMVAULT

Python (boto3, exemple générique) :

import boto3

s3 = boto3.client(
    "s3",
    endpoint_url="https://ENDPOINT_S3_COMMVAULT",
    aws_access_key_id="CLE_Access",
    aws_secret_access_key="CLE_Secrète",
)

s3.upload_file("backup.dump", "mon-bucket-protege", "exports/backup.dump")

Ce qui est intéressant, c’est que l’équipe n’a pas besoin de redévelopper ses outils : elle continue à utiliser S3, mais la donnée arrive déjà avec les politiques de résilience applicables.

Disponibilité et déploiement : une approche aussi pensée pour les partenaires

Commvault a placé le service en Early Access, avec une sortie officielle prévue pour le printemps 2026. La société le présente comme une pièce pouvant être déployée via son écosystème de partenaires, avec un discours clair à l’intention des MSPs et fournisseurs gérés : moins de “bricolage” par client (scripts, règles sur mesure, variations par compte), pour un service plus standardisé avec des politiques centralisées.

Questions fréquentes

Unified Data Vault remplace-t-il S3 ou mon fournisseur cloud ?
Non, il ne s’agit pas de “remplacer S3” en tant que tel, mais d’offrir un endpoint S3 compatible géré par Commvault permettant de centraliser la résilience des données écrites via ce protocole.

Dans quels cas est-il le plus adapté : backups, datasets ou les deux ?
Particulièrement lorsque l’on a déjà pour habitude d’exporter vers S3 : sauvegardes de bases de données, snapshots d’applications, ainsi que les données d’Intelligence Artificielle (datasets, dépôts intermédiaires, résultats de pipelines).

Quels bénéfices par rapport à des politiques de rétention et d’inimmutabilité sur des buckets dispersés ?
Réduit le risque de configuration incohérente et accélère la récupération : plutôt que de vérifier la politique de chaque bucket individuellement, la donnée évolue déjà dans un environnement gouverné de façon centralisée.

Faut-il installer des agents sur serveurs ou bases de données ?
La solution repose sur une approche sans agent pour ces flux S3 : l’application écrit directement dans le endpoint compatible, et hérite automatiquement de la protection.

via : commvault