Evaluations | The .NET Blog

Les évaluations du model router sont l'étape que trop d'équipes sautent

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Le routage automatique des modèles semble génial jusqu’au moment où l’on réalise qu’il faut encore prouver que c’est le bon choix pour votre charge de travail.

C’est pourquoi le nouveau dépôt d’évaluation du model router est utile.

Il donne aux équipes une façon plus concrète de répondre aux questions qui comptent vraiment :

le routage préserve-t-il la qualité ?
améliore-t-il le coût ?
qu’en est-il de la latence ?
que se passe-t-il si je restreins le sous-ensemble de modèles ?

L’article source pose les bonnes questions

Ce que j’aime particulièrement dans l’article original, c’est qu’il ne traite pas le model router comme étant évidemment bon.

À la place, il pose les questions inconfortables mais justes :

“Sur mes prompts, le modèle sélectionné automatiquement par le model router égalise-t-il ou dépasse-t-il le modèle unique que je choisirais sinon ?”
“Est-ce que j’économise réellement de l’argent de bout en bout, ou est-ce que je ne fais que déplacer les dépenses d’un endroit à un autre ?”

C’est exactement la bonne attitude.

Parce que le routage automatique est attrayant, mais cela reste une décision de système. Et les décisions de système doivent être mesurées, pas admirées.

Pourquoi ce dépôt compte plus qu’il n’y paraît au premier abord

À un niveau, il ne s’agit que d’un dépôt d’évaluation.

À un autre niveau, c’est un signe de maturité.

Cela dit : si vous voulez adopter le routage automatique, voici une façon plus disciplinée de tester :

la qualité
le coût
la latence
les compromis liés au sous-ensemble
le comportement de distribution des modèles

C’est bien mieux que de traiter le routage comme une boîte noire avec une bonne image de marque.

Mon avis

C’est un bon exemple du type d’outils dont les plateformes d’IA ont besoin davantage : pas plus de magie, mais davantage de moyens de valider la magie avant de lui faire confiance.

C’est ainsi que les équipes évitent de bâtir une confiance coûteuse sur des hypothèses non testées.

Article original : How to run evals for the model router

La partie difficile du développement de l'IA n'est plus l'accès. C'est bien exploiter le bon modèle

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Nous avons dépassé l’étape où le simple fait d’avoir accès à un modèle puissant suffisait.

C’est exactement ce que ce nouveau guide Foundry pour gérer les modèles, les coûts et la qualité comprend bien.

Le vrai défi est maintenant opérationnel :

choisir le bon modèle pour chaque charge de travail
le valider sur vos propres données
gérer la latence et les dépenses
gouverner les mises à jour et le risque de régression

C’est dans cela que les équipes sérieuses doivent exceller.

L’article source définit bien le problème

Une phrase de l’article d’origine capture très bien ce changement :

“La partie la plus difficile de la construction de systèmes d’IA aujourd’hui n’est plus d’obtenir l’accès à un modèle capable. C’est de savoir comment choisir, valider, optimiser et exploiter le bon modèle sur l’ensemble du cycle de vie d’une application réelle.”

C’est exactement le bon diagnostic.

Trop d’équipes pensent encore que la sélection du modèle est la décision principale.

Ce n’est pas le cas.

L’exploitation du modèle est le plus gros problème :

quelle charge de travail reçoit quel modèle ?
comment vérifier la qualité ?
quelle forme de coût est acceptable ?
que se passe-t-il lorsqu’un nouveau modèle apparaît ou qu’un ancien dérive ?
comment tester un changement sans casser les vrais workflows ?

C’est maintenant le vrai travail d’ingénierie.

Pourquoi cette pièce Foundry est utile

J’aime cet article parce qu’il parle des systèmes d’IA comme des ingénieurs de plateforme expérimentés doivent réellement les penser.

Pas comme “choisissez le modèle le plus intelligent et continuez”.

Mais comme des systèmes qui vivent sous des arbitrages :

capacité
latence
coût
sécurité
gouvernance
pression des mises à jour

C’est bien plus utile qu’un optimisme guidé par les benchmarks.

Le changement le plus important est de penser d’abord aux critères

L’article original recommande de définir les critères de réussite avant d’ouvrir le catalogue des modèles.

Je pense que c’est l’une des habitudes les plus importantes que les équipes puissent adopter.

Si vous ouvrez d’abord le catalogue, vous vous ancrez dans la réputation.

Si vous définissez d’abord les critères, vous vous ancrez dans la réalité de la charge de travail.

C’est un processus plus sain.

Parce que le modèle qui gagne un benchmark n’est pas automatiquement celui qui gagne sur :

vos prompts
votre budget de latence
vos limites de coût
vos exigences de gouvernance

Cette distinction, c’est là que commence la maturité de l’ingénierie IA.

L’histoire multi-modèles devient un vrai avantage

Autre point que j’aime : l’approche explicitement agnostique vis-à-vis des modèles.

L’article présente Foundry non pas comme une destination à modèle unique, mais comme une surface d’exploitation sur :

les modèles Microsoft
les modèles partenaires
les modèles open source
les variantes post-entraînées
les stratégies de routage et d’optimisation

Cela compte parce que la flexibilité des modèles n’est plus un luxe. C’est une partie de la gestion du risque.

Si la qualité change, si les prix bougent ou si les quotas se resserrent, les équipes ont besoin d’options.

Le contrôle des coûts n’est pas un sujet secondaire

L’article a aussi raison de présenter le coût comme une question d’architecture.

Ce n’est pas un problème du genre “on optimisera plus tard”.

Si vous envoyez chaque tâche au modèle le plus lourd par défaut, cela peut très bien fonctionner dans une démo et s’effondrer sous l’économie de la production.

C’est pourquoi je pense que les sections sur :

le routage
le batching
le caching
le provisioned throughput
la gestion des quotas

sont plus importantes que beaucoup ne le pensent.

Les équipes qui traitent la discipline des coûts comme faisant partie de la conception du système vieilliront bien mieux que celles qui la traitent comme du nettoyage après coup.

Mon avis

C’est une pièce Foundry utile parce qu’elle parle des systèmes d’IA comme des ingénieurs expérimentés doivent réellement les exploiter.

Pas comme des démos. Pas comme des prototypes uniques. Et pas comme du tourisme de classements.

Mais comme des systèmes d’exploitation pour des charges de travail, des contraintes, des arbitrages et des changements constants.

C’est vers ce niveau de conversation qu’il faut continuer à aller.

Et si vous construisez des systèmes d’IA en production, c’est exactement l’état d’esprit que je veux voir les équipes adopter tôt.

Article original : A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

L’histoire de Foundry, de l’observabilité au ROI, est exactement ce qu’il faut aux plateformes d’agents sérieuses

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si les agents IA doivent vivre en production, l’observabilité ne peut pas s’arrêter aux logs et aux traces.

C’est pour cela que la nouvelle histoire de Foundry, de l’observabilité au ROI, paraît importante.

Le vrai message n’est pas « nous avons ajouté plus de tableaux de bord ».

Le vrai message est que les plateformes d’agents sérieuses ont besoin d’une boucle opérationnelle continue :

tracer ce qui s’est passé
évaluer si c’était bon
optimiser ce qui doit être amélioré
relier le résultat à la valeur métier

C’est une histoire bien plus solide que le discours flou habituel sur les plateformes.

La phrase clé de l’article source dit tout

L’article d’origine commence par une phrase à laquelle je pense que toute équipe qui construit des agents devrait prêter attention :

“Lancer un agent IA est la partie facile. Le garder précis, sûr et responsable en production est l’endroit où les équipes se bloquent.”

C’est exactement vrai.

Nous avons déjà dépassé l’étape où la question principale était : « puis-je faire faire quelque chose de cool à un agent ? »

La question la plus difficile et la plus utile est :

puis-je exploiter la chose une fois qu’elle commence à interagir avec de vrais utilisateurs, de vrais outils et de vrais coûts ?

C’est là que Foundry essaie de faire avancer la conversation.

Pourquoi c’est plus important qu’une autre démo d’agent

Beaucoup d’annonces d’agents IA se concentrent encore sur la création : construire l’agent, brancher les outils, router les tâches, publier l’interface.

Tout cela est très bien.

Mais les questions opérationnelles sont ce qui permet à la plupart des systèmes sérieux de devenir durables ou de devenir des expériences coûteuses :

que fait réellement l’agent en production ?
a-t-il fait la bonne chose ?
se dégrade-t-il avec le temps ?
est-il trop coûteux par rapport à la valeur qu’il crée ?
quels changements de configuration ont réellement amélioré la qualité ?

C’est pourquoi je pense que l’annonce Foundry est plus importante qu’un simple récapitulatif de fonctionnalités. Elle essaie de définir une boucle d’Agent DevOps, pas seulement une histoire de création d’agent.

La boucle en quatre parties est le vrai produit ici

L’article organise essentiellement la plateforme autour de quatre capacités :

Trace
Evaluate
Monitor
Optimize

C’est la bonne forme.

Je dirais même que toute plateforme qui veut être prise au sérieux pour des charges de travail d’agents en production finira par avoir besoin des quatre.

Le tracing seul ne suffit pas.

L’évaluation seule ne suffit pas.

L’optimisation sans preuves n’est qu’une supposition.

Et parler de ROI sans télémétrie relève généralement du théâtre.

L’angle d’interopérabilité est particulièrement intelligent

L’une des décisions les plus fortes de l’annonce est que Foundry ne prétend pas que chaque agent sera construit dans un seul framework.

L’article source parle explicitement d’étendre le tracing et les évaluations à :

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
des frameworks personnalisés via OpenTelemetry

C’est important.

Parce que le verrouillage de plateforme est l’un des moyens les plus rapides de rendre moins attrayante une histoire d’exploitation qui était pourtant utile.

Si les équipes peuvent conserver leurs choix de frameworks tout en bénéficiant de la télémétrie et des surfaces d’évaluation de niveau production, la friction diminue considérablement.

L’évaluation par grille pourrait finir par compter plus que les gens ne l’imaginent

La partie évaluation par grille mérite aussi d’être mentionnée.

Je pense que c’est l’un des ajouts les plus pratiques de tout l’article.

Pourquoi ? Parce que le « bon » dépend du contexte.

L’article dit que l’évaluation par grille génère des « critères d’évaluation sensibles au contexte à partir du comportement prévu de votre agent ». C’est exactement la direction dont ces systèmes ont besoin.

Le scoring de qualité générique est utile.

Mais à terme, les équipes doivent évaluer les agents selon leurs propres standards :

ton
exécution des tâches
respect des politiques
attentes de latence
limites de coût
règles métier spécifiques au domaine

C’est là que l’évaluation devient opérationnellement significative plutôt qu’uniquement intéressante sur le plan académique.

Le ROI est la partie la plus inconfortable, et c’est pour cela qu’elle compte

Je pense aussi que la partie ROI de l’annonce est importante précisément parce qu’elle est inconfortable.

L’article pose directement la question :

“cet agent vaut-il ce qu’il coûte ?”

Cette question est souvent éludée dans les discussions sur l’IA.

Mais c’est la bonne question.

Si la plateforme peut vraiment relier le coût, l’exécution des tâches, le temps gagné et les traces de production en un seul endroit, cela donne à l’ingénierie et au leadership un langage commun bien meilleur.

Et franchement, ce langage commun est cruellement nécessaire.

Mon avis

C’est l’une des meilleures annonces au niveau plateforme de cette série, parce qu’elle se concentre sur l’exploitation des agents, pas seulement sur leur création.

Et c’est là que le vrai travail difficile commence.

Les plateformes IA les plus solides des deux prochaines années ne seront pas seulement celles qui donnent accès à plus de modèles ou à plus de démonstrations. Ce seront celles qui aident les équipes à tracer le comportement, évaluer les résultats, optimiser en sécurité et justifier les coûts avec des preuves.

Cette histoire Foundry essaie d’aller exactement dans cette direction.

C’est pour cela qu’elle mérite d’être prise au sérieux.

Article original : Build 2026: From observability to ROI for AI agents on any framework