Choisir un parcours d’intégration

Choisissez le parcours selon le propriétaire du compte connecté, l’endroit où les appels s’exécutent et l’équipe qui exploite la limite des identifiants.

Comparer les quatre parcours

Parcours	Propriétaire du compte connecté	Les appels passent par	Vous exploitez
Configuration d’un Agent	Vous	oo CLI ou OOMOL MCP	L’environnement de l’Agent
SDK Connector hébergé	Vous	La passerelle OOMOL hébergée	Votre code backend
Projet Connector SaaS	Chaque utilisateur de votre produit	La passerelle OOMOL hébergée	Votre produit et la mise en correspondance des utilisateurs
OpenConnector auto-hébergé	Vous ou votre organisation	Votre runtime OpenConnector	Le runtime, le stockage, la sécurité et les mises à niveau

Utiliser OOMOL depuis un Agent

Choisissez ce parcours pour permettre à Codex, ChatGPT, Claude Code ou un autre Agent pris en charge d’utiliser les Apps que vous connectez.

Vous allez :

Connecter une App dans OOMOL.
Installer oo CLI dans l’Agent ou configurer un client MCP.
Demander à l’Agent d’utiliser l’App connectée.

Commencez par le Démarrage rapide.

Appeler vos propres connexions depuis le backend

Choisissez le client Connector hébergé lorsqu’un backend de confiance doit appeler les Apps connectées à votre compte OOMOL.

Ce parcours utilise une clé API personnelle au format api_…. La clé reste sur le backend et autorise les appels sur vos propres connexions.

Consultez le guide du SDK OOMOL Connector.

Permettre aux utilisateurs finaux de connecter leurs comptes

Choisissez Connector for SaaS lorsque chaque utilisateur de votre produit doit autoriser son propre compte Gmail, Slack, Notion ou celui d’un autre fournisseur.

Votre backend crée les liens d’autorisation, stocke votre ID utilisateur avec l’ID du compte connecté obtenu et exécute les opérations pour cet utilisateur. Ce parcours utilise une clé API de projet au format oo_proj_….

Consultez le guide Connector for SaaS.

Exécuter OpenConnector vous-même

Choisissez l’auto-hébergement lorsque votre équipe doit exploiter le runtime, la base de données, le chiffrement des identifiants, l’accès réseau, les journaux et le processus de mise à niveau.

Les clients runtime peuvent utiliser un jeton au format oct_…. Les apps OAuth des fournisseurs, les clés de chiffrement, le stockage, les sauvegardes et la politique des opérations restent sous votre responsabilité.

Consultez le guide d’auto-hébergement d’OOMOL OpenConnector.

Portée des identifiants par produit

Identifiant	Utilisé par	Portée
`api_…`	Client `Connector` hébergé	Vos connexions personnelles
`oo_proj_…`	`ProjectConnector` et les API SaaS	Un projet Connector et ses utilisateurs finaux
`oct_…`	Client `OpenConnector`, HTTP ou MCP	Un runtime auto-hébergé

Conservez ces trois types d’identifiants dans un backend de confiance, un gestionnaire de secrets ou un environnement d’Agent protégé. Ne les placez pas dans des bundles de navigateur, des dépôts publics ou des prompts.

Décider avec trois questions

À qui appartient le compte connecté ? Votre compte mène à la configuration d’un Agent ou au SDK personnel. Les comptes des utilisateurs finaux mènent à un projet SaaS.
Qui doit gérer le stockage des identifiants et le renouvellement des jetons ? Utilisez l’hébergement OOMOL pour réduire le travail opérationnel ; auto-hébergez lorsque votre équipe doit posséder cette limite.
Où les opérations seront-elles appelées ? Utilisez la configuration d’un Agent pour le travail interactif et un SDK ou HTTP pour les appels du backend d’un produit.

Après avoir choisi un parcours, suivez son Démarrage rapide avant d’ajouter davantage de fournisseurs ou une politique de production.