Le stockage cloud conserve plusieurs versions, pourtant le fichier a disparu de la liste. Sur un stockage objet versionné, une suppression peut créer un marqueur de suppression qui masque l’objet dans les lectures courantes, sans effacer immédiatement toutes ses versions. Le comportement exact dépend du fournisseur et de la configuration.

Une liste courante ne montre pas toute l’histoire

Dans le cas d’Amazon S3 avec versioning activé, une suppression sans identifiant de version peut ajouter un delete marker. Les accès ordinaires voient alors l’objet comme supprimé. Des versions antérieures peuvent encore exister et rester accessibles avec les droits et les identifiants appropriés.

Ce fonctionnement explique pourquoi deux personnes peuvent décrire des états apparemment contradictoires : l’utilisateur ne trouve plus le fichier, tandis que l’administrateur voit encore ses versions. Le stockage n’a pas forcément perdu la donnée, mais le parcours normal ne la présente plus.

Le versioning doit être activé et compris avant l’incident. Il ne faut pas supposer que tous les services cloud conservent automatiquement une histoire complète. Les règles de rétention, les suppressions définitives et les permissions peuvent aussi retirer les versions conservées.

Restaurer commence par choisir ce qu’on veut retrouver

Pour un dossier de démonstration, créez plusieurs versions puis faites une suppression selon la procédure documentée. Observez la liste normale et la liste des versions. Demandez au responsable de retrouver le contenu attendu dans un emplacement contrôlé.

Les méthodes de récupération varient. Retirer un marqueur, copier une ancienne version ou recréer un objet ne présentent pas exactement le même résultat ni les mêmes effets sur les outils connectés. Le prestataire doit expliquer la méthode retenue et les contrôles qui suivent.

Rendre un nom visible ne prouve pas que le bon contenu a été récupéré.

Comparez donc le contenu, sa date, ses métadonnées utiles et les permissions. Si une application possède sa propre base qui référence l’objet, le retour du fichier ne restaure pas automatiquement cette référence. Une recette doit regarder le service complet et non uniquement la console de stockage.

Notre article sur les suppressions et la synchronisation OneDrive décrit un autre mécanisme, mais rappelle la même nécessité : comprendre ce que l’interface appelle « supprimer » dans le système réellement utilisé.

La conservation ajoute des coûts et des règles

Les versions anciennes peuvent occuper de l’espace facturé. Des politiques de cycle de vie peuvent les retirer après une durée donnée. Ce nettoyage doit correspondre au délai pendant lequel l’entreprise veut pouvoir retrouver une erreur, avec une configuration vérifiée.

L’accès aux versions doit également être contrôlé. Conserver une donnée ne signifie pas que chaque utilisateur doit pouvoir récupérer toutes ses anciennes formes. Documentez qui peut consulter, restaurer et supprimer définitivement.

Lors d’un exercice, notez également le délai et les droits utilisés pour la récupération. Une fonction accessible uniquement à un administrateur absent peut ralentir fortement le retour au travail. Le responsable doit connaître le canal de demande et disposer d’un remplaçant habilité selon les règles de l’entreprise.

Une procédure indépendante de l’auteur initial

La personne qui a configuré le stockage peut être absente au moment du besoin. Conservez le nom du service, l’état du versioning, les règles de conservation et une procédure testée. Les secrets d’accès doivent rester dans leur emplacement sécurisé, pas dans le document partagé de dépannage.

Le stockage objet versionné offre des possibilités utiles de récupération, mais elles restent liées à sa configuration. Une donnée invisible peut être encore présente ; une donnée présente peut être inaccessible ; une donnée versionnée peut finir par être supprimée. Le test de restauration transforme ces nuances en une procédure que l’équipe saura utiliser.