Auto-héberger OpenConnector ou choisir OOMOL hébergé ? Commencez par faire fonctionner votre intégration

Au moment de connecter Google, Zoom ou monday.com à une application ou à un agent, vous pouvez vous poser la question : puisque OpenConnector est open source, pourquoi ne pas déployer votre propre passerelle ?

Vous contrôlez alors le stockage des identifiants, les opérations autorisées et l’enregistrement des appels. Mais une fois le service lancé, il reste un travail souvent sous-estimé : préparer l’autorisation pour chaque application.

Pour la plupart des équipes qui veulent lancer rapidement une fonctionnalité, nous recommandons OOMOL hébergé et une intégration via le SDK. Choisissez OpenConnector auto-hébergé si le service de connexion et les identifiants doivent rester sur votre infrastructure, ou si vous devez modifier la passerelle ou les connecteurs.

Vous pouvez aussi avancer par étapes : faire fonctionner l’intégration avec le service hébergé, préparer vos propres applications OAuth en parallèle, puis migrer lorsque vous êtes prêt.

Partez de vos besoins actuels

Votre besoin	Point de départ conseillé
Connecter rapidement des applications, avec la possibilité d’utiliser un hébergement externe	OOMOL hébergé
Partager des connexions et centraliser les accès des membres et les opérations autorisées	Les fonctions d’équipe d’OOMOL hébergé
Utiliser vos propres applications OAuth, encore en configuration ou en cours de validation	Commencer avec l’hébergement, puis évaluer la migration
Garder les identifiants, la passerelle et les journaux d’exécution sur votre infrastructure	OpenConnector auto-hébergé
Modifier les connecteurs, adapter la passerelle ou contrôler les accès réseau sortants	OpenConnector auto-hébergé

La taille de l’entreprise peut peser dans la décision. Les questions les plus directes restent le niveau de contrôle nécessaire et la maintenance que votre équipe est prête à assurer.

L’auto-hébergement commence souvent par OAuth

Lancer OpenConnector avec Docker vous donne une passerelle de connexion. Pour accéder à un service qui utilise OAuth, vous devez également créer votre application OAuth dans sa console développeur.

Deux éléments sont à distinguer. Le Client ID et le Client Secret identifient votre application. Le jeton d’accès, obtenu après l’autorisation d’un utilisateur, permet d’accéder aux ressources que cet utilisateur a approuvées.

Vous préparez les premiers avant de connecter le compte. Le jeton est délivré lors de l’autorisation.

Avec Google, par exemple, il faut créer un projet, activer les API nécessaires, créer un client OAuth, renseigner l’URL de rappel et choisir les permissions demandées. Selon ces permissions et l’usage prévu, une vérification de l’application peut être nécessaire. Documentation OAuth de Google

Les autres services ont leurs propres règles de configuration et de distribution. Une intégration peut rester simple à gérer ; plusieurs applications impliquent de maintenir séparément les paramètres clients, les URL de rappel, les permissions et les validations.

Les exigences peuvent aussi varier entre un test interne et une ouverture à de nombreux clients. Certains services permettent de commencer avec votre compte ou des utilisateurs de test. D’autres imposent une approbation administrative ou une vérification supplémentaire pour certains usages. Référez-vous à la console et à la documentation du fournisseur.

OpenConnector enregistre les paramètres OAuth, connecte les comptes et exécute les opérations. Avec vos propres applications OAuth, leur création et le respect des exigences des fournisseurs restent à la charge de votre équipe. Consultez le guide de configuration des applications OAuth.

Avec l’hébergement, concentrez-vous sur l’intégration

Si votre objectif immédiat est de livrer une fonction — consulter un calendrier, organiser des e-mails ou actualiser un projet — commencez par faire fonctionner les connexions nécessaires.

Pour les intégrations compatibles avec les applications OAuth gérées, OOMOL réduit le travail de création et de maintenance chez chaque fournisseur. Vous devez toujours connecter vos comptes et approuver les permissions nécessaires. Les services utilisant une clé API ou une autre méthode d’authentification nécessitent leurs paramètres propres.

Une fois le compte connecté, OOMOL hébergé prend en charge le stockage des identifiants, le renouvellement des jetons et les appels aux applications. Votre backend choisit une connexion via le SDK, transmet les paramètres et reçoit les résultats. Les jetons bruts des fournisseurs n’ont pas à figurer dans votre code métier ou dans les prompts des agents. Guide du Connector hébergé

Schéma : les deux modes de déploiement. L’emplacement et la gestion de la passerelle changent ; l’accès aux applications externes reste soumis aux autorisations du fournisseur et à la connectivité réseau.

L’hébergement apporte aussi la gestion d’équipe. Les administrateurs gèrent les membres, définissent les opérations autorisées pour chaque connexion et choisissent qui peut l’utiliser.

Un même compte de messagerie peut, par exemple, avoir deux connexions. La première autorise la lecture et est attribuée aux personnes qui doivent consulter les messages. La seconde autorise l’envoi et est réservée aux personnes responsables de la communication externe. Les membres exécutent les opérations approuvées sans recevoir le jeton d’accès brut du compte. Permissions des équipes et des connexions

Ces réglages permettent de conserver un contrôle des accès à mesure que vous ajoutez des applications. L’accès à une donnée précise reste limité par les droits du compte d’origine et les permissions accordées.

Si chaque utilisateur de votre produit doit connecter ses propres comptes, utilisez Connector for SaaS et le client ProjectConnector côté hébergé pour séparer les connexions par utilisateur.

Choisissez OpenConnector pour maîtriser l’environnement d’exécution

Certaines équipes ont des exigences dès le départ : protéger les identifiants avec leurs propres clés et leur stockage, exécuter la passerelle dans le réseau de l’entreprise, et conserver les journaux selon leurs règles internes.

Ces exigences déterminent le déploiement. Avec OpenConnector auto-hébergé, l’équipe gère la passerelle, les identifiants, les règles d’opérations et les journaux, ainsi que les bases de données, sauvegardes, mises à jour et accès réseau.

L’open source donne également accès au code. Les sources du runtime, des définitions de connecteurs, du code d’exécution des opérations et de la console web sont publiques, tout comme celles du Connector SDK et de oo CLI. Vous pouvez partir du projet existant pour examiner les appels, ajouter une intégration ou modifier l’implémentation. Les autorisations et conditions d’utilisation des API tierces continuent de s’appliquer.

Ce contrôle implique de la maintenance. Quelqu’un doit assurer la gestion des clés, la protection des accès, les mises à jour, les sauvegardes et le traitement des incidents. La sécurité dépend de la manière dont ces tâches sont réalisées.

Choisissez selon votre environnement :

• Docker Compose : exécution sur vos serveurs ou dans votre réseau d’entreprise, avec une gestion directe du stockage et des accès.
• Cloudflare Workers : déploiement OpenConnector que vous gérez sur l’infrastructure Cloudflare, notamment D1 et R2, si un environnement cloud convient.
• Exécution depuis les sources : développement de connecteurs, débogage ou modification d’OpenConnector.

Cloudflare est une option cloud. Une exigence stricte d’exécution dans le réseau d’entreprise nécessite un environnement serveur adapté.

Une passerelle interne a aussi besoin d’accès sortants appropriés. Appeler des SaaS externes comme Google ou Zoom nécessite d’atteindre leurs API et leurs points d’autorisation. Dans un réseau sans accès externe, vérifiez d’abord si le service visé dispose d’une interface interne accessible.

Les étapes sont décrites dans le guide d’auto-hébergement OpenConnector.

Commencez hébergé, migrez lorsque vous êtes prêt

Si vous prévoyez d’utiliser vos propres applications OAuth mais attendez encore des configurations ou validations, avancez sur deux fronts : validez l’intégration avec l’hébergement et préparez les identifiants et l’environnement de l’auto-hébergement.

Les deux modes utilisent le package SDK @oomol-lab/connector. Il fournit Connector pour les connexions hébergées, ProjectConnector pour les utilisateurs d’un produit et OpenConnector pour un runtime auto-hébergé. Les clients partagent les types d’opérations et les conventions d’appel, mais diffèrent par l’authentification, la séparation des comptes et les méthodes disponibles. Référence du SDK TypeScript

Les identifiants d’opérations prises en charge, les paramètres d’entrée et les conventions d’appel peuvent être réutilisés. Une recherche d’e-mails peut conserver son nom d’opération et ses paramètres, puis s’exécuter avec le client relié au runtime auto-hébergé.

Préparez la migration en suivant ces étapes :

1. Déployer et protéger OpenConnector dans le nouvel environnement, puis configurer vos applications OAuth.
2. Créer les connexions aux comptes et confirmer les permissions nécessaires.
3. Adapter le client SDK, l’URL du service, le jeton du runtime et le choix des connexions.
4. Vérifier la prise en charge des opérations et des fonctions d’équipe, d’utilisateurs de projet et de permissions dont dépend votre application.
5. Tester une opération courante, puis transférer progressivement les autres appels.

Les connexions aux comptes et les fonctions de gestion hébergées doivent être traitées séparément. Le SDK commun permet de conserver les appels et structures de paramètres existants, ce qui réduit le travail de réintégration des API.

La migration reste un choix. Continuez avec l’hébergement tant qu’il répond à vos besoins. Reprenez la gestion de la passerelle lorsque la maîtrise de l’environnement devient une exigence concrète.

Commencez par une opération réelle

Sans obligation actuelle d’auto-hébergement, choisissez une fonction à livrer : consulter le calendrier du jour, rechercher des e-mails clients ou vérifier l’avancement d’un projet.

Connectez une application dans OOMOL Console, autorisez le compte, puis suivez le guide d’intégration SDK pour appeler une opération depuis votre backend. Vérifiez son fonctionnement avant de configurer les membres et leurs permissions.

Si l’auto-hébergement est déjà une exigence, suivez le guide de déploiement OpenConnector, puis configurez les applications OAuth.

Choisissez le point de départ adapté à vos besoins actuels. L’hébergement aide à faire fonctionner l’intégration rapidement ; OpenConnector open source permet de maîtriser le code, les identifiants et l’environnement lorsque cela devient nécessaire.