Agents IA : la plateforme devient le vrai sujet d'architecture

Les agents IA changent l'architecture des plateformes : identité, exécution isolée et observabilité deviennent essentielles pour les déployer à grande échelle, avec une gouvernance maîtrisée.

Pendant longtemps, construire un agent IA a surtout consisté à choisir un modèle, lui fournir du contexte et le connecter à quelques outils. Cette approche suffit pour une démonstration. Elle atteint ses limites dès que l'agent doit surveiller un événement, intervenir dans un dépôt, exécuter du code ou reprendre une tâche interrompue.

Les annonces récentes de Microsoft et GitHub dessinent une évolution : l'agent devient une charge de travail à exploiter et à gouverner, avec une identité, des droits, un environnement d'exécution et des traces. Le choix du modèle reste important, mais il ne suffit plus à définir l’architecture.

Déclencher un agent ne devrait plus nécessiter une plateforme parallèle

Depuis le 24 septembre, les Routines de Microsoft Foundry Agent Service sont disponibles de manière générale. Elles permettent de lancer un agent à une date donnée, selon une récurrence ou à partir d’un événement. Les premières intégrations événementielles couvrent notamment les issues GitHub et les messages de canaux Teams. Le déclencheur, l’identité utilisée, les connexions et l’historique d’exécution sont réunis dans le projet Foundry. En revanche, l’outil qui permet à un agent hébergé de programmer lui-même sa reprise sur la même conversation reste en préversion.

Pour les équipes d’architecture, la question devient concrète : quels ordonnanceurs, webhooks et mécanismes de suivi faut-il encore développer et maintenir soi-même ? Une capacité managée peut simplifier certains scénarios, à condition de vérifier la fiabilité attendue, les intégrations disponibles et la manière dont les échecs seront traités.

Elle oblige aussi à trancher une question 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 permissions exercées lorsque personne ne supervise directement l’exécution.

Séparer le contrôle de l’agent de l’endroit où il travaille

Un agent qui analyse un document et un agent qui clone un dépôt, installe des dépendances puis lance du code ne présentent pas le même risque opérationnel. 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 environnements isolés Azure Container Apps Sandboxes. C’est un modèle d’architecture à évaluer selon les usages, plutôt qu’un schéma universel à appliquer tel quel.

Pour une équipe de Platform Engineering, cette séparation peut devenir un golden path : fournir à chaque agent un environnement adapté à sa tâche, avec une identité définie, des accès réseau limités et des traces exploitables. Le développeur obtient un cadre prêt à l’emploi ; l’équipe plateforme garde la maîtrise des conditions dans lesquelles le code généré ou les outils de l’agent s’exécutent.

GitHub suit une logique proche sur le poste de développement. Le sandboxing local de l’application Copilot permet de limiter, par projet, l’accès aux fichiers, au réseau et aux identifiants. Il est en préversion et désactivé par défaut : son adoption demande donc une configuration explicite et une validation dans les environnements concernés.

Observer le travail des agents, puis mesurer ses effets

Quand un agent agit en plusieurs étapes, connaître sa réponse finale ne suffit pas. Il faut pouvoir 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 de traces OpenTelemetry au moyen de paramètres gérés par l’entreprise. Le contenu des prompts et des réponses est exclu par défaut ; toute modification de cette capture doit être examinée au regard des règles de confidentialité.

L’observabilité technique ne dit toutefois pas, à elle seule, si la Developer Experience progresse. GitHub a également ajouté à son API de métriques une décomposition du temps de revue des pull requests : attente de la première revue, échanges jusqu’à la revue finale, puis délai avant fusion. Les médianes et les p90 permettent de distinguer un problème courant de quelques cas particulièrement lents. Ces nouvelles données concernent les revues humaines éligibles et ne sont pas reconstituées pour l’historique antérieur.

Cette mesure est précieuse pour éviter une erreur fréquente : célébrer l’accélération de la production de code alors que les changements attendent toujours plusieurs jours avant d’être relus et intégrés. Si les agents produisent davantage de propositions, la capacité de revue et les règles de décision deviennent encore plus déterminantes.

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 en production. Microsoft positionne Astra sur les travaux de raisonnement exigeants, Sol sur les usages généraux et Luna sur les tâches à fort volume. Les modes de déploiement et les zones disponibles diffèrent selon le modèle.

La conséquence architecturale est de sortir du choix d’un modèle unique pour tous les agents. Un routage simple, une extraction répétitive et une décision complexe n’ont pas les mêmes exigences. Il faut comparer la qualité obtenue, la latence, le coût par tâche réussie et les contraintes de résidence des données sur des évaluations représentatives des usages réels.

Une nouvelle responsabilité pour les équipes plateforme

Ces évolutions ne rendent pas l’ingénierie de plateforme moins nécessaire. Elles déplacent 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 qu’il peut atteindre, ce qui est enregistré et comment son résultat est évalué.

Le prochain chantier 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 est de montrer que l’organisation sait comprendre, contrôler et améliorer ce qu’il fait lorsqu’il travaille à l’échelle.