Microsoft a rendu Routines généralement disponible dans Foundry Agent Service. Cette fonction transforme une partie de l’infrastructure que les équipes construisent habituellement autour des agents en capacité managée. Un Routine peut lancer un agent une fois à une date donnée, de manière récurrente selon un calendrier ou en réaction à un événement externe. Le déclencheur, l’action, les connexions, l’identité choisie et l’historique d’exécution restent réunis dans le même projet Foundry.
À première vue, il s’agit de planification. Le changement plus important est architectural. Un agent autonome utile a besoin de plus qu’un modèle et des outils : il faut détecter qu’un travail est arrivé, s’authentifier auprès du système concerné, transmettre l’événement, invoquer l’agent et conserver une trace de ce qui s’est passé. Foundry absorbe désormais une partie significative de cette couche opérationnelle.
Trois modes de déclenchement pour les principaux usages
La version GA prend en charge les timers, les exécutions récurrentes et les déclenchements événementiels. Un timer lance une tâche une seule fois dans le futur. Un Routine récurrent convient aux rapports quotidiens, contrôles de conformité ou revues périodiques. Un déclenchement événementiel réagit à une modification dans un système connecté.
Microsoft cite comme premières intégrations les événements liés aux issues GitHub et les nouveaux messages dans des canaux Microsoft Teams. Foundry reçoit l’événement via la connexion configurée, transmet son payload à l’agent et enregistre l’exécution. L’agent peut ensuite raisonner sur l’événement, utiliser ses outils et agir sans qu’un utilisateur ouvre d’abord une conversation.
Cela rapproche deux notions souvent confondues : un agent capable d’exécuter une tâche et un agent réellement automatisé dans un processus métier. Savoir classer une issue ne suffit pas ; il faut encore surveiller GitHub, gérer l’authentification, transporter l’événement et auditer l’exécution. Routines place cette mécanique autour de la configuration de l’agent.
L’identité fait partie de la définition de l’automatisation
Le détail le plus important concerne l’identité. Microsoft indique qu’un Routine peut invoquer l’agent et ses outils avec l’identité du créateur du Routine ou avec l’identité propre de l’agent.
L’identité du créateur conserve les droits délégués de cette personne et convient aux outils configurés avec l’OAuth utilisateur. L’identité de l’agent permet au contraire une exécution indépendante avec les permissions attribuées dans Microsoft Entra.
Ce choix détermine concrètement quelles données une automatisation peut lire et quelles actions elle peut effectuer sans présence humaine. Deux Routines reposant sur le même modèle peuvent donc avoir des frontières d’accès très différentes.
Pour les équipes d’ingénierie, l’identité doit être conçue en même temps que le déclencheur et l’action. Un résumé quotidien peut nécessiter beaucoup de droits en lecture mais aucun droit d’écriture. Un agent de remédiation peut avoir besoin d’un petit ensemble de permissions d’écriture, de validations humaines et d’un journal complet des actions.
Le reminder tool ajoute la continuité du travail
L’annonce décrit également le reminder tool, encore en preview, pour les Hosted Agents qui doivent reprendre une tâche plus tard. Un agent peut démarrer une opération longue, programmer son propre retour et être réinvoqué dans la même conversation afin de vérifier si le travail est terminé.
Ce mécanisme complète les Routines. Un Routine décide quand l’environnement lance l’agent ; un reminder permet à l’agent de décider lui-même qu’il doit revenir plus tard. Ensemble, ils couvrent des scénarios tels que l’attente d’un export, le suivi d’un déploiement ou la reprise après une approbation.
Pour les automatisations avec état, cela réduit le besoin de construire séparément un service de polling et une couche de persistance de contexte.
Analyse Aipolix : le scheduler entre dans le control plane de l’agent
La conséquence la plus importante est que les plateformes d’agents absorbent l’infrastructure auparavant située autour du runtime. Planification, réception des événements, identité, connexions et historique d’exécution convergent vers une même surface de contrôle.
Cette consolidation peut simplifier l’architecture de production : moins de services indépendants à déployer et à surveiller. Elle peut aussi améliorer la gouvernance, puisque l’organisation peut examiner ce qui déclenche l’agent, sous quelle identité il agit et quelles exécutions ont eu lieu.
Mais une architecture plus simple ne supprime pas les questions de fiabilité. Microsoft explique que Foundry met les invocations en file et conserve leurs résultats, mais l’annonce ne détaille pas toutes les garanties de livraison ou les règles de reprise. Avant d’utiliser un Routine pour une action irréversible — suppression de données, changement d’accès ou opération financière — une équipe doit vérifier le comportement précis face aux doublons, retries, échecs partiels et replays.
C’est une frontière opérationnelle importante. Le modèle peut choisir la bonne action et malgré tout produire un mauvais résultat si le même événement est traité deux fois ou si un appel d’outil réussit avant qu’une exécution soit relancée. L’idempotence des outils, le moindre privilège et les validations explicites restent donc des responsabilités de l’application.
Pourquoi la disponibilité générale compte
Routines existait déjà en preview. Le changement matériel n’est donc pas l’apparition de la planification, mais le passage de cette couche d’automatisation à une offre généralement disponible destinée aux usages de production.
Pour les organisations déjà sur Foundry Agent Service, cela peut supprimer une catégorie de glue code. Au lieu d’associer chaque agent à un scheduler, un récepteur de webhooks, une queue et une base d’historique séparés, l’équipe peut partir d’un Routine managé et n’ajouter du sur-mesure que lorsqu’elle a besoin de garanties ou de contrôles supplémentaires.
La direction générale est claire : les plateformes d’agents d’entreprise évoluent de « héberger un modèle avec des outils » vers « exploiter un acteur logiciel durable ». Lorsque déclencheurs, identité et continuité deviennent des composants du runtime, la qualité d’un système d’agents dépend autant de ses contrôles opérationnels que du modèle qui raisonne à l’intérieur.