Catégorie : Sauvegarde & PRA

88 % des entreprises utilisent déjà des agents IA en production ou en test, mais 7 % seulement se disent prêtes à encaisser les dégâts qu’ils peuvent causer. C’est le chiffre qui ouvre le communiqué de Veeam du 15 octobre 2026 annonçant la disponibilité générale d’Intelligent ResOps (iResOps) pour Microsoft 365. Et il résume bien le problème : un agent Copilot qui modifie ou supprime des fichiers par erreur dans SharePoint, ça arrive déjà, et la plupart des équipes IT ne le savent même pas tant que ça ne fait pas de bruit.

Ce que fait vraiment iResOps pour Microsoft 365

iResOps n’est pas un nouveau produit de sauvegarde — c’est un module qui se branche sur Veeam Data Cloud for Microsoft 365 déjà en place, sans migration de données ni refonte d’architecture. Son rôle : relier les données de production à leur contexte de sauvegarde via ce que Veeam appelle le DataAI Command Graph, une couche qui couvre SharePoint, OneDrive, Teams et Exchange Online. Les capacités de sécurité et de gouvernance viennent en grande partie de Securiti AI, une société que Veeam a rachetée pour bâtir cette plateforme DataAI Command.

Concrètement, trois blocs de fonctions :

• Découverte des agents IA et de leurs accès : iResOps détecte les agents présents dans le tenant — Copilot en tête — et montre à quelles données sensibles chacun peut toucher. Il signale le partage excessif, ce qui est souvent la vraie porte d’entrée du problème plutôt que l’agent lui-même.
• L’« AI agent file undo » : quand un agent modifie ou supprime des fichiers à tort, les admins voient les changements fichier par fichier et peuvent annuler individuellement — pas besoin de restaurer tout un site SharePoint pour récupérer un seul document corrompu. Veeam ne détaille pas la profondeur d’historique disponible ni le mécanisme technique exact de restauration, donc à vérifier en POC si cette granularité correspond à ton besoin réel.
• Classification et nettoyage ROT (données redondantes, obsolètes, triviales) sur les quatre charges de travail M365, avec mise en quarantaine avant archivage ou suppression définitive, et une fonction de « minimum viable recovery » qui repère les données prioritaires et les lacunes de couverture avant qu’un incident ne les révèle.

Pourquoi maintenant : la friction entre agents IA et gouvernance des données

Le chiffre le plus inquiétant du Data Trust & Resilience Report 2026 de Veeam n’est pas celui des 88 % d’adoption — c’est que plus de 82 % des entreprises ont des agents IA non identifiés dans leur environnement IT. Autrement dit, la plupart des DSI pilotent une flotte d’agents dont ils ne connaissent qu’une partie. Un agent qui réécrit des fichiers dans Teams sans qu’on sache qu’il existe, c’est le scénario exact que la fonction de découverte d’iResOps cible.

Ça rejoint un problème qu’on a déjà creusé côté couverture M365 native : notre article sur ce que Microsoft 365 Backup couvre vraiment montrait déjà que la protection native laisse des angles morts sur la gouvernance fine. iResOps ne remplace pas une stratégie de sauvegarde — il ajoute une couche de contexte et de réversibilité par-dessus, ce qui est différent.

Ce qui arrive ensuite : la feuille de route iResOps

Microsoft 365 est le premier produit de la gamme iResOps à atteindre le GA depuis son lancement en mai 2026 — les autres sont encore en Private Preview, à des stades d’avancement très différents :

• Veeam Data Platform (Private Preview) : connecte les serveurs de sauvegarde existants à DataAI Command, avec recherche globale, récupération de fichiers et trois agents IA intégrés. La version 13.2 est attendue en GA plus tard au T4 2026.
• Okta (Private Preview) : service géré pour corriger les erreurs de configuration et les modifications malveillantes d’identités, avec des points de restauration immuables sur 29 types d’objets et une fenêtre de suppression réversible de 30 jours.
• GitHub, Azure DevOps et Google IAM : Private Previews prévues plus tard au T4 2026.

Si tu protèges déjà tes workloads M365 avec Veeam, le module Microsoft 365 est disponible dès aujourd’hui en add-on sur les éditions Foundation et Advanced de Veeam Data Cloud for Microsoft 365, ou via les Veeam Cloud & Service Providers. Pour les autres briques, patience — on parle de previews, pas de produits stabilisés, et Veeam prévient lui-même que les fonctionnalités en Private Preview peuvent encore changer.

Est-ce que ça vaut le coup de s’y intéresser maintenant ?

Oui, si Copilot ou un autre agent IA tourne déjà sur ton tenant M365 et que tu n’as aucune visibilité sur ce qu’il touche — c’est précisément le trou que ce module comble, et c’est rare de voir un éditeur de sauvegarde attaquer le sujet par ce biais plutôt que par un simple argument de rétention plus longue. En revanche, si tu cherches une refonte complète de ta stratégie de sauvegarde M365, ce n’est pas le bon point d’entrée : iResOps suppose que tu as déjà Veeam Data Cloud for Microsoft 365 en place. Et pour tout ce qui touche aux autres briques de la gamme (Veeam Data Platform, Okta, GitHub…), mieux vaut attendre une stabilisation avant de t’engager en production, vu le nombre de Private Previews encore en jeu.

FAQ

iResOps pour Microsoft 365 nécessite-t-il de changer d’outil de sauvegarde ?

Non. C’est un add-on sur Veeam Data Cloud for Microsoft 365 — si tu utilises déjà ce produit, l’activation ne demande ni migration de données ni changement d’architecture.

Quelle est la différence avec notre récapitulatif des failles Veeam KB4902 ?

Rien à voir directement : KB4902 concerne des vulnérabilités corrigées dans Backup & Replication côté infrastructure on-prem. iResOps, lui, cible la gouvernance des données SaaS M365 face aux agents IA — deux périmètres de risque distincts chez le même éditeur.

Et si je n’utilise pas encore d’agents IA type Copilot dans mon tenant ?

La fonction de découverte reste utile : d’après Veeam, plus de 82 % des organisations ont des agents IA non identifiés dans leur environnement — tu pourrais en avoir sans le savoir, via des intégrations tierces ou des extensions activées par défaut.

En pratique

Si tu es déjà client Veeam Data Cloud for Microsoft 365, le plus simple est de demander une démo du module iResOps à ton contact Veeam ou à ton CSP pour voir la granularité réelle de l’« agent file undo » sur tes propres données avant de l’activer en production — c’est le genre de fonctionnalité dont la valeur se juge sur un cas concret, pas sur une fiche produit.

Le 25 août 2026, Veeam a publié deux avis de sécurité le même jour : KB4902 pour Backup & Replication, KB4905 pour Veeam ONE. Cinq CVE au total. Rien d’exceptionnel en apparence pour un éditeur qui patche plusieurs fois par an — sauf que l’une de ces failles touche un composant que tu utilises probablement tous les jours sans y penser, et qu’une autre se corrige sans interaction utilisateur depuis le réseau. Si tu gères des sauvegardes Veeam, voici ce qui mérite vraiment ton attention, dans l’ordre.

Ce que corrige KB4902

L’avis KB4902 couvre quatre vulnérabilités dans Backup & Replication, toutes signalées via le programme HackerOne de Veeam. Les correctifs arrivent avec la 13.1 (build 13.1.0.411), la 13.0.3 (13.0.3.63), et pour une des failles, la 12.3.2 Patch 4 (12.3.2.4934).

• CVE-2026-58070 (CVSS v4.0 6.8, moyenne) — les identifiants du compte invité utilisés pour le traitement Application-Aware se retrouvaient enregistrés en clair dans les journaux de la machine invitée. Concerne les versions Windows et l’appliance logicielle, de la 13.0.2.29 et antérieures ; la branche 12.x n’est pas touchée.
• CVE-2026-58069 (CVSS v4.0 8.3, élevée) — lecture arbitraire de fichiers sur l’hôte du fournisseur de services, exploitable par un locataire Cloud Connect authentifié. C’est celle qui doit inquiéter les MSP : un seul client malveillant ou compromis peut lire des fichiers côté hébergeur. Touche à la fois la 13.0.2.29- et la 12.3.2.4854-.
• CVE-2026-58068 (CVSS v4.0 6.8, moyenne) — déni de service sur des processus système via Veeam Agent for Microsoft Windows. Le champ de versions affectées remonte jusqu’à la branche 6, ce qui en dit long sur l’ancienneté de certains agents encore déployés en prod.
• CVE-2025-64391 (CVSS v4.0 4.1, moyenne) — un utilisateur local peut écrire un fichier arbitraire en tant que SYSTEM en manipulant des points de montage et des liens symboliques pendant l’installation de l’agent.

Le détail qui compte vraiment, c’est la mitigation donnée pour la 58070 : le patch empêche l’écriture de nouveaux mots de passe en clair dans les journaux, mais il ne nettoie pas ceux déjà présents. Si tu utilises le traitement Application-Aware sur des VM sensibles, change les identifiants concernés — patcher ne suffit pas à effacer ce qui est déjà loggé sur le disque.

Veeam ONE : la vraie urgence, CVSS 9.3

KB4905 publié le même jour est plus simple à résumer, et plus inquiétant. CVE-2026-65641 permet à un attaquant réseau non authentifié de forcer une authentification SMB depuis le compte de service de Veeam ONE — sans qu’aucun utilisateur n’ait à cliquer sur quoi que ce soit. Score CVSS v4.0 de 9,3, classé critique. Ça touche Veeam ONE 13.1.0.7034 et les builds 13 antérieures (la branche 12.x est épargnée), corrigé en 13.1 Patch 0 (build 13.1.0.7233) et 13.0.2 Patch 1 (13.0.2.7159).

Un attaquant qui obtient un hash NTLM via coercition SMB peut ensuite tenter un relais vers un autre service, ou simplement craquer le hash hors ligne. Sur un compte de service qui tourne souvent avec des droits étendus sur Active Directory, c’est exactement le genre de faille qu’on ne laisse pas traîner un trimestre avant de patcher.

Si tu es encore sur la branche 12, ce n’est pas la première fois cette année

Remonte un peu dans le calendrier 2026 et le tableau devient moins confortable. En mars, CVE-2026-21708 (injection SQL dans le Backup Viewer, CVSS 9.9) permettait une exécution de code sous l’utilisateur postgres — et touchait à la fois la 12.x et les premières builds 13.x. En juin, CVE-2026-44963 (CVSS 9.4) ouvrait une RCE sur le serveur de sauvegarde pour n’importe quel utilisateur de domaine authentifié, mais cette fois seulement sur la branche 12 : les changements d’architecture de la 13.x l’ont rendue immune de fait, sans correctif dédié nécessaire côté 13. Trois vagues de failles critiques en six mois sur la même branche, ça commence à ressembler moins à de la malchance qu’à une dette technique qu’il devient urgent de solder.

On a déjà détaillé les nouveautés fonctionnelles de la 13.1 — restauration de forêt AD, chiffrement post-quantique, support hyperviseurs élargi : la bascule depuis la 12.x n’est plus seulement un confort pour ces fonctionnalités, c’est une réduction mesurable de la surface d’attaque exposée à ton infra de sauvegarde.

Dans quel ordre patcher

Si tu dois prioriser avec un temps de maintenance limité : Veeam ONE d’abord (CVSS 9.3, zéro interaction requise), puis Backup & Replication sur les locataires Cloud Connect exposés (CVE-2026-58069), puis le reste. Et si ton infra tourne encore en 12.x, traite la migration vers la 13.x comme un chantier de sécurité, pas comme une simple montée de version fonctionnelle — ça rejoint directement la logique de la règle 3-2-1-1-0 : une sauvegarde immuable mais gérée par un serveur vulnérable n’est qu’une protection partielle.

FAQ

Le patch KB4902 suffit-il pour la fuite de mots de passe (CVE-2026-58070) ?
Non. Il empêche de nouvelles écritures en clair dans les journaux, mais ne purge pas les logs existants. Change les identifiants du compte invité utilisé pour le traitement Application-Aware après avoir patché.

Je suis encore en Backup & Replication 12.x, dois-je m’inquiéter de CVE-2026-65641 ?
Non, cette faille concerne uniquement Veeam ONE 13.x. En revanche, la 12.x reste concernée par CVE-2026-58069 (lecture de fichiers, Cloud Connect) et par les deux CVE critiques de mars et juin 2026.

Faut-il redémarrer les services après l’application des patchs ?
Les avis Veeam ne le précisent pas explicitement pour chaque CVE ; suis la procédure de mise à jour standard de Backup & Replication (arrêt des jobs en cours, mise à jour via le Patch Manager ou l’ISO, puis redémarrage des services Veeam) et vérifie la version effective après coup.

Ce qu’il faut retenir

Cinq failles corrigées en un seul patch Tuesday, deux critiques, une exploitable sans authentification. Si tu n’as qu’une chose à faire cette semaine : vérifie la version de ton Veeam ONE et patche-la en priorité, puis planifie la montée vers Backup & Replication 13.1 si tu es encore en 12.x. Les correctifs sont disponibles depuis fin août — le risque, à ce stade, c’est surtout le temps qu’il te reste avant qu’un scan automatisé repère l’instance non patchée.

57 % des RSSI mettent en moyenne plus de 4,5 jours à restaurer complètement leurs opérations après une cyberattaque, et aucun ne descend sous 24 heures. C’est le chiffre qu’avance Commvault — tiré d’une enquête d’Absolute Security auprès de 750 RSSI, le rapport « The Resilient CISO » — pour justifier l’extension de Cloud Rewind à Azure, annoncée le 18 août 2026. Le constat derrière ce chiffre : la plupart des plans de reprise ne découvrent qu’ils sont incomplets qu’au moment où on en a vraiment besoin.

Ce que Cloud Rewind fait, que ta sauvegarde classique ne fait pas

Une sauvegarde — la tienne, Veeam, Azure Backup, peu importe — protège des données. Elle ne protège pas la manière dont ces données s’articulent avec le reste : réseau virtuel, groupes de sécurité, identités managées, app settings, dépendances entre services. Après un incident, restaurer les données ne suffit pas si personne ne sait reconstruire l’infrastructure qui tournait autour.

C’est exactement le créneau que vise Cloud Rewind, lancé en octobre 2024 et bâti sur la technologie d’Appranix, une start-up cloud de Boston rachetée par Commvault. Le service découvre en continu les ressources cloud, cartographie leurs dépendances, puis orchestre la reconstruction de l’application complète — infrastructure, configuration et dépendances — pas seulement ses données. Tu peux aussi simuler une reprise avant l’incident réel, y compris dans un environnement isolé (air-gapped), ce qui change tout par rapport à un test de restauration classique qu’on fait une fois par an sous contrainte.

Le changement d’échelle du 18 août 2026

L’annonce triple la gamme de ressources Azure couvertes, pour atteindre 62 % des types de ressources que Commvault juge pertinents pour des déploiements d’entreprise. Deux nouveautés accompagnent cet élargissement :

• Protection Groups : les données applicatives et la configuration cloud sont regroupées dans un seul flux de reprise isolé, plutôt que gérées séparément.
• Protection basée sur des politiques : les nouvelles ressources découvertes s’inscrivent automatiquement selon leurs tags, leur région et leur type — et ça fonctionne sur plusieurs clouds depuis un seul workflow, pas uniquement sur Azure.

La couverture Azure élargie reste annoncée « dans les prochains mois » au moment de la publication — à vérifier directement dans ta console Commvault Cloud si tu es déjà client, la bascule peut très bien être en cours au moment où tu lis ces lignes.

Est-ce que ça remplace ce que tu as déjà en place ?

Non, et ce serait une erreur de le présenter comme ça. Si tu appliques déjà la règle 3-2-1-1-0 ou que tu utilises Veeam Data Cloud Vault pour l’immuabilité de tes sauvegardes Azure, Cloud Rewind ne remplace rien de tout ça : il vient en complément, sur la couche qui manque systématiquement dans les plans de PRA — la capacité à reconstruire l’environnement autour de la donnée, pas seulement la donnée elle-même. Même logique côté immuabilité Azure Backup : l’immuabilité protège contre la suppression ou le chiffrement de ta sauvegarde, pas contre l’absence de plan pour redéployer l’infra qui l’entoure.

Le modèle commercial suit cette logique de complément : Cloud Rewind est un module add-on de Commvault Cloud, facturé à l’usage selon le nombre de ressources cloud protégées — pas un forfait global qui remplacerait ta licence de sauvegarde existante.

Le contexte Microsoft derrière l’annonce

Commvault et Microsoft ont signé en juin 2026 un accord pluriannuel pour proposer la technologie de reprise de Commvault comme service Azure natif. Vu sous cet angle, l’extension de couverture d’août n’est pas un coup isolé : c’est une étape dans un rapprochement plus large entre les deux éditeurs, qui doit encore se traduire par une intégration plus profonde dans les mois qui viennent. Melinda Marks, analyste chez Omdia, résume le problème que ça cherche à adresser : beaucoup d’organisations découvrent que leur plan de reprise est incomplet « seulement après qu’un incident s’est produit ».

FAQ

Cloud Rewind remplace-t-il mon outil de sauvegarde ?

Non. Il protège la reconstruction de l’application (infra, configuration, dépendances), pas les données elles-mêmes — qui restent la responsabilité de ton outil de sauvegarde.

Quelles ressources Azure exactement sont couvertes ?

Commvault ne publie pas la liste détaillée des types de ressources, seulement le chiffre global de 62 % des types jugés pertinents pour l’entreprise. Si cette granularité est bloquante pour ta décision, il faut la demander directement à ton contact Commvault.

Qui est derrière la technologie ?

Appranix, une start-up cloud de Boston rachetée par Commvault en avril 2024, avant le lancement de Cloud Rewind en octobre de la même année.

Ce qu’il faut retenir

Teste ta reprise avant d’en avoir besoin : c’est le vrai message derrière cette annonce, bien plus que la fonctionnalité elle-même. Que tu passes par Cloud Rewind ou par un run book maison, la question à te poser est la même — si ton datacenter virtuel disparaît ce soir, qui sait reconstruire le réseau, les identités et les dépendances autour de tes sauvegardes, et en combien de temps ? Si la réponse n’est pas satisfaisante, c’est le bon moment pour relire ta stratégie de PRA plutôt que d’attendre le prochain incident pour le découvrir.

Veeam a sorti la version 13.1 de Backup & Replication le 29 juillet 2026, et ce n’est pas une mise à jour de confort. Deux fonctionnalités sortent clairement du lot pour qui protège une infrastructure Active Directory ou s’inquiète du chiffrement à long terme, et la liste des hyperviseurs supportés s’élargit enfin au-delà du duo VMware/Hyper-V habituel.

Restaurer une forêt Active Directory : d’un chantier de plusieurs jours à un assistant guidé

Si tu as déjà dû reconstruire une forêt AD après un ransomware qui a soufflé les contrôleurs de domaine, tu sais à quel point l’exercice est casse-tête : restaurer le premier DC porteur des rôles FSMO, nettoyer les métadonnées des objets orphelins, remettre le DNS d’aplomb, relancer la réplication dans le bon ordre — tout ça à la main, sous pression, un dimanche soir. Veeam 13.1 automatise cette séquence via un assistant qui guide chaque étape de la récupération de forêt, avec en plus une reconstruction des relations d’objets persistants pour Microsoft Entra ID.

Veeam ne communique pas de chiffre précis sur le temps gagné — ça dépend trop de la taille de la forêt et de l’état des sauvegardes. Le vrai gain, c’est la suppression des étapes manuelles à risque d’erreur, pas une automatisation à zéro intervention : il faut toujours un administrateur AD aux commandes, mais avec un filet sous les pieds.

Chiffrement post-quantique : anticiper le « harvest now, decrypt later »

La 13.1 introduit une cryptographie hybride combinant les algorithmes FIPS classiques avec des mécanismes post-quantiques. L’intérêt n’est pas théorique : la menace dite harvest now, decrypt later consiste à voler aujourd’hui des sauvegardes chiffrées pour les déchiffrer plus tard, une fois qu’un ordinateur quantique suffisamment puissant existera. Pour des données qui doivent rester confidentielles dix ou vingt ans — dossiers RH, contrats, secrets industriels — le chiffrement actuel ne suffit déjà plus à garantir la confidentialité sur cette durée. Les algorithmes post-quantiques standardisés par le NIST (FIPS 203, 204 et 205) sont justement conçus pour résister à ce scénario ; les détails techniques sont sur la page du projet NIST Post-Quantum Cryptography.

Concrètement, cette fonctionnalité ne te sert à rien si tu sauvegardes des logs applicatifs sans valeur dans six mois. Elle devient pertinente si tu archives des données avec une durée de rétention longue et une sensibilité réelle.

Les nouveaux hyperviseurs supportés

Jusqu’ici, Veeam Backup & Replication couvrait essentiellement VMware vSphere, Hyper-V et les principaux clouds publics. La 13.1 ajoute un support natif pour :

• Citrix XenServer
• XCP-ng (la variante open source de XenServer)
• Sangfor aSV
• Platform9
• VergeOS
• KubeVirt, avec un backend de sauvegarde standardisé pour les VM tournant nativement sur Kubernetes

Le support de KubeVirt mérite une mention à part : c’est la première fois que Veeam couvre un hyperviseur pensé pour tourner à l’intérieur d’un cluster Kubernetes plutôt qu’à côté. Pour les équipes qui migrent progressivement des VM legacy vers une plateforme Kubernetes commune, ça évite de maintenir deux outils de sauvegarde en parallèle pendant la transition.

Application Backup Repository : une cible NFS immuable prête à l’emploi

Autre ajout notable : l’Application Backup Repository transforme un dépôt durci en cible NFS immuable gérée nativement, sans configuration manuelle du stockage sous-jacent. Couplé à Veeam Snap Scale, pensé pour protéger des bases de données volumineuses — au-delà de 100 To — ça cible clairement les environnements avec de grosses bases transactionnelles plutôt que l’infra PME classique.

Faut-il migrer maintenant ?

Pas systématiquement. Si ton infra tourne uniquement sur VMware vSphere ou Hyper-V classique, sans forêt AD critique à restaurer en urgence ni base de données de plusieurs dizaines de téraoctets, rien n’oblige à migrer dans la semaine — autant attendre le prochain patch cumulatif, comme d’habitude avec Veeam. En revanche, si tu protèges une forêt AD sensible, si tu viens de déployer un des hyperviseurs listés ci-dessus, ou si la rétention longue durée de données sensibles fait partie de tes contraintes, la mise à jour vaut largement le détour.

FAQ

Faut-il une nouvelle licence pour passer à la VSA (Veeam Software Appliance) ?

La VSA s’appuie sur le modèle de licence Veeam Universal License (VUL) déjà en place pour les déploiements récents. Si tu es encore sur un ancien modèle de licence par socket ou par instance, vérifie ta compatibilité avant de basculer — c’est le genre de détail qui bloque une migration plus souvent qu’on ne le pense.

Le chiffrement post-quantique est-il activé par défaut ?

Non, et ça se comprend : activer un chiffrement hybride FIPS + post-quantique par défaut pour tout le monde aurait un coût de calcul inutile pour l’immense majorité des sauvegardes. C’est une option à activer consciemment sur les jobs qui en ont vraiment besoin.

Puis-je tester la récupération de forêt AD sans attendre un vrai incident ?

Oui, et c’est même fortement recommandé : fais un exercice de restauration en labo avec une forêt de test avant d’en avoir besoin en production. Un assistant guidé réduit le risque d’erreur manuelle, mais ne remplace pas la familiarité avec la procédure le jour où ça compte vraiment.

Pour aller plus loin

Avant toute mise à jour en production, prends le temps de relire les notes de version officielles de la 13.1 et l’annonce de la Veeam Community pour les correctifs spécifiques à ton environnement. Et si ta stratégie de sauvegarde n’a pas encore de volet immuabilité, ça reste la base avant de s’intéresser au post-quantique — voir notre article sur la règle 3-2-1-1-0 face aux ransomwares, et pour ceux qui sauvegardent déjà vers Azure, le point sur Veeam Data Cloud Vault.

Jusqu’ici, sur Azure Backup, l’immuabilité d’un point de restauration durait exactement aussi longtemps que la politique de rétention qui le protégeait. Tu voulais garder tes sauvegardes immuables 90 jours pour respecter une clause d’assurance cyber, mais ta politique de rétention en gardait 365 pour des raisons de conformité ? Impossible de dissocier les deux. Depuis début septembre 2026, Microsoft a changé la donne : la durée d’immuabilité d’un coffre Recovery Services peut désormais être fixée indépendamment de la rétention.

C’est un détail qui a l’air anodin sur le papier, mais qui change concrètement la façon de dimensionner une stratégie de résilience, surtout si tu factures le stockage de sauvegarde à ton client ou à un autre service interne.

Le problème que ça résout

Avant ce changement, deux options existaient pour un coffre Recovery Services : pas d’immuabilité du tout, ou une immuabilité calquée sur la rétention de chaque politique de sauvegarde. Concrètement, si ta politique gardait les sauvegardes 7 ans pour des raisons légales, la totalité de ces 7 ans devenait immuable — WORM inclus si tu verrouillais le paramètre. Bien pratique pour la conformité, beaucoup moins pour la flexibilité opérationnelle : impossible de dire « je veux que ce soit inaltérable pendant 90 jours contre le ransomware, puis je gère la suite normalement ».

Résultat : certaines équipes évitaient carrément le verrouillage d’immuabilité, ou finissaient par sur-dimensionner leurs politiques de rétention juste pour caler la fenêtre d’immuabilité qu’elles voulaient réellement.

Ce qui change : deux modes au choix

Le coffre propose maintenant deux façons d’activer l’immuabilité, dans Properties > Immutable vault > Settings :

• Basée sur la politique de rétention (comportement historique, toujours disponible) : la durée d’immuabilité suit exactement la rétention configurée pour chaque élément protégé.
• Durée fixe (nouveau) : tu indiques un nombre de jours — 30, 90, peu importe — et cette fenêtre s’applique uniformément à tous les points de restauration du coffre, indépendamment de la politique de rétention en vigueur.

Une contrainte reste en place dans les deux cas : tu ne peux pas réduire la rétention de ta politique en dessous de la durée d’immuabilité configurée. Logique — sinon tu pourrais supprimer un point de restauration encore censé être inaltérable. Une fois la durée fixe dépassée, le point de restauration continue d’exister tant que la politique le retient, mais il n’est simplement plus protégé contre la suppression ou la modification.

Le verrouillage (lock) reste optionnel et irréversible une fois activé — il transforme l’immuabilité en vraie protection WORM, au prix de ne plus jamais pouvoir la désactiver sur ce coffre. Il ne peut pas être posé à la création du coffre : il faut d’abord activer l’immuabilité, puis verrouiller séparément. Pour la désactiver (avant verrouillage), il faut passer par Resource Guard, ce qui empêche un compte compromis de couper la protection tout seul.

Un point à connaître avant de te lancer

La documentation officielle de Microsoft ne couvre pour l’instant que la configuration via le portail Azure — ni cmdlet PowerShell ni commande Azure CLI documentée pour activer la durée fixe à ce jour. Si ton IaC gère déjà tes coffres Recovery Services par Bicep ou Terraform, prévois donc une étape manuelle (ou une vérification après déploiement) tant que l’automatisation complète n’est pas exposée.

Autre limite à garder en tête : cette fonctionnalité s’applique aux coffres Recovery Services — VM Azure, SQL, SAP HANA, etc. Les coffres Backup vault, qui protègent le blob storage et Azure Data Lake Storage, n’ont pas cette option de durée fixe pour le moment.

Où ça se situe dans ta stratégie de résilience

Si tu appliques déjà la règle 3-2-1-1-0 sur ton parc Azure, cette durée fixe te permet enfin de faire coller précisément la copie « immuable » de la règle à une fenêtre de temps choisie, sans devoir gonfler artificiellement ta rétention globale. C’est aussi une vraie alternative native à des solutions tierces comme Veeam Data Cloud Vault, qui appliquait déjà une immuabilité par défaut sans configuration — sauf que là, tu restes dans l’écosystème Azure Backup natif, sans facturation forfaitaire séparée ni connecteur supplémentaire à maintenir.

Pour autant, je ne remplacerais pas un vault tiers isolé du tenant Azure si ton exigence de résilience inclut un scénario où le tenant lui-même est compromis (identité Entra ID détournée, abonnement entier chiffré). Un coffre Recovery Services reste une ressource Azure comme une autre : verrouillée, oui, mais dans le même environnement. Pour ce cas précis, un stockage réellement hors tenant garde son intérêt.

FAQ

La durée fixe remplace-t-elle le verrouillage d’immuabilité classique ?

Non, ce sont deux réglages distincts. La durée fixe change combien de temps l’immuabilité s’applique ; le verrouillage décide si tu peux encore la désactiver un jour. Tu peux combiner les deux.

Puis-je appliquer une durée différente par type de charge protégée dans le même coffre ?

Non, la durée s’applique uniformément à tout le coffre. Si tu as besoin de fenêtres différentes selon les charges, il faut séparer les charges sur des coffres distincts.

Que se passe-t-il pour les points de restauration déjà créés avant d’activer cette option ?

La documentation Microsoft ne précise pas de rétroactivité automatique sur les points existants — pars du principe que le réglage s’applique aux nouveaux points de restauration créés après l’activation, et vérifie sur ton environnement avant de t’y fier pour un audit de conformité.

Ce qu’il faut retenir

Ce n’est pas un bouleversement, mais c’est exactement le genre de réglage fin qui manquait pour aligner Azure Backup sur des exigences d’assurance cyber ou de conformité qui, elles, ne demandent jamais une immuabilité calquée sur la rétention légale complète. Si tu as un audit de résilience ou un renouvellement d’assurance cyber dans les prochains mois, c’est le bon moment pour revoir la configuration de tes coffres Recovery Services et voir où une durée fixe te ferait gagner en flexibilité sans rien perdre en protection.

Une sauvegarde immuable, c’est la base d’une vraie stratégie anti-ransomware — mais dans les faits, la rendre réellement immuable sur du stockage cloud self-managé demande de configurer des politiques de verrouillage, d’isoler l’architecture, et de surveiller que rien ne dérive dans le temps. Fin août 2026, Veeam a lancé Veeam Data Cloud Vault pour Azure : un stockage immuable entièrement managé, pensé spécifiquement pour recevoir les sauvegardes Veeam. Voici ce que ça change concrètement pour tes sauvegardes Azure, et où sont ses limites.

Le problème que Veeam Vault vient résoudre

Si tu as déjà mis en place le principe 3-2-1-1-0, tu sais que la copie « immuable » est justement celle censée survivre à une attaque, même si l’attaquant a compromis tes identifiants d’administration. Le problème, c’est que sur du stockage cloud auto-géré, cette immuabilité n’est pas automatique : il faut activer des politiques WORM (write once, read many), les verrouiller au bon niveau, isoler l’architecture (abonnement dédié, RBAC strict), et rester vigilant dans la durée — une simple erreur de configuration, ou une fenêtre de latence entre la création de la sauvegarde et l’activation du verrouillage, suffit à ouvrir une brèche.

Veeam Vault change l’approche : il s’agit d’un stockage cloud entièrement managé, construit sur Azure Blob Storage, mais où l’immuabilité est appliquée par défaut, pas configurée. Toute sauvegarde qui atterrit dans Veeam Vault se retrouve automatiquement en état WORM, sans verrouillage manuel à paramétrer et sans fenêtre de vulnérabilité où une sauvegarde toute fraîche serait encore modifiable.

Comment ça s’intègre à ton environnement Veeam

Vault n’est pas un produit à part : il s’intègre nativement à Veeam Data Platform. Si tu utilises déjà Veeam Backup for Microsoft Azure, tu peux cibler Veeam Vault directement comme destination, sans connecteur ni outillage supplémentaire à déployer. Il fonctionne aussi avec Veeam Kasten pour les charges Kubernetes, si une partie de ton infra tourne en conteneurs.

Détail important côté souveraineté des données : Vault se déploie dans ton propre abonnement Azure, pas dans une infrastructure tierce partagée. Les sauvegardes restent donc dans ton tenant, ce qui simplifie les questions de gouvernance et de conformité par rapport à un stockage immuable hébergé ailleurs.

Le modèle de facturation : prévisible, au To par an

Un des points de friction classiques du stockage cloud, c’est la facture qui varie selon les appels API, les lectures, les restaurations et la sortie de données (egress) — difficile à prévoir en amont. Veeam Vault fonctionne avec une facturation forfaitaire, au téraoctet et à l’année, qui englobe le stockage, les appels API, les lectures, les restaurations et l’egress dans un seul prix. Ça t’évite la mauvaise surprise en fin de mois si tu dois restaurer un volume important après un incident.

Vault natif Azure Backup : l’alternative déjà en place

Si tu n’utilises pas Veeam, sache que Microsoft propose depuis un moment son propre mécanisme d’immuabilité pour Azure Backup, les immutable vaults, directement au niveau des coffres de sauvegarde (Recovery Services vault et Backup vault). La différence principale : côté Azure natif, c’est à toi de configurer et de verrouiller cette immuabilité toi-même, alors que Veeam Vault l’impose par construction dès la première sauvegarde. Le bon choix dépend surtout de l’outil de sauvegarde que tu utilises déjà — Veeam Vault n’a de sens que si Veeam Backup & Replication ou Veeam Backup for Microsoft Azure fait déjà partie de ta stack, sinon les immutable vaults natifs restent la voie la plus directe.

Ça complète bien la réflexion sur la couverture de Microsoft 365 Backup : les deux approches partagent la même logique — un stockage de secours qui doit rester hors de portée d’un attaquant ayant compromis tes accès principaux.

Les limites à connaître avant de basculer

• Veeam Vault n’est pas disponible dans les régions Azure Government à ce jour — à vérifier si tu opères dans ce contexte.
• Ça suppose d’avoir déjà (ou de vouloir déployer) Veeam Backup for Microsoft Azure comme brique de sauvegarde — ce n’est pas un service autonome sans l’écosystème Veeam.
• Compare le coût réel face aux immutable vaults natifs Azure Backup selon ton volume : le forfait au To/an de Veeam n’est pas forcément plus avantageux pour tous les profils d’usage, notamment sur de très gros volumes rarement restaurés.

FAQ

Faut-il Veeam pour bénéficier de sauvegardes immuables sur Azure ?

Non. Azure Backup propose ses propres immutable vaults nativement, sans dépendance à un éditeur tiers. Veeam Vault est une option supplémentaire, pertinente si tu es déjà sur l’écosystème Veeam et que tu veux une immuabilité appliquée par défaut sans la configurer toi-même.

Les données restent-elles dans mon tenant Azure ?

Oui, Veeam Vault se déploie dans ton propre abonnement Azure, pas dans une infrastructure partagée par Veeam.

Est-ce compatible avec Azure Government ?

Non, pas à ce jour — Veeam Vault n’est pas disponible dans les régions Azure Government.

Ça remplace complètement la règle 3-2-1-1-0 ?

Non, ça sécurise une des copies de cette règle — la copie immuable. Le reste de la stratégie (copies multiples, support différent, copie hors site, zéro erreur vérifiée) reste à construire autour.

Ce qu’il faut retenir

Veeam Data Cloud Vault pour Azure répond à un vrai point de friction : la difficulté de garantir une immuabilité fiable sur du stockage cloud auto-géré. Si Veeam fait déjà partie de ta stack de sauvegarde, ça vaut le coup d’évaluer le forfait au To/an face à tes immutable vaults Azure Backup actuels — surtout si la configuration manuelle de ces derniers a déjà généré des ratés dans ton environnement. Dans tous les cas, l’essentiel reste le même : teste régulièrement une restauration réelle depuis ta copie immuable, pas seulement sa présence.

Depuis que Microsoft 365 Backup est disponible, beaucoup d’admins cochent la case « sauvegarde » dans leur audit de conformité et passent au sujet suivant. Le problème, c’est que cette case ne veut pas dire ce que tu crois. Microsoft 365 Backup protège une partie de ton tenant, à un prix précis, avec des limites de performance bien réelles — et il laisse de côté des pans entiers de ce que tes utilisateurs produisent chaque jour, Teams et Copilot en tête.

Dans cet article, tu vas voir concrètement ce que couvre l’outil, combien il coûte réellement (avec le détail du calcul), ce qu’il ne sauvegarde pas, et comment construire une vraie stratégie de résilience autour de ces angles morts plutôt que de découvrir le trou le jour où tu en as besoin.

Microsoft 365 Backup, concrètement

Microsoft 365 Backup est un service de sauvegarde géré par Microsoft, intégré à l’infrastructure Azure, qui crée des points de restauration pour une partie de ton contenu M365. Contrairement aux stratégies de rétention (conformité, eDiscovery), il vise une vraie restauration opérationnelle : « je veux récupérer ce site SharePoint tel qu’il était il y a trois jours ».

Ce qu’il protège

• OneDrive — comptes utilisateurs, y compris la corbeille de premier niveau
• SharePoint — sites complets
• Exchange Online — boîtes aux lettres actives et leurs archives en ligne

Le RPO (Recovery Point Objective) est configurable, avec des intervalles disponibles jusqu’à 10 minutes. Pour l’activer, il te faut un abonnement Azure lié (facturation à la consommation), le rôle Administrateur SharePoint ou Administrateur général — ou le rôle dédié « Microsoft 365 Backup Administrator » qui couvre les trois services d’un coup. Le détail des rôles et de la mise en place est sur la documentation officielle Microsoft Learn.

Combien ça coûte vraiment

Le modèle est à la consommation : 0,15 $/Go/mois de contenu protégé. Mais « contenu protégé » inclut plus que ce qu’on imagine spontanément — c’est là que les surprises de facturation arrivent.

Sont comptabilisés :

• Le contenu actif (sites SharePoint, comptes OneDrive, boîtes aux lettres actives)
• La corbeille de second niveau SharePoint/OneDrive
• Les éléments supprimés et versionnés dans les boîtes protégées
• Les archives en ligne Exchange

Exemple donné par Microsoft : un site de 1 Go + 0,5 Go de corbeille second niveau + 1 Go de boîte + 1 Go d’archive = 3,5 Go facturés, pas 1 Go. Bonne nouvelle : la fréquence des points de restauration n’a aucun impact sur le coût, et les coûts Azure sous-jacents sont inclus dans le tarif — pas de facture Azure séparée à surveiller.

Pour estimer ta facture avant d’activer quoi que ce soit, Microsoft fournit un calculateur Excel et une méthode de collecte via PowerShell :

#  Tailles SharePoint / OneDrive en direct
Get-SPOSite

# Corbeille de second niveau
Get-PnPRecycleBinItem -SecondStage

# Archives en ligne Exchange
Get-MailboxStatistics -Identity "utilisateur@tondomaine.com" -Archive

Le détail complet du modèle de facturation, avec le lien vers le calculateur, est sur la page pricing officielle.

Ce que Microsoft 365 Backup ne sauvegarde pas

C’est le point qui mérite vraiment ton attention avant de considérer le sujet comme réglé.

Teams et l’historique Copilot

Les conversations Teams sont stockées dans Exchange à des fins de conformité, mais leur restauration native dans l’interface Teams elle-même reste immature. Pire : à ce jour, il n’existe pas de solution mature pour restaurer l’historique des échanges avec Copilot — si un utilisateur supprime ou perd ses conversations Copilot, elles ne reviennent pas.

Power Platform

Pas de sauvegarde continue pour Power Apps, Power Automate ou Power BI. Les organisations peuvent exporter manuellement leurs solutions, mais ça ne remplace pas un vrai modèle de sauvegarde automatisé — c’est une opération ponctuelle, facile à oublier.

Planner, et la configuration en général

Les tâches Planner font partie des éléments souvent oubliés dans les audits. Plus largement, tout ce qui est configuration plutôt que contenu — règles de flux de courrier, politiques d’accès conditionnel, paramètres de conformité — n’est généralement pas couvert. Si ta configuration dérive ou qu’une règle est supprimée par erreur, Microsoft 365 Backup ne t’aide pas.

La limite qu’on oublie : la vitesse de restauration

Même sur le périmètre couvert, le débit de restauration a un plafond concret : environ 1 à 3 To/heure. Ça semble confortable jusqu’à ce que tu fasses le calcul sur un tenant de taille réelle : pour restaurer 300 To de données, il faut plus de 100 heures. Sur un vrai incident (ransomware, corruption massive), ce chiffre doit rentrer dans ton calcul de RTO (Recovery Time Objective) — pas juste dans ton RPO.

Comment combler ces angles morts

Microsoft 365 Backup n’est pas mauvais — il fait bien ce qu’il fait. Le problème, c’est de croire qu’il couvre tout. Une stratégie réaliste en 2026 :

• Garde la logique 3-2-1-1-0 pour ton PRA global (voir notre article sur la règle 3-2-1-1-0 face aux ransomwares) — M365 Backup peut être une des copies, pas la seule stratégie.
• Documente ta configuration séparément : exporte régulièrement tes politiques de flux de courrier, tes règles d’accès conditionnel et tes paramètres de conformité en dehors de M365 Backup — un script PowerShell planifié suffit pour la plupart des cas.
• Évalue une solution tierce pour Teams/Power Platform si ces workloads sont critiques chez toi — le marché des outils spécialisés a mûri sur ce créneau précisément parce que Microsoft ne le couvre pas encore bien.
• Teste une vraie restauration à l’échelle, pas juste un fichier isolé — c’est le seul moyen de savoir si ton RTO réel tient face au débit de 1-3 To/heure sur TON volume de données.

FAQ

Microsoft 365 Backup remplace-t-il un antivirus/EDR ?

Non, ce sont deux couches différentes. Le backup te permet de revenir en arrière après un incident (ransomware, suppression accidentelle) ; l’EDR sert à détecter et bloquer l’attaque en amont. Les deux sont complémentaires, pas substituables.

Est-ce que je peux désactiver M365 Backup sur un site pour réduire la facture ?

Oui, tu ne payes que pour le contenu activement protégé. Si tu retires un site ou une boîte de la protection, le coût se fige à la taille du dernier instantané, puis les données supprimées expirent selon ta fenêtre de rétention et cessent d’être facturées.

Les conversations Copilot seront-elles un jour sauvegardées nativement ?

Rien d’annoncé officiellement à ce stade. C’est un point à surveiller si Copilot devient central dans tes usages métier — en attendant, ne compte pas dessus dans ton plan de continuité.

En bref

Microsoft 365 Backup coche une vraie case, mais ce n’est qu’une case parmi plusieurs. Avant ta prochaine revue de PRA, vérifie précisément ce qui est protégé chez toi, calcule ton RTO réel avec le débit annoncé, et documente ce qui reste hors périmètre — Teams, Copilot, Power Platform, configuration. C’est ce triage, pas l’activation du service, qui fait la différence le jour où tu en as vraiment besoin.

90 % des organisations se disent confiantes dans leur capacité à récupérer après une cyberattaque. Dans les faits, seulement 28 % y parviennent totalement. Cet écart, révélé par le dernier rapport Veeam sur la résilience des données, résume à lui seul pourquoi « avoir des sauvegardes » et « avoir une vraie stratégie de sauvegarde et de PRA » sont deux choses très différentes. Voici ce que ces chiffres impliquent concrètement pour ton infrastructure.

Le fossé entre confiance et réalité

Le rapport 2026 de Veeam sur la résilience face aux ransomwares dresse un constat qui devrait faire réfléchir toute équipe infra :

• 90 % des organisations se disent confiantes dans leur capacité de reprise après incident, mais seulement 28 % récupèrent l’intégralité de leurs données après une attaque — la récupération moyenne plafonne à 72 % des données touchées.
• 42 % des organisations attaquées signalent une perturbation directe pour leurs clients ou utilisateurs, 41 % des pertes financières, et 38 % un arrêt de service prolongé.
• Les organisations ayant augmenté leur budget cybersécurité affichent un taux de récupération complète de 40 %, contre seulement 16 % pour les autres — la corrélation entre investissement et résilience réelle est nette.

Le rapport identifie quatre pratiques qui font la différence : une visibilité claire sur les données en production et en sauvegarde, des contrôles de sécurité réellement appliqués (pas seulement documentés), des tests de restauration réalistes, et un alignement de la direction sur les responsabilités et objectifs de reprise (rapport complet sur veeam.com).

La règle 3-2-1-1-0, colonne vertébrale d’une stratégie solide

La bonne nouvelle, c’est que le cadre pour combler cet écart existe depuis longtemps et reste valable en 2026. La règle 3-2-1 s’est enrichie de deux exigences supplémentaires face aux ransomwares modernes :

• 3 copies de tes données (la production + 2 sauvegardes)
• 2 supports de stockage différents (ex. disque local + stockage objet cloud)
• 1 copie hors site (offsite, dans une autre région/datacenter)
• 1 copie hors ligne, immuable ou air-gapée — inaccessible même si un attaquant obtient des droits d’administration sur ton infra
• 0 erreur après vérification — une sauvegarde qui n’a jamais été testée n’est qu’une hypothèse

Le dernier point est celui que la plupart des équipes négligent. Une sauvegarde immuable qui ne restaure pas correctement au moment critique n’apporte aucune protection réelle.

Rendre tes sauvegardes vraiment immuables (pas juste « protégées »)

Sur Azure, le point de départ est le soft delete renforcé des coffres Recovery Services, activé par défaut sur les nouveaux coffres depuis les dernières évolutions de sécurité d’Azure Backup, avec une rétention configurable et une protection contre la suppression accidentelle ou malveillante des points de restauration :

# Activer l'immuabilité sur un coffre Recovery Services existant (Azure CLI)
az backup vault backup-properties set \
  --name "rsv-prod-backup" \
  --resource-group "rg-backup" \
  --backup-storage-redundancy GeoRedundant \
  --immutability-state Locked

# Vérifier l'état de l'immuabilité du coffre
az backup vault backup-properties show \
  --name "rsv-prod-backup" \
  --resource-group "rg-backup" \
  --query immutabilitySettings

Le point de vigilance : une fois passé en état Locked, l’immuabilité ne peut plus être désactivée, ce qui est précisément le comportement recherché contre un attaquant disposant de droits élevés. Teste d’abord en environnement non critique avant de verrouiller un coffre de production. Le détail des options (soft delete, coffres verrouillés, sauvegardes « vaulted ») est couvert dans la documentation officielle sur le soft delete renforcé d’Azure Backup et la vue d’ensemble des fonctionnalités de sécurité d’Azure Backup.

Le PRA, ce n’est pas la sauvegarde (et c’est souvent là que ça coince)

Avoir des sauvegardes fiables ne garantit pas un plan de reprise d’activité (PRA) fonctionnel. Ce sont deux disciplines complémentaires mais distinctes :

• La sauvegarde répond à la question « puis-je restaurer mes données ? »
• Le PRA répond à la question « en combien de temps mon service est-il de nouveau opérationnel, et avec quelle perte de données acceptable ? »

Ça se traduit par deux indicateurs à définir service par service, pas globalement pour toute l’infra :

• RPO (Recovery Point Objective) : quantité de données que tu acceptes de perdre, mesurée en temps depuis la dernière sauvegarde valide.
• RTO (Recovery Time Objective) : délai maximal acceptable avant que le service soit de nouveau disponible.

Un serveur de fichiers interne et une base de données transactionnelle critique n’ont pas les mêmes exigences — les traiter avec la même politique de sauvegarde est une erreur fréquente. C’est aussi un sujet que la réglementation pousse de plus en plus : la directive NIS2 en cours de transposition en France impose justement aux entités concernées de formaliser des capacités de continuité et de reprise d’activité, pas seulement des sauvegardes techniques.

Tester vraiment, pas seulement sur le papier

Un PRA qui n’a jamais été exécuté en conditions réelles reste une théorie. Quelques pratiques concrètes pour sortir de la théorie :

• Planifie des exercices de restauration complets (pas juste un fichier isolé) au moins une à deux fois par an, en dehors des heures critiques.
• Restaure vers un environnement isolé du réseau de production pour valider qu’une sauvegarde compromise ne recontamine pas l’infra restaurée.
• Mesure le RTO réel obtenu lors du test et compare-le à ton objectif — l’écart, s’il existe, te dit exactement où prioriser tes efforts.
• Documente qui fait quoi pendant l’exercice : un PRA qui dépend d’une seule personne disponible est un PRA fragile.

Si ton infrastructure de sauvegarde et de reprise est déployée sur Azure, la définir en Infrastructure as Code facilite grandement la reproductibilité de ces tests — coffres, politiques de rétention et réseaux isolés redéployés à l’identique à chaque exercice. Notre article sur les Azure Landing Zones et les Azure Verified Modules couvre justement cette approche pour structurer ce type d’infrastructure de façon cohérente.

FAQ

Quelle différence entre RTO et RPO ?

Le RPO mesure la perte de données acceptable (combien de temps depuis la dernière sauvegarde valide), le RTO mesure le temps d’indisponibilité acceptable avant reprise du service. Les deux se définissent ensemble, service par service.

Une sauvegarde immuable, c’est quoi concrètement ?

C’est une copie de sauvegarde qui ne peut être ni modifiée ni supprimée pendant une période définie, même par un compte disposant de droits d’administration — la protection ultime contre un ransomware qui aurait compromis tes accès élevés.

À quelle fréquence tester son PRA ?

Au minimum une à deux fois par an pour un test complet, et idéalement après chaque changement structurant de l’infrastructure (migration, nouvelle application critique, changement de fournisseur cloud).

Ce qu’il faut retenir

L’écart entre « je pense pouvoir récupérer » et « je peux effectivement récupérer » se comble avec trois ingrédients : des sauvegardes réellement immuables suivant la règle 3-2-1-1-0, des objectifs RTO/RPO définis service par service, et des tests de restauration exécutés en conditions réelles plutôt que supposés fonctionner. C’est un chantier qui se construit progressivement — mais qui vaut clairement l’investissement le jour où tu en as besoin.