Résumé

  • Scaleway indique que la rétention par défaut s’applique aux nouveaux objets et commence à leur création. Une durée commune ne donne donc pas une échéance commune à une archive qui continue de croître.
  • Le gel juridique n’a pas d’expiration automatique et reste indépendant de la rétention. Une période écoulée ne prouve ni sa levée ni la suppression d’une version.
  • Une fois le verrouillage activé, le bucket ne peut pas le désactiver ni suspendre le versionnement. Cette contrainte durable ne signifie pas que chaque objet doit rester éternellement.

Le temps ne ferme pas toutes les décisions

L’acheteur qui demande une durée de conservation pose une question nécessaire, mais incomplète. Certaines contraintes se terminent à une date ; d’autres exigent une décision explicite. La documentation de Scaleway distingue la rétention et le gel juridique précisément sur ce point. Le second constitue un état indépendant, sans date d’expiration, qu’un utilisateur disposant des permissions requises doit lever.

Un objet peut donc, dans un scénario hypothétique, avoir dépassé sa date de rétention tout en conservant un gel actif. La fin de la période ne suffit pas à annoncer que toutes les contraintes ont disparu. L’inverse est également vrai : lever le gel n’établit pas que la rétention distincte est arrivée à son terme. Ces exemples expliquent des relations entre mécanismes ; ils ne décrivent pas un portefeuille client observé.

Le terme de gel juridique désigne ici une fonction de produit. L’article ne détermine pas le droit applicable ni une durée obligatoire pour une catégorie de documents. Une période utilisée dans un exemple technique de fournisseur ne devient pas une prescription légale pour l’acheteur.

Une durée n’est pas une date de sortie

Le guide de verrouillage d’objets, révisé le 21 mai 2026, explique que la politique par défaut s’applique à chaque nouvel objet et que sa période part de la création de cet objet. Les jours ou les années expriment une durée, tandis que le champ de fin de rétention d’un objet est un horodatage absolu. Ces deux représentations ne répondent pas à la même question de suivi.

Imaginons une archive alimentée à plusieurs moments avec une seule durée par défaut. Les objets entrés plus tôt et plus tard ne démarrent pas ensemble. La politique paraît uniforme, mais les dates auxquelles les engagements correspondants mûrissent diffèrent. Cette conséquence découle du point de départ documenté ; aucun inventaire réel ni volume de données n’est calculé.

Scaleway indique aussi qu’un réglage au niveau de l’objet peut remplacer le défaut pour cet objet précis. Le défaut ne constitue donc pas la preuve de l’état actuel de chaque élément. La mention des nouveaux objets ne suffit pas davantage à établir une protection rétroactive de tous les éléments déjà présents. Il faut connaître leurs propres paramètres, sans inventer un redémarrage de l’horloge à la lecture ou au changement de nom.

La protection retire une partie de la liberté future

Le mode Compliance empêche la suppression ou l’écrasement pendant la période prévue, y compris par un propriétaire ou un administrateur. Selon le guide détaillé, le mode ne peut pas être changé et la durée ne peut pas être raccourcie. Le mode Governance conserve au contraire une possibilité de modification et de suppression pour les utilisateurs correctement autorisés.

Il ne s’agit pas de deux degrés de confort dans la même interface. Ce sont deux répartitions de la capacité de décider plus tard. L’organisation achète une restriction plus forte lorsqu’elle veut empêcher une décision administrative ultérieure de détruire un enregistrement protégé. Elle accepte en même temps de perdre cette faculté dans le périmètre défini.

Le guide exige le versionnement pour le verrouillage. Une fois activé sur un bucket, le verrouillage ne peut plus être désactivé et le versionnement ne peut pas être suspendu. Cette décision durable concerne le régime du conteneur. Elle ne signifie ni une rétention sans fin de chaque objet ni des paramètres identiques pour toutes les versions.

Confondre cette permanence avec la période d’un objet reviendrait à perdre les deux échelles du contrôle. Le bucket ne quitte pas son régime activé ; une version particulière reste soumise à sa contrainte jusqu’à la condition qui lui correspond. Le mot « permanent » ne remplace pas l’identification de ces conditions.

Une disparition de l’écran n’est pas une destruction

Le guide de dépannage des suppressions, révisé en juillet 2025, indique qu’une suppression sans identifiant de version dans un bucket versionné crée un marqueur de suppression, alors que les objets visés continuent d’exister. Il traite séparément la dérogation de gouvernance et l’identifiant de version. Ces précisions décrivent les frontières du mécanisme ; aucune opération sur les données d’un client n’est demandée ici.

La documentation des stratégies de sauvegarde explique également que le versionnement crée de nouvelles versions sous un même nom. Le nom affiché ou une liste ordinaire ne représente donc pas tout l’historique conservé. Visibilité, existence d’une version et permissions correspondantes sont trois informations différentes.

Un rapport établi seulement à partir des éléments visibles pourrait sous-estimer les engagements encore ouverts. C’est une possibilité d’erreur de mesure, pas un cas démontré de perte de données ou de facturation incorrecte chez Scaleway. Le marqueur ne prouve pas l’effacement physique ; des octets conservés ne prouvent pas non plus une restauration utile à l’application.

La promesse de conservation a un périmètre

Le modèle de responsabilité du stockage attribue l’exploitation de l’infrastructure à Scaleway, mais laisse au client les choix de cycle de vie, la gestion des versions, les mesures de continuité et le travail d’intégrité. Les traces disponibles sur demande et les obligations de vérification du client ne sont pas un résultat de reprise mesuré pour une archive particulière.

Empêcher une modification d’une version n’établit pas que tous les composants nécessaires à une application ont été capturés de manière cohérente. Cela ne valide pas non plus un environnement de remplacement. La protection contre une suppression définie et la capacité de récupérer un service constituent des bénéfices distincts.

Les formulations publiques introduisent encore une frontière plus large. La page des concepts et le guide de sauvegarde d’avril 2026 mentionnent la suppression de l’ensemble du compte à côté de l’expiration du verrouillage. Le guide de fermeture de février 2026 annonce la suppression permanente des ressources et sauvegardes, tout en conservant l’accès à la console et en distinguant la fermeture de l’effacement des données personnelles.

Ces documents ne tranchent pas ici le traitement exact d’une version actuellement verrouillée pendant cette procédure. La recherche n’a fermé aucun compte et n’a testé aucun contournement. Elle ne démontre ni une vulnérabilité fonctionnelle ni la défaillance de la promesse au niveau de l’objet. Il faut faire préciser cette frontière, au lieu d’élargir la restriction sur les administrateurs à une garantie non testée sur tout le cycle de vie du compte.

Ce que l’acheteur doit effectivement comparer

La question commerciale est celle des décisions futures retirées, des enregistrements concernés et des conditions de leur libération. Une politique simple peut être pertinente sans suffire à décrire les engagements qu’elle a déjà produits. Nouveaux objets, dates explicites et gels indépendants rendent ce portefeuille plus fin que son conteneur.

Les six sources ne chiffrent ni coût final, ni économie, ni incident, ni taux de restauration. Elles permettent une conclusion plus précise : acheter une protection revient à choisir une limite à la discrétion future. La simplicité du défaut ne doit pas conduire à prendre une échéance ou un écran vide pour la preuve que cette limite a entièrement disparu.

Sources