Profil S4 : scorecard de réversibilité¶

Version 0.3 · 31 octobre 2026 · draft · PDF

La scorecard du profil S4 (Sovereign S3) répond à une question simple : combien de temps faut-il pour sortir d'un service de stockage objet, avec quelles contraintes et avec quelles pertes ? Elle traduit les contrats comportementaux du profil (contrats) en critères et en mesures, que les scénarios de test (scénarios) évaluent. Sa structure a été retenue par l'atelier OpenInterop du 9 octobre 2026 consacré à la réversibilité du stockage objet ; les seuils et plusieurs méthodes restent à valider par le groupe de travail (section 6).

Le CTK S4, implémentation des scénarios CTK-01 à CTK-05 (CTK S4), évalue aujourd'hui tous les critères de la première étape, trois des cinq critères de la seconde (A6, A7, A8) et publie trois des onze mesures. Les tableaux des sections 2 et 3 indiquent, pour chaque critère et chaque mesure, le scénario qui l'évalue dans le CTK S4.

1. Principes¶

1.1 Trois blocs, aucun score composite¶

Les huit métriques de départ (délai, débit, intégrité, métadonnées, portabilité, dépendances, automatisation, coût) sont de natures différentes. La scorecard les répartit en trois blocs, restitués séparément :

Cette répartition applique la règle de la doctrine OpenInterop (doctrine, §5.2). La conformité exige que tous les critères obligatoires du périmètre revendiqué soient satisfaits, sans compensation entre critères. Les mesures sont publiées à part, avec leurs conditions. Aucune moyenne pondérée ne fonde un verdict de conformité : un excellent débit ne compense ni un objet manquant, ni un contenu corrompu, ni un accès interdit devenu autorisé. Le bloc B informe l'acheteur, qui fixe ses seuils selon son besoin ; le bloc C éclaire le choix sans le trancher. L'atelier a jugé prématurés un score global pondéré et un seuil universel de débit.

1.2 Comparabilité¶

Une métrique n'est comparable entre fournisseurs que si les conditions de mesure sont fixées. La scorecard est donc indissociable d'une méthode de mesure normalisée :

• Jeux de données de référence fixés et publiés, générés de façon déterministe à partir d'une graine (cf. scénarios, §2). Le CTK S4 produit les mêmes octets pour une même graine, à trois volumes : essai rapide, volume fonctionnel (10 000 objets, 10 Go) et volume de charge (100 000 objets, 1 To).
• Client de référence : outil, version et paramètres (parallélisme, taille des parts, reprises) fixés. Les essais du CTK S4 ont montré la nécessité de ce point. Depuis janvier 2025, le client AWS pour Python (boto3) valide par défaut des sommes de contrôle CRC et rejette la réponse de Garage pour un objet multipartie. Le client de référence du CTK S4 désactive donc ces calculs hors des cas où l'API les exige ; il vérifie lui-même l'intégrité par SHA-256.
• Environnement identique : mêmes régions, mêmes quotas, même chemin réseau.
• Réseau non limitant : le client est placé de sorte que le réseau ne soit pas le goulot (même région, ou lien de capacité supérieure au débit mesuré). La capacité du lien est mesurée et publiée avec le résultat.
• Durée minimale des mesures de débit (30 minutes proposées) pour neutraliser les effets de rafale.
• Répétition : au moins trois exécutions, dont on publie la médiane et la dispersion.
• Horodatage et versions : date, région, version du profil, version du CTK. Le rapport du CTK S4 contient ces éléments, ainsi que l'empreinte du manifeste de référence et la commande qui rejoue l'exécution.

1.3 Limites de la comparaison¶

2. Bloc A : critères obligatoires¶

Chaque critère est évalué sur le périmètre revendiqué par le fournisseur : niveau Core en V0, les niveaux Versioned, Governance et Extended relevant des périmètres avancés. Les critères entrent en vigueur par étapes. La première étape reprend les cinq critères retenus par l'atelier : complétude (A1), intégrité (A2), métadonnées (A3, A4), droits d'accès (A10) et portabilité fonctionnelle (A11). Les cinq autres (A5 à A9), qui découlent des contrats du profil, s'ajouteront dans une étape suivante ; d'ici là, le CTK peut les évaluer à titre informatif.

La colonne « Scénarios » renvoie à la spécification ; la colonne « CTK S4 » indique les scénarios qui évaluent le critère dans l'implémentation actuelle.

Dans le CTK S4, A4 est vérifié par le transport des valeurs Last-Modified et ETag d'origine en métadonnées utilisateur sur la cible. A8 n'est évalué que si l'on fournit les anciens identifiants de l'application, révoqués avant l'exécution ; la source doit alors les refuser. A5 (export de la configuration des buckets) et A9 (absence d'intervention manuelle) ne font pas encore l'objet d'un verdict.

Verdict du bloc A. Chaque critère reçoit l'un des quatre verdicts de la doctrine :

• CONFORME : le seuil est atteint sur le périmètre testé ;
• NON CONFORME : le seuil n'est pas atteint ; le rapport donne les éléments de preuve (objets en écart, extraits du rapport du CTK) ;
• NON APPLICABLE : le critère est hors du périmètre revendiqué ou n'a pas été demandé ;
• NON CONCLUANT : l'environnement de test a fait défaut (service injoignable, identifiants refusés) ; l'exécution est à refaire.

Le bloc est conforme si aucun critère n'est non conforme ni non concluant ; un seul critère non conforme rend le bloc non conforme.

Une fonction revendiquée mais absente donne un verdict non conforme. Les premiers essais du CTK S4 l'illustrent : Garage v1.0.1 satisfait les critères évalués au niveau Core, sauf A11 : il ignore les lectures conditionnelles (If-Match), que l'application témoin vérifie. Une exécution qui revendique les étiquettes d'objet échoue en outre sur A3, car GetObjectTagging n'y est pas implémenté. Sur Ceph RGW v19.2.7 (moteur de stockage autonome dbstore), la lecture d'un objet multipartie dont la dernière partie fait un octet ne se termine jamais ; les exécutions complètes n'aboutissent donc pas et RGW n'a pas encore de verdict.

3. Bloc B : mesures publiées¶

Les mesures sont publiées avec leurs conditions ; le seuil dépend du profil du client. La méthode « valeur déclarée par le fournisseur, puis vérifiée par le CTK » reste une option du scénario CTK-06 (performance de la migration), dont le contenu est à définir par le groupe de travail. Le CTK S4 n'implémente pas CTK-06 ni les scénarios avancés CTK-X1 à CTK-X4 : il ne publie donc aujourd'hui que B9, B10 et B11, à titre informatif.

Statut de chaque valeur.

• PUBLIÉ : mesure publiée avec ses conditions ;
• TENU ou NON TENU : valeur déclarée comparée à la mesure, si CTK-06 retient cette méthode ;
• NON DÉCLARÉ, NON MESURÉ. L'absence de déclaration est elle-même une information publiée.

Grandeur dérivée pour l'acheteur : délai d'export estimé pour un volume V et un nombre d'objets N :

délai_estimé ≈ max( V / B1 , N / B3 ) + B4 (ou B5) + B6 (si classes froides)

Exemple indicatif : 200 To, 50 millions d'objets, B1 = 10 Gbit/s, B3 = 2 000 req/s → max(44 h, 7 h) ≈ 44 h de transfert, hors listage et restauration. La formule aide à lire les mesures et n'engage pas le fournisseur ; elle suppose que le réseau du client n'est pas limitant.

4. Bloc C : contexte¶

Le bloc C relève de déclarations et de relevés ; aucun élément n'est évalué par le CTK S4.

Grille d'étapes pour l'automatisation (C3)¶

5. Fiche de profil fournisseur¶

La scorecard est restituée sous forme d'une fiche par service et par région. Les valeurs du gabarit ci-dessous sont fictives. Il indique le niveau de preuve (§5.3 de la doctrine) : autoévaluation par le fournisseur, vérification par un acheteur ou un tiers, essai croisé organisé par OpenInterop. Seul l'essai croisé ouvre droit au badge de conformité délivré par l'autorité technique.

Fiche de réversibilité S4 : <Fournisseur> / <Service> / <Région>
Profil : S4 V0.1         CTK : v0.x        Date : AAAA-MM-JJ
Niveau revendiqué : Versioned     Preuve : vérification

A. Critères obligatoires                  Verdict : CONFORME (Versioned)
   A1 Complétude ............ OK     A7 Réimport (Garage) ..... OK
   A2 Intégrité ............. OK     A8 Indépendance .......... OK
   A3 Métadonnées ........... OK     A9 Automatisation ........ OK
   A4 Manifeste ............. OK     A10 Droits d'accès ....... OK
   A5 Configuration ......... OK     A11 Tests applicatifs .... OK
   A6 Interface ............. OK

B. Mesures publiées
   B4 Listage 10⁶ objets .... 95 s                            PUBLIÉ
   B6 Restauration froide ... NON DÉCLARÉ
   B9 Reprise ............... 3 incidents, 0 intervention    PUBLIÉ
   B10 Durée totale ......... 6 h 40 (volume de charge, lien 10 Gbit/s)   PUBLIÉ
   B11 Débit utile .......... 8,9 Gbit/s                      PUBLIÉ

C. Contexte
   C1 Coût sortie 100 To .... 0 € (sur demande, fermeture du compte)
   C3 Automatisation ........ 8/9 étapes (attestation d'effacement manuelle)
   C5 Dépendances ........... notifications d'événements (format propriétaire)

Rapport CTK détaillé : <lien>   Empreinte du rapport : <sha256>

La fiche 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.

Paliers¶

La fiche cloud prévoit un indicateur d'interopérabilité cloud (fiche cloud, chantier CL4) ; la doctrine prévoit un indicateur calculé à partir des rapports de conformité (§5.4). Si des paliers sont retenus, ils se définissent par des conditions cumulatives, jamais par une moyenne :

6. Points ouverts¶

Les points suivants restent à trancher par le groupe de travail. Les dates proposées par l'atelier en fixent le cadre : TechSprint début novembre 2026, essais croisés fin novembre, profil V0.1 et proposition d'annexe contractuelle en décembre 2026.

1. Calendrier de la seconde étape (A5 à A9) et éventuelle révision de leurs seuils après les premiers essais croisés.
2. Liste des champs obligatoires et transformations admises (A3), dont le caractère obligatoire des étiquettes d'objet au niveau Core.
3. Format de la matrice d'accès et correspondances entre modèles IAM (A10). Le CTK S4 accepte une matrice d'identités et de cas attendus, qui sert de proposition.
4. Seuils de reprise (B9), à calibrer après les essais croisés ; incidents à ajouter aux coupures de connexion (erreurs serveur, expiration des identifiants).
5. Contenu de CTK-06 : méthode de mesure des débits (B1 à B3, B7) et, si la méthode « déclaré puis vérifié » est retenue, tolérances entre valeur déclarée et valeur mesurée.
6. Cible de référence pour le réimport (A7) : Garage couvre le niveau Core ; Ceph RGW, plus complet, doit d'abord être validé sur un déploiement où le défaut de lecture multipartie ne se produit pas.
7. Scénario type pour le calcul du coût (C1) et méthode de relevé de l'effort (C4).
8. Définition des paliers et articulation avec l'indicateur d'interopérabilité cloud.