> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Bring your own bucket (BYOB) > Stockez les artifacts et les données W&B dans vos propres buckets de stockage cloud grâce à la fonctionnalité Bring Your Own Bucket (BYOB). **Ce guide s’applique à tous les types de déploiement W\&B :** * **Cloud mutualisé** : BYOB au niveau de l’équipe * **Cloud dédié** : BYOB au niveau de l’instance et de l’équipe * **Autogéré** : BYOB au niveau de l’instance et de l’équipe Les instructions de provisionnement du bucket présentées dans ce guide sont identiques, quel que soit votre type de déploiement. Cette page concerne le Secure Storage Connector de la plateforme W\&B (BYOB) et ne s’applique pas à Weave. Pour afficher dans Weave le rendu d’images et de vidéos stockées dans votre propre bucket cloud, sans en importer les octets dans Weave, consultez la [référence BYOB de Weave](/fr/products/wandb/weave/guides/tracking/byob-references#reference-media-in-your-own-bucket-byob-using-weave-op).

Aperçu

Bring your own bucket (BYOB) vous permet de stocker les artifacts W\&B et d’autres données sensibles dans votre propre infrastructure cloud ou sur site. Avec le [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud) ou le [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud), W\&B ne copie pas les données stockées dans votre bucket vers l’infrastructure gérée par W\&B. Cette page s’adresse aux administrateurs W\&B et aux ingénieurs plateforme qui doivent garder la maîtrise du stockage des artifacts pour répondre à des exigences de gouvernance des données, de résidence ou de conformité. * La communication entre le SDK, la CLI ou l’interface utilisateur W\&B et vos buckets s’effectue au moyen d’[URL pré-signées](/fr/products/wandb/platform/hosting/data-security/presigned-urls). * W\&B s’appuie sur la garbage collection et des processus associés pour supprimer progressivement de votre bucket les **artifacts** et les **données de run** supprimés. Pour la suppression des artifacts, voir [Supprimer un artifact](/fr/products/wandb/artifacts/delete-artifacts). Sur les déploiements Cloud dédié et autogérés, la suppression des données de run dépend également de `GORILLA_DATA_RETENTION_PERIOD`, comme décrit dans [Configurer les variables d’environnement](/fr/products/wandb/platform/hosting/env-vars). W\&B ne garantit aucun délai de nettoyage. Pour une vue d’ensemble de l’utilisation et des coûts des buckets, voir [Gérer le stockage et les coûts des buckets](/fr/products/wandb/platform/hosting/managing-bucket-storage). * Lorsque vous configurez un bucket, vous pouvez spécifier un sous-chemin afin que W\&B ne stocke aucun fichier dans un dossier à la racine du bucket. Vous vous conformez ainsi plus facilement à la politique de gouvernance des buckets de votre organisation.

Données stockées dans la base de données centrale ou dans les buckets

Lorsque vous utilisez la fonctionnalité BYOB, W\&B stocke certains types de données dans sa base de données centrale et d’autres dans votre bucket. Consultez les listes suivantes pour savoir quelles données restent dans l’infrastructure gérée par W\&B et lesquelles W\&B écrit dans votre propre stockage.

Base de données

La base de données centrale de W\&B stocke les données suivantes : * Les métadonnées des utilisateurs, des équipes, des artifacts, des expériences et des projets. * Les rapports. * Les journaux d’expériences. * Les métriques système. * Les journaux de console.

Buckets

Votre bucket de stockage contient les données suivantes : * Fichiers et métriques des expériences. * Fichiers d’artifacts. * Fichiers multimédias. * Fichiers de runs. * Métriques d’historique et événements système exportés au format Parquet.

Portées des buckets

Vous pouvez configurer votre bucket de stockage selon l’une des deux portées suivantes : | Portée | Description | | - | - | | Niveau de l’instance | Dans un déploiement [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud) ou [autogéré](/fr/products/wandb/platform/hosting/hosting-options/self-managed), tout utilisateur de votre organisation ou de votre instance disposant des autorisations requises peut accéder aux fichiers stockés dans le bucket de stockage de votre instance. Non applicable au [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud). | | Niveau de l’équipe | Si vous configurez une équipe W\&B pour qu’elle utilise un bucket de stockage au niveau de l’équipe, les membres de l’équipe peuvent accéder aux fichiers qui y sont stockés. Les buckets de stockage au niveau de l’équipe renforcent le contrôle d’accès aux données et leur isolation pour les équipes qui manipulent des données sensibles ou sont soumises à des exigences de conformité strictes.

Le stockage au niveau de l’équipe permet aux différentes unités opérationnelles ou aux différents services qui partagent une instance d’utiliser efficacement l’infrastructure et les ressources administratives. Il permet également à des équipes de projet distinctes de gérer les flux de travail d’IA de missions clients distinctes. Disponible pour tous les types de déploiement. Le BYOB au niveau de l’équipe se configure lors de la configuration de l’équipe. | Cette conception prend en charge différentes topologies de stockage, selon les besoins de votre organisation. Par exemple : * Un même bucket peut desservir l’instance et une ou plusieurs équipes. * Chaque équipe peut utiliser un bucket distinct, certaines équipes peuvent choisir d’écrire dans le bucket de l’instance, ou plusieurs équipes peuvent partager un bucket en écrivant dans des sous-chemins. * Les buckets de différentes équipes peuvent se trouver dans des environnements d’infrastructure cloud ou des régions différents, et être gérés par différentes équipes d’administration du stockage. Par exemple, supposons que votre organisation comporte une équipe nommée Kappa. Par défaut, votre organisation (et l’équipe Kappa) utilise le bucket de stockage au niveau de l’instance. Vous créez ensuite une équipe nommée Omega et, lors de sa création, vous lui configurez un bucket de stockage au niveau de l’équipe. L’équipe Kappa ne peut pas accéder aux fichiers générés par l’équipe Omega. En revanche, l’équipe Omega peut accéder aux fichiers créés par l’équipe Kappa. Pour isoler les données de l’équipe Kappa, vous devez également lui configurer un bucket de stockage au niveau de l’équipe.

Matrice de disponibilité

Avant de commencer, vérifiez que BYOB est disponible pour votre type de déploiement et votre fournisseur de stockage. W\&B peut se connecter aux fournisseurs de stockage suivants : * [CoreWeave AI Object Storage](/products/storage/object-storage) : service de stockage d’objets hautes performances, compatible S3 et optimisé pour les charges de travail d’IA. * [Amazon S3](https://aws.amazon.com/s3/) : service de stockage d’objets offrant évolutivité, disponibilité des données, sécurité et performances. * [Google Cloud Storage](https://cloud.google.com/storage) : service géré de stockage de données non structurées à grande échelle. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) : solution cloud de stockage d’objets conçue pour stocker d’énormes volumes de données non structurées, telles que du texte, des données binaires, des images, des vidéos et des journaux. * Un stockage compatible S3, tel que [MinIO Enterprise (AIStor)](https://min.io/product/aistor), ou d’autres solutions de niveau entreprise hébergées dans votre cloud ou sur votre infrastructure sur site. Le tableau suivant indique la disponibilité de BYOB pour chaque portée et chaque type de déploiement W\&B. | Type de déploiement W\&B | Niveau de l’instance | Niveau de l’équipe | Informations complémentaires | | - | - | - | - | | Cloud dédié | ✓ | ✓ | BYOB au niveau de l’instance et de l’équipe est pris en charge pour CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage et les stockages compatibles S3, tels que [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor), hébergés dans votre cloud ou sur votre infrastructure sur site. | | Cloud mutualisé | Non applicable | ✓1 | BYOB au niveau de l’équipe est pris en charge pour CoreWeave AI Object Storage, Amazon S3 et Google Cloud Storage. | | Autogéré | ✓ | ✓ | BYOB au niveau de l’instance et de l’équipe est pris en charge pour CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage et les stockages compatibles S3, tels que [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor), hébergés dans votre cloud ou sur votre infrastructure sur site. | 1.Azure Blob Storage n’est pas pris en charge pour BYOB au niveau de l’équipe sur le Cloud mutualisé. Les sections suivantes décrivent les étapes de configuration de BYOB.

Provisionner votre bucket

Après avoir [vérifié la disponibilité](#availability-matrix), vous pouvez provisionner votre bucket de stockage, ainsi que sa stratégie d’accès et sa configuration CORS. Le provisionnement crée le bucket dans lequel W\&B écrit les données et accorde à la plateforme W\&B les autorisations dont elle a besoin pour générer des URL pré-signées en votre nom. Sélectionnez un onglet pour continuer. **Exigences** : * **Cloud mutualisé**, ou * **Cloud dédié** v0.73.0 ou version ultérieure, ou * **Autogéré** v0.73.0 ou version ultérieure, déployé avec la version 0.33.14 ou ultérieure du chart Helm * Un compte CoreWeave sur lequel AI Object Storage est activé et disposant de l’autorisation de créer des buckets, des clés d’accès API et des clés secrètes. * Votre instance W\&B doit pouvoir se connecter aux points de terminaison réseau de CoreWeave. Pour plus de détails, voir [Create a CoreWeave AI Object Storage bucket](/products/storage/object-storage/buckets/create-bucket) dans la documentation CoreWeave. 1. **Cloud mutualisé** : obtenez l’ID de votre organisation, nécessaire pour votre bucket policy. 1. Connectez-vous à l’[App W\&B](https://wandb.ai/site). 2. Dans le menu de navigation de gauche, cliquez sur **Create a new team**. 3. Dans le volet latéral qui s’ouvre, copiez l’ID d’organisation W\&B, affiché au-dessus de **Invite team members**. 4. Laissez cette page ouverte. Vous en aurez besoin pour [configurer W\&B](#configure-byob). 2. **Cloud dédié** / **Autogéré** : obtenez votre namespace client, nécessaire à votre stratégie de bucket. 1. Dans l’application W\&B, cliquez sur l’icône de votre profil utilisateur, puis sur **System Console**. 2. Cliquez sur l’onglet **Authentication**. 3. En bas de la page, copiez la valeur de **Customer Namespace**. Conservez cette valeur : vous en aurez besoin pour configurer la politique de bucket. 4. Vous pouvez maintenant fermer la System Console. 3. Dans CoreWeave, créez le bucket en lui donnant le nom de votre choix, dans l’Availability Zone CoreWeave que vous préférez. Si vous le souhaitez, créez un dossier que W\&B utilisera comme sous-chemin pour tous ses fichiers. Notez le nom du bucket, l’Availability Zone, la clé d’accès API, la clé secrète et le sous-chemin. 4. Définissez la politique de partage des ressources entre origines (CORS) suivante pour le bucket : ```json theme={"system"} [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ] ``` Le stockage CoreWeave est compatible S3. Pour en savoir plus sur CORS, consultez [Configuring cross-origin resource sharing (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html) dans la documentation AWS. 5. Configurez une stratégie de bucket (bucket policy) qui accorde à votre déploiement W\&B les autorisations requises pour accéder au bucket et générer des [URL pré-signées](/fr/products/wandb/platform/hosting/data-security/presigned-urls), grâce auxquelles les charges de travail d’IA de votre infrastructure cloud ou les navigateurs des utilisateurs accèdent au bucket. Voir [Bucket Policy Reference](/products/storage/object-storage/auth-access/bucket-access/bucket-policies) dans la documentation CoreWeave. ```json theme={"system"} { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowWandbUser", "Action": [ "s3:GetObject*", "s3:GetEncryptionConfiguration", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketVersioning" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::/*", "arn:aws:s3:::" ], "Principal": { "CW": "arn:aws:iam::wandb:static/" }, "Condition": { "StringLike": { "wandb:OrgID": [ "" ] } } }, { "Sid": "AllowUsersInOrg", "Action": "s3:*", "Effect": "Allow", "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::/*" ], "Principal": { "CW": "arn:aws:iam:::*" } }] } ``` La clause commençant par `"Sid": "AllowUsersInOrg"` accorde aux utilisateurs de votre organisation un accès direct au bucket. Si vous n'avez pas besoin de cet accès, vous pouvez supprimer cette clause de votre stratégie. 6. Dans la stratégie de bucket, remplacez les espaces réservés : * `` : le nom de votre bucket. * `` : * **Cloud mutualisé** : `arn:aws:iam::wandb:static/wandb-integration-public` * **Cloud dédié** ou **autogéré** : `arn:aws:iam::wandb:static/wandb-integration` * `` : * **Cloud mutualisé** : l’ID d’organisation obtenu à l’étape [Provisionner votre bucket](#coreweave-org-id). * **Cloud dédié** ou **autogéré** : le namespace client obtenu à l’étape [Provisionner votre bucket](#coreweave-customer-namespace). 7. **Cloud dédié** : contactez l’[assistance](mailto:forge-support@coreweave.com) pour effectuer des étapes supplémentaires. 8. **Autogéré** : mettez à jour votre déploiement W\&B pour définir la variable d’environnement `GORILLA_SUPPORTED_FILE_STORES` sur la chaîne exacte `cw://`, puis redémarrez W\&B. Sans cela, l’option CoreWeave n’apparaîtra pas lorsque vous configurerez le stockage de l’équipe. Ensuite, [configurez W\&B](#configure-byob). Pour plus d’informations, voir [Create an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dans la documentation AWS. 1. Provisionnez la clé KMS. W\&B exige que vous provisionniez une clé KMS pour chiffrer et déchiffrer les données du bucket S3. Le type d’utilisation de la clé doit être `ENCRYPT_DECRYPT`. Attribuez la stratégie suivante à la clé : ```json theme={"system"} { "Version": "2012-10-17", "Statement": [ { "Sid" : "Internal", "Effect" : "Allow", "Principal" : { "AWS" : "" }, "Action" : "kms:*", "Resource" : "" }, { "Sid" : "External", "Effect" : "Allow", "Principal" : { "AWS" : "" }, "Action" : [ "kms:Decrypt", "kms:Describe*", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource" : "" } ] } ``` Remplacez `` et `` par les valeurs correspondantes. Si vous utilisez le [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options#w%26b-multi-tenant-cloud) ou le [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options#w%26b-dedicated-cloud), remplacez `` par la valeur correspondante : * **Cloud mutualisé** : `arn:aws:iam::725579432336:role/WandbIntegration` * **Cloud dédié** : `arn:aws:iam::830241207209:root` Cette stratégie accorde à votre compte AWS un accès complet à la clé et attribue également les autorisations requises au compte AWS qui héberge la plateforme W\&B. Notez l’ARN de la clé KMS. 2. Provisionnez le bucket S3. Suivez ces étapes pour provisionner le bucket S3 dans votre compte AWS : 1. Créez le bucket S3 avec le nom de votre choix. Vous pouvez également créer un dossier, que vous pourrez configurer comme sous-chemin pour stocker tous les fichiers W\&B. 2. Activez le chiffrement côté serveur à l’aide de la clé KMS créée à l’étape précédente. 3. Configurez CORS avec la stratégie suivante : ```json theme={"system"} [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ] ``` Si les données de votre bucket expirent en raison d’une [stratégie de gestion du cycle de vie des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html), vous risquez de ne plus pouvoir lire l’historique de certains runs. 4. Accordez les autorisations S3 requises au compte AWS qui héberge la plateforme W\&B. Celle-ci en a besoin pour générer les [URL pré-signées](/fr/products/wandb/platform/hosting/data-security/presigned-urls) grâce auxquelles les charges de travail d’IA de votre infrastructure cloud ou les navigateurs des utilisateurs accèdent au bucket. ```json theme={"system"} { "Version": "2012-10-17", "Id": "WandBAccess", "Statement": [ { "Sid": "WAndBAccountAccess", "Effect": "Allow", "Principal": { "AWS": "" }, "Action" : [ "s3:GetObject*", "s3:GetEncryptionConfiguration", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketVersioning" ], "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::/*" ] } ] } ``` Remplacez `` par la valeur appropriée et notez le nom du bucket. Ensuite, [configurez W\&B](#configure-byob). Si vous utilisez le [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) ou le [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud), remplacez `` par la valeur correspondante. * Pour le [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) : `arn:aws:iam::725579432336:role/WandbIntegration` * Pour le [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud) : `arn:aws:iam::830241207209:root` Pour en savoir plus, consultez le [guide d’hébergement autogéré sur AWS](/fr/products/wandb/platform/hosting/hosting-options). Pour plus de détails, consultez [Create a bucket](https://docs.cloud.google.com/storage/docs/creating-buckets) dans la documentation Google Cloud. 1. Provisionnez le bucket GCS. Suivez ces étapes pour provisionner le bucket GCS dans votre projet Google Cloud : 1. Créez le bucket GCS avec le nom de votre choix. Si vous le souhaitez, créez un dossier que vous pourrez configurer comme sous-chemin pour stocker tous les fichiers W\&B. 2. Définissez le type de chiffrement sur `Google-managed`. 3. Activez la suppression réversible (soft delete). Consultez [Edit a bucket's soft delete policy](https://docs.cloud.google.com/storage/docs/use-soft-delete). 4. Définissez la stratégie CORS avec `gsutil`. Cette opération n’est pas possible dans l’interface utilisateur. 1. Créez localement un fichier nommé `cors-policy.json`. 2. Copiez la stratégie CORS suivante dans le fichier, puis enregistrez-le. ```json theme={"system"} [ { "origin": ["*"], "responseHeader": ["Content-Type"], "exposeHeaders": ["ETag"], "method": ["GET", "HEAD", "PUT"], "maxAgeSeconds": 3000 } ] ``` Si les données de votre bucket expirent en raison d’une [stratégie de gestion du cycle de vie des objets](https://cloud.google.com/storage/docs/lifecycle), vous risquez de ne plus pouvoir lire l’historique de certains runs. 5. Remplacez `` par le nom de votre bucket, puis exécutez `gsutil`. ```bash theme={"system"} gsutil cors set cors-policy.json gs:// ``` 6. Vérifiez la stratégie du bucket. Remplacez `` par le nom de votre bucket. ```bash theme={"system"} gsutil cors get gs:// ``` 2. Si vous utilisez le [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) ou le [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud), attribuez le rôle `storage.admin` au compte de service Google Cloud lié à la plateforme W\&B. W\&B a besoin de ce rôle pour vérifier la configuration CORS et les attributs du bucket, par exemple si la gestion des versions des objets est activée. Si le compte de service ne dispose pas du rôle `storage.admin`, ces vérifications renvoient une erreur HTTP 403. * Pour le [Cloud mutualisé](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud), le compte est : `wandb-integration@wandb-production.iam.gserviceaccount.com` * Pour le [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud), le compte est : `deploy@wandb-production.iam.gserviceaccount.com` Notez le nom du bucket. Ensuite, [configurez W\&B pour BYOB](#configure-byob). Pour plus de détails, consultez [Create a blob storage container](https://learn.microsoft.com/en-us/azure/storage/blobs/blob-containers-portal) dans la documentation Azure. **BYOB au niveau de l’instance** : 1. Provisionnez le conteneur Azure Blob Storage. Pour les déploiements autogérés, ainsi que pour les déploiements Cloud dédié qui n'utilisent pas [ce module Terraform](https://github.com/wandb/terraform-azurerm-wandb/tree/main/examples/byob), suivez ces étapes pour provisionner un conteneur Azure Blob Storage dans votre abonnement Azure : 1. Créez un conteneur portant le nom de votre choix. Vous pouvez également créer un dossier, à configurer comme sous-chemin, pour stocker l’ensemble des fichiers W\&B. 2. Configurez la stratégie CORS du conteneur. Pour définir la stratégie CORS depuis l’interface utilisateur, accédez au stockage de blobs, faites défiler jusqu’à `Settings/Resource Sharing (CORS)`, puis définissez les valeurs suivantes : | Paramètre | Valeur | | - | - | | Allowed Origins | `*` | | Allowed Methods | `GET`, `HEAD`, `PUT` | | Allowed Headers | `*` | | Exposed Headers | `*` | | Max Age | `3000` | Si les données de votre bucket expirent en raison d’une [stratégie de gestion du cycle de vie des objets](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-policy-configure?tabs=azure-portal), vous risquez de ne plus pouvoir lire l’historique de certains runs. 2. Choisissez une méthode d’authentification : * **Clé du compte de stockage** : générez une clé d’accès au compte de stockage, puis notez la clé ainsi que le nom du compte de stockage. Si votre organisation utilise Cloud dédié, transmettez ces valeurs à votre équipe de compte W\&B au moyen d’un mécanisme de partage sécurisé. * **Identité de charge de travail** : accordez à une identité managée Azure l’accès à votre compte de stockage, puis configurez W\&B pour qu’il l’utilise. Vous n'avez alors pas besoin de partager de clé de compte de stockage. Suivez les [instructions relatives à l’identité de charge de travail pour votre type de déploiement](#set-up-azure-workload-identity). **BYOB au niveau de l’équipe** : Pour les déploiements Cloud dédié, W\&B recommande d’utiliser [Terraform](https://github.com/wandb/terraform-azurerm-wandb/tree/main/examples/secure-storage-connector) pour provisionner le conteneur Azure Blob Storage avec le mécanisme d’accès et les autorisations nécessaires. Pour les déploiements Cloud dédié qui n'utilisent pas Terraform, ou pour les déploiements autogérés, provisionnez le bucket en suivant les étapes de provisionnement du stockage au niveau de l’instance. Fournissez l’URL de l’émetteur OIDC de votre instance. Notez les informations suivantes : * Nom du compte de stockage * Nom du conteneur de stockage * ID client de l’identité managée * ID de locataire Azure Créez votre bucket compatible S3. Notez les informations suivantes : * Clé d’accès * Clé d’accès secrète * URL du point de terminaison * Nom du bucket * Chemin du dossier, le cas échéant * Région Ensuite, [déterminez l’adresse de stockage](#determine-the-storage-address).

Déterminer l’adresse de stockage

Une fois le bucket provisionné, vous avez besoin d’une adresse de stockage, qui permet à W\&B de le localiser et de s’y authentifier. Les sections suivantes décrivent la syntaxe à utiliser pour connecter une équipe W\&B à un bucket de stockage BYOB. Dans les exemples, remplacez les valeurs d’espace réservé entre chevrons (`<>`) par les informations de votre bucket. Sélectionnez un onglet pour obtenir des instructions détaillées. Cette section concerne uniquement le BYOB au niveau de l’équipe sur **Cloud dédié** ou en environnement **autogéré**. Pour le BYOB au niveau de l’instance ou pour le Cloud mutualisé, vous pouvez passer directement à la [configuration de W\&B](#configure-byob). Déterminez le chemin complet du bucket au format suivant. Remplacez les espaces réservés entre chevrons (`<>`) par les valeurs du bucket. **Format du bucket** : ```text theme={"system"} cw://:@cwobject.com/?tls=true ``` W\&B prend en charge le point de terminaison HTTPS `cwobject.com`. TLS 1.3 est requis. Si d’autres points de terminaison CoreWeave vous intéressent, contactez l’[assistance](mailto:forge-support@coreweave.com). **Format du bucket** : ```text theme={"system"} s3://:@/?region= ``` Dans l’adresse, le paramètre `region` est obligatoire, sauf si votre instance W\&B et votre bucket de stockage sont tous deux déployés sur AWS et que la valeur `AWS_REGION` de l’instance W\&B correspond à la région AWS S3 du bucket. **Format du bucket** : ```text theme={"system"} gs://:@ ``` **Format du bucket** : ```text theme={"system"} az://:@/ ``` **Format du bucket** : ```text theme={"system"} s3://:@/?region=&tls=true ``` Dans l’adresse, le paramètre `region` est obligatoire. Cette section concerne les buckets de stockage compatibles S3 qui ne sont pas hébergés dans S3, comme [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor) ou d’autres solutions compatibles S3 de niveau entreprise hébergées sur site. Pour les buckets de stockage hébergés dans AWS S3, consultez plutôt l’onglet **AWS**. MinIO Open Source est en [mode maintenance](https://github.com/minio/minio) : il ne fait plus l’objet d’aucun développement actif et aucun binaire précompilé n’est fourni. Pour les déploiements en production, utilisez des solutions compatibles S3 de niveau entreprise. Pour les buckets de stockage cloud natifs proposant un mode compatible S3 facultatif, utilisez si possible le spécificateur de protocole cloud natif. Par exemple, utilisez `cw://` plutôt que `s3://` pour un bucket CoreWeave. Une fois l’adresse de stockage déterminée, vous pouvez [configurer le BYOB au niveau de l’équipe](#configure-team-level-byob).

Configurer W\&B

Après avoir [provisionné votre bucket](#provision-your-bucket) et [déterminé son adresse](#determine-the-storage-address), vous pouvez configurer BYOB au [niveau de l’instance](#instance-level-byob) ou au [niveau de l’équipe](#team-level-byob). Cette dernière étape indique à W\&B d’acheminer vers votre bucket le stockage des artifacts, des fichiers de run et des autres objets volumineux. Planifiez soigneusement l’organisation de votre bucket de stockage. Une fois un bucket de stockage configuré pour W\&B, la migration de ses données vers un autre bucket est complexe et nécessite l’assistance de W\&B. Cela concerne le stockage des déploiements Cloud dédié et autogérés, ainsi que le stockage au niveau de l’équipe dans le Cloud mutualisé. Pour toute question, contactez l’[assistance](mailto:forge-support@coreweave.com).

BYOB au niveau de l’instance

Pour CoreWeave AI Object Storage au niveau de l’instance, contactez l’[assistance W\&B](mailto:forge-support@coreweave.com) plutôt que de suivre ces instructions. La configuration en libre-service n’est pas encore prise en charge. Pour le **Cloud dédié** : transmettez les informations du bucket à votre équipe W\&B, qui se charge de configurer votre instance. Pour Azure workload identity, [accordez l’accès à votre compte de stockage](#set-up-azure-workload-identity) et fournissez le nom du compte de stockage, le nom du conteneur et, éventuellement, le chemin. Pour un déploiement **autogéré**, configurez le BYOB au niveau de l’instance dans la System Console de W\&B. Pour Azure workload identity, effectuez d’abord la [configuration de l’identité](#set-up-azure-workload-identity). 1. Connectez-vous à W\&B en tant qu’utilisateur disposant du rôle `admin`. 2. Cliquez sur l’icône utilisateur en haut de la page, puis sur **System Console**. 3. Accédez à **Settings** > **System Connections**. 4. Dans **Bucket Storage**, sélectionnez le **Provider** et saisissez les informations du bucket. Pour Azure, sélectionnez **Azure Blob Storage (az)**, puis saisissez séparément le **Storage account** et le **Blob container**. 5. Facultatif : saisissez le **Path** à utiliser dans le nouveau bucket. 6. Vérifiez que l’identité ou les identifiants d’authentification du fournisseur sélectionné ont accès au bucket. Pour Azure, sélectionnez une méthode d’**Authentication** : * **Storage account key** : saisissez la **Storage account key**. * **Workload identity (user-delegation SAS)** : utilisez l’identité configurée par l’administrateur de votre déploiement. Si cette option n’est pas disponible, effectuez la [configuration de l’identité](#set-up-azure-workload-identity). 7. Cliquez sur **Save**. Une fois la configuration enregistrée, W\&B utilise le bucket configuré comme destination de stockage par défaut pour les nouveaux artifacts et fichiers de run au niveau de l’instance. Si un paramètre n’est pas modifiable, contactez l’administrateur de votre déploiement.

Configurer Azure workload identity

Azure workload identity permet à W\&B d’accéder à votre bucket Azure sans clé de compte de stockage. Sélectionnez votre type de déploiement pour afficher les instructions de configuration. W\&B configure le déploiement. De votre côté, vous configurez l’accès à votre compte de stockage Azure : 1. Contactez votre équipe W\&B en lui indiquant l’ID de tenant de votre compte de stockage afin de confirmer l’identité managée à utiliser. 2. Si l’identité se trouve dans votre tenant Azure, utilisez son ID de principal pour les attributions de rôles ci-dessous. Sinon, créez ou sélectionnez une identité managée dans votre tenant et configurez ses identifiants d’authentification fédérés à l’aide des valeurs d’émetteur, de sujet et d’audience fournies par W\&B. Une identité managée [ne peut pas accéder directement au stockage d’un autre tenant](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/managed-identities-faq#can-i-use-a-managed-identity-to-access-a-resource-in-a-different-directorytenant). 3. Attribuez au principal de l’identité les rôles **Reader** et **Storage Blob Data Contributor**, avec une portée au niveau du compte de stockage, sur votre compte de stockage BYOB. 4. Communiquez à votre équipe W\&B le nom du compte de stockage, le nom du conteneur, le chemin facultatif, ainsi que l’ID de tenant et l’ID client de l’identité. Une fois la connexion configurée par W\&B, vérifiez l’accès en téléversant puis en téléchargeant un fichier de run ou un artifact. En tant qu’administrateur du déploiement, configurez Azure workload identity dans Azure et Kubernetes, puis sélectionnez cette méthode dans System Console. Utilisez les versions suivantes pour ce flux de travail : | Composant | Version requise | | - | - | | Serveur W\&B | v0.84.0 ou ultérieure, y compris pour chaque composant qui accède au stockage | | Chart Helm de l’opérateur | [v0.44.13](https://github.com/wandb/helm-charts/releases/tag/operator-wandb-0.44.13) ou ultérieure | | W\&B System Console | [v2.20.0](https://github.com/wandb/console/releases/tag/v2.20.0) ou ultérieure pour le sélecteur d’authentification | 1. Activez la fédération de jetons OpenID Connect (OIDC) et Azure workload identity pour le cluster Kubernetes. Pour Azure Kubernetes Service (AKS), suivez la procédure [Configurer Microsoft Entra Workload ID](https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster). 2. Créez ou sélectionnez une identité managée Azure et notez son ID de tenant, son ID client et son ID de principal. Attribuez à son principal les rôles **Reader** et **Storage Blob Data Contributor**, avec une portée au niveau du compte de stockage, sur votre compte de stockage BYOB. 3. Configurez `global.azureStorageIdentity` dans vos valeurs Helm avec l’ID de tenant, l’ID client et l’ID de principal de l’identité. Configurez la fédération et l’annotation `azure.workload.identity/client-id` pour les comptes de service Kubernetes qui accèdent au stockage. Pour plus de détails sur la configuration Helm, consultez [Configuration d’Azure workload identity](https://github.com/wandb/helm-charts/blob/operator-wandb-0.44.13/charts/operator-wandb/README.md#azure-managed-storage-workload-identity). 4. Suivez la [procédure de la Console](#instance-level-byob) pour sélectionner Azure workload identity et enregistrer les paramètres de votre bucket. Vérifiez l’accès en téléversant puis en téléchargeant un fichier de run ou un artifact.

BYOB au niveau de l’équipe

Vous pouvez configurer le BYOB au niveau de l’équipe lorsque vous créez une équipe dans la W\&B App ou à l’aide de l’[API SCIM](/fr/products/wandb/platform/hosting/iam/scim#create-team) (POST Groups avec le paramètre facultatif `storageBucket`). Deux options s’offrent à vous : * **Utiliser un bucket existant** : vous devez d’abord [déterminer l’emplacement de stockage](#determine-the-storage-address) de votre bucket. * **Créer un nouveau bucket** (Cloud mutualisé uniquement) : W\&B peut créer automatiquement un bucket chez votre fournisseur de cloud lors de la création de l’équipe. W\&B prend en charge cette option pour CoreWeave, AWS et Google Cloud. - Une fois l’équipe créée, vous ne pouvez plus modifier son stockage. - Pour le BYOB au niveau de l’instance, consultez plutôt la section [BYOB au niveau de l’instance](#instance-level-byob). - Si vous prévoyez de configurer un stockage CoreWeave pour l’équipe, consultez les [exigences CoreWeave](#coreweave-requirements) et contactez l’[assistance](mailto:forge-support@coreweave.com) pour vérifier que votre bucket est correctement configuré dans CoreWeave et faire valider la configuration de votre équipe : les détails du stockage ne sont plus modifiables une fois l’équipe créée. Sélectionnez votre type de déploiement pour continuer. 1. Revenez à la fenêtre du navigateur dans laquelle vous avez commencé à créer la nouvelle équipe pour trouver l’ID d’organisation W\&B. Sinon, connectez-vous à W\&B en tant qu’utilisateur disposant du rôle `admin`, cliquez sur l’icône en haut à gauche pour ouvrir le menu de navigation de gauche, puis cliquez sur **Create a team to collaborate**. 2. Indiquez un nom pour l’équipe. 3. Définissez **Storage Type** sur **External storage**. 4. Cliquez sur **Bucket location**. 5. Pour utiliser un bucket existant, sélectionnez-le dans la liste. 6. Pour créer un nouveau bucket, cliquez sur **Add bucket** en bas de la liste, puis : 1. Cliquez sur **Cloud provider** et sélectionnez **CoreWeave**, **AWS** ou **Google Cloud**. 2. Saisissez les informations du bucket : * **Name** : saisissez le nom du bucket. * **Path** (facultatif) : saisissez un sous-chemin à utiliser dans le bucket. 3. Fournissez les paramètres de connexion supplémentaires propres au fournisseur de cloud choisi : * CoreWeave : aucun paramètre supplémentaire requis. * AWS : vous pouvez fournir un **KMS key ARN** pour le chiffrement (facultatif). * Google Cloud : aucun paramètre supplémentaire requis. Lorsque vous cliquez sur **Create team**, W\&B crée automatiquement le bucket chez votre fournisseur de cloud avec la configuration spécifiée. 7. Invitez des membres dans l’équipe. Dans **Invite team members**, indiquez une liste d’adresses e-mail séparées par des virgules. Vous pouvez aussi inviter des membres après avoir créé l’équipe. 8. Cliquez sur **Create team**. Si W\&B rencontre des erreurs lors de l’accès au bucket ou détecte des paramètres non valides, une erreur ou un avertissement s’affiche en bas de la page. Sinon, W\&B crée l’équipe. 1. **Cloud dédié** : avant de suivre les étapes ci-dessous pour utiliser le bucket de stockage pour une équipe, vous **devez** fournir le chemin du bucket à votre équipe de compte afin qu’elle l’ajoute aux magasins de fichiers pris en charge par votre instance. 2. **Autogéré** : avant de suivre les étapes ci-dessous pour utiliser le bucket de stockage pour une équipe, vous **devez** ajouter le chemin du bucket à la variable d’environnement `GORILLA_SUPPORTED_FILE_STORES`, puis redémarrer W\&B. 3. Connectez-vous à W\&B en tant qu’utilisateur disposant du rôle `admin`, cliquez sur l’icône en haut à gauche pour ouvrir le menu de navigation de gauche, puis cliquez sur **Create a team to collaborate**. 4. Indiquez un nom pour l’équipe. 5. Définissez **Storage Type** sur **External storage**. Pour utiliser le stockage de l’instance comme stockage de l’équipe (qu’il soit interne ou externe), laissez **Storage Type** sur **Internal**, même si le bucket de l’instance est configuré en BYOB. Pour utiliser un stockage externe distinct pour l’équipe, définissez **Storage Type** sur **External** et configurez les informations du bucket à l’étape suivante. 6. Cliquez sur **Bucket location**. 7. Pour utiliser un bucket existant, sélectionnez-le dans la liste. Pour ajouter un nouveau bucket, cliquez sur **Add bucket** en bas de la liste, puis fournissez les informations du bucket. Cliquez sur **Cloud provider** et sélectionnez **CoreWeave**, **AWS**, **Google Cloud** ou **Azure**. Si le fournisseur de cloud n’apparaît pas dans la liste, vérifiez que vous avez suivi les instructions de la section [Provisionner votre bucket](#set-environment-variable) pour ajouter le chemin du bucket aux magasins de fichiers pris en charge par votre instance. Si le fournisseur de stockage n’apparaît toujours pas, [contactez l’assistance](mailto:forge-support@coreweave.com). 8. Indiquez les informations du bucket. * Pour **CoreWeave**, fournissez uniquement le nom du bucket. * Pour Amazon S3, Google Cloud ou un stockage compatible S3, fournissez le chemin complet du bucket que vous avez [déterminé précédemment](#determine-the-storage-address). * Pour Azure sur W\&B Cloud dédié ou autogéré, définissez **Account name** sur le compte Azure et **Container name** sur le conteneur Azure Blob Storage. * Vous pouvez également fournir des paramètres de connexion supplémentaires (facultatif) : * Le cas échéant, définissez **Path** sur le sous-chemin du bucket. * **CoreWeave** : aucun paramètre de connexion supplémentaire requis. * **AWS** : définissez **KMS key ARN** sur l’ARN de votre clé de chiffrement KMS. * **Google Cloud** : aucun paramètre de connexion supplémentaire requis. * **Azure** : renseignez les champs **Tenant ID** et **Managed Identity Client ID**. Ces champs sont obligatoires, sauf si vous avez configuré la chaîne de connexion avec `GORILLA_SUPPORTED_FILE_STORES`. 9. Cliquez sur **Create team**. Si W\&B rencontre des erreurs lors de l’accès au bucket ou détecte des paramètres non valides, une erreur ou un avertissement s’affiche en bas de la page. Sinon, W\&B crée l’équipe.

Dépannage

Si W\&B signale des erreurs lors de la validation de votre bucket ou de la connexion à celui-ci, consultez les sections suivantes pour identifier les causes les plus courantes selon votre fournisseur de stockage.

CoreWeave

Cette section vous aide à résoudre les problèmes de connexion à CoreWeave AI Object Storage. * **Erreurs de connexion** * Vérifiez que votre instance W\&B peut se connecter aux points de terminaison réseau de CoreWeave. * CoreWeave utilise des chemins de type virtual-hosted, dans lesquels le nom du bucket est un sous-domaine placé au début du chemin. Par exemple, `cw://bucket-name.cwobject.com` est correct, alors que `cw://cwobject.com/bucket-name/` ne l’est pas. * Les noms de bucket ne doivent pas contenir de caractères de soulignement (`_`) ni d’autres caractères incompatibles avec les règles DNS. * Les noms de bucket doivent être globalement uniques sur l’ensemble des emplacements CoreWeave. * Les noms de bucket ne doivent pas commencer par `cw-` ou `vip-`, qui sont des préfixes réservés. * **Échecs de validation CORS** * Une stratégie CORS est requise. CoreWeave est compatible S3. Pour en savoir plus sur CORS, consultez [Configuring cross-origin resource sharing (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html) dans la documentation AWS. * `AllowedMethods` doit inclure les méthodes `GET`, `PUT` et `HEAD`. * `ExposeHeaders` doit inclure `ETag`. * Le champ `AllowedOrigins` de la stratégie CORS doit inclure les domaines front-end de W\&B. Les exemples de stratégies CORS fournis sur cette page autorisent tous les domaines grâce à `*`. * **Problèmes liés aux points de terminaison LOTA** * W\&B ne prend pas encore en charge les connexions aux points de terminaison LOTA. Si cette fonctionnalité vous intéresse, [contactez l’assistance](mailto:forge-support@coreweave.com). * **Erreurs de clé d’accès et d’autorisations** * Vérifiez que votre clé d’accès à l’API CoreWeave n’a pas expiré. * Vérifiez que votre clé d’accès et votre clé secrète de l’API CoreWeave disposent des autorisations nécessaires : `GetObject`, `PutObject`, `DeleteObject` et `ListBucket`. Les exemples de cette page répondent à cette exigence. Voir [Create and Manage Access Keys](/products/storage/object-storage/auth-access/manage-access-keys/about) dans la documentation CoreWeave.

Google Cloud

Cette section vous aide à résoudre les problèmes de connexion à Google Cloud Storage. * `Bucket does not have soft deletion enabled` Vérifiez que la suppression réversible est activée pour votre bucket Google Cloud Storage. Voir [Modifier la règle de suppression réversible d’un bucket](https://docs.cloud.google.com/storage/docs/use-soft-delete).