OpenConnector, Composio, Nango et Pipedream : jusqu’où va l’open source ?

Connecter un agent IA à Gmail, Notion ou Slack rend la première exécution particulièrement concrète. L’assistant peut désormais chercher des messages, modifier des documents et accomplir un vrai travail.

Puis viennent d’autres questions. Peut-on ajouter une opération manquante ? Jusqu’où peut-on examiner un appel qui échoue ? Si un client exige que ses identifiants restent dans votre infrastructure, pouvez-vous y déplacer le service de connexion ?

C’est là que le périmètre du code publié et les possibilités d’exploitation deviennent importants. OpenConnector, Composio, Nango et Pipedream permettent tous des intégrations, mais leur code public, leurs licences et leurs options de déploiement couvrent des périmètres différents.

Quelle partie du système est ouverte ?

Le SDK, le connecteur et le moteur d’exécution remplissent des rôles distincts.

• Le SDK prépare les requêtes et reçoit les résultats. Son code permet d’examiner le comportement du client.
• Le code d’exécution du connecteur transforme une opération en requête vers une API tierce, avec la conversion des paramètres et le traitement des réponses. Sa publication permet d’inspecter et d’étendre cette implémentation.
• Le moteur de connexion exécute les opérations et gère généralement les identifiants, les autorisations et les journaux. Son code et des instructions de déploiement publics permettent à une équipe de l’exploiter elle-même.

Figure 1. Le code du connecteur s’exécute dans le moteur. L’implémentation précise dépend du produit.

Un SDK public ne prouve pas que le code de la passerelle l’est aussi. Pouvoir modifier un connecteur ne suffit pas non plus à rendre toute la plateforme déployable de façon autonome.

Les quatre produits en un tableau

Produit	Principal code public	Auto-hébergement	Périmètre à vérifier
OpenConnector	Connector SDK, oo CLI, passerelle, définitions des providers, exécuteurs et Web Console	Déploiement public avec Docker ou Node.js, prise en charge de Cloudflare	Dépôt principal : Apache-2.0 ; SDK et CLI : MIT. Vérifier l’exécuteur et l’autorisation de chaque opération
Composio	SDK, CLI et adaptateurs de frameworks dans le dépôt principal public	Options d’auto-hébergement et de déploiement privé pour les entreprises	La licence MIT du SDK ne définit pas celle de la passerelle
Nango	Code de la plateforme d’intégration et des fonctions	Auto-hébergement gratuit ou Enterprise	Elastic License 2.0 pour le dépôt principal ; fonctions limitées dans l’édition gratuite
Pipedream	Composants, documentation et paquets associés	Les composants s’exécutent généralement sur l’infrastructure hébergée de Pipedream	Licence Source Available ; les composants publics ne constituent pas une plateforme entière déployable librement

Sources : OpenConnector, dépôt Composio, déploiement Composio, auto-hébergement Nango et composants Pipedream.

Votre service n’a pas encore de provider

Votre équipe adopte un nouveau CRM et veut permettre à un agent de chercher des clients et de mettre à jour leur suivi. Or, ce service ne figure pas encore dans le catalogue.

L’extension utile consiste à ajouter un provider côté passerelle : l’intégration d’un service avec son authentification, ses paramètres et ses opérations. Le SDK et la CLI gardent leur mode d’appel habituel. Les utilisateurs n’ont généralement pas à modifier leur code source.

OpenConnector propose trois chemins :

• Développer le provider vous-même, dans votre passerelle, selon votre calendrier.
• Soumettre une PR, pour partager l’implémentation avec les autres utilisateurs.
• Ouvrir une issue, en décrivant le service et les opérations à prendre en charge par notre équipe.

Pour ces demandes de nouveaux providers ou d’opérations, nous intégrons généralement les fonctionnalités concernées sous 24 à 36 heures. C’est notre rythme habituel ; la complexité de l’API, les comptes de test et les autorisations du service tiers peuvent modifier ce délai.

Une absence dans le catalogue laisse donc une voie concrète pour avancer, seul ou avec les mainteneurs, tout en conservant les outils d’appel existants. Voir le guide de contribution ou ouvrir une demande.

Le code public d’OpenConnector couvre Connector SDK, oo CLI, la passerelle, les définitions et exécuteurs d’opérations, ainsi que la Web Console. Le SDK sert au code applicatif ; oo connector recherche, inspecte et exécute les opérations ; MCP et HTTP/OpenAPI permettent d’autres accès. Le SDK et la CLI peuvent utiliser le service OOMOL ou un moteur auto-hébergé. Outils de développement

Les dépôts OpenConnector, Connector SDK et oo CLI permettent d’examiner le trajet du client à l’exécution. L’équipe peut gérer les comptes connectés, les opérations autorisées et les journaux expurgés des données sensibles dans son environnement.

Figure 2. Capture du dépôt officiel. Les libellés et les nombres correspondent à la version capturée, sans garantir la couverture actuelle.

Après l’ajout d’un provider, les applications et agents gardent les mêmes points d’entrée. Avant d’adopter une opération, vérifiez son exécuteur, ses paramètres et les conditions d’autorisation du service tiers.

Le dépôt principal de Composio se présente comme un monorepo de SDK : Python, TypeScript, CLI et adaptateurs. Il aide à inspecter le client, mais n’établit pas que l’implémentation interne de la passerelle soit ouverte. Dépôt Composio

Composio propose bien un auto-hébergement et des environnements privés pour les entreprises. Le qualifier de service exclusivement cloud serait inexact. Comparez plutôt les chemins accessibles depuis le code public, ceux qui nécessitent un accord commercial et les parties modifiables après déploiement. Composio MCP Gateway

Nango publie le code de sa plateforme et permet l’auto-hébergement. Son édition gratuite couvre principalement l’authentification et le proxy API ; les fonctions, synchronisations, webhooks et MCP relèvent de l’offre complète Cloud ou Enterprise. Présentation de Nango

Pipedream permet de lire, écrire et contribuer des composants. Ceux-ci s’exécutent habituellement sur son infrastructure serverless. Modifier une opération et exploiter toute la plateforme restent deux capacités distinctes. Documentation Pipedream

Lire aussi les licences

Du code visible sur GitHub n’implique pas des conditions d’utilisation identiques.

Code concerné	Licence publiée
Dépôt principal OpenConnector	Apache-2.0
Connector SDK	MIT
oo CLI	MIT
SDK public de Composio	MIT
Dépôt principal Nango	Elastic License 2.0
Dépôt principal Pipedream	Pipedream Source Available License

Avant de maintenir un fork, redistribuer du code ou proposer un service fondé dessus, vérifiez les dispositions applicables. La licence OpenConnector couvre le code du projet ; les conditions des API tierces, les autorisations et les droits sur les marques restent distincts.

Exploiter le service implique de le maintenir

Avec votre propre déploiement, vous pouvez examiner l’état du moteur, les échecs récents et les journaux, puis modifier la configuration ou le code si nécessaire.

Figure 3. Capture du dépôt officiel. Les statistiques illustrent l’interface, pas la taille ou la fiabilité actuelles du service.

Il faut aussi assurer les mises à jour, les sauvegardes, la gestion des clés et l’infrastructure, voire enregistrer ses propres applications OAuth. Davantage de contrôle implique cette responsabilité d’exploitation.

Commencer en SaaS, puis passer à son propre moteur

Le SaaS OOMOL et OpenConnector partagent le même modèle d’appel des connecteurs : identifiants des providers et des opérations, contrats de paramètres. L’application ou l’agent conserve ce vocabulaire, que le moteur tourne chez OOMOL ou sur vos serveurs. Modes de déploiement

Vous pouvez démarrer sur le SaaS, puis déployer OpenConnector lorsque l’activité grandit ou qu’un client exige une infrastructure privée. Le SDK et la CLI pointent alors vers votre instance. Les appels pris en charge et leurs paramètres restent réutilisables, sans réécrire ces intégrations.

Point d’entrée	Configuration à modifier	Éléments réutilisables
Connector SDK	Initialiser OpenConnector avec votre baseUrl et le jeton du moteur	Identifiants des opérations prises en charge, paramètres et méthodes comme execute
oo CLI	Définir OO_CONNECTOR_URL et, si nécessaire, OO_CONNECTOR_TOKEN	Commandes de connecteur search, schema, run et paramètres des opérations

Consultez les guides du SDK et de la CLI.

Le nouvel environnement doit encore disposer des comptes connectés, applications OAuth et identifiants nécessaires. La gestion des équipes, les utilisateurs de projet et les autres capacités hébergées demandent une vérification distincte. La structure commune préserve les appels des connecteurs ; elle ne transfère pas automatiquement tous les comptes et toutes les fonctions SaaS.

Pour évaluer cette voie, exécutez une opération courante sur le SaaS, puis essayez la même opération avec les mêmes paramètres sur votre instance, depuis le même SDK ou la même CLI. Si un service manque, examinez aussi le parcours de contribution ou de demande.

Pour démarrer rapidement tout en gardant une voie vers votre propre infrastructure, connectez une application avec OOMOL ou déployez une instance et testez une opération utilisée au quotidien.

---

Les logos et captures proviennent des sites ou dépôts officiels et servent à identifier et comparer les produits. Les droits restent à leurs propriétaires. Le schéma conceptuel a été créé pour cet article.