Forter est parvenue à faire participer environ 200 personnes à la création d’agents d’IA lors d’un sprint pratique de deux semaines, après avoir conçu un environnement réduisant le besoin d’expertise en programmation et permettant aux analystes comme aux ingénieurs d’expérimenter rapidement leurs idées. Ben Maraney, ingénieur principal de l’entreprise, présente cette expérience comme une leçon sur l’élimination de la complexité inutile, plutôt que comme une tentative de résoudre d’un seul coup tous les défis liés à la création d’agents.
Le début : un sprint pratique avec un délai de cinq semaines
L’objectif était de former les équipes de recherche et développement à la création de leurs propres agents, notamment des analystes issus de formations juridiques, psychologiques et scientifiques, dont certains n’avaient jamais écrit de SQL. L’équipe devait préparer l’environnement en cinq semaines, puis organiser un sprint de création de deux semaines. La conception s’est donc concentrée sur trois axes : les outils, les plateformes et la suppression des obstacles pour les utilisateurs.
Un serveur MCP central plutôt que des outils dispersés
Forter s’est appuyée sur un serveur interne fondé sur le protocole MCP, baptisé Toolchain. Le serveur fournissait une interface unique pour découvrir et tester les outils, ainsi que pour créer les connexions propres à chaque agent. Il permettait également à l’utilisateur de sélectionner uniquement les outils dont l’agent avait besoin, plutôt que de lui accorder un accès étendu susceptible de le perturber ou de l’amener à utiliser des outils inadaptés.
Le nombre d’outils est passé d’environ 20 lors de la création de l’équipe à près de 60 au début du sprint, puis à presque 100 deux semaines après sa fin. L’unification du dépôt, ainsi que la présence d’exemples et de fichiers de configuration clairs, ont facilité l’ajout rapide de nouveaux outils, tout en fournissant des capacités de gouvernance telles que le suivi de la consommation de jetons et de l’utilisation des outils.
Plutôt que de construire en peu de temps un système personnalisé de génération augmentée par récupération (RAG), l’entreprise a relié Toolchain à la plateforme Glean, utilisée pour effectuer des recherches dans des sources internes telles que Confluence, Asana, Jira, Slack et Salesforce. Elle a proposé trois types d’outils : rechercher des documents et des extraits pertinents, lire un document dans son intégralité et le résumer selon une question ou un axe défini par l’agent.
D’une plateforme sans programmation à des solutions personnalisables
Forter a utilisé LibreChat pour fournir une expérience conversationnelle rapide nécessitant peu de programmation. Les utilisateurs pouvaient voir les outils appelés par l’agent, les requêtes et les paramètres qu’il envoyait, ainsi que les résultats qu’il recevait. Cela a aidé à comprendre le comportement des agents et à détecter rapidement les problèmes, même si l’intégration de MCP était parfois instable, avec un contrôle limité des versions et de la personnalisation.
Pour les cas plus complexes, l’entreprise a fourni des dépôts modèles donnant aux développeurs un contrôle total du code et permettant d’ajouter des outils et des sous-agents, mais leur configuration et leur déploiement étaient plus lents, en particulier pour les analystes. Forter a ensuite créé une interface interne appelée AI Hub, qui permet de choisir le modèle, de rédiger le message système, de définir les outils, puis de partager l’agent en quelques étapes.
Pour les agents non interactifs, l’entreprise a utilisé le framework Strands avec Argo Workflows afin de les exécuter selon des calendriers ou des événements tels que la création de tickets Jira et Asana. Maraney souligne que l’existence d’un système de planification et d’exécution déjà en place peut rendre inutile la création d’une nouvelle architecture spécifique aux agents.
Qu’a-t-on réellement construit ?
Les usages comprenaient des agents aidant les analystes à formuler de meilleures hypothèses et expériences, à examiner les rapports postérieurs aux incidents et à analyser la baisse des performances des marchands à l’aide de Snowflake et des notebooks Databricks. L’entreprise a également développé des agents experts tels que Layla et Penny pour accéder au code, aux configurations et aux données, et répondre à des questions concernant les décisions relatives aux transactions et à la facturation. L’utilisation de Layla s’est étendue aux équipes chargées de la réussite client et du support, après que ses connaissances du système sont devenues plus vastes que celles de n’importe quel individu.
Parmi les exemples d’agents non interactifs figuraient la suggestion de configurations initiales pour un nouveau marchand à partir de marchands similaires, la préparation de recherches préliminaires à la réception d’un ticket de support, ainsi que l’analyse des alertes de cas anormaux et leur mise en relation avec des modifications du code. Forter a également testé un agent de réponse aux incidents, mais a découvert que ses résultats apparemment excellents reposaient principalement sur la copie d’analyses des causes profondes rédigées auparavant par des humains dans des rapports BetterNext.
Qu’est-ce qui change concrètement ?
Cette expérience montre que l’observabilité n’est pas une fonctionnalité secondaire. Le fait d’afficher les outils, les paramètres et les résultats sur lesquels l’agent s’appuie était essentiel pour découvrir que l’agent de réponse aux incidents ne déduisait pas réellement la cause profonde. Forter a donc ajouté par la suite Langfuse afin de suivre les sessions des agents, les appels d’outils et le déroulement du travail.
L’expérience montre également que la multiplicité des plateformes peut être intentionnelle : une plateforme sans programmation pour l’expérimentation rapide, des solutions logicielles pour la personnalisation, et des agents fonctionnant selon des événements ou des calendriers. En revanche, l’entreprise a rencontré des difficultés avec le modèle consistant à créer un dépôt distinct pour chaque agent, puis est revenue à un nombre réduit de dépôts regroupant des agents liés, afin de faciliter l’introduction de capacités partagées telles que le suivi.
Maraney avertit également que les indicateurs d’évaluation généraux, tels que la pertinence, la cohérence et la sécurité, peuvent donner une fausse impression de qualité. Une évaluation utile doit tester l’exactitude de la réponse, l’utilisation des outils appropriés et la récupération du contexte correct, autant d’éléments plus difficiles qui nécessitent de savoir précisément ce qu’est une bonne réponse. Les évaluations avancées peuvent donc être différées dans les expérimentations internes où l’humain reste intégré à la boucle de prise de décision, mais cela ne doit pas être considéré comme un substitut permanent à l’évaluation.
Les initiatives d’extension doivent également associer rapidement les équipes juridiques et de sécurité, notamment en ce qui concerne le lieu de traitement et la conservation des données. Maraney indique que l’utilisation d’un service cloud tel qu’Amazon Bedrock, accompagnée de la documentation des politiques de non-conservation des données, a contribué à traiter ces préoccupations dans le cadre des contrôles de l’entreprise, plutôt que de transformer chaque agent en un cas d’approbation distinct.