L’agent d’entreprise devient une charge de production comme une autre

Pendant longtemps, l’agent de développement était un outil individuel : un chat, un IDE, une clé API. Cette semaine, les nouveautés les plus intéressantes racontent autre chose.

GitHub exporte désormais les traces des agents via OpenTelemetry et ajoute une sandbox locale contrôlant fichiers, réseau et credentials. AWS publie un mécanisme d’autorisation au niveau des objets réellement retournés aux agents, tandis que les coding agents commencent à router leurs tâches entre plusieurs modèles.

Le signal commun : l’agent devient une charge de production. Il lui faut donc les mêmes disciplines que nos services — observabilité, isolation, identité, policy, FinOps et SLO.

⚡ Le signal de la semaine — L’observabilité agentique rejoint enfin la stack d’observabilité

Le 22 septembre, GitHub a ajouté le support OpenTelemetry à l’application Copilot via des paramètres gérés par l’entreprise. Les administrateurs peuvent exporter l’activité des agents vers leurs outils compatibles : déroulé d’une session, appels aux modèles et utilisation des tools. Le contenu des prompts et réponses est exclu par défaut.

Tant qu’un agent reste un assistant individuel, on accepte une boîte noire. Dès qu’il agit dans un processus de Delivery, il faut pouvoir reconstruire une exécution : quel modèle, quel tool, quel ordre, quelle latence, quel échec ?

Le changement d’architecture consiste à traiter une session agentique comme une trace distribuée. On peut alors rapprocher télémétrie agent, CI, application et incident dans les mêmes outils.

Pour une ESN, cela ouvre un chantier concret : définir un standard d’observabilité agentique — spans, attributs, coûts, erreurs, tool calls et indicateurs de qualité — plutôt que laisser chaque équipe inventer son dashboard.

Décision : branchez un agent réel sur votre backend OTel et identifiez les trois questions de production auxquelles vos traces actuelles ne savent pas répondre.

1 — Une sandbox locale doit échouer fermée, pas « faire au mieux »

Le 23 septembre, GitHub a mis en public preview le sandboxing local dans l’application Copilot. La politique est définie par projet : dossiers read/write, read-only ou interdits ; accès Internet et réseau local ; credentials Git et GitHub CLI. Les politiques gérées par l’entreprise peuvent encore restreindre ces droits.

Le détail important est le comportement d’échec : si le système d’exploitation ne peut pas faire respecter la politique demandée, le shell sandboxé échoue au lieu de s’exécuter sans isolation.

Un agent capable de lancer des commandes n’est plus seulement une fonctionnalité IDE : c’est un workload qui touche filesystem, réseau et credentials.

Décision : documentez ce qu’un agent local peut lire, écrire, joindre sur le réseau et utiliser comme identité — puis faites de cette policy une configuration d’équipe.

2 — IAM autorise le tool ; il ne suffit pas à autoriser les données retournées

Le 22 septembre, AWS a publié TOLAP en open source sous Apache-2.0. Le problème visé est précis : IAM ou OAuth peuvent autoriser un agent à invoquer un tool, sans décider quelles lignes, colonnes, champs, endpoints ou objets ce tool peut réellement lui retourner.

TOLAP applique la policy au point où la donnée sort de sa source : filtrage de lignes, masquage de champs, limites de résultats, contrôle d’actions, purpose-binding et chaînes de délégation. Les SDK sont disponibles en .NET, Python et TypeScript avec des intégrations MCP, OpenAI Agents, LangChain, Semantic Kernel et Bedrock Agents.

L’intérêt architectural dépasse TOLAP : la sécurité d’un agent ne peut pas dépendre du prompt qui lui demande de ne pas regarder une donnée. La donnée interdite ne devrait jamais entrer dans son contexte.

Pour les architectures RAG/MCP d’entreprise, c’est le niveau de maturité suivant après « nous avons mis OAuth devant le serveur MCP ».

3 — Le coding agent devient un routeur de modèles, pas un abonnement monolithique

Le 23 septembre, AWS a publié une architecture OpenCode + Bedrock où différents modèles open weight peuvent être affectés à différents rôles : un modèle pour le plan et le raisonnement, un autre pour le build, avec un modèle par défaut. L’exemple utilise Kimi K3, GPT-OSS 120B et Nemotron 3 Super 120B.

Le signal est économique et architectural : le harness devient stable tandis que le modèle devient une ressource routable selon complexité, latence, coût, contexte et résidence.

AWS met aussi en avant Flex, annoncé à 50 % moins cher que Standard pour les workloads tolérant davantage de latence. C’est une affirmation fournisseur ; le bon coût reste celui mesuré sur vos tâches.

Pour un CTO, le KPI devient coût par tâche réussie — avec modèle et tier choisis dynamiquement.

4 — Le ROI agentique se mesure mieux sur un workflow qu’en « productivité développeur »

Le 22 septembre, AWS et Trane ont publié un retour d’expérience sur un agent de diagnostic de bâtiments. Trane indique être passé d’un workflow multi-écrans d’environ 20 minutes à une interaction en langage naturel d’environ 20 secondes, soit 60× sur le time-to-insight, d’après ses benchmarks internes avec des techniciens.

L’architecture combine assistants spécialisés, runtime isolé par session, gateway de tools, mémoire, identité, observabilité et télémétries temps réel. Le prototype a été construit en trois à quatre semaines, puis testé d’abord avec les techniciens internes.

Ce cas rappelle une règle utile : le ROI est plus crédible quand on choisit un workflow borné avec un « avant » mesurable qu’en annonçant un pourcentage générique de productivité.

Décision : choisissez un parcours qui prend 10 à 30 minutes aujourd’hui, instrumentez son temps et ses erreurs, puis mesurez l’agent sur cette unité de valeur.

🧭 Ce que ça change pour nous

Développeurs : une session agentique doit devenir débogable comme une requête distribuée.

Architectes : séparez exécution, identité, accès aux données et observabilité. Le prompt n’est une frontière de sécurité pour aucun des quatre.

Platform Engineering : fournissez sandbox et télémétrie par défaut.

CTO / DSI : pilotez les agents avec tâches réussies, latence, coût et incidents — pas seulement licences actives.

ESN : l’intégration IA bascule vers un marché de production readiness : sécuriser, instrumenter, router et opérer les agents.

🏢 Le sujet que je mettrais sur la table d’un COMEX IT

Sommes-nous prêts à traiter nos agents comme des composants du SI — avec owner, SLO, logs, droits, coût unitaire et procédure d’incident — ou les pilotons-nous encore comme des fonctionnalités expérimentales ?

Le passage à l’échelle se joue probablement moins sur la prochaine démonstration que sur cette réponse.

🧪 À tester lundi

Prenez un agent utilisé par une vraie équipe et dessinez sa fiche de production : identité, fichiers accessibles, réseau autorisé, tools, sources de données, modèle, coût d’une tâche, traces disponibles et owner.

Lancez cinq tâches et essayez de reconstruire chaque exécution depuis votre outil d’observabilité sans lire l’historique du chat. Les trous dans la reconstruction sont votre backlog Platform Engineering.

💰 Où est le business ?

Agent Production Readiness Review : audit de sandbox, IAM, MCP/tools, data policy, observabilité, evals, FinOps et exploitation.

Agent Observability Starter Kit : conventions OTel, dashboards, alerting et corrélation agent → tool → service → incident.

AI Routing & FinOps : benchmark interne de plusieurs modèles et tiers, puis routage par catégorie de tâche sur un objectif coût × qualité × latence.

Workflow Value Sprint : identifier un workflow de 10–30 minutes, établir la baseline et construire un agent dont le ROI peut être démontré en semaines.

❓ Question de la semaine

Si un de vos agents produit demain une mauvaise action en production, combien de minutes vous faut-il pour savoir exactement quel modèle, quel tool, quelle identité et quelle donnée ont participé à la décision ?

🤓 Pour ceux qui ont encore du contexte window