Activepieces 0.93.0, publié le 8 novembre 2026, permet à un flux de se connecter à un serveur MCP protégé par OAuth 2.0 sans saisir manuellement l'identifiant et le secret client, à condition que le service expose les métadonnées nécessaires. L'utilisateur renseigne l'adresse du serveur, puis approuve l'accès via une fenêtre d'autorisation. Cette évolution simplifie la configuration des flux pour quiconque souhaite faire travailler un agent avec des outils externes. La mise à jour modifie par ailleurs l'environnement d'exécution par défaut des étapes de code.
La version est documentée dans les notes officielles d'Activepieces sur GitHub. La proposition technique du 22 septembre décrit la fonctionnalité et présente un test local avec le serveur MCP d'Aleph. Les deux sources couvrent des phases distinctes: l'implémentation a été intégrée le 18 octobre et distribuée dans la version publiée le 8 novembre.
Le client se connecte à des services externes
MCP, pour Model Context Protocol, permet à un programme de découvrir et d'appeler des outils exposés par un autre service. Le client est le programme qui initie la connexion; le serveur est celui qui rend les outils disponibles. Dans cette mise à jour, Activepieces agit en tant que client. La connexion dans le sens inverse, où un assistant externe utilise les outils qu'Activepieces expose via son propre serveur MCP, est une fonctionnalité distincte.
Pour bien saisir la différence, il faut partir du type d'action qu'exige le flux. Avec un service MCP, l'automatisation appelle une fonction déclarée par le serveur, par exemple une recherche dans une base documentaire. Un projet comme agent-desktop de Vercel Labs traite un autre cas: interagir avec l'interface d'une application. Dans la version d'Activepieces, l'enjeu est l'accès à des outils déjà exposés par un serveur, sans passer par l'interface du service à chaque opération.
De l’adresse au consentement
La proposition sur GitHub identifie un obstacle précis. Certains serveurs exigent OAuth mais ne fournissent pas à l'utilisateur un identifiant et un secret à copier dans la configuration du client. Activepieces a ajouté la découverte automatique des métadonnées d'autorisation pour couvrir ce cas. Si les informations nécessaires sont disponibles, l'adresse du serveur est la seule donnée que le contributeur a dû saisir manuellement dans le test documenté.
Le bouton de connexion ouvre une fenêtre d'autorisation. L'utilisateur peut y accorder l'accès; selon la spécification MCP, le client utilise un jeton pour les requêtes adressées au service protégé. Séparer l'identité qui émet la requête des fonctions que le service autorise est une bonne pratique. Dans le cas du Gemini agent, l'identité opérationnelle et le périmètre des permissions sont eux aussi deux aspects distincts. Une connexion moins complexe à configurer laisse néanmoins ouverte la question des fonctions à autoriser.
Lire et modifier sont des permissions différentes
Prenons un flux qui recherche un document pour répondre à une question interne. Pour accomplir cette tâche, il a besoin d'accéder en lecture aux contenus pertinents. La possibilité de modifier ou de supprimer des documents changerait la portée de la connexion, même si la procédure de configuration était identique. La spécification MCP permet aux serveurs d'indiquer les périmètres d'autorisation: ce que l'on peut demander et obtenir dépend de la configuration du service.
Une façon d'évaluer la mise à jour consiste à comparer la tâche du flux avec les outils disponibles après le consentement. Dans les tests où Anthropic a restreint l'accès à Internet, les outils accordés constituaient une variable concrète du comportement observé. Le contexte d'Activepieces est différent. La question opérationnelle reste la même: si l'automatisation prend une initiative inattendue, quelles opérations peut-elle réellement exécuter? La réponse dépend aussi des contrôles du service, au-delà des instructions données à l'agent.
Le test documente un cas compatible
Dans le test local avec Aleph, le contributeur a montré la sélection d'OAuth 2.0, l'ouverture de la fenêtre d'autorisation, puis la découverte et l'appel des outils. Le test documente ce parcours avec un service spécifique. Les notes de version ne fournissent pas de liste de serveurs vérifiés ni de données sur les délais de configuration dans des environnements différents. Une organisation peut donc reproduire ce cas d'usage sur ses propres serveurs, y compris ceux qui requièrent des étapes d'enregistrement ou des paramètres supplémentaires.
C'est la distinction qui compte aussi lorsqu'on lit la documentation d'autres outils. Dans le prototype d'agent pour GitHub et Feishu, le point de départ est constitué par les intégrations déclarées par le projet. Ici, le logiciel est distribué dans une version publique, tandis que le comportement de la connexion reste lié au service à connecter. Pour ceux qui gèrent plusieurs flux, l'information la plus utile est de savoir quels endpoints atteignent la configuration dès le premier usage, sans étapes manuelles supplémentaires.
Deno devient le défaut pour les étapes de code
Le changelog d'Activepieces indique que les étapes de code passent à Deno comme environnement d'exécution par défaut. Cette modification concerne le point où un flux exécute du code personnalisé. Elle peut avoir de l'importance même pour ceux qui n'utilisent pas MCP: le changement de défaut est une raison de vérifier les scripts indépendamment des connexions configurées. Les notes mentionnent également une adaptation pour faire fonctionner sous Deno du code CommonJS préexistant; elles ne publient pas de vérification exhaustive de tous les scripts des utilisateurs.
Pour ceux qui gèrent l'installation, une démarche raisonnable est d'exécuter les flux les plus utilisés dans un environnement de test et de comparer les résultats. Il convient d'observer les imports, les dépendances et la façon dont les erreurs remontent. Ce sont des contrôles sur le logiciel qui exécute le flux, distincts du choix du modèle qui pilote un agent. Un résultat différent après la mise à jour doit être rattaché à l'étape qui le produit, avant de l'attribuer au modèle ou à la connexion.
Activepieces 0.93.0
- Confirmé: version du 8 novembre avec OAuth 2.0 dans le client MCP et Deno comme défaut pour les étapes de code.
- Non précisé: une liste complète des serveurs compatibles.
- À surveiller: le comportement des flux en production et les permissions effectivement accordées par les nouvelles connexions.
Lecture d’ensemble
L'avantage de cette version se mesure au moment où une connexion devient réutilisable. Celui qui crée un flux peut partir de l'adresse d'un serveur compatible et l'autoriser; celui qui gère le service conserve la responsabilité de décider quels outils exposer. Cette distinction prend encore plus de poids lorsque les agents travaillent en arrière-plan, car une connexion peut être rappelée bien après la première interaction qui l'a configurée.
Les prochains retours utiles sont concrets: connexions réussies avec des serveurs autres que celui du test, renouvellement et révocation des autorisations dans les conditions d'usage réelles, et résultats cohérents des scripts après le changement de runtime. Ces éléments permettraient de mesurer la part du travail de configuration réellement éliminée. Pour les utilisateurs d'Activepieces, le test le plus révélateur reste leur propre flux: il doit obtenir les données dont il a besoin et conserver le périmètre d'accès prévu.
