Maven Apps : vos agents ont besoin d'opérateurs, pas de tableaux de commande

Un tableau de commutation fait exactement ce pour quoi il a été câblé : vous actionnez l'interrupteur, vous obtenez la même réponse figée, à chaque fois. Demandez-lui de traiter quoi que ce soit en dehors de ce circuit et il en est incapable, car il ne gère pas la variabilité, seulement le câblage.

Un opérateur, c'est autre chose. Donnez-lui une demande, « passez-moi la réception », et il trouve comment faire : quelle ligne utiliser, que faire si elle est occupée, que faire si la demande elle-même était ambiguë. Il ne se contente pas de transmettre le signal ; il l'interprète et agit en conséquence.

Les Maven Apps sont des opérateurs, pas des tableaux de commutation. Lorsque nous avons conçu le framework qui fait tourner notre infrastructure d'Apps, nous avons fait un pari délibéré : ne pas construire une couche d'intégration de plus. Construire une véritable plateforme applicative, sur laquelle les agents IA sont des citoyens de premier rang.

Aujourd'hui, des milliers d'apps tournent sur notre framework. Oui, on y trouve des apps pour les grands systèmes tiers comme Salesforce, Zendesk et Notion. Mais aussi des centaines d'apps sur mesure en production sur des agents en service.

Pourquoi les intégrations basiques ne suffisent pas

Demandez à dix éditeurs ce que signifie « s'intègre avec Salesforce » pour leur produit, et vous obtiendrez dix réponses différentes, car un système comme Salesforce, Zendesk ou Front n'est jamais une seule chose. Ce peut être :

• Un endroit où votre agent doit aller chercher de l'information (une base de connaissances, un historique de dossiers)
• Un endroit où votre agent doit aller agir (créer un ticket, mettre à jour un enregistrement, effectuer un remboursement)
• Une interface où votre agent doit être présent (un copilote d'assistance intégré à la console dans laquelle votre équipe support travaille déjà)

Une « intégration Salesforce » qui ne connaît que les articles n'est pas le même produit qu'une intégration capable aussi d'ouvrir un dossier, ni que celle qui peut s'installer dans la console agent en tant que copilote. Ces réalités sont souvent regroupées sous un même terme marketing, et c'est pendant le déploiement que vous découvrez les manques.

C'est le problème du distributeur automatique : un menu figé qui fonctionne exactement comme annoncé, jusqu'au jour où ce dont vous avez besoin n'y figure pas, et à ce moment-là vous êtes déjà engagé. Nous ne voulions pas que les Maven Apps fonctionnent ainsi. Nous avons donc construit le framework autour de la vraie question posée (connaissance, capacité ou canal) plutôt qu'autour d'un « connecteur » générique.

Maven Apps : bien plus que des intégrations

Les Maven Apps peuvent prendre de nombreuses formes, mais la plupart reposent sur quelques modèles communs. Quelques exemples de ce que les apps peuvent faire :

• Les apps de connaissance lisent et indexent le contenu d'un système externe pour que l'agent puisse s'en servir pour répondre : en lecture seule, versionné, étiquetable par audience.
• Les apps de capacité permettent à l'agent d'agir réellement dans ce système : un véritable appel d'API, enchaîné dans un workflow en plusieurs étapes (rechercher la commande, vérifier la politique de retour, effectuer le remboursement, le confirmer au client), le tout au sein d'une seule conversation. Là où un distributeur de billets exécute une transaction scriptée à partir d'un menu figé, une app de capacité se comporte plutôt comme un conseiller bancaire : elle reçoit un objectif, pas une option de menu, et fait le nécessaire pour l'atteindre, y compris gérer l'exception.
• Les apps de canal placent l'agent là où se trouvent déjà vos clients ou votre équipe support : un widget intégré, un appel téléphonique, une boîte de réception ou un panneau de copilote dans la console que vos agents utilisent au quotidien.

Une app prête à l'emploi de notre catalogue s'installe généralement en quelques minutes. Lorsque le système d'un client n'y figure pas, c'est le même framework, le même SDK, les mêmes hooks de cycle de vie et le même modèle de sécurité qu'un développeur utilise pour en créer une sur mesure.

Il n'existe pas de version « entreprise » distincte du framework réservée à nos ingénieurs ; App Studio, notre plateforme de développement d'apps, repose sur une architecture identique. Du vrai TypeScript, un vrai SDK (@mavenagi/mavenagi) et un vrai pipeline de déploiement, pas un langage de script propriétaire à apprendre juste pour nous.

Si vous avez déjà développé avec MCP, une Maven App repose sur une idée similaire, entièrement gérée. Un serveur MCP standard implique toujours de le mettre en place, de l'enregistrer, de le maintenir en service et de le faire évoluer vous-même. Une Maven App s'apparente plutôt à un endpoint MCP qui s'enregistre et s'adapte automatiquement à la charge, sans aucune infrastructure à votre charge : vous écrivez la logique, et l'endpoint, l'authentification et l'hébergement sont pris en charge pour vous.

Des Apps conçues pour être puissantes

Une Maven App est une application serverless qui s'exécute dans un environnement sécurisé et isolé, et communique avec la plateforme Maven via un SDK défini. Concrètement :

Elle est multi-tenant. Une app est développée une fois et installée de nombreuses fois, dans différentes organisations et sur différents agents. Chaque installation dispose de son propre contexte (son propre identifiant d'organisation, identifiant d'agent et configuration d'exécution), mais partage le même code sous-jacent. Ainsi, lorsque nous livrons une amélioration de l'app Salesforce, tous les clients qui l'utilisent en profitent, et personne ne reste bloqué sur une version obsolète et bricolée de « son » intégration.

Elle est isolée, pas greffée. Chaque app s'exécute comme une fonction distincte dans un environnement sécurisé, séparée du backend principal de Maven et des apps des autres clients. Votre logique sur mesure ne s'exécute jamais dans un monolithe partagé à côté de celle de quelqu'un d'autre. Les connexions vers vos systèmes de référence peuvent passer par VPN, VPC peering, OIDC ou simple HTTPS avec liste blanche d'adresses IP : c'est vous qui choisissez, pas nous.

Elle réagit à de vrais événements, pas à des calendriers d'interrogation. Au lieu d'une synchronisation nocturne, une app peut implémenter des hooks d'événements appelés triggers : une conversation a été créée, un retour a été reçu, une base de connaissances a été actualisée, et la plateforme notifie l'app dès que l'événement se produit. C'est un modèle différent des outils d'automatisation que vous connaissez peut-être. Un trigger Maven est passif : c'est la plateforme elle-même qui écoute les changements d'état et les transmet à toute app concernée, sans couplage entre l'app à l'origine de l'événement et celle qui y réagit. Concrètement, une app de réponse par e-mail et une app de synchronisation Salesforce totalement distincte peuvent réagir chacune de leur côté au même événement « conversation mise à jour », chacune faisant son travail, sans que l'une sache que l'autre existe.

C'est le même mécanisme de coordination que celui d'une colonie de fourmis. Aucune fourmi ne planifie le comportement de la colonie, et aucune n'envoie de message directement à une autre ; une fourmi modifie quelque chose dans l'environnement partagé (une piste de phéromones) et toutes les autres réagissent à ce changement indépendamment, chacune suivant sa propre règle simple. L'intelligence collective (itinéraires de recherche de nourriture optimisés, répartition de la charge, voire décisions collectives comme le déménagement du nid) en émerge, sans coordinateur central et sans qu'aucune fourmi ne connaisse le plan. Les Maven Apps se coordonnent de la même façon : un événement modifie l'état partagé, et chaque app concernée réagit d'elle-même.

Elle a un véritable cycle de vie. Chaque app implémente un petit ensemble de hooks de cycle de vie :

• preInstall : valide les identifiants et la configuration avant toute mise en service. Si votre clé d'API est erronée, l'installation échoue clairement à ce stade, plutôt qu'en silence trois semaines plus tard.
• postInstall : enregistre les actions de l'app et provisionne les ressources nécessaires une fois l'installation réussie.
• executeAction : exécute le travail réellement demandé par un agent, exposé aux clients sous forme de capacité : rechercher une commande, créer un dossier, effectuer un remboursement, consulter le solde d'un compte.

La plupart des intégrations sont un interrupteur : allumé ou éteint, rien entre les deux. Les nôtres suivent un cycle de vie complet (installation, validation, exécution, désinstallation), plus proche d'une routine qui lit le contexte et s'adapte (vérifier ce qui est ouvert, confirmer ce qui est sûr, puis agir) que d'un interrupteur à deux positions. C'est exactement la rigueur que l'on attend d'un logiciel de production, parce que c'est exactement ce qu'il est.

Apps ou intégrations

Une intégration classique répond à une question étroite, généralement « les données peuvent-elles aller de A à B », et considère que le travail s'arrête là. Une Maven App est conçue pour répondre à une question plus difficile et plus utile : un agent IA peut-il savoir de manière fiable ce qui est vrai dans vos systèmes à l'instant présent, et peut-on lui faire confiance pour agir en votre nom quand il le faut ?

La plupart des plateformes d'entreprise proposent une variante de « développez-le vous-même si nous ne l'avons pas en standard ». Ce qu'elles ne précisent généralement pas, c'est que développer soi-même implique de gérer son propre serveur, sa propre montée en charge, sa propre revue de sécurité, sur sa propre infrastructure. Un simple manque dans le catalogue de connecteurs devient alors une décision de recrutement : obtenez-vous un budget d'ingénierie et d'infrastructure, ou restez-vous limité à ce qui existe déjà ? Avec les Maven Apps, nos clients n'ont pas à choisir la moins mauvaise option. Une app sur mesure que vous ou votre développeur créez s'exécute sur notre infrastructure, avec la même supervision, la même montée en charge et le même niveau de sécurité que toutes les apps prêtes à l'emploi de notre catalogue. Vous écrivez le code ; nous l'exécutons.

C'est aussi pourquoi l'architecture impose des exigences dont un simple webhook n'a jamais à se soucier :

• Des réponses structurées et de taille limitée. Chaque action exécutée par une app renvoie une réponse claire accompagnée de données structurées sur lesquelles l'agent peut raisonner, et non un bloc brut et illimité qu'il devrait interpréter au hasard.
• Une authentification mutuelle et signée. La plateforme signe chaque requête envoyée à une app pour que celle-ci puisse vérifier que c'est bien Maven qui l'appelle, et l'app s'authentifie en retour auprès de la plateforme avec ses propres identifiants. Aucune des deux parties n'a à se fier uniquement au réseau.
• Une configuration validée avant d'arriver en production. Comme preInstall s'exécute avant la mise en service d'une app, un identifiant invalide ou un paramètre manquant est détecté à l'installation, et non la première fois qu'un client en dépend.
• Une véritable infrastructure, pas un simple appel de fonction. Les apps étant de vraies applications, elles peuvent conserver un état réel : un cache, un compteur de débit, une petite base de données, et pas seulement une requête et une réponse sans état. C'est ce qui permet, par exemple, de vérifier si le taux de résolution d'un domaine donné a baissé de plus de 10 % au cours des dernières 24 heures et d'alerter votre équipe le cas échéant. Un simple appel d'API ne peut pas conserver ce type de mémoire. Une vraie application le peut, tout comme une colonie de fourmis garde en mémoire l'emplacement de la nourriture alors qu'aucune fourmi ne le sait individuellement.
• Des données sensibles tenues à l'écart du modèle. Certaines étapes ne devraient jamais passer par une IA. Lorsqu'un client est prêt à acheter le contenu de son panier, l'agent déclenche le paiement de l'app, et l'app collecte les données de paiement et les informations personnelles directement auprès du client via sa propre interface sécurisée. L'agent orchestre le parcours, mais les numéros de carte et autres informations sensibles n'entrent jamais dans la conversation avec l'IA.
• Une seule base de code, tous les clients, un impact isolé. Le multi-tenant permet de livrer correctifs et améliorations une seule fois pour tout le monde, tandis que l'isolation garantit que la logique sur mesure d'un client ne peut jamais affecter celle d'un autre.

Ce que cela change pour vous

Si vous évaluez Maven, voici l'essentiel à retenir : lorsque nous disons qu'un agent peut répondre à une question et agir en conséquence, cela signifie qu'une véritable application se trouve derrière cette action, versionnée, authentifiée, isolée et construite sur le même framework, qu'elle ait été livrée par notre équipe ou par la vôtre. C'est toute la différence entre un agent capable de parler de vos systèmes et un agent réellement connecté à eux.

Nous avons créé les Maven Apps parce que nous pensons que c'est ce que le mot « intégration » aurait toujours dû signifier.