Skip to main content
Un compte de service représente un utilisateur non humain, ou machine, capable d’effectuer automatiquement des tâches courantes dans plusieurs projets d’une même équipe ou dans plusieurs équipes. Les comptes de service sont particulièrement adaptés aux pipelines CI/CD, aux tâches d’entraînement automatisées et aux autres flux de travail de machine à machine. Cette page présente les portées disponibles pour les comptes de service, explique comment les créer et les gérer, et décrit les bonnes pratiques pour les utiliser en toute sécurité dans vos automatisations en production. Elle s’adresse aux administrateurs d’organisation et d’équipe chargés de fournir des identifiants d’authentification aux systèmes automatisés.

Principaux avantages

Principaux avantages des comptes de service :
  • Aucune consommation de licence : les comptes de service ne consomment aucune licence utilisateur.
  • Clés API dédiées : des identifiants d’authentification sécurisés pour les flux de travail automatisés.
  • Attribution de l’utilisateur : possibilité d’attribuer les runs automatisés à des utilisateurs humains.
  • Prêt pour l’entreprise : conçu pour l’automatisation en production à grande échelle.
  • Opérations déléguées : les comptes de service agissent pour le compte de l’utilisateur ou de l’organisation qui les crée.

Aperçu

Les comptes de service permettent d’automatiser en toute sécurité les flux de travail W&B, sans recourir à des identifiants d’authentification personnels ni à des identifiants codés en dur. Vous pouvez les créer selon deux portées :
  • Limité à l’organisation : créé par les administrateurs de l’organisation, avec un accès à toutes les équipes.
  • À portée d’équipe : créé par les administrateurs d’équipe, avec un accès restreint à une équipe donnée.
Un compte de service limité à l’organisation ne doit pas être confondu avec une clé API d’organisation. Un compte de service est une identité non humaine qui détient ses propres clés. Une clé API d’organisation appartient à une personne et authentifie cette personne au sein d’une seule organisation.
La clé API d’un compte de service permet à l’appelant de lire et d’écrire dans les projets compris dans la portée de ce compte. Vous pouvez ainsi gérer de manière centralisée les flux de travail automatisés, qu’il s’agisse du suivi des expériences dans W&B Models ou de la journalisation des traces dans W&B Weave. Les comptes de service sont notamment utiles pour :
  • Pipelines CI/CD : consigner automatiquement les runs d’entraînement de modèles depuis GitHub Actions, GitLab CI ou Jenkins.
  • Jobs planifiés : réentraînement nocturne de modèles, runs d’évaluation périodiques ou flux de travail de validation des données.
  • Surveillance en production : journaliser les métriques d’inférence et les performances des modèles depuis les systèmes de production.
  • Jupyter notebooks : notebooks partagés dans des environnements JupyterHub ou Google Colab.
  • Jobs Kubernetes : flux de travail automatisés exécutés dans des clusters Kubernetes.
  • Airflow/Prefect/Dagster : outils d’orchestration de pipelines de ML.
Les comptes de service sont disponibles sur le Cloud dédié, sur les instances autogérées disposant d’une licence Enterprise, ainsi que pour les comptes Enterprise sur le Cloud mutualisé.

Comptes de service limités à l’organisation

Utilisez un compte de service limité à l’organisation lorsque votre automatisation doit lire ou écrire dans des projets appartenant à plusieurs équipes. Les comptes de service limités à une organisation disposent d’autorisations de lecture et d’écriture sur tous les projets de l’organisation, quelle que soit l’équipe, à l’exception des projets restreints. Pour qu’un compte de service limité à l’organisation puisse accéder à un projet restreint, un administrateur de ce projet doit d’abord l’y ajouter explicitement.

Créer un compte de service limité à l’organisation

Pour créer un compte de service limité à l’organisation et une clé API :
  1. Connectez-vous à W&B.
  2. Cliquez sur l’icône de votre profil utilisateur, puis accédez à Service Accounts :
    • Cloud dédié ou autogéré : cliquez sur Organization Dashboard, puis sur Service Accounts.
    • Cloud mutualisé : cliquez sur Service Accounts.
  3. Cliquez sur Create service account.
  4. Indiquez un nom et sélectionnez une équipe par défaut.
  5. Cliquez sur Create.
  6. Repérez le compte de service que vous venez de créer, cliquez sur le menu action (), puis sur Create API key.
  7. Indiquez un nom pour la clé API, puis cliquez sur Create.
  8. Copiez la clé API et conservez-la en lieu sûr.
  9. Cliquez sur Done.
W&B n’affiche la clé API complète qu’une seule fois, lors de sa création. Une fois la boîte de dialogue fermée, vous ne pouvez plus consulter la clé API complète. Seul l’ID de la clé (sa première partie) apparaît dans vos paramètres. Si vous perdez la clé API complète, vous devez en créer une nouvelle.
Un compte de service limité à l’organisation doit avoir une équipe par défaut, même s’il a accès aux projets non restreints de toutes les équipes de l’organisation. Cela évite qu’une charge de travail échoue si la variable WANDB_ENTITY n’est pas définie dans l’environnement de votre entraînement de modèle ou de votre application d’IA générative. Pour utiliser un compte de service limité à l’organisation avec un projet d’une autre équipe, vous devez définir la variable d’environnement WANDB_ENTITY sur cette équipe.

Comptes de service à portée d’équipe

Utilisez un compte de service à portée d’équipe lorsque vous souhaitez limiter une automatisation aux projets d’une seule équipe, conformément au principe du moindre privilège. Un compte de service à portée d’équipe dispose d’un accès en lecture et en écriture à tous les projets de son équipe, à l’exception des projets restreints de cette équipe. Pour qu’un compte de service à portée d’équipe puisse accéder à un projet restreint, un administrateur de ce projet doit explicitement l’y ajouter.
Sur le Cloud dédié et les déploiements autogérés v0.83.0+, les administrateurs peuvent empêcher la création de comptes de service à portée d’équipe en définissant la variable d’environnement GORILLA_DISABLE_TEAM_SERVICE_ACCOUNT_CREATION sur true sur l’instance. Voir Configuration IAM avancée.

Créer un compte de service à portée d’équipe

Pour créer un compte de service à portée d’équipe et une clé API :
  1. Dans les paramètres de votre équipe, cliquez sur Service Accounts.
  2. Cliquez sur New Team Service Account.
  3. Saisissez un nom pour le compte de service.
  4. Définissez Authentication Method sur Generate API key (par défaut). Si vous sélectionnez Federated Identity, le compte de service ne peut pas posséder de clés API.
  5. Cliquez sur Create.
  6. Repérez le compte de service que vous avez créé, cliquez sur son menu action (), puis sur Create API key.
  7. Saisissez un nom pour la clé API, puis cliquez sur Create.
  8. Copiez la clé API et conservez-la en lieu sûr.
  9. Cliquez sur Done.
W&B n’affiche la clé API complète qu’une seule fois, lors de sa création. Une fois la boîte de dialogue fermée, vous ne pouvez plus consulter la clé API complète. Seul l’ID de la clé (sa première partie) apparaît dans vos paramètres. Si vous perdez la clé API complète, vous devez en créer une nouvelle.

Créer des clés API supplémentaires pour un compte de service

Pour créer une clé API appartenant à un compte de service :
  1. Dans les paramètres de votre équipe ou de votre organisation, accédez à l’onglet Service Accounts.
  2. Trouvez le compte de service dans la liste.
  3. Cliquez sur le menu action (), puis sur Create API key.
  4. Saisissez un nom pour la clé API, puis cliquez sur Create.
  5. Copiez immédiatement la clé API affichée et conservez-la en lieu sûr.
  6. Cliquez sur Done.
Vous pouvez créer plusieurs clés API pour un même compte de service afin de répondre aux besoins de différents environnements ou flux de travail.
W&B n’affiche la clé API complète qu’une seule fois, lors de sa création. Une fois la boîte de dialogue fermée, vous ne pouvez plus consulter la clé API complète. Seul l’ID de la clé (sa première partie) apparaît dans vos paramètres. Si vous perdez la clé API complète, vous devez en créer une nouvelle.

Supprimer une clé API de compte de service

Pour supprimer une clé API appartenant à un compte de service d’organisation ou d’équipe :
  1. Accédez à Organization settings, puis cliquez sur API Keys.
  2. Repérez la clé API. La liste comprend toutes les clés API appartenant aux comptes de service d’organisation et d’équipe. Vous pouvez rechercher ou filtrer les clés par nom ou par ID, et les trier selon n’importe quelle colonne.
  3. Cliquez sur le bouton de suppression.
Si vous ne configurez pas d’équipe dans l’environnement d’entraînement de modèle ou d’application d’IA générative qui utilise un compte de service à portée d’équipe, les runs du modèle ou les traces Weave sont journalisés dans le projet indiqué, au sein de l’équipe parente du compte de service. Dans ce cas, l’attribution de l’utilisateur au moyen des variables WANDB_USERNAME ou WANDB_USER_EMAIL ne fonctionne pas, sauf si l’utilisateur référencé fait partie de l’équipe parente du compte de service.
Un compte de service à portée d’équipe ne peut pas journaliser de runs dans un projet à portée d’équipe ou restreinte appartenant à une autre équipe que son équipe parente. En revanche, il peut journaliser des runs dans un projet à visibilité ouverte d’une autre équipe.

Comptes de service externes

Si vous préférez émettre des identifiants d’authentification via votre propre fournisseur d’identité plutôt que de gérer des clés API natives W&B, utilisez des comptes de service externes. Outre les comptes de service intégrés, W&B prend également en charge, avec le SDK et la CLI W&B, les comptes de service externes à portée d’équipe, grâce à la fédération d’identités avec des fournisseurs d’identité (IdP) qui émettent des jetons Web JSON (JWT).

Bonnes pratiques

Après avoir créé les comptes de service dont vous avez besoin, suivez ces recommandations pour garantir une utilisation sécurisée et efficace des comptes de service dans votre organisation :
  • Utiliser un gestionnaire de secrets : stockez les clés API des comptes de service dans un système de gestion des secrets sécurisé (par exemple, AWS Secrets Manager, HashiCorp Vault ou Azure Key Vault) plutôt que dans des fichiers de configuration en texte brut.
  • Principe du moindre privilège : dans la mesure du possible, créez des comptes de service à portée d’équipe plutôt que des comptes limités à l’organisation, afin de limiter l’accès aux seuls projets nécessaires.
  • Un compte de service par cas d’usage : créez des comptes de service distincts pour les différents flux de travail d’automatisation (par exemple, un pour la CI/CD, un autre pour le réentraînement planifié) afin de faciliter les audits et de permettre un contrôle d’accès granulaire.
  • Audits réguliers : passez régulièrement en revue les comptes de service actifs et supprimez ceux qui ne sont plus utilisés. Consultez les journaux d’audit pour surveiller l’activité des comptes de service.
  • Gestion sécurisée des clés API :
    • Ne commitez jamais de clés API dans un système de gestion de versions.
    • Utilisez des variables d’environnement pour transmettre les clés aux applications.
    • Faites pivoter les clés si elles ont été exposées accidentellement.
  • Conventions de nommage : utilisez des noms descriptifs qui indiquent la fonction du compte de service :
    • Recommandé : ci-model-training, nightly-eval-pipeline, prod-inference-monitor
    • À éviter : service-account-1, test-sa, temp
  • Attribution de l’utilisateur : lorsque plusieurs membres de l’équipe utilisent le même flux de travail d’automatisation, définissez WANDB_USERNAME ou WANDB_USER_EMAIL pour savoir qui a déclenché chaque run :
  • Configuration de l’environnement : pour les comptes de service à portée d’équipe, définissez toujours WANDB_ENTITY afin que les runs soient journalisés dans la bonne équipe :
  • Gestion des erreurs : mettez en place une gestion des erreurs et des alertes appropriées en cas d’échec d’authentification, afin d’identifier rapidement les problèmes liés aux identifiants des comptes de service.
  • Documentation : tenez à jour une documentation indiquant :
    • Les comptes de service existants et leur fonction.
    • Les systèmes ou flux de travail qui utilisent chaque compte de service.
    • Les coordonnées de l’équipe responsable de chaque compte.

Dépannage

Si un compte de service ne se comporte pas comme prévu, consultez les problèmes courants et leurs solutions ci-dessous :
  • Erreurs « Unauthorized » : vérifiez que la clé API est correctement définie et que le compte de service a accès au projet cible.
  • Les runs n’apparaissent pas : vérifiez que WANDB_ENTITY correspond au bon nom d’équipe.
  • L’attribution de l’utilisateur ne fonctionne pas : assurez-vous que l’utilisateur indiqué dans WANDB_USERNAME est membre de l’équipe.
  • Accès refusé aux projets restreints : ajoutez explicitement le compte de service à la liste d’accès du projet restreint.
Dernière modification le 30 septembre 2026