Le passage en production des agents IA est un sérieux défi pour les responsables IT. Pour les aider, Google vient de présenter Agent Executor. Ce runtime open source est capable de prendre en charge les workflows d'agents de longue durée et distribués. En général, ces tâches s’exécutent sur des périodes pouvant aller de quelques minutes à plusieurs jours. Elles impliquent souvent plusieurs étapes, des interactions avec le SI, des pauses pour une intervention humaine ou la reprise après des interruptions avant d'aboutir à leur achèvement. « Pour ce genre de worklow, le runtime inclut le support de l’exécution dans la durée afin d’assurer une reprise des workflows après des pannes ou des validations humaines, ainsi qu’un sandboxing sécurisé pour isoler les composants des agents, des contrôles de cohérence des sessions pour les workflows distribués, et des fonctionnalités de rétablissement de connexion destinées à préserver l’état d’exécution lors d’interruptions réseau », souligne Google dans un article de blog.
Le moteur prend également en charge la « ramification de trajectoire », qui permet aux développeurs de tester d'autres chemins d'exécution à partir de points de contrôle enregistrés sans perdre le contexte précédent, a ajouté la société. « De plus, Agent Executor fait le pont entre plusieurs modèles de déploiement, notamment sur site et des agents préconstruits ou gérés sur mesure », a ajouté le fournisseur, si bien que les utilisateurs peuvent combiner à leur guise tout ou partie d’Antigravity, des agents développés par Google, des agents développés par l’utilisateur et gérés par Google, ainsi que des agents personnalisés et des agents utilisant le protocole Agent2Agent (A2A).
Combler les lacunes de fiabilité en production
Les analystes et les experts voient dans les capacités d’Agent Executor un intérêt tant pour les développeurs que pour les entreprises. « La durabilité, l’orchestration et la reprise sont les véritables obstacles pour tout agent de production d’entreprise », a déclaré Advait Patel, ingénieur senior en fiabilité (SRE) chez Broadcom. « Ce qui freine l’adoption par les entreprises, ce sont les agents qui perdent leur état lors du redémarrage d’un pod, les sessions qui se corrompent lors d’écritures simultanées, ou les workflows de longue durée qui ne peuvent pas se remettre d’un incident réseau. Une fois que l’agent effectue des actions sur des systèmes réels, on ne peut pas se permettre qu’il oublie ce qu’il a fait à mi-chemin », a-t-il souligné. « Le journal des événements, la création d’instantanés, le modèle à auteur unique et la reprise de connexion dans Agent Executor correspondent exactement à ce que les équipes SRE ont dû bricoler tant bien que mal au cours de l’année écoulée », a fait remarquer M. Patel, ajoutant que les frameworks existants tels que LangChain et AutoGen sont parfaits pour le prototypage, mais qu’ils échouent le plus souvent en production dès que les agents fonctionnent pendant des heures ou des jours.
Gaurav Dewan, directeur de recherche chez Avasant, estime pour sa part que pour les DSI, les mesures de sécurité opérationnelles du runtime, telles que le sandboxing sécurisé et les points de contrôle, pourraient s’avérer tout aussi importantes pour l’analyse des incidents et l’auditabilité. Il pense cependant que les capacités du runtime ne suffisent pas à elles seules à résoudre les défis plus larges de gouvernance et de supervision auxquels les DSI continuent de faire face dans le cadre des déploiements IA en entreprise. « Des questions de responsabilité, d’explicabilité des décisions des agents, d’application des politiques et de sécurité des accès entre les systèmes interconnectés sont encore en pleine évolution », a-t-il souligné. « Par conséquent, si les environnements d’exécution distribués peuvent renforcer l’infrastructure opérationnelle des déploiements d’agents, au niveau des DSI, les considérations concernant la confiance, la conformité et le contrôle d’entreprise nécessiteront probablement des couches supplémentaires de gouvernance et de supervision, au-delà de la simple infrastructure d’exécution. »
La couche d’infrastructure comme avantage stratégique
Google n'est toutefois pas le seul à tenter de façonner la couche d'infrastructure émergente destinée aux agents IA d'entreprise. D'autres hyperscalers, tels que Microsoft, avec AutoGen, et AWS, avec Bedrock AgentCore, promeuvent des frameworks ouverts ou interopérables afin d'obtenir un avantage stratégique. « De plus en plus d'éléments indiquent que les hyperscalers convergent vers un modèle combinant des outils ouverts ou interopérables au sommet de la pile avec une monétisation concentrée dans les couches d'infrastructure sous-jacentes », a fait remarquer M. Dewan. « Google, Microsoft et AWS proposent de plus en plus de SDK, de frameworks d'agents et d'outils d'orchestration pour favoriser l'adoption par les développeurs et la croissance de l'écosystème, tout en continuant à générer de la valeur grâce à l'infrastructure de calcul, aux plateformes d'IA gérées, aux services de données et aux capacités d'observabilité », a-t-il ajouté.
Et, selon M. Patel, la stratégie de Google autour d’Agent Executor rappelle la voie suivie par l’hyperscaler avec Kubernetes il y a dix ans qui consistait à « offrir gratuitement le runtime, et stimuler la consommation sur Google Cloud via des services comme Gemini Enterprise Agent Platform et l’API Managed Agents. » Il ajoute encore que « les hyperscalers ont compris que les frameworks d’agents propriétaires ne seront pas adoptés à l’échelle de l’entreprise. La monétisation se trouve dans la consommation cloud, les services gérés et l’inférence de modèles. Les outils qui s’y ajoutent doivent être ouverts, sinon personne ne leur fera confiance. »