Comptes de service (identités d'exécution de workflows)
Créez des identités machine avec leur propre habilitation, liez-les à des workflows comme identités d'exécution et révoquez-les — depuis la page Membres de l'organisation.
Un compte de service est une identité machine (un client OAuth client_credentials) qui appartient à votre organisation. Par défaut, c'est un compte de service standard — vous choisissez ses portées et copiez son secret client pour appeler l'API de la plateforme.
Cette page décrit le mode habilitation d'exécution optionnelle. Lorsque vous attribuez une habilitation d'exécution à un compte de service lors de sa création, il devient une identité d'exécution de workflow : il porte sa propre habilitation, la plateforme garde son secret confiné côté hôte (il n'y a aucun secret à copier — l'hôte émet lui-même des jetons de courte durée), et il peut être lié à un workflow. Quand un workflow lié s'exécute, les accès au stockage et aux identifiants sont effectués en tant que compte de service — pas en tant que la personne qui a créé ou déclenché le workflow. Les décisions d'accès, les lignes d'audit et les contrôles d'habilitation sont tous attribués à l'identité machine.
L'habilitation d'exécution est optionnelle. Laissez-la sur Aucune — compte de service standard pour obtenir le compte externe-M2M ordinaire ci-dessus. Attribuer une habilitation bascule le compte en identité d'exécution confinée côté hôte (aucun secret n'est affiché). Et une identité d'exécution liée ne change le comportement d'un workflow qu'une fois que vous l'avez liée — les workflows non liés continuent de s'exécuter au nom de leur auteur.
Où les trouver
Les comptes de service se gèrent sur la page Membres de l'organisation (Paramètres → Organisation → Membres), regroupés séparément des utilisateurs humains afin qu'il soit toujours clair qui est une personne et ce qui est une identité machine :
- Utilisateurs — vos membres humains (invitation, rôles, suppression).
- Comptes de service — identités machine (nom, ID client, habilitation, statut, révocation).
Créer un compte de service
Sur Paramètres → Organisation → Membres, ouvrez l'onglet Comptes de service et sélectionnez Ajouter un compte de service.
Donnez-lui un nom (p. ex. production-runner), puis définissez l'habilitation d'exécution sur un niveau du schéma de classification actif de votre organisation (au lieu de la valeur par défaut Aucune). Vous ne pouvez attribuer qu'une habilitation égale ou inférieure à la vôtre.
Sélectionnez Créer le compte de service. Le nouvel ID client s'affiche avec une action de copie — utilisez-le pour lier le compte à un workflow.
Lorsque vous attribuez une habilitation, il n'y a aucun secret à copier ou à conserver. La plateforme garde le secret client chiffré côté serveur et émet elle-même des jetons de courte durée à chaque exécution d'un workflow lié — ni vous ni le runtime de workflow ne manipulez jamais l'identifiant. (Laisser l'habilitation sur Aucune crée plutôt un compte de service standard dont vous copiez le secret une fois.)
La création de comptes de service requiert la permission d'organisation member: create (les administrateurs d'organisation l'ont) ; la révocation requiert member: delete.
Le lier à un workflow
Définissez l'identité d'exécution du workflow avec l'ID client du compte de service. La liaison est accréditée : vous ne pouvez lier qu'une identité dont l'habilitation est inférieure ou égale à la vôtre — un auteur ne peut jamais élever un workflow au-dessus de lui-même, et un auteur sans habilitation ne peut rien lier du tout.
Une fois lié :
- Les accès du workflow au stockage et aux identifiants s'exécutent en tant que compte de service, contrôlés par l'habilitation du compte (pas de lecture vers le haut).
- Les lignes d'audit attribuent les actions au compte de service, avec l'exécution qui les a effectuées.
- Les connexions exigeant une habilitation supérieure à celle du compte sont invisibles pour le workflow.
Révoquer
La révocation d'un compte de service (l'action ✕ sur sa ligne) le désactive immédiatement. Les workflows encore liés échouent de manière sûre (fail-closed) à leur prochaine exécution — ils ne retombent pas silencieusement sur l'identité de leur auteur. Reliez le workflow à une nouvelle identité, ou supprimez la liaison pour rétablir l'exécution sous l'identité de l'auteur.