superglue : construire des intégrations à partir de langage naturel, et ce que le dépôt dit vraiment

Le problème visé : la longue traîne des systèmes d'entreprise

Le README ne présente pas superglue comme un énième connecteur SaaS, mais comme un outil qui apprend le fonctionnement de vos systèmes à partir des connaissances de votre entreprise. La cible annoncée est double. D'un côté les projets d'implémentation lourds : NetSuite, Sage Intacct, SAP, Business Central, Acumatica. De l'autre, l'exposition de systèmes internes à des plateformes d'IA comme Claude, avec la mention d'un accès aux données gouverné et d'un suivi de l'usage. Le tableau d'exemples du dépôt oppose deux colonnes. Sans superglue : transformations Excel manuelles, dizaines d'itérations de nettoyage sur un historique de grand livre, 140 heures sur un projet, un connecteur à maintenir par CRM ou par outil de ticketing. Avec superglue : une cartographie décrite en langage courant, 185 comptes migrés en moins d'une heure, une couche d'intégration unique. Ces chiffres viennent du README et de lui seul. Ils ne sont accompagnés d'aucun protocole de mesure, d'aucune taille d'échantillon, d'aucune définition de ce qu'est un compte migré. À prendre comme une revendication commerciale, pas comme un résultat reproductible.

Ce que le dépôt laisse voir de l'architecture

La description du dépôt parle de construire des intégrations et des outils à partir de langage naturel, avec des thèmes qui cadrent le périmètre : agentic-workflows, function-calling, mcp, oauth2, api-gateway, api-orchestration, etl-automation, transformations. Le README ajoute que superglue fonctionne avec tout système REST, GraphQL, SOAP, fichier ou base de données. Autrement dit, la couche d'agents se place au-dessus de protocoles existants plutôt que d'imposer un format propriétaire. Le projet est en TypeScript, ce qui situe le cœur du code côté Node. Au-delà de ces éléments, le README ne décrit ni le pipeline interne, ni la façon dont les schémas sont inférés, ni comment les identifiants OAuth sont stockés. Le topic mcp suggère une intégration avec le Model Context Protocol, mais aucun détail d'implémentation n'apparaît dans le matériel fourni. C'est une lacune du README, pas nécessairement du projet : la documentation externe est renvoyée vers docs.superglue.cloud, que je n'ai pas consultée. Toute équipe qui doit valider un modèle de menace sur les jetons OAuth devra aller chercher cette information ailleurs.

Mise en route : deux chemins, peu de détails dans le dépôt

Le Quick Start propose deux options. La première consiste à créer un compte sur app.superglue.cloud et à commencer immédiatement. La seconde est l'auto-hébergement, présenté comme la voie du contrôle et de la personnalisation, avec un renvoi vers docs.superglue.cloud/getting-started/setup#self-hosted. Le README lui-même ne contient aucune commande d'installation, aucun fichier de configuration, aucune variable d'environnement. C'est un point à connaître avant de cloner le dépôt en espérant un docker run copié depuis la page d'accueil : il n'y est pas. Les seuls éléments concrets fournis sont les badges. Un paquet client publié sur npm sous le nom @superglue/client, donc installable via npm, et une image Docker publiée sous superglueai/superglue sur Docker Hub. Ces deux artefacts indiquent la forme de l'intégration : un SDK pour piloter la plateforme depuis du code Node, et un conteneur pour l'exécuter vous-même. Pour les commandes exactes, les clés de configuration et les prérequis, il faut passer par la documentation, ce que le dépôt ne remplace pas.

La licence FSL, contrainte structurante du projet

Le README indique que superglue est sous licence FSL, tandis que les SDK clients sont sous MIT. Le champ license du dépôt renvoie NOASSERTION, ce qui signifie que l'outil d'analyse de GitHub n'a pas su rattacher automatiquement le texte à un identifiant SPDX reconnu. Ce n'est pas anodin : la FSL (Functional Source License) est une licence source-available avec des restrictions d'usage concurrentiel, et non une licence open source au sens de l'OSI. Le README renvoie au fichier LICENSE pour les détails, et je ne les ai pas lus. Concrètement, pour une équipe, la question n'est pas théorique. Si vous construisez un produit qui concurrence superglue, la licence peut vous bloquer. Si vous l'utilisez en interne pour migrer votre ERP, la situation est différente, mais c'est le texte du LICENSE qui tranche, pas cette lecture. Le CLA mentionné dans la section Contributing ajoute une deuxième couche : les contributions passent par un accord de licence contributeur, ce qui donne au projet des droits plus larges sur le code reçu. Un contributeur individuel doit lire ce document avant d'ouvrir une pull request.

Là où l'outil n'est pas le bon choix

Le README promet une couche unique pour des dizaines de systèmes. C'est aussi la source de sa principale faiblesse potentielle. Un moteur d'agents qui génère des connecteurs à partir de langage naturel introduit une dépendance à la qualité de la description et à la stabilité du modèle sous-jacent. Pour deux endpoints REST qui ne changeront pas pendant trois ans, écrire un client typé à la main reste plus simple à auditer et à déboguer qu'une chaîne d'agents. Le tableau d'exemples insiste sur le volume et la diversité : plusieurs CRM, plusieurs notetakers, plusieurs outils de ticketing, des flux universitaires entre CRM, fundraising et bases de données. C'est précisément le régime où la génération automatique paie. À l'inverse, une petite équipe avec trois intégrations stables n'a aucune raison d'ajouter cette couche. Autre limite visible : le README ne dit rien sur le comportement en cas d'échec partiel d'une migration, ni sur la reprise après erreur, ni sur la journalisation. Pour un projet d'implémentation ERP, ces sujets comptent davantage que la liste des systèmes supportés.

Face à un outil iPaaS classique, la différence de méthode

Un iPaaS traditionnel comme ceux du marché fonctionne par connecteurs prédéfinis et par un éditeur visuel de flux : vous assemblez des briques documentées, avec des schémas connus à l'avance. superglue prend le chemin inverse. Le README parle d'agents qui apprennent le fonctionnement de vos systèmes à partir des connaissances de l'entreprise, et qui réalisent l'implémentation à votre place. La différence pratique est nette sur la longue traîne. Avec un iPaaS, un système absent du catalogue se traite par du code custom ou par une passerelle HTTP générique. Avec superglue, la promesse est que la description en langage courant suffit à produire le connecteur, ce qui abaisse le coût marginal d'un système de plus. Le revers est symétrique. Un connecteur prédéfini est testé, versionné, documenté par l'éditeur. Un connecteur généré doit être validé par vous, et sa stabilité dépend d'un composant probabiliste. Le README ne fournit aucun élément sur la façon dont les connecteurs générés sont versionnés ou revus, ce qui est exactement le point qu'un intégrateur voudra creuser avant de s'engager.

Maintenance, mises à jour et coût de suivi

Le dépôt n'a pas de release publiée dans les informations fournies, et le dernier push sur main date du 19 août 2026. Un dépôt actif sans release taguée signifie que le suivi se fait sur la branche principale, avec ce que cela implique : pas de notes de version pour annoncer les ruptures, pas de point d'ancrage clair pour épingler une version. Pour un auto-hébergement en production, c'est une contrainte réelle. Vous devrez choisir un commit, le tester, et gérer vous-même la comparaison avec les commits suivants. Le paquet @superglue/client sur npm apporte un peu de structure côté SDK, mais rien n'indique dans le matériel fourni comment les versions du client et du serveur sont alignées. La contribution, enfin, est encadrée : lire CONTRIBUTING.md et signer le CLA avant toute pull request. Ce n'est pas un détail administratif, c'est ce qui conditionne votre capacité à faire remonter un correctif si vous tombez sur un bug dans un connecteur généré.

Conclusion éditoriale

superglue vise les équipes qui doivent brancher des systèmes d'entreprise hétérogènes (Sage Intacct, NetSuite, SAP, Dynamics 365) ou exposer des données gouvernées à des agents IA, et qui acceptent de dépendre d'un moteur d'agents pour générer et maintenir ces connecteurs. Une équipe qui a besoin de deux appels REST stables n'a rien à y gagner. Avant de vous engager, vérifiez la licence FSL dans le fichier LICENSE, les conditions du CLA dans CONTRIBUTING.md, et le contenu réel de la documentation self-host sur docs.superglue.cloud.

Sources officielles

1. Issues
2. Project website
3. README
4. superglue-ai/superglue on GitHub