Connexion des comptes

Comment connecter un compte OAuth personnel — depuis les Paramètres ou directement depuis un bloc de workflow — et comment diagnostiquer une connexion qui échoue

Les intégrations basées sur OAuth (GitHub, Google, Microsoft, …) distinguent deux choses :

L'intégration elle-même — installée et configurée par un administrateur de l'organisation sous Paramètres → Intégrations. Elle stocke les identifiants OAuth au niveau de l'organisation (Client ID / Client Secret) et crée une connexion pour le produit. Une intégration affichée Active ici signifie que l'organisation l'a configurée et activée — cela ne signifie pas que votre compte personnel est déjà lié.
Votre compte personnel — le compte OAuth que vous autorisez via cette intégration. Un bloc de workflow n'offre pas de sélecteur pour choisir entre plusieurs comptes ; il utilise automatiquement le compte que l'identité qui exécute le workflow (vous, ou le compte de service en tant que qui il s'exécute) a connecté pour ce produit.

Les fournisseurs de connexion sont distincts

La section Fournisseurs sous Paramètres → Profil → Sécurité associe un fournisseur d'authentification à votre identité Scrydon. Elle est distincte des comptes d'intégration décrits sur cette page et utilise la configuration de connexion sociale du déploiement.

Seuls les fournisseurs configurés par votre opérateur Scrydon y apparaissent. Si la section Fournisseurs est absente, le déploiement ne propose aucun fournisseur de connexion sociale pour l'association de comptes ; utilisez les méthodes de connexion activées ou contactez votre opérateur. L'installation de GitHub, Google ou Microsoft sous Paramètres → Plateforme → Extensions n'active pas le fournisseur d'authentification correspondant.

Où connecter un compte

Vous pouvez connecter un compte personnel depuis les deux endroits — les deux aboutissent au même écran de consentement OAuth du fournisseur :

Paramètres → Intégrations (onglet compte) : choisissez le fournisseur et cliquez sur Connect.
Directement depuis un bloc : un bloc dont le champ Identité indique qu'il n'a pas encore de compte pour ce produit affiche un unique bouton Connecter <produit> — pas de liste déroulante, pas de compte à choisir. Cliquer dessus vous envoie directement chez le fournisseur ; il n'y a rien à confirmer au préalable. À votre retour, le bloc se lit automatiquement comme prêt avec votre nouveau compte — il n'y a pas d'étape de sélection séparée.

Les comptes sont connectés sur la connexion Default de l'intégration — la connexion créée automatiquement par la plateforme lorsqu'un administrateur installe l'intégration. Si votre organisation utilise des connexions nommées supplémentaires (par exemple par environnement), utilisez Re-authorize sur la connexion concernée dans le panneau d'administration des connexions.

Le champ Identité d'un bloc affiche votre propre compte connecté — il n'y a pas de liste déroulante affichant les comptes d'autres personnes, ni d'état « Saved by collaborator ». Une exécution agit toujours en tant que celui qui l'exécute (vous, ou le compte de service en tant que qui elle s'exécute), jamais en tant qu'un·e collaborateur·rice qui aurait configuré le bloc.

Qui possède un compte connecté

Chaque compte connecté a un propriétaire dans Scrydon, distinct de la personne qui a cliqué sur Connecter. Le propriétaire détermine ce qu'il advient de l'identifiant quand des membres partent :

Propriétaire	Signification	Quand un membre est retiré
Un membre	Son propre compte — le cas par défaut quand vous connectez un compte vous-même.	L'identifiant est supprimé avec lui.
Un compte de service	Une identité machine détient l'identifiant. Typique pour une boîte d'automatisation partagée comme `automation@example.com`.	Rien ne change — le compte de service continue de fonctionner.
L'organisation	Un identifiant partagé par tous, comme une inscription d'application ou une clé d'API.	Rien ne change.

La connexion Microsoft derrière une boîte d'automatisation reste un vrai compte utilisateur chez le fournisseur ; la propriété concerne qui le détient dans Scrydon, pas le type de compte chez le fournisseur.

Un administrateur de l'organisation peut changer le propriétaire depuis le panneau Identifiants du compte de service avec Réattribuer à ce compte de service. Il s'agit uniquement d'un changement de propriété : la connexion existante et ses autorisations sont conservées, personne n'a à consentir de nouveau.

Un identifiant détenu par un membre est à un départ près de casser tous les workflows qui l'utilisent. Si un compte de service utilise le compte d'un membre, réattribuez-le avant le départ de ce membre.

Comptes de service et environnements

L'identifiant d'un compte de service est lié par connexion. Si un produit a une connexion Dev et une connexion Prod, liez le compte de service sur chacune : ce sont deux applications distinctes chez le fournisseur avec deux connexions distinctes, un lien Dev ne se reporte donc jamais sur Prod. Quand un workflow exécuté en tant que compte de service est promu vers un environnement où rien n'est encore lié, l'exécution s'arrête à cette étape avec RUN_AS_IDENTITY_MISSING, en nommant la connexion à corriger.

Rendre un compte disponible dans un espace de travail

Un compte personnel que vous possédez est automatiquement utilisable dans tous les espaces de travail dont vous êtes membre — il n'y a pas d'étape d'attribution, car un bloc ne sélectionne jamais de compte pour vous permettre d'opter pour ce partage.

Pour rendre votre compte utilisable par d'autres membres d'un espace de travail, un propriétaire ou administrateur de l'espace de travail le partage explicitement depuis Paramètres → Espaces de travail → Identifiants d'intégration, et peut révoquer ce partage depuis le même panneau plus tard, sans déconnecter votre compte fournisseur. Un bloc de workflow ne déclenche jamais cela lui-même — le partage est toujours une action d'administrateur, jamais un effet secondaire de la configuration d'un bloc.

Microsoft Teams autorise la cible nécessaire à chaque action. Les actions de chat comme Écrire un message de chat sélectionnent un Chat et n'exigent pas d'Équipe. Les actions de canal exigent une Équipe ainsi que leur entrée de canal. Si un workflow de préproduction conservé demande une resélection, choisissez de nouveau le compte : les anciennes chaînes d'identifiants encodées ne sont volontairement pas devinées.

Diagnostiquer une connexion qui échoue

La boîte de dialogue de connexion reste ouverte et affiche l'erreur lorsque l'URL d'autorisation ne peut pas être construite :

Erreur	Signification	Correctif
`No Default connection found. Install the extension first.`	L'intégration n'est pas installée (ou a été retirée) pour cette organisation.	Un administrateur installe/active l'intégration sous Paramètres → Plateforme → Extensions.
`OAuth client credentials are misconfigured for provider …`	Le Client ID au niveau de l'organisation est mal formé — p. ex. une adresse e-mail collée dans le champ Client ID.	Un administrateur corrige le Client ID / Client Secret dans le formulaire d'identifiants de l'intégration.
`OAuth client credentials are not configured for provider …`	L'intégration est activée mais aucun Client ID / Secret n'a été enregistré.	Un administrateur complète le formulaire d'identifiants.
`AADSTS7000215: Invalid client secret provided`	Microsoft a rejeté le secret OAuth configuré. L'identifiant du secret a pu être saisi à la place de sa valeur, ou la valeur a expiré.	Créez ou récupérez une valeur de secret client valide dans Entra, enregistrez-la sur l'intégration, puis reconnectez le compte.
Le fournisseur affiche un avertissement `redirect_uri`	L'application OAuth enregistrée chez le fournisseur ne liste pas l'URL de rappel de votre déploiement.	Enregistrez `https://<votre-hôte>/api/auth/extensions/account/callback/<provider>` sur l'application OAuth du fournisseur.

Après une connexion réussie, vous êtes redirigé vers votre point de départ. Sous Paramètres → Intégrations, le nouveau compte apparaît dans votre liste de comptes connectés ; sur un bloc, son champ Identité se lit automatiquement comme prêt avec le nouveau compte — il n'y a rien de plus à sélectionner.

Microsoft : « Approbation de l'administrateur requise »

Les connexions Microsoft 365 / Teams peuvent être interrompues par une invite Azure :

Approbation de l'administrateur requise — Scrydon a besoin d'une autorisation pour accéder à des ressources de votre organisation que seul un administrateur peut accorder.

Il s'agit d'une stratégie de locataire Azure Entra (Azure AD), pas d'une erreur Scrydon : votre organisation restreint les applications auxquelles les utilisateurs peuvent consentir, donc les étendues Microsoft demandées par Scrydon nécessitent une approbation unique par un administrateur du locataire. Tant que cette approbation n'est pas accordée, aucun compte n'est stocké — un bloc Teams signale alors que le compte Microsoft n'est pas connecté.

Pour corriger cela, un administrateur du locataire Microsoft accorde une seule fois le consentement pour l'application Scrydon — soit en complétant l'invite de consentement administrateur, soit via le centre d'administration Entra (Applications d'entreprise → Consentement et autorisations). Ensuite, reconnectez votre compte sous Paramètres → Comptes connectés ; pour une organisation mono-locataire, l'administrateur doit aussi définir le Tenant ID de l'intégration sur le GUID du locataire plutôt que common.

Une fois le consentement accordé à l'échelle du locataire, les utilisateurs se connectent sans écran d'approbation. Si des utilisateurs non administrateurs voient encore « Approbation de l'administrateur requise » alors que le portail Entra affiche toutes les autorisations comme accordées, vous utilisez une version de Scrydon qui forçait une invite de re-consentement à chaque connexion (corrigé en juillet 2026) — mettez à niveau : sur une invite forcée, Entra exige que l'utilisateur connecté ré-approuve personnellement les étendues réservées aux administrateurs, ce qu'un non-administrateur ne peut jamais faire.