Postman déploie son Agent Mode auprès de 40 millions de développeurs grâce à Amazon Bedrock
Postman a détaillé l'architecture d'Agent Mode, son assistant d'IA natif, conçu avec AWS pour les 40 millions de développeurs de la plateforme. L'outil permet de travailler sur les tests d'API, la documentation, la découverte et l'implémentation sans naviguer dans l'interface. Il s'appuie sur Amazon Bedrock, qui fournit un accès géré aux modèles de fondation. Postman peut ainsi absorber une demande mondiale variable, sensible à la latence et marquée par de fortes pointes, sans exploiter sa propre infrastructure d'inférence. L'entreprise garde la main sur le choix des modèles, le débit, la localisation géographique du traitement et les coûts. Le contrôle humain fait partie du dispositif : toute action qui modifie l'état de l'application exige l'approbation de l'utilisateur, et les outils disponibles sont limités à la tâche en cours. Amazon Bedrock Guardrails sert à masquer les informations personnelles identifiables avant qu'elles n'atteignent le modèle. Les administrateurs d'entreprise peuvent activer cette option dans les paramètres. Les modèles pris en charge bénéficient aussi de réglages de rétention des données, de l'inférence interrégionale à périmètre géographique défini et d'un cache de prompts à plusieurs niveaux. Le premier choix de conception a été de multiplier des outils très atomiques, comme ouvrir une requête, modifier un champ ou récupérer une métadonnée. Cette approche a vite montré ses limites.
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 →
Le point central est que le plus difficile n'était ni la qualité du modèle ni la rédaction des prompts, contrairement à ce que l'équipe attendait. Les enjeux étaient d'intégrer un agent à un produit mature et de rendre cet ensemble lisible pour lui. Les workflows réels exigent de longues séquences d'appels, et chaque étape doit repasser par le modèle avant la suivante. Même si chaque appel est rapide, l'expérience paraît lente, et l'utilisateur regarde l'agent détailler des gestes qu'il perçoit comme une seule opération. Postman en tire trois principes : contrôler la prolifération des outils, exposer des lectures fondées sur des schémas, et considérer que le contexte, plutôt que la capacité du modèle, est le principal goulot d'étranglement. Pour les équipes qui veulent passer d'un prototype à un agent en production, la leçon est que la réussite dépend moins du modèle que de la façon de présenter le produit à l'agent. Un agent doit aussi être testé et surveillé en continu, car les garde-fous réduisent les actions non voulues et l'exposition inutile de données sans les éliminer.
Ces difficultés viennent de l'histoire du produit. Postman existe depuis onze ans, et ses utilisateurs ont appris à trouver l'information par l'interface, en déployant des barres latérales, en consultant des onglets et en ouvrant des requêtes. Ce savoir implicite, réparti entre l'interface, les API et la façon dont la connaissance du produit est distribuée, ne se transmet pas tel quel à un agent, qui raisonne sur des données et non sur un écran. Rendre ces hypothèses explicites a obligé l'équipe à revoir des choix structurels anciens. Le cas illustre une tendance plus large : les éditeurs de logiciels établis ajoutent des agents à des produits conçus pour des humains qui naviguent visuellement. AWS y voit une vitrine pour Bedrock, en concurrence avec les accès directs aux modèles proposés par les autres grands fournisseurs de cloud. La suite de la série d'articles de Postman et d'AWS doit détailler les composants de l'architecture, de la gestion du contexte à la mise en cache des prompts.
Pas d'impact direct sur la France/UE