Profil S4 : contrats comportementaux¶

Version 0.3 · 31 octobre 2026 · draft · PDF

Cette note fixe les exigences du profil S4 pour l'export massif d'un stockage objet compatible S3. Chaque exigence prend la forme d'un contrat comportemental : une garantie, un comportement observable, un critère mesurable et un test. Les contrats alimentent la scorecard et les scénarios de test ; le CTK S4 en vérifie déjà une partie. Le cadre général du projet S4 (Sovereign S3) figure dans la synthèse et la note de constat et propositions.

Les contrats sont issus de l'atelier OpenInterop du 9 octobre 2026 (Track 6, « Connecting the Clouds »), qui a fixé les familles, le classement de maturité et les scénarios prioritaires. Ils restent soumis à la validation du groupe de travail : l'atelier a proposé un profil V0.1 et une proposition d'annexe contractuelle pour décembre 2026, après un TechSprint début novembre et des essais croisés fin novembre.

Prérequis commun à tous les contrats : le client dispose d'un contrat avec B et d'une connexion entre A et B. Le périmètre de la V0 est le niveau Core sur une source figée. Versions, rétention, Object Lock, classes froides et migration pendant les écritures relèvent des périmètres avancés.

1. Principes¶

1.1 Structure d'un contrat¶

Un contrat comportemental (« contrat sémantique » dans le cadrage de l'atelier, facette comportementale au sens de l'ISO/IEC 19941) transforme une promesse (« le fournisseur garantit la réversibilité ») en exigence vérifiable. Chaque contrat comporte :

• Exigence : la garantie due ;
• Comportement attendu : le comportement observable du service ;
• Critère mesurable : la mesure, avec le seuil quand la spécification le fixe ;
• Test : le ou les scénarios qui l'établissent (CTK-01 à CTK-06, CTK-X1 à CTK-X4) ;
• Niveau de profil : niveau du profil S4 auquel l'exigence s'applique (Core, Versioned, Governance, Extended ; cf. note de constat et propositions, §4.1) ;
• Nature : bloquant (tout ou rien), déclaré-vérifié (le fournisseur déclare une valeur, le CTK la mesure) ou déclaratif-auditable (non testable de l'extérieur, vérifiable par audit) ;
• Maturité : classement de l'atelier, Prête à être spécifiée, À approfondir ou Pas mûre ;
• CTK S4 : état de la vérification par l'implémentation actuelle du kit.

1.2 Contrats, critères et verdicts¶

Les contrats bloquants alimentent les critères obligatoires de la scorecard (A1 à A11) ; les contrats déclarés-vérifiés alimentent ses mesures (B1 à B11). Conformément à la doctrine OpenInterop (§5.2), la conformité exige que tous les critères obligatoires du périmètre revendiqué soient satisfaits, sans compensation entre critères ; aucune moyenne pondérée ne fonde un verdict. Les mesures sont publiées à part, avec leurs conditions.

Chaque critère reçoit l'un des quatre verdicts de la doctrine : conforme, non conforme, non applicable (hors du périmètre revendiqué) ou non concluant (l'environnement de test a échoué). Une fonction revendiquée mais absente donne un verdict non conforme.

La preuve s'établit à l'un des trois niveaux de la doctrine (§5.3) : autoévaluation par le fournisseur, vérification par un acheteur ou un tiers, essai croisé organisé par OpenInterop. Un rapport du CTK est une preuve technique ; son usage dans un contrat demande une rédaction propre, objet de la proposition d'annexe contractuelle prévue en décembre 2026.

1.3 Conventions¶

• « Source » désigne le fournisseur quitté (A), « cible » le fournisseur ou la plateforme de destination (B).
• « Données exportables » s'entend au sens du Data Act : données et métadonnées fournies ou générées par l'usage du client, hors actifs protégés du fournisseur.
• Le manifeste d'export décrit chaque objet avec ses métadonnées et une somme de contrôle de l'objet complet, au format JSON Lines accompagné d'un JSON Schema (cf. scénarios, annexe A).
• Les jeux de données de référence (DS-S, DS-L, DS-M, DS-K, DS-V) sont définis dans la note sur les scénarios.

1.4 Familles¶

1.5 État de la vérification par le CTK S4¶

La colonne « CTK S4 » du tableau de la section 2 prend trois valeurs. Vérifié : le kit juge le critère correspondant et rend un verdict. Partiel : le kit couvre une partie du comportement attendu, précisée dans la fiche du contrat. Non : le contrat n'est pas encore testé, ou ne relève pas d'un test automatisé.

Le CTK S4 met en œuvre les scénarios CTK-01 à CTK-05 au niveau Core, étiquettes comprises. Il juge les critères A1, A2, A3, A4, A6, A7, A8, A10 et A11 et publie les mesures B9, B10 et B11 à titre informatif. CTK-06 (performance de la migration) attend sa définition par le groupe de travail ; les scénarios des périmètres avancés (CTK-X1 à CTK-X4) ne sont pas implémentés.

Les premières exécutions (dernière vérification le 26 octobre 2026) donnent trois résultats :

• Garage v1.0.1 est conforme au niveau Core sur les scénarios CTK-01 à CTK-05, y compris la reprise après les coupures injectées et la matrice d'accès, à une exception près : il ignore If-Match en lecture (API-03). Il est non conforme sur les étiquettes lorsqu'elles sont revendiquées (GetObjectTagging non implémenté).
• Ceph RGW v19.2.7, sur son backend de test dbstore, ne termine pas la lecture d'un objet multipartie dont la dernière partie fait un octet (5 Mio + 1 octet) ; le défaut se reproduit en v20.2.4. Le jeu de données contient un tel objet : les exécutions complètes contre RGW attendent sa correction.
• Le client boto3 (version 1.36 et suivantes) valide par défaut des sommes de contrôle CRC et rejette la réponse de Garage pour un objet multipartie. C'est l'incident de janvier 2025 décrit dans la note de constat et propositions (§2.5). Le client de référence du kit désactive donc ces contrôles et vérifie lui-même l'intégrité par SHA-256.

2. Vue d'ensemble¶

Hors famille ORG, le kit vérifie 10 contrats sur 30 et en couvre 6 en partie. Complétude, intégrité, métadonnées système, clés difficiles, pagination, réimport, droits et portabilité fonctionnelle sont vérifiés ; métadonnées utilisateur, manifeste, lectures partielles, mesures de performance et reprise le sont en partie.

3. Famille EXP : export¶

EXP-01 : Exhaustivité de l'export¶

• Exigence : toutes les données exportables du bucket peuvent être récupérées.
• Comportement attendu : le listage complet du bucket (ou le manifeste) énumère tous les objets présents ; chaque objet énuméré est lisible intégralement par l'API, sans exception ni filtrage implicite (taille, classe de stockage, caractères de la clé).
• Critère mesurable : nombre d'objets et volume total récupérés / nombre d'objets et volume total présents dans le jeu de données de référence. Seuil : 100 %.
• Test : CTK-01 (export complet), CTK-04 (export avec incidents), CTK-X1 (grand nombre d'objets).
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : vérifié (critère A1) par CTK-01 et CTK-04, objet par objet. Le kit propose un volume fonctionnel (10 000 objets, 10 Go) et un volume de charge (100 000 objets, 1 To). Le grand nombre d'objets de CTK-X1 n'est pas encore couvert.

EXP-02 : Export des versions et marqueurs de suppression¶

• Exigence : sur un bucket versionné, l'historique complet est exportable.
• Comportement attendu : le listage des versions énumère toutes les versions de chaque clé et tous les marqueurs de suppression, avec leur ordre ; chaque version non courante est lisible.
• Critère mesurable : versions et marqueurs exportés / versions et marqueurs présents. Seuil : 100 %.
• Test : CTK-X3 (périmètre avancé).
• Niveau / nature / maturité : Versioned / bloquant / À approfondir. Les versions relèvent des périmètres avancés.
• CTK S4 : non.

EXP-03 : Manifeste d'export¶

• Exigence : le fournisseur met à disposition (ou l'outillage de référence produit) un manifeste d'export conforme au schéma du profil S4.
• Comportement attendu : à la demande, un manifeste décrivant chaque objet (et chaque version) avec ses métadonnées et une somme de contrôle de l'objet complet est produit dans un délai déclaré, dans un format ouvert.
• Critère mesurable : conformité du manifeste au schéma ; cohérence manifeste / contenu réel (100 %) ; délai de production (déclaré-vérifié).
• Test : CTK-01, CTK-03, CTK-X2 (conformité du manifeste au schéma).
• Niveau / nature / maturité : Core / bloquant / À approfondir. Format retenu : JSON Lines accompagné d'un JSON Schema. Le partage des rôles entre fournisseur et outil client reste ouvert (cf. section 12) ; la proposition actuelle réserve l'obligation du fournisseur aux données que l'API n'expose pas (MET-04) et accepte un outil client pour le reste.
• CTK S4 : partiel. Le kit produit lui-même, à partir de l'API, trois manifestes JSON Lines (référence, source, cible) conformes à un premier JSON Schema. Il valide contre ce schéma tout manifeste fourni par un fournisseur. Le délai de production d'un manifeste par le fournisseur n'est pas mesuré.

EXP-04 : Export de la configuration du bucket¶

• Exigence : la configuration du bucket est exportable sous forme lisible par machine.
• Comportement attendu : la configuration (versionnage, Object Lock par défaut, cycle de vie, CORS, chiffrement par défaut, politique d'accès, étiquettes de bucket) est lisible par l'API ou fournie dans le manifeste.
• Critère mesurable : éléments de configuration exportés / éléments de configuration actifs. Seuil : 100 % pour les éléments du niveau de profil déclaré.
• Test : CTK-01 (volet configuration).
• Niveau / nature / maturité : Core pour versionnage et politique d'accès, Extended pour le reste / bloquant au niveau Core / À approfondir.
• CTK S4 : non (critère A5 non évalué).

EXP-05 : Accès aux objets des classes froides¶

• Exigence : les objets stockés en classe froide (archive) sont récupérables dans un délai et à un coût déclarés.
• Comportement attendu : une demande de restauration en masse est possible par l'API ; le délai de mise à disposition est conforme à la valeur déclarée ; aucune restauration manuelle objet par objet n'est nécessaire.
• Critère mesurable : délai de restauration mesuré comparé au délai déclaré ; possibilité d'automatiser la restauration en masse (oui/non).
• Test : CTK-X4 (périmètre avancé).
• Niveau / nature / maturité : Extended / déclaré-vérifié / À approfondir.
• CTK S4 : non.

EXP-06 : Export assisté pour très gros volumes¶

• Exigence : pour les volumes dont la sortie par le réseau excède un délai raisonnable, le fournisseur propose une modalité d'export assisté.
• Comportement attendu : modalité documentée (liaison dédiée temporaire, transfert physique, export vers un point de collecte), avec délai de mise en place et débit déclarés.
• Critère mesurable : existence (oui/non), délai de déploiement déclaré, débit déclaré.
• Test : vérifiable par déclaration et retour d'expérience ; un CTK automatisé ne peut pas le tester.
• Niveau / nature / maturité : hors profil / déclaré-vérifié / Pas mûre. À rattacher à l'obligation d'assistance du Data Act (art. 25).
• CTK S4 : non.

4. Famille MET : métadonnées¶

MET-01 : Métadonnées système reproductibles¶

• Exigence : les métadonnées système que l'API permet de fixer à l'écriture sont préservées.
• Comportement attendu : Content-Type, Content-Encoding, Content-Language, Content-Disposition, Cache-Control, Expires lus à la source sont identiques après réimport chez la cible.
• Critère mesurable : taux de conservation par attribut. Seuil : 100 %.
• Test : CTK-03 (jeu de données DS-M).
• Niveau / nature / maturité : Core / bloquant / Prête après accord sur la liste des champs obligatoires et des transformations admises.
• CTK S4 : vérifié (critère A3). Le kit compare Content-Type, Content-Encoding, Content-Language, Content-Disposition, Cache-Control et Expires.

MET-02 : Métadonnées utilisateur¶

• Exigence : les métadonnées utilisateur (x-amz-meta-*) sont préservées à l'identique.
• Comportement attendu : noms et valeurs identiques, y compris valeurs encodées (RFC 2047 ou équivalent) et taille cumulée jusqu'à la limite déclarée par le profil.
• Critère mesurable : taux de conservation. Seuil : 100 %, dans la limite de taille définie par le profil.
• Test : CTK-03 (DS-M).
• Niveau / nature / maturité : Core / bloquant / Prête après accord sur la liste des champs. La limite de taille commune du profil reste à fixer (AWS : 2 Ko par requête PUT).
• CTK S4 : partiel (critère A3). Le kit vérifie les noms, les valeurs ASCII et des valeurs non ASCII encodées selon la RFC 2047, qui doivent être restituées à l'identique ; la taille proche de la limite attend la fixation de cette limite.

MET-03 : Étiquettes¶

• Exigence : les étiquettes d'objets et de bucket sont exportées et réimportables.
• Critère mesurable : taux de conservation. Seuil : 100 %.
• Test : CTK-03 (DS-M).
• Niveau / nature / maturité : Governance / bloquant / Prête. Les étiquettes font partie du jeu fonctionnel ; leur caractère obligatoire au niveau Core reste à trancher.
• CTK S4 : vérifié pour les étiquettes d'objets (critère A3), lorsque le service les revendique. Garage v1.0.1 ne les prend pas en charge : revendiquées, elles donnent un verdict non conforme. Les étiquettes de bucket ne sont pas couvertes.

MET-04 : Métadonnées non reproductibles¶

• Exigence : les métadonnées que l'API ne permet pas de recréer sont transportées par le manifeste et conservées à côté des données chez la cible.
• Comportement attendu : le manifeste contient, pour chaque objet ou version, Last-Modified d'origine, VersionId d'origine, ETag d'origine, classe de stockage d'origine, propriétaire d'origine ; la cible les conserve (par exemple en métadonnées utilisateur normalisées oi-orig-*, ou dans le manifeste archivé avec les données).
• Critère mesurable : présence et exactitude de ces champs dans le manifeste. Seuil : 100 %.
• Test : CTK-03, CTK-X2, CTK-X3.
• Niveau / nature / maturité : Core / bloquant / À approfondir. Principe retenu : la valeur d'origine est préservée dans le manifeste, sans prétention à conserver son fonctionnement natif. La convention de conservation chez la cible reste à définir.
• CTK S4 : partiel (critère A4). Le kit copie Last-Modified et l'ETag d'origine en métadonnées utilisateur oi-orig-* chez la cible et vérifie leur exactitude. VersionId, classe de stockage et propriétaire d'origine ne sont pas couverts.

MET-05 : Rétention et legal hold¶

• Exigence : les objets soumis à rétention (Object Lock) ou à legal hold sont exportés avec leurs paramètres ; la protection peut être réappliquée chez la cible.
• Comportement attendu : le manifeste indique le mode (governance ou compliance), la date de fin de rétention et le legal hold ; chez une cible de niveau Governance, la rétention est réappliquée avec la même date de fin.
• Critère mesurable : exactitude des paramètres exportés (100 %) ; rétention effective chez la cible (vérifiée par une tentative de suppression refusée).
• Test : CTK-X3 (volet Governance).
• Niveau / nature / maturité : Governance / bloquant / À approfondir. La continuité de la conservation légale pendant le transfert, quand l'objet existe chez la cible sans protection, pose une question juridique ouverte.
• CTK S4 : non.

MET-06 : Droits d'accès¶

• Exigence : les politiques d'accès et ACL sont exportées sous forme documentaire lisible par machine.
• Comportement attendu : la politique du bucket, les ACL éventuelles et la configuration de propriété sont lisibles par l'API ou incluses dans le manifeste.
• Critère mesurable : export complet (100 %). La V0 n'exige pas la traduction vers le modèle IAM de la cible.
• Test : CTK-03 (volet droits) ; la reconstruction des droits relève de SEC-01.
• Niveau / nature / maturité : Core / bloquant / À approfondir.
• CTK S4 : non. Le kit compare les droits par leur effet (SEC-01), sans lire les politiques elles-mêmes.

5. Famille INT : intégrité¶

INT-01 : Somme de contrôle de l'objet complet¶

• Exigence : chaque objet dispose d'une somme de contrôle de son contenu complet, indépendante du découpage multipartie et du chiffrement côté serveur.
• Comportement attendu : la somme (liste fermée d'algorithmes fixée par le profil, SHA-256 ou CRC64NVME) est calculée à l'écriture, restituée à la lecture et dans le manifeste. L'ETag ne sert pas de somme de contrôle.
• Critère mesurable : présence de la somme pour 100 % des objets ; concordance avec un recalcul indépendant.
• Test : CTK-02, CTK-04.
• Niveau / nature / maturité : Core / bloquant / Prête. Proposition de l'atelier : SHA-256 calculé sur le contenu complet de chaque objet. L'ETag ne constitue pas une preuve d'intégrité.
• CTK S4 : non comme propriété du service. Le kit calcule lui-même le SHA-256 de chaque objet complet à chaque étape, ce qui fournit le recalcul indépendant ; il ne vérifie pas que le service stocke et restitue une telle somme. L'incident boto3 (section 1.5) montre l'enjeu : faute d'algorithme fixé par le profil, client et serveur peuvent diverger sur les sommes attendues.

INT-02 : Zéro corruption, zéro perte¶

• Exigence : le contenu récupéré est identique bit à bit au contenu déposé.
• Comportement attendu : pour chaque objet du jeu de référence, la somme recalculée après export, puis après réimport chez la cible, est identique à la somme de référence.
• Critère mesurable : nombre d'objets divergents. Seuil : 0.
• Test : CTK-01 à CTK-05 ; CTK-02 vérifie en outre que des corruptions injectées sont détectées.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : vérifié (critère A2) par CTK-02 et CTK-04. CTK-02 injecte chez la cible trois corruptions (octet inversé, troncature, remplacement), exige que toutes soient détectées et localisées, puis répare les objets.

INT-03 : Vérification d'intégrité à la lecture¶

• Exigence : le service permet au client de vérifier l'intégrité à la lecture, y compris pour les lectures partielles.
• Comportement attendu : restitution de la somme de contrôle sur demande ; en cas de corruption détectée côté serveur, erreur explicite à la place d'un contenu altéré.
• Critère mesurable : disponibilité de la somme sur GET et HEAD (oui/non) ; comportement en lecture partielle documenté.
• Test : CTK-02, sélection de s3-tests.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : non. La sélection de s3-tests n'est pas intégrée.

6. Famille PERF : performance¶

PERF-01 : Débit d'export soutenable¶

• Exigence : le fournisseur déclare le débit d'export soutenable par bucket et par compte, puis le tient.
• Comportement attendu : dans les conditions normalisées du CTK (client de référence, parallélisme défini, réseau non limitant), le débit mesuré sur une durée minimale atteint au moins la valeur déclarée.
• Critère mesurable : débit soutenu mesuré (Gbit/s) sur une fenêtre d'au moins 30 minutes ; écart au déclaré. Tolérance proposée : -10 %.
• Test : CTK-06 ; CTK-05 publie la durée totale et le débit utile observés.
• Niveau / nature / maturité : Core / déclaré-vérifié / À approfondir. Dépend de la méthode de mesure normalisée, en particulier de la neutralisation du réseau.
• CTK S4 : partiel. CTK-05 publie la durée totale (B10) et le débit utile (B11) à titre informatif. Le transfert passe par la machine qui exécute le kit, si bien que ces valeurs mesurent la chaîne complète. CTK-06 n'est pas implémenté.

PERF-02 : Limites de requêtes¶

• Exigence : les limites de débit de requêtes (par préfixe, bucket, compte) sont déclarées ; leur dépassement est signalé de façon normalisée.
• Comportement attendu : au-delà de la limite, réponse 503 SlowDown (ou code défini par le profil) avec, si possible, Retry-After ; jamais de perte silencieuse, de connexion coupée sans réponse ou de délai indéfini.
• Critère mesurable : limite mesurée comparée à la limite déclarée ; conformité des réponses de limitation (100 %).
• Test : CTK-06 (montée en charge), CTK-04 (injection).
• Niveau / nature / maturité : Core / déclaré-vérifié / À approfondir, comme l'ensemble « durée et débit » dans le classement de l'atelier.
• CTK S4 : non.

PERF-03 : Parallélisation¶

• Exigence : l'export peut être parallélisé (plusieurs connexions, plusieurs préfixes, lectures par plages) sans dégradation anormale.
• Critère mesurable : courbe débit / parallélisme ; parallélisme maximal déclaré atteint sans hausse du taux d'erreur au-delà d'un seuil défini.
• Test : CTK-06.
• Niveau / nature / maturité : Core / déclaré-vérifié / À approfondir.
• CTK S4 : non.

PERF-04 : Listage de très grands buckets¶

• Exigence : le listage complet d'un bucket de très grande cardinalité se fait dans un délai déclaré.
• Critère mesurable : temps de listage complet de DS-S (10⁶ objets) ; extrapolation documentée pour 10⁸ et 10⁹ objets ; ou délai de production du manifeste (EXP-03) si celui-ci remplace le listage.
• Test : CTK-X1.
• Niveau / nature / maturité : Core / déclaré-vérifié / À approfondir.
• CTK S4 : non.

7. Famille API : comportements d'interface¶

API-01 : Pagination complète et stable¶

• Exigence : le listage paginé énumère chaque objet exactement une fois.
• Comportement attendu : ordre lexicographique binaire UTF-8 des clés ; jeton de continuation valide pendant une durée déclarée ; pas de doublon ni d'omission sur un bucket stable ; comportement documenté si le bucket est modifié pendant le listage.
• Critère mesurable : doublons et omissions sur DS-S et DS-K. Seuil : 0.
• Test : CTK-01 (inventaire sur plusieurs pages), CTK-X1.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : vérifié par CTK-01, sur un inventaire de plusieurs pages : les doublons relèvent du critère A6, les omissions du critère A1. L'ordre des clés et la durée de validité du jeton ne sont pas contrôlés.

API-02 : Erreurs normalisées et reprise¶

• Exigence : toute erreur est signalée par un code HTTP et un code d'erreur du profil, qui distinguent erreurs définitives et erreurs transitoires.
• Comportement attendu : les erreurs transitoires (5xx, SlowDown) peuvent être rejouées sans effet de bord ; aucune réponse 200 avec contenu tronqué.
• Critère mesurable : conformité des réponses d'erreur aux codes du profil (100 %) sur les cas provoqués.
• Test : CTK-04, sélection de s3-tests.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : non. CTK-04 injecte pour l'instant des coupures de connexion ; les erreurs 5xx sont prévues.

API-03 : Lectures partielles et reprise¶

• Exigence : un transfert interrompu peut reprendre sans relire l'objet depuis le début.
• Comportement attendu : prise en charge de Range sur GET (une plage, au minimum) ; If-Match sur l'ETag pour garantir la cohérence des plages.
• Critère mesurable : conformité (oui/non) ; reprise réussie après coupure simulée.
• Test : CTK-04.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : partiel. L'application témoin de CTK-05 lit trois plages d'octets chez la cible (milieu de l'objet, frontière de partie, fin) et les compare aux octets de référence ; elle vérifie qu'un If-Match sur l'ETag courant réussit et qu'un ETag périmé donne 412. Garage v1.0.1 ignore If-Match en lecture : un ETag périmé renvoie l'objet, d'où un verdict non conforme sur A11. Le kit reprend les transferts interrompus objet par objet, sans reprise par plage.

API-04 : Clés difficiles¶

• Exigence : toute clé acceptée à l'écriture est restituée à l'identique au listage et à la lecture.
• Comportement attendu : pas de normalisation Unicode, de modification de casse, de fusion de / consécutifs ou d'interprétation de . et .. ; longueur maximale de clé du profil prise en charge ; objets se terminant par / traités comme des objets ordinaires.
• Critère mesurable : clés de DS-K restituées à l'identique. Seuil : 100 % des clés que la cible du profil déclare accepter.
• Test : CTK-01 (DS-K).
• Niveau / nature / maturité : Core / bloquant / Prête. Le jeu de caractères minimal garanti par le profil reste à fixer.
• CTK S4 : vérifié (critères A1 et A6). Le kit dépose les treize clés de DS-K : même clé en NFC et en NFD, espaces intérieur, de tête et de fin, emoji, //, segments . et .., clé finissant par /, clés ne différant que par la casse, clé de 1 024 octets.

API-05 : Accès automatisable¶

• Exigence : l'export complet peut être réalisé par programme, sans console web, sans ticket de support et sans intervention humaine du fournisseur (hors export assisté).
• Comportement attendu : identifiants d'accès programmatiques obtenables par le client ; toutes les opérations nécessaires à l'export disponibles par l'API.
• Critère mesurable : part des étapes de l'export automatisables (cf. scorecard, A9). Seuil pour le niveau Core : 100 %.
• Test : CTK-01 exécuté de bout en bout sans intervention manuelle.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : non comme critère (A9 n'est pas évalué). Les exécutions du kit se déroulent sans intervention manuelle une fois les comptes et buckets préparés. Le rapport de CTK-04 consigne zéro intervention.

8. Famille REC : reconstruction¶

REC-01 : Réimport chez une cible de référence¶

• Exigence : les données exportées (avec le manifeste) peuvent être réimportées chez une cible de référence open source, avec un résultat vérifiable.
• Comportement attendu : après réimport dans Ceph RGW (tous niveaux) ou Garage (niveau Core), les objets, métadonnées reproductibles et sommes de contrôle sont identiques ; les métadonnées non reproductibles sont conservées selon la convention MET-04.
• Critère mesurable : comparaison manifeste source / manifeste cible. Seuil : zéro écart sur les champs du niveau déclaré.
• Test : CTK-01, CTK-03.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : vérifié (critère A7) par CTK-01. Garage v1.0.1 est conforme comme cible de niveau Core. Le défaut de lecture multipartie de Ceph RGW bloque pour l'instant les exécutions contre la seconde cible de référence.

REC-02 : Absence de dépendance propriétaire¶

• Exigence : relire et réutiliser les données exportées ne requiert aucun logiciel, format ou service propriétaire du fournisseur source.
• Comportement attendu : les données sont exportées dans leur forme d'origine (octets déposés par le client) ; le manifeste est dans un format ouvert ; aucun outil de déchiffrement ou de décompression spécifique au fournisseur n'est nécessaire.
• Critère mesurable : liste des dépendances requises (cible : vide).
• Test : CTK-01 exécuté avec le seul outillage de référence open source ; CTK-05 pour l'indépendance à l'usage.
• Niveau / nature / maturité : Core / bloquant / Prête.
• CTK S4 : vérifié (critère A8) par CTK-05. L'application témoin travaille sur la cible seule. Les anciens identifiants de l'application doivent être refusés par la source ; s'ils restent acceptés, le verdict est non concluant. Le kit est lui-même un outillage open source et lit les données dans leur forme d'origine.

REC-03 : Reconstruction de l'historique des versions¶

• Exigence : l'historique des versions peut être reconstruit chez une cible de niveau Versioned.
• Comportement attendu : rejeu chronologique des versions et marqueurs de suppression ; correspondance entre VersionId d'origine et VersionId cible conservée (métadonnée ou table de correspondance).
• Critère mesurable : nombre et ordre des versions identiques ; table de correspondance complète.
• Test : CTK-X3.
• Niveau / nature / maturité : Versioned / bloquant / À approfondir. Le manifeste transporte les dates d'origine ; la cible ne les reconstruit pas.
• CTK S4 : non.

REC-04 : Portabilité fonctionnelle (équivalence fonctionnelle)¶

• Exigence : les données migrées sont exploitables sur B sans dépendre de A. Cette exigence donne une définition opérationnelle de l'équivalence fonctionnelle de l'article 30 du Data Act pour le stockage objet.
• Comportement attendu : après révocation de tous ses accès à A, une application témoin configurée vers B (adresse du point d'accès et identifiants uniquement) passe sa suite de tests.
• Critère mesurable : tests applicatifs réussis sur tests prévus. Seuil : 100 % sur le profil obligatoire.
• Test : CTK-05.
• Niveau / nature / maturité : Core / bloquant / À approfondir. L'application témoin de référence et sa suite de tests restent à valider, de préférence avec un utilisateur volontaire.
• CTK S4 : vérifié (critère A11). L'application témoin du kit lit un échantillon d'objets et le compare au manifeste, contrôle les métadonnées, parcourt un listage paginé, lit une plage d'octets et écrit un objet. Le scénario est prévu pour le volume de charge.

9. Famille SEC : sécurité et droits¶

SEC-01 : Droits reconstruits équivalents¶

• Exigence : le transfert se fait sous contrôle ; les droits convenus sont reconstruits chez B.
• Comportement attendu : pour une matrice d'accès convenue (identités, opérations, objets), chaque accès autorisé chez A l'est chez B et chaque accès interdit chez A l'est chez B ; aucun objet ne devient public par accident.
• Critère mesurable : cas d'accès correctement appliqués sur cas prévus. Seuil : 100 % ; zéro exposition publique involontaire.
• Test : CTK-03.
• Niveau / nature / maturité : Core / bloquant / À approfondir. Les droits se comparent par leur effet sur les accès, car les modèles IAM diffèrent d'un fournisseur à l'autre. Restent à définir le format de la matrice d'accès, les correspondances entre modèles et les droits minimaux nécessaires à l'export et à l'import. La définition des identités et des droits rejoint le socle transverse.
• CTK S4 : vérifié (critère A10) lorsqu'une matrice d'accès est fournie ; sinon, le verdict est non applicable. La matrice du kit, au format TOML, associe des identités (un compte de chaque côté, ou l'accès anonyme) à des cas, chacun formé d'une opération (lecture, en-tête, listage, écriture ou suppression) et de la décision attendue. Le kit ajoute par défaut deux cas où la lecture et le listage anonymes doivent être interdits. Un cas où la source s'écarte déjà de la décision attendue rend le verdict non concluant. Garage v1.0.1 est conforme avec une clé en lecture seule et l'accès anonyme : lectures autorisées, écritures, suppressions et accès anonyme interdits.

10. Famille REP : reprise après incident¶

REP-01 : Reprise d'une migration interrompue¶

• Exigence : une migration interrompue reprend sans perte ni duplication logique.
• Comportement attendu : après une coupure réseau, des erreurs temporaires injectées ou l'expiration d'identifiants, l'outil reprend automatiquement ; le rapport décrit chaque incident.
• Critère mesurable : résultat final identique au manifeste ; délai de reprise, octets retransmis et interventions nécessaires publiés (B9).
• Test : CTK-04.
• Niveau / nature / maturité : Core / bloquant / Prête après précision des incidents, des délais et des erreurs à couvrir. Les seuils de délai et de retransmission seront calibrés après les premiers essais.
• CTK S4 : partiel. CTK-04 injecte des coupures de connexion plus longues que les tentatives du SDK, exige un résultat final complet et intègre (A1, A2) et publie les incidents, les reprises, un majorant des octets retransmis et le nombre d'interventions. Si aucun incident n'atteint le transfert, le verdict est non concluant. Il mesure aussi la durée de reprise. Les erreurs 5xx et l'expiration d'identifiants sont prévues.

11. Famille ORG : exigences organisationnelles et juridiques¶

Ces exigences reprennent pour l'essentiel le chapitre VI du Data Act. Le profil les rend vérifiables (documentées, datées, auditables) dans le cadre d'un achat. Elles se prouvent par déclaration et audit, hors CTK.

ORG-01 : Procédure de sortie documentée¶

• Exigence : une procédure de sortie complète, publique et à jour, décrit les étapes, outils, formats, limites connues et interlocuteurs.
• Critère : existence, date de mise à jour, cohérence avec la fiche de déclaration fournisseur.
• Nature / maturité : déclaratif-auditable / Prête. Ancrage Data Act art. 26.

ORG-02 : Délais¶

• Exigence : préavis maximal, période de transition et période de récupération conformes au Data Act et inscrits au contrat.
• Critère : préavis ≤ 2 mois ; transition de 30 jours (ou justification de l'extension) ; récupération ≥ 30 jours.
• Nature / maturité : déclaratif-auditable / Prête. Ancrage Data Act art. 25.

ORG-03 : Coût de sortie¶

• Exigence : le coût de sortie et ses conditions sont publiés à l'avance.
• Critère : grille publiée ; à partir du 12 janvier 2027, absence de frais de changement ; conditions d'éligibilité à la gratuité (délai de demande, fermeture de compte) explicites.
• Nature / maturité : déclaratif-auditable / Prête. Ancrage Data Act art. 29.

ORG-04 : Effacement et attestation¶

• Exigence : à l'issue de la période de récupération, les données exportables sont effacées, y compris les sauvegardes et répliques. Le client reçoit une attestation.
• Critère : délai d'effacement déclaré ; attestation datée listant le périmètre ; traitement explicite des objets sous rétention légale.
• Nature / maturité : déclaratif-auditable / À approfondir. Modalités de preuve à définir (journal signé, audit tiers).

ORG-05 : Réversibilité des clés¶

• Exigence : lorsque le client utilise un service de gestion de clés du fournisseur, les conditions de récupération ou de migration des clés sont documentées.
• Nature / maturité : déclaratif-auditable / Pas mûre. L'exigence déborde du stockage objet ; elle relève du socle transverse et de la cybersécurité.

12. Points ouverts¶

Les points suivants restent à trancher par le groupe de travail, en vue du profil V0.1 de décembre 2026. Les essais croisés de fin novembre devraient en éclairer plusieurs.

1. Manifeste (EXP-03). Le manifeste est-il une obligation du fournisseur, ou un outil client open source suffit-il pour les données que l'API expose ? Le CTK S4 montre qu'un outil client peut produire un manifeste conforme au schéma, au prix d'une lecture intégrale du bucket ; un manifeste fourni par le fournisseur éviterait cette seconde lecture sur les grands volumes.
2. Somme de contrôle (INT-01). L'atelier propose SHA-256 sur le contenu complet de chaque objet. Restent à fixer le mode de calcul pour les objets multiparties et la façon dont le service restitue la somme. L'incident boto3 relevé par le kit montre le coût d'un algorithme non fixé.
3. Limites communes (MET-02, API-04). Limite de taille des métadonnées utilisateur, longueur maximale de clé et jeu de caractères minimal garanti par le profil.
4. Liste des champs obligatoires (MET-01, MET-02, A3) et transformations admises.
5. Conservation des métadonnées non reproductibles (MET-04). Le CTK S4 emploie des métadonnées utilisateur oi-orig-* ; la convention du profil (préfixe, ou manifeste archivé à côté des données) reste à arrêter, de même que le traitement de VersionId, de la classe de stockage et du propriétaire.
6. Étiquettes (MET-03). Font-elles partie des champs obligatoires du niveau Core ? Garage, cible de référence de ce niveau, ne les prend pas en charge.
7. Matrice d'accès (SEC-01). Le format TOML du kit sert de première proposition. Restent les correspondances entre modèles IAM et les droits minimaux nécessaires à l'export et à l'import.
8. Reprise (REP-01). Incidents, délais et erreurs à couvrir ; seuils de délai et de retransmission, à calibrer sur les premiers essais.
9. Rétention légale pendant le transfert (MET-05). La continuité de la protection relève-t-elle du contrat comportemental ou du seul contrat juridique ? Point reporté avec les périmètres avancés.
10. Performance (PERF-01 à PERF-04, CTK-06). Méthode de mesure normalisée, neutralisation du réseau et tolérance sur les valeurs déclarées.
11. Seconde cible de référence. Les exécutions complètes contre Ceph RGW attendent la correction du défaut de lecture multipartie, ou une exécution sur un déploiement RADOS.
12. Migration par API. L'atelier a classé à approfondir le point « migration S3 api disponible », sans autre précision ; son rattachement à API-05 ou à un contrat nouveau reste à établir.
13. Usage contractuel. La traduction des verdicts du CTK en clauses relève de la proposition d'annexe contractuelle annoncée pour décembre 2026.