Connexion des comptes

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

1. L'extension elle-même — installée et configurée par un administrateur de l'organisation sous Paramètres → Plateforme → Extensions. Elle stocke les identifiants du client OAuth au niveau de l'organisation (Client ID / Client Secret) et crée une connexion pour ce qu'elle fournit. Une extension 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é.
2. Votre compte personnel — le compte OAuth que vous autorisez auprès de cette extension. 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 sous lequel il s'exécute) a connecté pour cet élément fourni.

Connexions par clé API et ressources IA régionales

Le formulaire Connexions → Ajouter une connexion utilise la définition d'identifiants de l'extension, y compris le libellé de sa clé et ses champs de configuration. Azure AI Foundry demande la clé API de sa ressource et les endpoints Foundry. Les produits Microsoft OAuth demandent un Client ID et un Client Secret. Si une extension propose plusieurs méthodes d'authentification, choisissez la méthode dans le formulaire. Les produits qui ont une exigence d'identifiants explicite ne reçoivent que des identifiants compatibles.

Pour plusieurs ressources Foundry, installez l'extension une seule fois et ajoutez des connexions nommées, par exemple North Europe, Sweden Central et West Europe. Donnez à chaque connexion sa propre clé de ressource et ses propres endpoints, et choisissez sa portée d'environnement. Modifier une connexion affichée comme couvrant plusieurs produits met à jour ensemble la configuration de ce groupe.

Dans Paramètres → Plateforme → Extensions → Modèles & valeurs par défaut, choisissez Tous les environnements pour modifier la valeur par défaut partagée, ou un environnement de l'organisation tel que Development ou Production pour la remplacer. Personnel configure les espaces de travail personnels, dont l'identifiant d'environnement interne reste main. Le sélecteur ne change pas votre espace de travail actif.

Ouvrez la liste déroulante avec recherche d'une capacité pour charger les modèles de toutes les connexions admissibles :

• Tous les environnements inclut les connexions configurées pour tous les environnements.
• Un environnement précis inclut ses propres connexions ainsi que les connexions partagées, sous réserve de la politique de l'organisation sur les connexions génériques.
• Les entrées sont regroupées par vendeur et par connexion. Des noms de modèles identiques sur des ressources Azure différentes restent des choix distincts ; en choisir un épingle cette connexion et ce modèle.
• Automatique choisit un vendeur/modèle admissible au moment de l'exécution. Un remplacement Automatique remplace un épinglage hérité. Utiliser la valeur par défaut partagée supprime le remplacement.

Le catalogue est commun à toute l'organisation : vous pouvez donc configurer Development ou Production tout en travaillant dans Personnel. La liste déroulante ne propose que des choix de modèles admissibles ; les modèles explicitement signalés comme indisponibles ou non vérifiés sont omis. Les autorisations de l'espace de travail et l'habilitation s'appliquent toujours lorsqu'un workflow s'exécute. Les identifiants réservés à Production ne sont jamais empruntés par Development ou Staging.

Les épinglages de connexion déjà enregistrés restent épinglés, y compris les anciennes valeurs par défaut à l'échelle de l'organisation qui nommaient une connexion propre à un environnement. Si une connexion est supprimée, désactivée ou inaccessible, l'exécution signale une configuration indisponible jusqu'à ce que vous choisissiez un remplacement. Une mise à jour concurrente de la politique rejette un enregistrement obsolète au lieu d'écraser les paramètres d'un autre environnement. Rechargez la politique avant de réessayer.

Azure Speech passe par l'endpoint de la ressource Foundry configurée ; aucun champ distinct Azure Speech Region n'est nécessaire pour le routage. Renseignez Azure Region sur chaque connexion Foundry afin que le catalogue puisse filtrer les modèles Speech intégrés selon la prise en charge régionale de Microsoft. La région Azure (par exemple northeurope) est distincte de l'environnement applicatif (Development, Production ou Tous les environnements) ; elle ne peut pas être déduite du nom choisi par l'utilisateur pour une ressource.

Le catalogue STT inclut MAI Transcribe 2, MAI Transcribe 1.5, Azure Speech Fast Transcription et Azure AI Speech — live transcription with speaker labels, en plus des déploiements découverts. MAI et Fast Transcription utilisent l'API de transcription Speech de Microsoft, sans déploiement OpenAI. MAI accepte l'audio WAV, MP3 ou FLAC. L'opération de transcription HTTP de MAI n'est pas une session de streaming du Speech SDK.

Les entrées de service intégrées utilisent la région Azure configurée sur la connexion pour filtrer les modèles connus comme non pris en charge. Les modèles Speech intégrés dont la région est inconnue sont également omis tant que la prise en charge régionale n'est pas confirmée. Renseignez Azure Region avec la région réelle de la ressource et rouvrez le sélecteur pour actualiser ses choix ; des noms de connexion comme Default ou Sweden Central n'établissent pas la région. Le sélecteur liste les choix sans badge de disponibilité. Si aucun n'est disponible pour une capacité dans l'environnement sélectionné, la ligne l'explique au lieu d'afficher une liste déroulante. Installez et configurez les extensions depuis l'onglet Installées. La prise en charge par le catalogue ne prouve pas qu'une ressource donnée peut exécuter un modèle. Ouvrir le sélecteur n'envoie aucun audio de test facturable ; Azure valide l'accès lorsqu'une transcription est demandée.

Le tableau des régions de Microsoft liste Speech en temps réel ordinaire en North Europe, Sweden Central et West Europe, tandis que son tableau du service de transcription LLM/MAI inclut North Europe mais pas les deux autres. Vérifiez la disponibilité des modèles MAI pour la ressource réelle. Ajouter une connexion ne provisionne pas de modèles et ne les active pas dans toutes les régions.

Si les choix ne peuvent pas être chargés, utilisez Réessayer et vérifiez l'environnement et la connexion sélectionnés.

Adresses des endpoints

Certaines extensions demandent une adresse sur la connexion — l'URL de votre propre Twenty ou Home Assistant, par exemple. Le formulaire la vérifie pendant la saisie puis à l'enregistrement, et indique quel champ corriger :

Une source de données qui n'a besoin d'aucun identifiant reçoit tout de même une connexion — c'est là que vit l'adresse. Son formulaire demande le nom, l'environnement et l'adresse, et rien d'autre.

Une source de base de données a besoin d'une connexion par environnement. Elle ne lit jamais une connexion enregistrée pour Tous les environnements : lorsqu'une connexion en sert une, le formulaire ne propose pas ce choix et s'ouvre sur l'environnement d'où vous venez. Connecter l'extension depuis Ajouter une extension pose la même question : lorsqu'elle fournit une source de base de données, l'étape de connexion demande pour quel environnement est la connexion et l'y enregistre ; tout ce qu'elle fournit d'autre garde Tous les environnements. Une connexion déjà enregistrée pour Tous les environnements qui sert une source de base de données affiche À configurer — modifiez-la et choisissez son environnement, par exemple Development ou Production. D'ici là, Analytics la liste dans Ajouter une source de données, mais elle ne peut pas être choisie et le panneau dit pourquoi.

Une source, plusieurs connexions

Une source de données peut passer par plusieurs connexions dans le même environnement — par exemple la source States d'une extension Home Assistant qui lit à la fois votre Home Assistant personnel et celui de votre entreprise. Chacune est une instance de la source, avec sa propre planification, son propre état, son propre historique et sa propre table.

1. Ouvrez Paramètres → Plateforme → Extensions → Installées, sélectionnez l'extension et ouvrez l'onglet Connections.
2. Si un système n'a pas encore de connexion, ajoutez-en une : nom, environnement, adresse et identifiant dans un seul formulaire.
3. Choisissez l'environnement en haut de l'onglet. Dans la ligne de la source, sélectionnez Ajouter une instance. Seuls les administrateurs de l'organisation la voient.
4. Saisissez un Nom, par exemple Entreprise. Le Nom court est rempli à partir de celui-ci et nomme la table de l'instance — ha_states_entreprise pour entreprise. Vous pouvez le modifier : lettres minuscules, chiffres et tirets simples, 24 caractères au maximum.
5. Choisissez la Connexion. La liste ne propose que les connexions activées de cette source configurées pour cet environnement — ou pour Tous les environnements, sauf pour une source de base de données —, chacune marquée Prête, À configurer ou Pas encore utilisable.
6. Sélectionnez Ajouter une instance.

L'instance apparaît dans l'onglet et dans Analytics → Data Sources sous le nom de la source suivi du sien — Home Assistant states · Entreprise — avec son propre état, son propre historique et sa propre table.

L'instance existante garde sa connexion. Lorsque vous ajoutez la première instance, la source que vous aviez déjà est fixée sur la connexion qu'elle utilise à ce moment-là : ajouter d'autres connexions ensuite ne la fait jamais changer. Si cette source peut utiliser plusieurs connexions dans cet environnement, ou aucune, la boîte de dialogue vous demande de choisir celle qu'elle conserve.

Ajouter ou déplacer une connexion ne fait jamais changer une source en cours. Avant d'enregistrer une nouvelle connexion pour l'environnement d'une source (ou pour Tous les environnements), ou de déplacer une connexion vers un autre environnement, chaque source qui y lit exactement une connexion est d'abord fixée sur celle-ci. Un message les nomme : Conservent la connexion qu'elles utilisent déjà : …. Pour lire l'une d'elles aussi via la nouvelle connexion, utilisez Ajouter une instance sur sa ligne ; pour la faire basculer, utilisez Changer de connexion. Si cette vérification ne peut pas aboutir, la connexion n'est pas enregistrée et rien ne change — réessayez.

Modifier ou supprimer une instance. Sur la ligne de l'instance dans l'onglet Connections, le menu ⋯ (administrateurs de l'organisation uniquement) propose :

• Changer de connexion — l'instance lit la connexion que vous choisissez dès sa prochaine synchronisation. Sa table et son historique restent tels quels. La ligne d'origine de la source le propose aussi : c'est ainsi que vous choisissez entre plusieurs connexions lorsqu'une source indique More than one connection in this environment can serve ….
• Point de terminaison push (sources push uniquement) — ce avec quoi configurer le système qui envoie à cette instance : le chemin vers lequel il envoie, qui se termine par l'ID de liaison de l'instance ; l'en-tête qui porte son identifiant ou sa signature, et son contenu ; et l'en-tête qui nomme chaque livraison. Chaque valeur a un bouton de copie. Le chemin est affiché sans hôte : les livraisons vont à l'hôte push public de votre déploiement, que votre opérateur Scrydon peut vous indiquer.
• Supprimer l'instance (instances ajoutées uniquement) — l'instance n'est plus synchronisée. Sa table et son historique de synchronisation sont conservés, et sa connexion n'est pas modifiée. Une instance ajoutée plus tard avec le même nom court écrit de nouveau dans la même table.

Lorsque la connexion d'une source est supprimée. Une source fixée sur une connexion ne bascule jamais d'elle-même vers une autre : si cette connexion est supprimée ou déplacée vers un autre environnement, la ligne de la source indique À configurer et précise The connection this source is fixed to was deleted or no longer applies to this environment. Ajouter une nouvelle connexion, même portant le même nom, ne la remplace pas : choisissez-en une avec Changer de connexion. Une source qui n'est fixée sur aucune connexion et n'en a aucune dans l'environnement indique No connection in this environment can serve this source yet. Ajoutez-en une dans l'onglet Connections. Une source dont la connexion n'a aucun identifiant enregistré, ou aucun compte connecté, indique The connection has no credential saved : modifiez la connexion et saisissez-le, ou connectez son compte.

Analytics → Data Sources ne propose pas Remove pour une instance : son menu propose Manage this instance in Platform, qui ouvre cet onglet. Une source qui a encore des instances ne peut pas non plus y être supprimée : supprimez d'abord ses instances.

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'extension 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 l'un ou l'autre endroit — les deux aboutissent au même écran de consentement OAuth du vendeur :

• Paramètres → Comptes connectés : choisissez le fournisseur et cliquez sur Connecter.
• 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'extension — la connexion que la plateforme crée automatiquement lorsqu'un administrateur installe l'extension. Si votre organisation utilise des connexions nommées supplémentaires (par exemple par environnement), utilisez plutôt Re-authorize sur la connexion concernée dans le panneau d'administration des connexions.

Lire le panneau d'administration des connexions

Paramètres → Plateforme → Extensions → <extension> → Connexions liste une ligne par identifiant, et non une par produit. Un identifiant qui sert plusieurs produits d'une extension n'apparaît qu'une fois, et la colonne S'applique à nomme les produits qu'il couvre — « Outlook », ou « 7 produits » quand la liste est longue.

Cela compte surtout pour les fournisseurs de modèles. L'installation d'Azure AI Foundry, par exemple, provisionne la même clé API pour chacun de ses produits (LLM, Embeddings, Speech-to-Text et les autres) ; le panneau l'affiche comme une seule connexion Default s'appliquant à sept produits, plutôt que sept lignes identiques.

Deux conséquences à connaître :

• Ajouter une connexion couvre tous les produits de l'extension. Vous saisissez l'identifiant une seule fois au lieu de répéter le formulaire pour chaque produit.
• En supprimer une la retire de tous les produits qu'elle couvre. La confirmation les nomme avant que vous ne validiez.

Les vendeurs dont chaque produit nécessite sa propre autorisation — Microsoft, où Outlook et Excel sont des consentements OAuth distincts — affichent toujours une ligne par produit, car ce sont réellement des identifiants différents.

Tester une connexion

Tester la connexion sur la ligne d'une connexion (et Enregistrer et tester dans son formulaire) envoie une vraie requête au service que la connexion atteint, avec la clé enregistrée dans la connexion, et rend compte de cinq vérifications :

Chaque vérification indique Réussi, Échec ou Inconnu, et dit pourquoi quand elle n'a pas réussi. Inconnu ne signifie jamais réussi : rien de ce que Scrydon a envoyé n'a pu répondre à cette question. Dès qu'une vérification échoue, les suivantes ne sont pas essayées. Les vérifications s'exécutent dans l'ordre : une clé n'est donc jamais envoyée à une adresse que votre politique de sortie refuse, ni à un hôte dont le certificat n'a pas été vérifié.

La requête envoyée dépend de ce que l'extension déclare déjà :

• Un fournisseur de modèles d'IA (LLM, embeddings, parole, etc.) : sa propre liste de modèles. Une liste qui ne contient que les modèles livrés avec l'extension a pu revenir sans la clé ; elle laisse donc les vérifications de clé et de lecture à Inconnu au lieu de les faire réussir.
• Une source de données qui appelle une API (source planifiée ou à la demande) : la propre requête de la source, envoyée une fois exactement comme sa prochaine exécution l'enverrait. Aucune ligne n'est lue, stockée ni écrite. Une source à la demande qui a besoin de valeurs saisies par la personne qui l'exécute n'est pas envoyée.
• Une source de base de données installée via cette connexion (épinglée à celle-ci) : une lecture de la liste des schémas de la base, via le catalogue que Scrydon tient pour cette source avec l'identifiant de la connexion. Aucune ligne n'est lue. Une lecture qui répond prouve à la fois l'hôte, l'identifiant et la lecture ; une lecture qui ne répond pas les laisse à Inconnu. Une source de base de données qui n'est pas épinglée à cette connexion n'est pas lue.
• Tout le reste — source en flux ou en push, extension qui ne fournit que des outils — ne reçoit pas encore de requête ; ses vérifications en direct restent à Inconnu et le disent.

Lecture seule ? n'est tranchée que par la lecture d'une source de base de données : Oui quand la base liste chaque privilège de l'identifiant et qu'aucun n'écrit, Non quand l'un d'eux écrit. Partout ailleurs, la réponse est Inconnu — aucune requête envoyée par le test ne demande au service ce que la clé peut faire d'autre, et une base de données ne peut pas toujours le dire (un identifiant dont les droits viennent d'un attribut de rôle est invisible pour son catalogue). Préférez une clé, un identifiant ou un compte de service en lecture seule chaque fois que le service le permet.

À savoir :

• Les administrateurs de l'organisation peuvent tester toute connexion ; les autres personnes peuvent tester une connexion sur laquelle elles détiennent Gérer.
• La requête est réelle : elle peut être décomptée de votre quota auprès du service. Scrydon n'enregistre aucun usage pour elle et n'écrit rien.
• Une connexion en brouillon n'envoie rien ; activez-la pour la tester avec sa clé.

Un compte par produit, pas par vendeur

Un compte connecté appartient à un produit, et non au vendeur dans son ensemble. Un compte que vous connectez pour Outlook ne peut pas être utilisé par un bloc Teams, et inversement — même si les deux vous connectent avec la même identité Microsoft. Le contrôle de connexion liste donc une entrée par produit (« Microsoft — Outlook », « Microsoft — Teams »), et un bloc ne lit jamais que le compte connecté pour son propre produit — il ne peut pas utiliser un compte connecté pour un autre produit du même vendeur.

C'est aussi pourquoi chaque connexion demande un ensemble d'autorisations différent : l'écran de consentement demande exactement ce dont ce produit a besoin. En pratique, vous verrez généralement l'écran de consentement une fois par vendeur — la plupart des fournisseurs d'identité renvoient toutes les autorisations que vous avez déjà approuvées pour la même application, si bien que connecter un second produit du même vendeur se termine souvent sans nouvelle invite.

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 personnes arrivent et partent :

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

L'endroit d'où vous connectez détermine le propriétaire. Connecter depuis vos propres paramètres vous donne un compte détenu par un membre. Connecter depuis le panneau Identifiants d'un compte de service — Connecter un compte / Connecter un autre compte — donne immédiatement l'identifiant à ce compte de service, même si c'est une personne qui se connecte chez le vendeur pour l'autoriser. Il n'y a aucune étape de réattribution à retenir, et aucun intervalle pendant lequel un identifiant d'automatisation appartient à une personne.

Un administrateur de l'organisation peut toujours transférer au compte de service un identifiant existant détenu par un membre, depuis le même panneau — utilisez-le pour reprendre une boîte aux lettres que quelqu'un avait connectée à titre personnel. Cliquez sur Transférer la propriété sur la ligne marquée Détenu par une personne, ou sur Transférer la propriété à ce compte de service sous le compte d'un membre dans la boîte de dialogue Associer un identifiant. Les deux ouvrent la même confirmation, qui nomme le compte et son propriétaire actuel ; rien ne change tant que vous n'avez pas confirmé.

Le transfert est uniquement un changement de propriété :

• La connexion reste la même. L'autorisation reste l'identité de cette personne chez le vendeur, avec les autorisations qu'elle a accordées, et personne n'a à consentir de nouveau.
• Le cycle de vie change. L'identifiant ne disparaît plus quand cette personne quitte l'organisation ou le déconnecte elle-même, et dès lors tout administrateur de l'organisation peut le dissocier.

Seuls les administrateurs de l'organisation peuvent transférer la propriété. Si le transfert est refusé, le message en donne la raison — par exemple que vous n'êtes pas administrateur, ou que le compte ou le compte de service n'existe plus.

La personne qui s'est connectée chez le vendeur est enregistrée séparément comme créatrice de l'identifiant. Cet enregistrement ne change jamais de mains, et ce n'est pas le propriétaire.

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 vendeur 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.

Accorder les autorisations manquantes

Un compte peut être connecté et en bon état tout en manquant d'une autorisation dont un bloc particulier a besoin — par exemple un compte connecté avant que votre organisation n'active les actions sur les boîtes aux lettres partagées.

Dans ce cas, Scrydon nomme les autorisations manquantes au lieu d'échouer à l'exécution du workflow :

• Dans le champ Identité du bloc — un avis orange liste les autorisations manquantes avec un bouton Mettre à jour l'accès.
• Sous Paramètres → Comptes connectés — le compte affiche un badge Autorisations manquantes et un bouton Accorder l'accès.

L'un comme l'autre vous renvoie vers l'écran de consentement du fournisseur pour ce produit uniquement. À votre retour, l'avis disparaît de lui-même. Rien d'autre ne change pour le compte — la même ligne de compte est réutilisée, si bien que tout partage avec un espace de travail et tout bloc qui y fait déjà référence continuent de fonctionner.

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'extension, 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 :

Après une connexion réussie, vous êtes redirigé vers votre point de départ. Sous Paramètres → Comptes connectés, 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é — et un bloc Teams signale alors que le compte Microsoft n'est pas connecté (auparavant, cela se manifestait par une erreur 401 opaque InvalidAuthenticationToken / IDX14100).

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'extension 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.

Enregistrer un modèle par défaut

Sélectionner une entrée dans Modèles & valeurs par défaut l'enregistre immédiatement. Les valeurs par défaut partagées s'appliquent aux environnements sans remplacement. Les choix déjà enregistrés sans connexion épinglée conservent leur comportement d'origine de résolution de connexion ; sélectionner un remplacement épingle sa connexion.

Si l'enregistrement échoue, le choix en attente reste visible. Utilisez Réessayer pour l'enregistrer de nouveau ou Annuler pour rétablir la valeur enregistrée.