Le rôle des agents d’intelligence artificielle en architecture évolue rapidement, l’identité, l’exécution isolée et l’observabilité devenant essentielles pour un déploiement à grande échelle. Traditionnellement, la construction d’un agent IA impliquait de sélectionner un modèle, de fournir un contexte et de le connecter à des outils — une approche qui fonctionnait pour des démonstrations simples, mais qui s’est révélée insuffisante lorsque les agents devaient surveiller des événements, intervenir dans des systèmes, exécuter du code ou reprendre des tâches après des interruptions. Les développements récents de Microsoft et de GitHub suggèrent un changement : les agents deviennent des charges de travail qui ne sont pas seulement utilisées, mais aussi gouvernées, avec l’identité, les autorisations, les environnements d’exécution et les traces jouant un rôle central. Bien que le choix du modèle reste important, il ne définit plus à lui seul l’architecture. Déclencher un agent ne devrait plus nécessiter une plateforme parallèle. Le Microsoft Foundry Agent Service Routines, disponible depuis le 24 septembre, permet de lancer un agent à une date précise, selon une récurrence, ou à partir d’un événement. Les premières intégrations basées sur des événements incluent les issues de GitHub et les messages des canaux Teams. Le déclencheur, l’identité utilisée, les connexions et l’historique d’exécution sont regroupés dans le projet Foundry. Cependant, l’outil permettant à un agent hébergé de programmer lui-même sa reprise dans la même conversation reste en préversion. Pour les équipes d’architecture, la question se pose de savoir quels planificateurs, webhooks et mécanismes de suivi doivent encore être développés et maintenus. Une capacité gérée peut simplifier certains scénarios, à condition de vérifier la fiabilité attendue, les intégrations disponibles et la manière dont les échecs sont gérés. Cela impose également une décision de gouvernance : au nom de qui l’agent agit-il ? Une routine peut utiliser l’identité déléguée de son créateur ou l’identité propre de l’agent. Ce choix détermine les systèmes accessibles et les autorisations exercées lorsque personne ne supervise directement l’exécution. Séparer le contrôle de l’agent de l’endroit où il travaille est crucial. Un agent qui analyse un document et un agent qui clone un dépôt, installe des dépendances et exécute du code présentent des risques opérationnels différents. Dans une analyse publiée le 23 septembre, Microsoft propose de gouverner l’agent dans Foundry et d’exécuter ses tâches dans des Azure Container Apps Sandboxes isolés. Il s’agit d’un modèle d’architecture à évaluer en fonction de l’usage plutôt que d’un schéma universel à appliquer directement. Pour une équipe d’ingénierie de plateforme, cette séparation peut devenir une voie privilégiée : fournir à chaque agent un environnement adapté à sa tâche, avec une identité définie, un accès réseau limité et des journaux traçables. Le développeur obtient un cadre prêt à l’emploi ; l’équipe de plateforme conserve le contrôle sur les conditions dans lesquelles le code généré ou les outils de l’agent s’exécutent. GitHub suit une logique similaire sur le poste de travail de développement. L’isolation locale de l’application Copilot permet de limiter, par projet, l’accès aux fichiers, aux réseaux et aux identifiants. Cette fonctionnalité est en préversion et désactivée par défaut : son adoption nécessite donc une configuration et une validation explicites dans les environnements concernés. Observer le travail des agents, puis mesurer ses effets. Lorsqu’un agent agit en plusieurs étapes, connaître sa réponse finale ne suffit pas. Il est nécessaire de comprendre quels modèles et outils il a sollicités, où il a échoué et pourquoi son comportement a changé. L’application GitHub Copilot prend désormais en charge l’export des traces OpenTelemetry via des paramètres gérés par l’entreprise. Le contenu des invites et des réponses est exclu par défaut ; toute modification de cette capture doit être examinée à la lumière des règles de confidentialité. Cependant, l’observabilité technique seule n’indique pas si l’expérience développeur progresse. GitHub a également ajouté à son API de métriques une ventilation du temps de révision des pull requests : attente de la première révision, échanges jusqu’à la révision finale, puis délai avant la fusion. Les médianes et les valeurs p90 permettent de distinguer un problème courant de quelques cas particulièrement lents. Ces nouvelles données concernent les révisions humaines éligibles et ne sont pas reconstituées pour les historiques précédents. Cette mesure est précieuse pour éviter une erreur courante : célébrer l’accélération de la production de code alors que les modifications attendent encore plusieurs jours avant d’être révisées et intégrées. Si les agents génèrent davantage de propositions, la capacité de révision et les règles de décision deviennent encore plus critiques. Le choix du modèle doit suivre celui de la tâche. L’arrivée de GPT-6 Sol et Luna aux côtés d’Astra dans Microsoft Foundry élargit les options pour les agents de production. Microsoft positionne Astra sur des tâches exigeantes en raisonnement, Sol sur des usages généraux et Luna sur des tâches à haut volume. Les modes de déploiement et les zones disponibles varient selon le modèle. La conséquence architecturale est de s’éloigner d’un modèle unique pour tous les agents. Une simple routage, une extraction répétitive et une décision complexe n’ont pas les mêmes exigences. Il est nécessaire de comparer la qualité obtenue, la latence, le coût par tâche réussie et les contraintes de résidence des données lors d’évaluations représentatives de l’usage réel. Ces évolutions ne rendent pas l’ingénierie de plateforme moins nécessaire. Elles recentrent son travail vers la définition d’un cadre commun : comment un agent est déclenché, quelle identité il utilise, où son code s’exécute, ce à quoi il peut accéder, ce qui est enregistré et comment son résultat est évalué. Le prochain projet utile consiste à prendre un cas d’usage limité mais réel — par exemple, le triage d’une issue ou l’analyse d’une pull request — et à documenter son parcours complet. L’objectif n’est pas seulement de prouver que l’agent sait accomplir la tâche. Il s’agit de montrer que l’organisation peut comprendre, contrôler et améliorer ce qu’elle fait lorsqu’elle fonctionne à grande échelle.