> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sélection et certification des fournisseurs de stockage

> Choisir un fournisseur sans confondre compatibilité d'adaptateur et certification en direct

Sélectionnez le stockage d'abord selon les exigences opérationnelles, puis
confirmez la déclaration de support lisible par machine de la version.
CaseBender ne considère pas chaque backend implémenté par un SDK comme
certifié pour la version.

## Flux de sélection

1. Choisissez un service externe, géré par le client, accessible à la fois par
   le web et le worker.
2. Provisionnez des emplacements distincts `quarantine`, `records` et
   `ephemeral`.
3. Confirmez les exigences d'identité, TLS/CA privée, chiffrement, versioning,
   rétention, conservation légale, journalisation d'audit, egress, sauvegarde
   et restauration.
4. Comparez le profil produit exact avec
   `scripts/storage/certification-matrix.json`.
5. Exécutez la qualification en direct contre le produit/la version exacts
   depuis le réseau des charges de travail.
6. Signez et conservez des preuves assainies avec l'enregistrement de version.

## Interprétation de la matrice actuelle

| ID matrice             | Adaptateur d'exécution | Support déclaré | Mode requis | Signification pour l'opérateur                                                    |
| ---------------------- | ---------------------- | --------------- | ----------- | --------------------------------------------------------------------------------- |
| `openshift-odf-rgw`    | `s3`                   | Oui             | `live`      | Cible de support uniquement après réussite des preuves en direct ODF/Ceph exactes |
| `aws-s3`               | `s3`                   | Non             | `live`      | Adaptateur implémenté ; ne pas revendiquer de certification de version            |
| `google-cloud-storage` | `gcs`                  | Non             | `live`      | Adaptateur implémenté ; ne pas revendiquer de certification de version            |
| `azure-blob`           | `azure`                | Non             | `live`      | Adaptateur implémenté ; ne pas décrire Azure comme du code non supporté           |
| `local-development`    | `local`                | Non             | `unit`      | Développement/test nœud unique uniquement                                         |

Les preuves en direct ODF/Ceph actuelles sont bloquées par les identifiants
du client. Le profil est configuré et prêt pour la qualification, non
certifié. Ne mettez à jour le statut client qu'après que le validateur de
version a accepté des preuves signées de version exacte.

## Niveaux de preuve

* **Unit** prouve le comportement de l'adaptateur local dans des tests de
  code contrôlés.
* **Emulator** prouve la compatibilité SDK et de contrat avec le sous-ensemble
  d'un émulateur.
* **Live** prouve les opérations requises contre un produit nommé et une
  version exacte dans le contexte réseau, de confiance, d'identité et de
  politique prévu.

Les résultats d'émulateur ne peuvent jamais satisfaire une entrée de matrice
dont `requiredCertification` est `live`. Les noms de famille de produits tels
que « S3 compatible », « Ceph » ou « Azure Blob » sont insuffisants sans une
version cible exacte et un condensé de preuves.

La compatibilité d'émulateur n'est pas une certification en direct.

## Valider la matrice

```bash theme={null}
node scripts/storage/validate-certification-matrix.mjs
node --test scripts/storage/certification-matrix.test.mjs

# Release use requires a sanitized evidence JSON document.
node scripts/storage/validate-certification-matrix.mjs \
  --release \
  --evidence '<path-to-sanitized-evidence.json>'
```

Partez de `scripts/storage/certification-evidence.template.json`. N'ajoutez
jamais d'identifiants, de jetons, de chaînes de connexion, de clés privées, de
contenus d'objets, de noms d'objets client ou d'URL signées aux preuves.

## Exemples de configuration

Pour la production, préférez un `STORAGE_CONFIG_FILE` monté en mode `0400` ou
`0600`. Cette forme est illustrative :

```json theme={null}
{
  "profiles": {
    "quarantine": { "provider": "s3", "bucket": "<quarantine-bucket>", "region": "<region>" },
    "records": { "provider": "s3", "bucket": "<records-bucket>", "region": "<region>", "requireWorm": true },
    "ephemeral": { "provider": "s3", "bucket": "<ephemeral-bucket>", "region": "<region>" }
  }
}
```

Le schéma de profil strict complet est documenté dans les pages des
fournisseurs. Ne placez pas de clés d'accès dans la documentation et ne
commitez pas un fichier de configuration renseigné.

## Déclencheurs de requalification

Relancez les preuves en direct après toute modification de :

* la version CaseBender ou le SDK de stockage ;
* le fournisseur, ODF, Ceph, le compte ou la version d'API ;
* la sécurité, le versioning, la rétention ou l'immuabilité du
  bucket/conteneur ;
* l'identité, le rôle, l'identifiant, le point de terminaison, la CA privée
  ou la politique d'egress ;
* la frontière scanner/promotion ; ou
* les outils de sauvegarde, de migration et de restauration.

Guides associés :

* [Politique de support du stockage d'entreprise](/fr/deployment/storage-support-policy)
* [Certification compatible S3](/fr/deployment/storage-s3-compatible)
* [Sécurité des versions de stockage](/fr/deployment/storage-release-security)