Comment MoEngage a transformé plus de 400 API en outils pour agents avec AgentCore Gateway
MoEngage, la plateforme d'engagement client utilisée par plus de 1 350 marques grand public pour envoyer des messages personnalisés par push, e-mail, in-app, SMS, WhatsApp et RCS, a transformé plus de 400 API internes en outils utilisables par des agents IA grâce à AgentCore Gateway, une brique d'Amazon Bedrock AgentCore. Ces API REST, conçues par 25 équipes d'ingénierie, tournent dans des clouds privés virtuels (VPC) répartis sur sept régions AWS, isolées pour respecter les engagements de résidence des données, et ne sont exposées à aucun point d'accès public. Selon l'entreprise, l'approche a permis d'économiser environ six mois d'ingénierie de plateforme. L'intégration d'une nouvelle API prend désormais quelques heures au lieu de plusieurs jours. Aucune équipe produit n'a écrit de code de serveur MCP (Model Context Protocol), aucun réseau n'a été provisionné par intégration, et aucun endpoint public n'existe sur le chemin des appels.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu dépasse le cas de MoEngage. Quand une entreprise lance des agents IA, les capacités nécessaires (création de campagnes, requêtes de segments, statistiques de livraison) existent presque toujours déjà sous forme d'API internes. La difficulté est de les rendre accessibles aux agents sans les exposer sur Internet, sans laisser les modèles décider de l'identité utilisée et sans saturer la fenêtre de contexte avec des centaines de définitions d'outils. MoEngage a écarté la solution la plus directe, qui aurait consisté à faire déployer par chaque équipe son propre serveur MCP. Plus de vingt serveurs auraient exigé autant de déploiements à surveiller, corriger et maintenir compatibles avec l'évolution du protocole. Les agents transverses, par exemple ceux qui lisent une campagne, vérifient son segment et analysent ses statistiques, auraient dû se connecter à plusieurs serveurs et en réconcilier les réponses. Chaque équipe aurait en outre dû acquérir une expertise MCP sans rapport avec son produit.
L'entreprise a donc posé un principe: les équipes produit ne font pas de MCP. Elles construisent des API REST et déclarent quelles opérations deviennent des outils, leur responsabilité s'arrêtant à une spécification OpenAPI bien décrite, tandis que l'équipe AI Platform gère toute la couche MCP. Ce principe impose trois exigences: une surface d'outils centrale à laquelle les agents se connectent une seule fois, une autorisation par agent appliquée côté serveur plutôt que par convention, et une connectivité privée qui n'a pas à être reconstruite à chaque nouvelle API. Développer un serveur MCP central sur mesure aurait résolu le problème des vingt serveurs, mais obligé MoEngage à construire un pipeline de génération d'outils, un format de fichier de politiques, un registre d'alias pour les renommages et des disjoncteurs, soit un travail sans valeur différenciante. L'entreprise a aussi fixé quatre contraintes à satisfaire simultanément, dont la première est qu'aucune API n'obtient de point d'accès public, même protégé par une authentification supplémentaire. Les contournements classiques (passerelle NAT, proxy inverse, tunnel VPN) se multiplieraient par sept régions et feraient croître la surface opérationnelle plus vite que le nombre d'agents, chaque API supplémentaire appelant une nouvelle demande de modification réseau et une nouvelle revue de sécurité.
Pas d'impact direct sur la France/UE