Concepts fondamentaux
Les trois produits Connector partagent les fournisseurs, les opérations et les schémas, mais utilisent des modèles différents d’isolation des comptes et de permissions. Identifiez d’abord le produit, puis interprétez ses ressources de connexion, de compte connecté, de Team ou de Project.
| Produit | Modèle de compte et d’isolation | Exécution dans |
|---|---|---|
| OOMOL Connector (Hosted) | Connexions dans un scope personnel ou de Team | L’hébergement OOMOL |
| Connector for SaaS | Projects, utilisateurs externes et comptes connectés | L’hébergement OOMOL |
| OpenConnector | Un runtime et des connexions gérés par l’opérateur | Votre infrastructure |
Concepts partagés par les trois produits
Apps et fournisseurs
Une App est le service que l’utilisateur voit et choisit de connecter, comme Gmail, GitHub ou Slack.
Un fournisseur ou service est l’intégration Connector correspondante. Il définit l’authentification, les opérations, les schémas et la manière dont Connector interroge l’API en amont. Le nom de l’App et celui du fournisseur correspondent généralement, mais le premier désigne le service présenté à l’utilisateur et le second la limite d’implémentation de Connector.
Opérations et outils
Une opération est une fonction appelable exposée par un fournisseur. Son action ID combine généralement un service et une opération, comme gmail.search_threads. Chaque opération possède un schéma d’entrée et définit les données renvoyées par un appel.
Un outil est la surface d’appel par laquelle un Agent, le CLI ou un client MCP voit une opération. Un SDK exécute généralement une opération directement, tandis qu’un Agent découvre et appelle les opérations disponibles sous forme d’outils.
Avant l’exécution, confirmez :
- le compte utilisé par l’opération ;
- les paramètres qui seront envoyés ;
- si l’opération lit, écrit ou supprime des données ;
- si l’identité actuelle peut utiliser la ressource de compte correspondante.
Agents et Skills
Un Agent choisit un outil, fournit les paramètres et utilise le résultat pour poursuivre une tâche. OOMOL fournit les capacités autorisées des Apps employées pendant ce travail.
Un Skill est un ensemble réutilisable d’instructions de tâche. Il indique à l’Agent quels outils utiliser, dans quel ordre, quelles contraintes préserver et comment organiser le résultat. L’exécution utilise l’identité et les outils disponibles de l’Agent, tandis que Connector stocke les identifiants de l’App.
OOMOL Connector (hébergé)
Connexion
Une connexion est une instance de connexion à un compte d’App dans un scope personnel ou de Team. Elle possède son propre nom et son propre ID de connexion, et elle est associée à l’autorisation du compte, à son état et aux paramètres de permissions.
Le même compte d’App peut être connecté plusieurs fois. Chaque connexion peut configurer séparément :
- Action access : les opérations autorisées par la connexion ;
- Member access : les membres de la Team qui peuvent utiliser la connexion.
Les opérations qu’un membre peut appeler correspondent à l’union des opérations autorisées par toutes les connexions auxquelles il a accès.
Team
Une Team est le scope de locataire Team pour Hosted Connector. La Team active détermine les connexions visibles par l’appelant et les opérations qu’il peut y utiliser.
Les clients CLI, MCP et SDK doivent sélectionner explicitement une Team afin qu’une modification ultérieure de la Team par défaut ne sélectionne pas la mauvaise connexion. Le forfait Team est facturé par siège ; consultez les informations actuelles dans la page Billing de Console.
Accès effectif
Un appel ne peut s’exécuter qu’à l’intersection de ces limites :
Provider authorization
∩ connection Action access
∩ Team Member access
∩ CLI, MCP, or SDK caller identity
= actions the caller can execute
Consultez Contrôle d’accès et Gestion des Teams pour les détails de configuration.
Parcours d’un appel Hosted Connector
User connects an App
→ a connection is created
→ Agent or trusted backend selects an action and connection
→ Hosted Connector checks access and loads credentials
→ Provider API
→ result and execution metadata return to the caller
Connector pour SaaS
Connector for SaaS permet aux utilisateurs de votre produit de connecter leurs propres comptes tiers. Il utilise un modèle de ressources multi-tenant distinct :
| Ressource | Rôle |
|---|---|
| Project | Isole la configuration, les clés, les comptes connectés, les enregistrements d’exécution et l’utilisation d’une intégration de produit |
| Provider config | Définit l’authentification d’un fournisseur dans un Project |
| External user ID | Associe les ressources OOMOL à un utilisateur de votre produit |
| Compte connecté | Représente un compte fournisseur autorisé par un utilisateur externe |
| Clé API du Project | Authentifie les requêtes du Project provenant d’un backend de confiance |
Un compte connecté représente un compte fournisseur autorisé par un utilisateur externe dans un Project. Le backend le sélectionne lors de l’exécution d’une opération pour cet utilisateur du produit.
Parcours d’un appel SaaS
Product user completes Provider authorization
→ connected account is linked to an external user ID
→ your backend uses a Project API key
→ ProjectConnector selects the user, connected account, and action
→ Hosted Connector executes the call
→ Provider API
Votre produit authentifie ses propres utilisateurs et maintient une association d’utilisateurs externes stable et difficile à deviner. Consultez Connector for SaaS pour le modèle de ressources et le flux d’intégration.
OpenConnector
OpenConnector est le runtime et la passerelle open source que vous déployez dans votre propre infrastructure.
- Le runtime charge les fournisseurs, gère les connexions, sélectionne les identifiants, applique les politiques et appelle les API des fournisseurs.
- La passerelle est la surface d’accès exposée par le runtime aux clients MCP, HTTP, OpenAPI et SDK.
- Un jeton runtime contrôle l’accès d’un client au runtime et à ses capacités.
OpenConnector place le runtime, les connexions et la politique d’accès dans l’infrastructure que vous gérez. Les appelants utilisent ses opérations via MCP, HTTP, OpenAPI ou le SDK.
Parcours d’un appel OpenConnector
You configure a Provider and connection
→ Agent or application selects an action and connection
→ OpenConnector runtime checks the token and policy
→ runtime loads credentials and calls the Provider API
→ result returns to the caller
L’opérateur est responsable du chiffrement des identifiants, des jetons, du stockage, du réseau, des journaux, des sauvegardes et des mises à niveau. Consultez OpenConnector pour la description complète de cette limite.
Limite des identifiants
Les jetons OAuth bruts des fournisseurs, les clés API et les identifiants personnalisés ne doivent pas être exposés aux Agents, aux Skills, aux clients de navigateur ou aux utilisateurs du produit :
- OOMOL stocke et renouvelle les identifiants dans sa limite hébergée pour Hosted Connector et Connector for SaaS ;
- l’opérateur d’OpenConnector protège les identifiants dans sa propre infrastructure ;
- Connector charge les identifiants lors de l’exécution d’une opération ou d’une requête proxy prise en charge, et ne renvoie que le résultat à l’appelant.
Choisir le terme approprié
| Scénario | Terme à utiliser |
|---|---|
| Un particulier ou une Team connecte un compte d’App | connexion |
| Un utilisateur d’un produit SaaS connecte son propre compte | compte connecté + utilisateur externe |
| La limite d’isolation d’une intégration SaaS | Project |
| Limiter l’utilisation d’un compte et des opérations dans une Team | Member access et Action access de la connexion |
| Une entrée appelable présentée à un Agent | outil |
| Une opération définie par Connector | opération |
| Un service d’exécution auto-hébergé | runtime / passerelle OpenConnector |
Après avoir choisi un produit, poursuivez avec sa vue d’ensemble et son guide d’intégration. Consultez la référence du SDK TypeScript pour les méthodes et types exacts.
Wanta