← Zakaria Khchiche · Tous les articles

Microsoft Agent Framework derrière un proxy d'entreprise : le transport HTTP qui ignorait HTTPS_PROXY

Un agent qui marche sur le poste du développeur mais n'atteint plus rien derrière le proxy de l'entreprise : la cause, le correctif et le test.

Zakaria Khchiche · · également publié sur Medium

Mon premier correctif fusionné dans le framework d’agents de Microsoft, et le test à ajouter à vos propres intégrations.

Un agent qui marche sur le poste du développeur, puis qui ne joint plus son API une fois déployé chez le client. Pas d’exception claire, pas de trace utile : simplement un appel qui n’aboutit pas. Dans une grande entreprise, le premier suspect est souvent le même : le proxy.

C’est ce qui m’est arrivé avec le connecteur TypeSafe (Jev) de Microsoft Agent Framework. Le correctif a été fusionné par l’équipe Microsoft le 6 octobre 2026 : microsoft/agent-framework#8984.

Le contexte

J’utilise Jev, le modèle de TypeSafe, pour décider si un passage retrouvé dans une grande base documentaire justifie vraiment une réponse. Microsoft Agent Framework fournit un connecteur Python vers TypeSafe. Dans un environnement d’entreprise, les serveurs sortent sur Internet par un proxy, configuré avec les variables HTTPS_PROXY, HTTP_PROXY, ALL_PROXY et NO_PROXY.

Le constat : le SDK TypeSafe utilisé seul joignait l’API dans cet environnement. Le même appel passé par le connecteur d’Agent Framework, non.

La cause

Quand le connecteur crée lui-même son client (AsyncTypeSafeClient), il lui passait un transport HTTP personnalisé, _ApiKeyTransport, dont le seul rôle était d'ajouter l'en-tête Authorization: Bearer <clé>.

Or httpx ne lit les variables de proxy que lorsqu’aucun transport personnalisé n’est fourni. En remplaçant le transport, le connecteur désactivait donc, sans le vouloir et sans le signaler, toute la configuration réseau de l’entreprise.

C’est un bug silencieux typique : aucune erreur à la création du client, aucun avertissement. Le réglage existe, il est simplement ignoré.

Le correctif

Le transport personnalisé était redondant : le SDK TypeSafe (versions 0.7.1 et 0.7.2) envoie déjà lui-même l’en-tête Authorization. Il masque d'ailleurs cet en-tête dans les journaux et les messages d'erreur, pas dans la requête envoyée.

Le correctif :

  1. supprime _ApiKeyTransport : le SDK construit son transport par défaut, et les variables de proxy s'appliquent de nouveau ;
  2. met à jour la note du fichier AGENTS.md du connecteur : les clients créés par le connecteur s'appuient sur le SDK pour l'en-tête d'authentification et gardent son transport ;
  3. garde des tests au niveau du transport, qui vérifient que la clé configurée part bien dans la requête réellement envoyée.

Moins de code, et un comportement réseau standard.

Le test à ajouter à vos propres intégrations

La leçon dépasse ce connecteur. Chaque fois qu’un client HTTP reçoit un transport, un adaptateur ou une session personnalisés, vérifiez deux choses :

Un test sur la configuration dit « la clé est réglée ». Un test sur la requête dit « la clé est envoyée, par le bon chemin ».

À retenir

C’est mon premier correctif dans Microsoft Agent Framework. J’en ai aussi fait fusionner chez Mistral AI (mistral-common) et dans OGX (ex-Llama Stack), toujours avec la même méthode : auditer une brique en conditions réelles avant de l’adopter, et corriger à la source.

Zakaria Khchiche est Tech Lead Data & IA freelance à Paris. Il construit et exploite des agents IA en production pour de grands comptes et contribue à des frameworks d’agents open source. LinkedIn · Site

Vous voulez que vos équipes construisent des agents comme ceux-ci ? J’anime avec Spar-x (organisme certifié Qualiopi, formation finançable par votre OPCO) une formation Copilot Studio pratique : programme de la formation. Et un kit gratuit pour l’article 4 de l’AI Act : kit AI Act.

À lire aussi : Localiser une signature dans un document scanné avec Jev 1.14 et Microsoft Agent Framework