S4 : la réversibilité du stockage objet, vérifiable¶

Version 0.2 · 31 octobre 2026 · draft · PDF

S4 (Sovereign S3) est le premier chantier du groupe de travail cloud d'OpenInterop. Il traite une question simple : un client peut-il quitter son fournisseur de stockage objet, récupérer toutes ses données dans un état utilisable et le prouver ? Le chantier a été lancé lors de l'atelier OpenInterop du 9 octobre 2026 (Track 6, « Connecting the Clouds »). Il produit un profil, des contrats comportementaux, une scorecard, des scénarios de test et leur implémentation, le CTK S4.

Le problème¶

Le stockage objet est le service managé le plus standardisé : presque tous les fournisseurs se disent « compatibles S3 ». Cette compatibilité ne garantit pourtant pas la réversibilité.

• Les fonctions prises en charge varient : étiquettes, versions, verrouillage, classes de stockage. Une offre « compatible S3 » ne dit pas lesquelles.
• Les comportements diffèrent à interface identique : pagination, cohérence, limites de débit, codes d'erreur, cas limites.
• Certaines métadonnées ne transitent pas par l'API : date de dernière modification, identifiants de version, ETag d'un objet multipartie.
• L'interface est contrôlée par un seul acteur. Au début de 2025, une modification par défaut des outils clients d'AWS a rendu de nombreux services « compatibles » inutilisables du jour au lendemain.

Le Data Act impose depuis le 12 septembre 2025 le changement de fournisseur de services cloud ; pour la circulaire du Premier ministre du 5 février 2026, la réversibilité est un critère clé du choix des solutions. Aucun référentiel technique ne permet encore de vérifier qu'une sortie a réussi.

La réponse¶

• Un profil S4 ouvert et versionné. Il définit le sous-ensemble de l'API S3 qu'un fournisseur peut revendiquer, par niveaux : Core d'abord, puis versions, gouvernance et fonctions étendues. Une déclaration de conformité précise le niveau et les fonctions revendiquées. Voir la note constat et propositions.
• Des contrats comportementaux. Trente-cinq exigences, en neuf familles (export, métadonnées, intégrité, performance, interface, reconstruction, sécurité et droits, reprise, exigences organisationnelles et juridiques), décrivent le comportement attendu et la manière de le vérifier. Voir les contrats.
• Un manifeste d'export. Un fichier JSON Lines décrit chaque objet (clé, taille, empreinte SHA-256, métadonnées) et transporte les valeurs que la cible ne peut pas reproduire.
• Une scorecard sans compensation. Dans une première étape, cinq critères obligatoires (complétude, intégrité, métadonnées, droits d'accès, portabilité fonctionnelle) doivent tous être satisfaits ; durée, débit, reprise, coût et effort sont publiés à part, avec leurs conditions. Aucune moyenne pondérée ne fonde un verdict. Voir la scorecard.
• Des scénarios de test. Six scénarios couvrent l'export complet, l'intégrité, les métadonnées et les droits, l'incident et la reprise, l'exploitation sur la cible après révocation des accès à la source, enfin la performance. Chaque critère reçoit l'un des quatre verdicts de la doctrine : conforme, non conforme, non applicable, non concluant. Voir les scénarios.

Le CTK S4¶

Le CTK S4 met en œuvre cinq des six scénarios. Il migre un jeu de données déterministe d'une source vers une cible, compare les manifestes, injecte des corruptions et des coupures de connexion, fait travailler une application témoin sur la cible et produit un rapport qu'un tiers peut rejouer. Il est lui-même testé contre deux implémentations libres de l'API S3, Garage et Ceph RGW.

Ses premiers essais, au volume d'essai rapide, montrent l'écart entre déclaration et comportement :

• Garage est conforme au niveau Core sur les cinq scénarios, à une exception près : il ignore les lectures conditionnelles (If-Match), qui permettent de détecter qu'un objet a changé pendant une reprise. Il ne prend pas non plus en charge les étiquettes d'objet : revendiquées, elles donnent un verdict « non conforme ».
• Ceph RGW, sur son moteur de stockage autonome, ne termine jamais la lecture d'un objet multipartie dont la dernière partie fait un octet.
• Le client AWS de référence (boto3, depuis janvier 2025) rejette par défaut des réponses de Garage ; le CTK fixe donc le comportement de son propre client et vérifie l'intégrité par sa propre empreinte.

Aucun de ces écarts n'apparaît dans une déclaration « compatible S3 ». Voir la note le CTK S4.

La méthode¶

S4 applique la doctrine OpenInterop : l'interopérabilité se prouve par un résultat reproductible, sur le périmètre revendiqué. Le rapport du CTK sert aux trois niveaux de preuve (autoévaluation par le fournisseur, vérification par un acheteur ou un tiers, essai croisé entre fournisseurs). C'est une preuve technique : son usage dans un contrat demande une rédaction propre, qui fixe le périmètre, la mesure, les conditions de test et les conséquences d'un écart. La méthode a vocation à s'étendre à d'autres services cloud (chantier CL4 de la fiche cloud).

Calendrier¶

Les échéances ont été proposées par l'atelier du 9 octobre 2026 et restent à confirmer par le groupe de travail. Les fournisseurs, utilisateurs et contributeurs qui souhaitent participer aux essais croisés sont les bienvenus.

Les notes S4¶