À mesure que le monde devient de plus en plus agentique, il est essentiel de rejoindre vos utilisateurs là où ils se trouvent, ce qui signifie généralement leur offrir une UX soignée sur les plateformes de communication qu’ils utilisent au quotidien :

  • WhatsApp
  • Email
  • Telegram
  • Discord
  • Slack

Intégrer une expérience chatbot à des interfaces de messagerie, c’est généralement assez simple. Je choisis un client LLM existant, j’ajoute ma clé API, un bon system prompt, et les utilisateurs peuvent discuter. Mais les choses se compliquent rapidement dès que l’agent doit réellement fairequelque chose, surtout quand il doit agir au nom de mes utilisateurs. Soudain, je dois gérer non seulement les interactions avec le LLM, mais aussi les appels d’outils, et l’authentification et l’autorisation liées à chaque outil dont les utilisateurs ont besoin. Tout cela en tenant compte des contraintes UX propres à chaque canal de communication. Difficile à faire évoluer si je veux rejoindre mes utilisateurs partout où ils se trouvent.

Heureusement, Arcade.dev propose une approche agentique qui me permet de déléguer cette complexité à la « couche agentique » et de me concentrer sur l’UX.

J’ai publié une vidéo dans laquelle je refactorise un bot Telegram conçu pour planifier des événements Google Calendar à partir de saisie en langage naturel, propulsé par le LLM rapide de Groq. L’implémentation originale, bien que fonctionnelle, illustre parfaitement la complexité d’une architecture agent « traditionnelle ». En intégrant le client Arcade, j’ai réduit le nombre de lignes (c’est agréable), mais surtout, j’ai supprimé la nécessité de maintenir les intégrations d’authentification et d’API Google pour le bot.

L’« avant » : une petite base de code déjà gagnée par la complexité

La configuration initiale comprend :

  1. Framework du bot Telegram : Gestion des messages entrants et des interactions utilisateurs.
  2. Appels à l’API Groq : Envoi des saisies utilisateur au LLM pour la reconnaissance d’intention et l’extraction d’entités (dates, heures, titres d’événements).
  3. API Google Calendar : La vraie bête. Elle nécessitait :
    • Implémenter le flux OAuth 2.0 complet pour obtenir les permissions utilisateurs.
    • Stocker de façon sécurisée les tokens d’accès et de rafraîchissement.
    • Gérer l’expiration des tokens et la logique de rafraîchissement.
    • Effectuer des appels API soigneusement construits pour lister les calendriers, vérifier les disponibilités et créer des événements.
    • Parser les réponses souvent complexes de l’API Google.

Chaque brique est gérable séparément, mais les assembler peut fragiliser l’ensemble au fur et à mesure que le système se complexifie. L’authentification, notamment, est une source constante de bugs potentiels et de problèmes de sécurité. Le débogage implique de tracer les appels à travers plusieurs services. Et adapter tout ça pour Slack ou WhatsApp ? C’est là que la scalabilité du produit devient un vrai problème.

C’est une petite base de code, et pourtant la complexité architecturaleest déjà élevée, surtout si l’on prévoit de supporter davantage de plateformes.

L’« après » : une architecture recentrée

En surface, les changements ne semblent pas spectaculaires :

const authArcade = async (chatId: number): Promise<{ logged_in: boolean, url: string }> => {
    const authResponse = await arcade.auth.start(
        chatId.toString(),
        "google",
        {
            scopes: ["https://www.googleapis.com/auth/calendar.readonly", "https://www.googleapis.com/auth/userinfo.email"],
        }
    )
    if (authResponse.status !== "completed") {
        return { logged_in: false, url: authResponse.url || "ERROR: No URL returned" };
    }
    return { logged_in: true, url: "" };
}

(oui, c’est toute l’authentification)

Les résultats : bien plus que quelques lignes en moins

Oui, le nombre de lignes a baissé, ce qui est toujours satisfaisant. Mais le vrai gain, c’est la réduction de la complexité :

  1. Architecture simplifiée : Toute la charge liée à OAuth et aux interactions directes avec l’API Google Calendar a disparu, abstraite par le client Arcade.
  2. Maintenabilité améliorée : La logique centrale du bot est maintenant bien plus claire et lisible. Le débogage est simplifié, car les interactions avec les outils externes passent par une interface unique et cohérente. Le mainteneur peut se concentrer sur l’amélioration de l’UX de cette plateforme sans craindre de casser l’authentification ou les appels d’outils de l’agent.
  3. Extensibilité sans effort : C’est énorme. Vous voulez ajouter Slack ? Ou WhatsApp ? La logique qui interagit avec Groq et Google Calendar via le client Arcade n’a pas besoin de changer. Il suffit de gérer les entrées/sorties de messages pour la nouvelle plateforme. Arcade fournit le pont stable vers les outils, quel que soit le frontend.

Conclusion : concentrez-vous sur la valeur, pas sur la plomberie

En remplaçant la gestion bespoke de l’API et de l’authentification par le client Arcade.dev, j’ai transformé le code original en quelque chose de plus fluide et adaptable, moins sujet à la dérive vers la complexité. Cela m’a permis de me concentrer sur la valeur centrale de l’agent (comprendre les demandes des utilisateurs et interagir avec leur calendrier), plutôt que de me perdre dans la plomberie des intégrations de services externes.

Vous pouvez tester le bot vous-même en créant un compte Arcade, puis en clonant le dépôt. Bonne construction !