Connecter des outils

Vos agents et vos automatisations ne valent que par ce qu’ils peuvent faire : lire une boîte mail, poster dans Slack, chercher dans un CRM, générer une réponse avec un modèle d’IA. Ce guide raconte toute l’histoire — comment donner à vos assistants un accès propre et sûr à vos outils, une fois pour toutes, et qui, de l’administrateur ou de l’utilisateur, fait quoi.

Ce document est un guide : il explique comment bien connecter vos outils et pourquoi les choses fonctionnent ainsi. Si vous cherchez plutôt la description bouton par bouton de chaque écran — chaque badge, chaque champ, chaque menu — reportez-vous à la référence Connecteurs — l’interface, qui parcourt la page contrôle par contrôle.

Abra réunit sur une même page trois familles d’outils :

Connecteurs — vos applications métier (Gmail, Slack, Salesforce, une base PostgreSQL, un serveur SMTP…). Ils alimentent vos workflows et vos automatisations.
Fournisseurs IA — les moteurs qui font penser vos agents (OpenAI, Anthropic, Mistral, Google Gemini, un modèle auto-hébergé…).
Serveurs MCP — des boîtes à outils que vos agents peuvent actionner en direct pendant une conversation (Microsoft 365, Google Workspace…).

Tout se passe sur la page Connexions, organisée en trois onglets qui reprennent ces trois familles.

À CAPTURER : la page Connexions avec ses trois onglets (Connecteurs, Fournisseurs IA, Serveurs MCP) et quelques cartes de connecteurs visibles en dessous

La page Connexions et ses trois onglets — le point de départ de tout ce qui suit.

Les deux types de connexion : compte personnel ou accès partagé

Avant de brancher quoi que ce soit, il faut comprendre une distinction qui gouverne tout le reste : un service se connecte soit avec le compte de chaque personne (OAuth), soit avec une clé partagée par toute l’organisation. Ce n’est pas Abra qui décide — c’est le service lui-même qui impose l’une ou l’autre méthode.

OAuth — « chacun relie son propre compte »

L’OAuth, c’est le bouton « Se connecter avec Google / Microsoft / Slack… » que vous connaissez déjà partout ailleurs. Personne ne partage son mot de passe : chaque membre autorise Abra depuis l’écran officiel du fournisseur, et chacun agit ensuite avec son propre compte. Quand un agent lit « votre » boîte mail, c’est bien la vôtre — pas celle d’un collègue.

C’est la méthode des services qui ont une notion de compte personnel : Gmail, Outlook, Google Drive, Slack, Salesforce, HubSpot… On la reconnaît au badge OAuth 2.0 sur la carte du connecteur.

Clé API — « l’organisation partage un accès »

D’autres services ne connaissent pas les comptes personnels : ils s’authentifient avec une clé API, un jeton, un login/mot de passe ou une chaîne de connexion. C’est le cas de Stripe, SendGrid, Twilio, une base de données, un serveur SMTP, ou encore des fournisseurs d’IA. Ici, l’administrateur saisit une seule clé, et toute l’organisation l’utilise de façon transparente. On les reconnaît aux badges Clé API, Basic Auth, Header Auth ou Service.

En un coup d’œil

Critère	Connecteur OAuth	Connecteur clé API / service
Comment on s’authentifie	Bouton « Se connecter » chez le fournisseur	Une clé saisie une fois
Qui se connecte	Chaque membre, avec son compte	Personne d’autre — c’est partagé
Portée	Personnelle (chacun ses droits)	Toute l’organisation
Exemples	Gmail, Outlook, Drive, Slack, CRM	Stripe, SendGrid, Twilio, base de données, IA
Badge sur la carte	OAuth 2.0	Clé API · Basic Auth · Header Auth · Service

La règle à retenir : OAuth = un compte par personne ; clé API = un accès unique partagé par toute l’organisation. Le reste de ce guide traite les deux cas séparément, parce qu’ils ne se configurent pas de la même manière.

Qui configure quoi — et pourquoi vos secrets restent protégés

Les deux méthodes ont un point commun : ce sont les administrateurs (et, selon les cas, les managers ou développeurs) qui mettent en place l’accès de l’organisation. Un membre ordinaire ne saisit jamais de secret.

L’administrateur enregistre une fois pour toutes l’accès de l’organisation : l’application OAuth d’un côté, la clé API partagée de l’autre. C’est lui qui manipule les client secrets et les clés.
Chaque membre, ensuite, se contente de relier son propre compte en un clic pour les connecteurs OAuth. Rien à copier, rien à coller.

Cette séparation est volontaire : les clés les plus sensibles restent entre les mains d’un petit nombre de personnes, et la grande majorité des utilisateurs n’a jamais à les voir.

Vos secrets ne sont jamais réaffichés. Toute clé, tout client secret, tout mot de passe est chiffré dès son enregistrement. Quand un administrateur rouvre un connecteur pour le modifier, les champs sensibles restent vides avec la mention « Laisser vide pour conserver la valeur existante ». Personne — pas même un autre administrateur — ne peut relire une clé une fois qu’elle est enregistrée. Elle sert, mais ne se montre plus.

Configurer un connecteur OAuth (Google, Microsoft, Slack…)

Mettre en place un connecteur OAuth se fait en deux temps, par deux personnes différentes : d’abord l’administrateur déclare l’application (cette section), ensuite chaque membre relie son compte (section suivante).

Étape 1 — Déclarer une application chez le fournisseur

Pour qu’Abra puisse dialoguer avec Google, Microsoft ou Slack, il faut d’abord créer une application OAuth dans la console du fournisseur. C’est une opération à faire une seule fois par organisation.

Rendez-vous dans la console du fournisseur : Google Cloud Console pour Google, portail Azure / Microsoft Entra pour Microsoft, la page développeur Slack, etc. (Depuis le dialogue de configuration d’Abra, un bouton Doc vous amène directement au bon endroit.)
Créez une nouvelle application OAuth. Le fournisseur vous remet deux valeurs : un identifiant client (client ID) et un secret client (client secret). Gardez-les sous la main.

Étape 2 — Coller les clés dans Abra et choisir les permissions

Dans Abra, ouvrez l’onglet Connecteurs, trouvez le service et cliquez Configurer (icône engrenage — visible pour les administrateurs uniquement).
Collez le Client ID et le Client Secret dans les champs correspondants.
Réglez les permissions (scopes) : « lire les e-mails », « envoyer un message », « accéder à l’agenda »… Un éditeur guidé décrit chaque permission en clair et pré-coche un jeu recommandé. Les permissions larges (accès étendu) sont signalées en ambre. N’accordez que ce dont vos agents ont réellement besoin.

À CAPTURER : le dialogue Configurer d'un connecteur Google — champs Client ID / Client Secret à gauche, éditeur de scopes en dessous, encadrés d'aide (enregistrement + redirect URIs) à droite

Le dialogue de configuration OAuth : les clés à coller, les permissions à cocher, et les aides contextuelles à droite.

Étape 3 — Déclarer l’URL de redirection côté fournisseur

Il reste une pièce à mettre en place : l’URL de redirection. C’est l’adresse à laquelle le fournisseur renverra vos utilisateurs une fois qu’ils auront donné leur accord. Abra vous fournit cette URL exacte dans le dialogue (encadré des redirect URIs, avec un bouton pour la copier).

Copiez la ou les URL(s) affichées par Abra.
Retournez dans la console du fournisseur, dans la liste Authorized redirect URIs de votre application.
Collez-y les URL exactes, puis enregistrez côté fournisseur.

Pourquoi c’est indispensable. Si cette URL n’est pas déclarée à l’identique chez le fournisseur, la connexion échouera avec une erreur redirect_uri_mismatch. Après enregistrement, Abra vous laisse le dialogue ouvert pour copier les URL définitives ; et le petit bouton « i » sur la carte du connecteur vous les redonne à tout moment, par exemple si le fournisseur change sa liste.

Une fois tout enregistré, le connecteur passe au statut Disponible : vos membres peuvent maintenant s’y relier.

L’astuce écosystème : une app pour toute une famille

Chez Google et Microsoft, une seule application couvre toute la famille de services :

une app Google ouvre d’un coup Gmail, Drive, Agenda, Sheets, Docs… ;
une app Microsoft ouvre Outlook, Teams, SharePoint, OneDrive, Excel…

Vous ne configurez donc qu’un seul connecteur de la famille : tous les autres en héritent automatiquement (ils affichent un badge bleu Hérité). Inutile de ressaisir les mêmes clés dix fois — configurez Google Drive, et Gmail comme l’Agenda sont déjà prêts.

Se connecter à un service OAuth (côté membre)

Une fois qu’un connecteur OAuth est Disponible, chaque membre fait le reste lui-même, en quelques secondes et sans aucune clé à saisir.

Sur la carte du service, cliquez Se connecter (icône prise).
Abra vous redirige vers l’écran de consentement officiel du fournisseur, qui liste les permissions demandées. Connectez-vous et cliquez Autoriser. (Ces boutons appartiennent au fournisseur, pas à Abra.)
De retour dans Abra, une notification confirme la connexion et la carte affiche Connecté. C’est terminé.

À CAPTURER : l'écran de consentement du fournisseur (ex. autorisation Google) listant les permissions, avec les boutons Autoriser / Refuser

L’écran de consentement du fournisseur — c’est là que le membre autorise Abra à agir en son nom.

À partir de là, quand un agent ou un workflow a besoin de ce service, il agit avec votre compte : vos e-mails, votre agenda, vos droits. Rien n’est mutualisé — le compte de votre collègue reste le sien.

Si le bouton « Se connecter » n’apparaît pas ou affiche « Fournisseur non configuré », c’est que votre organisation n’a pas encore déclaré l’application OAuth : voyez avec un administrateur.

Configurer un connecteur à clé API ou service (OpenAI, Stripe…)

Pour les services sans compte personnel — Stripe, SendGrid, Twilio, une base de données, un serveur SMTP… — la configuration est plus simple et entièrement à la charge de l’administrateur. Il n’y a ni écran de consentement, ni permissions à cocher, ni URL de redirection.

Onglet Connecteurs → Configurer sur le service voulu.
Saisissez la clé API (ou les identifiants attendus : hôte, port, utilisateur, mot de passe, chaîne de connexion — cela dépend du service).
Enregistrez. Le connecteur passe au statut Disponible pour l’organisation.

À CAPTURER : le dialogue Configurer d'un connecteur à clé API (ex. Stripe ou OpenAI) — encadré « Clé API partagée », champ libellé, champ secret masqué, boutons Annuler / Enregistrer

La configuration d’un connecteur à clé partagée : une seule clé, saisie une fois, utilisée par toute l’organisation.

Il n’y a rien à faire côté membre : tous les agents et workflows de l’organisation utilisent la même clé, sans jamais la voir. C’est le mode adapté aux services techniques (paiements, envoi d’e-mails, bases de données) qui n’ont pas de notion de « compte personnel ».

Brancher vos moteurs d’IA — les fournisseurs LLM

L’onglet Fournisseurs IA regroupe les moteurs qui font penser vos agents : OpenAI, Anthropic (Claude), Mistral, Google Gemini, Groq, OpenRouter, ou un modèle auto-hébergé (Ollama, tout endpoint compatible OpenAI…). C’est aussi ici que se règle le modèle d’embedding utilisé par la base de connaissances (RAG).

Techniquement, un fournisseur IA fonctionne comme un connecteur à clé API : on colle une clé, elle est partagée par l’organisation. Deux manières d’alimenter vos agents :

Votre propre clé (BYOK — Bring Your Own Key). L’administrateur ouvre le fournisseur, colle la clé API du compte de l’organisation et enregistre. La consommation est facturée directement par le fournisseur sur ce compte. Le fournisseur devient alors sélectionnable dans le constructeur d’agents.
La clé de la plateforme. Selon votre installation, l’exploitant d’Abra peut mettre à disposition une clé mutualisée (souvent avec des quotas et une liste de modèles autorisés). Dans ce cas, vous pouvez utiliser un modèle sans configurer la moindre clé — rien à saisir.

À CAPTURER : l'onglet Fournisseurs IA avec plusieurs cartes (OpenAI, Anthropic, Mistral…) dont certaines sont Configuré et d'autres Non configuré

L’onglet Fournisseurs IA : une clé par moteur, ou la clé mutualisée de la plateforme.

Vous n’êtes pas obligé de tout configurer. Une seule clé (par exemple OpenAI ou Anthropic) suffit pour démarrer ; ajoutez d’autres fournisseurs au fil de vos besoins. Comme pour tout secret, les clés saisies ne sont jamais réaffichées ensuite.

Ouvrir des outils à vos agents — les serveurs MCP

Un serveur MCP est une boîte à outils qu’un agent peut utiliser pendant une conversation : lire et envoyer des e-mails, créer un événement d’agenda, chercher un fichier… Microsoft 365 et Google Workspace en sont les exemples phares — plusieurs centaines d’outils chacun. L’onglet Serveurs MCP fonctionne à deux niveaux.

Côté administrateur : activer et cadrer

Dans le panneau admin, parcourez le catalogue et cliquez Activer sur le serveur voulu. Certains serveurs (Microsoft, Google…) demandent d’abord de configurer une application OAuth, exactement comme un connecteur — un bouton Configurer vous y amène.
Choisissez la liste des outils autorisés (allowlist) : vous décidez précisément ce que les agents pourront faire (autoriser « lire les e-mails » mais pas « supprimer », par exemple).
Un interrupteur général (kill-switch) en haut du panneau coupe, d’un seul geste, tous les serveurs MCP de l’organisation. Utile en cas de doute : vous reprenez le contrôle immédiatement, sans rien désinstaller.

Côté utilisateur : connecter son compte et choisir ses outils

Dans Mes connexions personnelles, chaque membre :

Clique Connecter sur un serveur activé par l’administrateur, puis s’authentifie auprès du fournisseur (comme un connecteur OAuth).
Coche, parmi les outils autorisés par l’administrateur, ceux qu’il veut réellement rendre disponibles à ses agents.
Peut désactiver ou déconnecter son accès à tout moment.

À CAPTURER : l'onglet Serveurs MCP — panneau admin avec kill-switch et allowlist en haut, section « Mes connexions personnelles » avec un serveur connecté en dessous

Les deux niveaux d’un serveur MCP : l’administrateur active et cadre, chaque membre connecte son compte et choisit ses outils.

Comptes Microsoft 365. Un compte professionnel ou scolaire donne accès à l’ensemble (Teams, SharePoint, boîtes partagées…). Un compte personnel (Outlook.com, Hotmail, Live) fonctionne aussi, mais se limite à Mail, Calendar, OneDrive et Excel.

Gérer vos connexions au quotidien

Une fois vos outils branchés, la page Connexions reste votre poste de pilotage. Voici les gestes courants.

Plusieurs comptes pour un même service (multi-instances). Un administrateur peut configurer plusieurs accès à un même connecteur — par exemple deux comptes Slack (« Production » et « Marketing »), ou deux bases de données. Chaque accès porte un libellé que l’on retrouve ensuite dans le sélecteur de credential des workflows. Sur la carte, un badge « N instances » et un chevron permettent de déplier la liste, de modifier (crayon) ou de supprimer (corbeille) chaque accès.

À CAPTURER : une carte connecteur dépliée montrant deux instances (« Production », « Marketing ») avec libellé, identifiant masqué et boutons crayon / corbeille

Plusieurs accès pour un même service, chacun avec son libellé — pratique quand une organisation jongle avec plusieurs comptes.

Se déconnecter (côté membre). Sur la carte d’un service OAuth, le bouton Se déconnecter retire votre connexion personnelle, immédiatement. Vos agents perdent aussitôt l’usage de ce compte ; vous pourrez vous reconnecter plus tard d’un clic.

Modifier ou retirer une configuration (côté admin). Un administrateur peut mettre à jour une clé (les champs secrets restent vides tant qu’on ne saisit pas une nouvelle valeur), ou retirer entièrement la configuration d’un connecteur, d’un fournisseur ou d’un serveur MCP.

Attention aux workflows en cours. Supprimer l’accès d’un connecteur utilisé par des workflows les fera échouer tant qu’un autre accès n’est pas choisi à la place. Une fenêtre de confirmation vous le rappelle avant toute suppression.

Sécurité et bonnes pratiques

À garder en tête pour des connexions saines et sûres.

Le moindre privilège, toujours. N’accordez que les permissions nécessaires — via l’éditeur de scopes (OAuth) ou l’allowlist d’outils (MCP). Un agent n’a presque jamais besoin de tout supprimer.

Chacun son compte. Pour l’OAuth (connecteurs et MCP), un agent agit toujours avec les droits de la personne connectée. Le périmètre d’un membre reste le sien — rien n’est partagé à son insu.

Les secrets ne se relisent pas. Clés API, client secrets et mots de passe sont chiffrés dès l’enregistrement et jamais réaffichés. Traitez la saisie initiale comme votre seule chance de les voir.

Réservez les clés aux administrateurs. C’est le sens de la séparation admin / membre : concentrez les secrets entre peu de mains.

Coupez large en cas de doute. Le kill-switch MCP désactive tous les serveurs d’un geste, sans rien désinstaller — la façon la plus rapide de reprendre le contrôle.

La révocation définitive se fait aussi côté fournisseur. Si un compte ne doit plus jamais être utilisé, retirez l’accès dans Abra et révoquez l’application dans la console du fournisseur (Google, Microsoft, Slack…). C’est la coupure la plus complète.

Questions fréquentes

Un utilisateur peut-il voir les clés ou les secrets configurés ? Non. Les secrets sont chiffrés dès leur enregistrement et ne sont jamais réaffichés — même à l’administrateur qui rouvre le connecteur. Les champs sensibles restent vides (« Laisser vide pour conserver la valeur existante ») et un membre ordinaire ne les voit jamais du tout.

Que se passe-t-il si je me déconnecte d’un service OAuth ? Votre connexion personnelle est retirée immédiatement. Les agents et workflows qui reposaient sur votre compte pour ce service cessent d’y avoir accès. Rien n’est supprimé côté fournisseur : vous pourrez vous reconnecter plus tard d’un simple clic sur Se connecter.

Où trouver l’URL de redirection à déclarer chez le fournisseur ? Abra vous la fournit dans le dialogue de configuration OAuth (encadré des redirect URIs, avec un bouton pour la copier). Une fois le connecteur configuré, le petit bouton « i » sur sa carte vous la redonne à tout moment. Collez-la à l’identique dans la liste « Authorized redirect URIs » de l’application, sinon la connexion échouera avec redirect_uri_mismatch.

Dois-je reconfigurer une application par service Google (ou Microsoft) ? Non. Une seule application couvre toute la famille : configurez un seul connecteur Google (ou Microsoft) et les autres en héritent automatiquement (badge bleu Hérité). Une app Google ouvre Gmail, Drive, Agenda, Sheets… d’un coup.

Quelle est la différence entre un connecteur, un fournisseur IA et un serveur MCP ? Un connecteur branche une application à vos workflows (Gmail, Stripe, une base de données…). Un fournisseur IA apporte la clé du modèle qui fait fonctionner vos agents (OpenAI, Anthropic…). Un serveur MCP ouvre des outils actionnables en direct par un agent pendant une conversation (Microsoft 365, Google Workspace…).

Faut-il tout configurer avant de créer un agent ? Non. Une seule clé de fournisseur IA suffit pour démarrer, et vous ajoutez connecteurs et serveurs MCP au fil de vos besoins. Vous pouvez parfaitement créer un premier agent avec le strict minimum, puis enrichir ses accès plus tard.

Puis-je avoir deux comptes pour le même service ? Oui, côté administrateur : un connecteur accepte plusieurs instances (par exemple deux comptes Slack). Chacune porte un libellé que l’on retrouve dans le sélecteur de credential des workflows.

Et ensuite ?

Une fois vos outils branchés, mettez-les entre les mains de vos assistants :

Créer un agent — pour donner ces outils à un assistant conversationnel.
Workflows & automatisations — pour câbler vos connecteurs à vos processus.
Connecteurs — l’interface — la référence complète, écran par écran, de chaque bouton et champ de la page.