La planification lance l’agent.
Qui répond du résultat ?

Dans son annonce du 24 septembre 2026, Microsoft présente Routines comme un service réunissant déclencheurs, actions des agents, identité, connexions et historique des exécutions au sein d’un projet Foundry. L’invocation et l’utilisation des outils peuvent se faire sous l’identité du créateur de la routine ou sous celle de l’agent. Un récapitulatif Foundry publié ensuite montre ce qu’une application doit faire après ce démarrage. Son titre mentionne septembre, mais ses métadonnées de publication indiquent le 16 octobre 2026. Les deux textes se complètent : l’annonce décrit le service d’exécution ; le récapitulatif suit le parcours d’un rapport dans une application.

Routines est annoncé en disponibilité générale ; l’outil de rappel qui permet à l’agent de programmer une reprise reste en préversion. Aucun de ces statuts ne démontre la fiabilité de la livraison de bout en bout. Le récapitulatif précise que Routines ne remplace ni l’orchestration multi-agents ni les circuits d’approbation. Un déclencheur géré peut dispenser de maintenir un planificateur distinct, mais l’application doit toujours suivre les tâches acceptées, conserver les résultats et traiter les envois dont l’état reste incertain.

Le processus de rapport de changements présenté dans le récapitulatif répartit le travail entre un agent qui rassemble des preuves publiques et un autre qui prépare puis livre le rapport. L’application enregistre la tâche avant d’en confirmer l’acceptation, puis propose des moyens distincts de consulter son état et de récupérer le résultat. L’appelant peut cesser d’attendre sans perdre l’identité de la tâche acceptée. Lors du transfert, le destinataire prend en charge sa copie du rapport et sa trace de livraison, sans présumer d’un accès au stockage privé du producteur. Selon l’auteur, la démonstration du 13 octobre a livré un rapport enregistré et permis de naviguer dans la même carte. Le producteur a ensuite repris le reçu de message du destinataire sans renvoyer le rapport. C’est un exemple d’application utile, mais la routine a été lancée manuellement. Bien que l’auteur indique que la planification du lundi est activée, la démonstration achevée ne prouve ni une exécution du lundi déclenchée par calendrier ni la fiabilité sans surveillance en production.

Microsoft décrit l’identité du créateur comme un accès délégué dans les limites des autorisations de cette personne, adapté aux outils utilisant une authentification utilisateur. L’identité de l’agent repose sur des autorisations configurées séparément dans Microsoft Entra ID, avec une authentification des outils par clé ou identité managée. Vérifiez ce choix pour chaque connexion réelle : une planification ne constitue pas une autorisation d’accès. Consignez qui approuve le périmètre des droits et qui peut désactiver l’exécution. Avec l’identité du créateur, demandez ce qui se passe si cette personne part ou si ses autorisations changent. Avec celle de l’agent, déterminez qui révise les droits et entretient les connexions. Ce sont des vérifications de responsabilité recommandées, pas des comportements de cycle de vie établis par les articles. Désignez aussi un responsable de la livraison pour approuver la destination et résoudre les envois ambigus. Sinon, chaque composant peut annoncer une réussite sans que personne ne réponde du rapport manquant.

Commencez par un rapport au périmètre défini. Consultez l’historique des déclenchements et des invocations pour identifier l’événement initial, l’heure et l’identité configurée ; distinguez les lancements manuels, calendaires et liés à un événement. Retrouvez ensuite la trace d’acceptation conservée durablement, l’identifiant de tâche et un état consultable ultérieurement. Une réponse d’API annonçant l’acceptation ne suffit pas si l’application ne retrouve plus le travail ensuite. Récupérez alors le rapport terminé et ses sources, sans masquer les lacunes de couverture. Une invocation achevée n’est pas nécessairement un livrable terminé, et enregistrer un rapport ne démontre pas son exactitude. Enfin, reliez l’accusé de livraison à ce rapport et à la destination approuvée. Un reçu de message dans un canal étaye la livraison, pas la lecture ou l’approbation par une personne. Demandez séparément des preuves d’exécution planifiée et testez les cas de tâche interrompue et d’accusé perdu. Ce sont des contrôles d’acceptation proposés, pas des essais réalisés pour cette analyse. Distinguez un accusé dont l’état est inconnu d’un échec confirmé comme d’une livraison confirmée : réessayer un envoi incertain peut créer un doublon.