Microsoft-Decision-1 est en ligne sur Foundry. Son onglet Benchmarks est vide.

La chose la plus intéressante à propos de la sortie Microsoft de cette semaine n'est pas ce que Microsoft-Decision-1 peut faire. C'est ce que Microsoft a choisi de ne pas publier à son sujet. Le modèle est disponible : il est passé en disponibilité générale sur Microsoft Foundry le 8 octobre 2026, deux jours avant la rédaction de cet article. C'est un modèle d'évaluation de décisions — vous lui donnez un état et une question avec un ensemble fixe de réponses, et il renvoie une probabilité calibrée par réponse — post-entraîné par Microsoft sur le modèle à poids ouverts Qwen3.5-9B, exécutant une passe sur jusqu'à 32 768 tokens et produisant zéro token de sortie parce qu'il ne génère jamais rien du tout. La page du catalogue comporte un onglet Benchmarks. Il contient un paragraphe de méthodologie et aucun chiffre.

Cet écart, c'est l'histoire, et c'est une histoire plus utile qu'un nouvel article du type « Microsoft lance un modèle ». Toute question sérieuse sur un scorer est une question de calibration — un 0,8 renvoyé signifie-t-il bien 0,8 — et un lancement qui arrive sans le moindre score de Brier ni chiffre d'erreur de calibration attendue laisse le soin de mesurer le seul nombre qui compte à quiconque l'adopte. Ce qui suit : ce que la page Foundry documente réellement, ce qu'elle omet de manière flagrante, et ce qu'une équipe d'évaluation peut faire à ce sujet cette semaine.

Qu'est-ce qui a été livré, précisément

Microsoft-Decision-1 est une API hébergée. Le contrat est un appel en entrée, une distribution en sortie, sans boucle de décodage nulle part dans le chemin : la requête contient le matériel à évaluer ainsi qu’une question avec un ensemble de réponses borné, et la réponse contient une probabilité pour chaque option. Microsoft répertorie les formes de questions prises en charge comme oui/non, à choix multiples, notation, classification et basées sur une grille d’évaluation, le tout au sein d’une seule invocation allant jusqu’à 32 K tokens. Elle est uniquement textuelle — aucune entrée image, audio ou vidéo, et rien d’autre que des nombres en sortie.

Les exclusions sont énoncées aussi simplement que les fonctionnalités, et elles valent la peine d'être lues avant toute autre chose : non conçu pour la génération de texte, les réponses à des questions ouvertes, la conversation, la traduction ou le résumé, et non destiné aux tâches qui exigent des connaissances absentes de l'entrée. Il ne produit aucune justification. Les cas d'usage publiés correspondent tous à des situations où une équipe plateforme a déjà une décision étiquetée à prendre — évaluer une réponse générée par rapport à une grille d'évaluation, juger la pertinence de la récupération, trier une file d'attente, valider un appel d'outil d'agent proposé, filtrer du contenu selon des seuils définis par l'application plutôt qu'une politique fixe du fournisseur, et accepter automatiquement les résultats à haute confiance tout en escaladant les autres.

Deux détails opérationnels ressortent de la liste de déploiement. Le premier est que Microsoft prend explicitement en charge une option d'abstention telle que « impossible à déterminer » lorsque les éléments de preuve fournis sont insuffisants — c'est là la différence entre un évaluateur calibré et un évaluateur simplement sûr de lui, et c'est ce qui permet à la seuilisation de fonctionner. Le second est que l'inférence par lots est désactivée. Vous ne pouvez pas amortir une grande campagne d'évaluation via le canal par lots comme vous le feriez avec un modèle génératif ; la latence par appel devient donc la latence de votre pipeline plutôt qu'un problème de tâche hors ligne.

La distribution est exclusivement via Foundry, dans le portefeuille « Direct from Azure », sous forme de déploiement serverless ou à point de terminaison unifié sur une référence SKU standard — paiement à l’usage ou débit provisionné réservé. Les poids ne sont pas distribués. Il n’existe aucun dépôt Hugging Face, aucun téléchargement, aucun chemin de fine-tuning et aucune option d’auto-hébergement. Les applications s’intègrent via HTTPS avec l’authentification Azure standard. La divulgation relative à l’entraînement indique que le jeu de données a été utilisé pour la première fois en septembre 2026 avec une collecte en cours, ce qui correspond à la distance la plus courte possible entre les données d’entraînement et une date de disponibilité générale et est normal pour un post-entraînement sur une base publiée par quelqu’un d’autre.

L'onglet des benchmarks, cité dans son intégralité

Voici l’intégralité de ce que Microsoft a publié sur la performance du modèle. L’évaluation a utilisé « des benchmarks de décision publics et communautaires et des ensembles de tests internes mis de côté, non utilisés lors de l’entraînement ». Les métriques étaient l’exactitude, l’erreur de calibration, le rappel de sûreté, les taux de faux positifs et la cohérence d’équité. L’ordre des options a été varié. Des tests statistiques appariés ont été appliqués. L’affirmation est qualitative : Microsoft-Decision-1 « affiche des performances comparables à celles des principaux modèles de décision et devant les autres modèles de décision ouverts évalués selon la même méthodologie ».

C'est une conception d'évaluation compétente, décrite sans résultat. Ce n'est pas une accusation que de le souligner — un paragraphe de méthodologie sans tableau est un choix précis et vérifiable, et c'est un choix différent de celui qu'a fait le reste de cette petite catégorie. Les modèles de décision ouverts auxquels Microsoft se compare implicitement publient leurs chiffres : la famille Intern-Decision d'InternLM affiche les valeurs de Brier et d'erreur de calibration attendue sur ses fiches de modèle, le Jev de TypeSafe publie les deux, et la gamme d1 de Liquid AI livre des tableaux de précision avec ses poids. Microsoft est la plus grande entreprise de ce groupe et la seule à demander qu'on lui fasse confiance.

L’entreprise dit bel et bien où, selon elle, le modèle est fort et faible, ce qui est plus exploitable qu’un score principal. Points les plus forts : le raisonnement, l’application de règles et la robustesse au formatage des invites. Compétitif : la classification, la récupération d’informations, l’équité, l’utilisation d’outils et la plupart des tâches multilingues. Points les plus faibles : les connaissances spécialisées dans un domaine. Les limites que le modèle déclare lui-même sont tout aussi franches : les scores peuvent varier selon la formulation et l’ordre des options, une question mal formulée renvoie quand même un score, la calibration est plus fiable sur les types de tâches familiers, et aucune explication ne permet de vérifier une réponse qui semble erronée.

La couverture linguistique comporte le même type de mise en garde. 25 langues sont répertoriées comme prises en charge, couvrant le japonais, le coréen, l'arabe, le vietnamien, le thaï, le turc, le hindi, le bengali, le swahili, l'hébreu, le persan et l'ukrainien, entre autres, avec l'avertissement explicite que la couverture, la qualité et la calibration « peuvent varier selon la langue » et que les langues autres que l'anglais, en particulier celles à faibles ressources, constituent un domaine de sous-performance. La base Qwen3.5-9B prend en charge bien plus de 200 langues. Le post-entraînement en a conservé environ un quart, et c'est sur ce quart que la calibration a été ajustée.

Pas de prix sur la page non plus

Le champ de tarification du catalogue n’indique pas de tarif. Il renvoie vers la propre surface de tarification des modèles de Microsoft, de sorte que le coût par décision est quelque chose que vous lisez sur Azure ou sur une facture plutôt que sur la fiche du modèle. Pour quiconque modélise le coût par décision à grande échelle, il s’agit d’une véritable lacune, et il vaut la peine de le dire clairement plutôt que de l’estimer. Deux choses découlent effectivement de l’architecture et méritent d’être prises en compte dans cette estimation : 0 % du coût d’un appel correspond aux jetons de sortie, car il n’y en a pas, et l’ensemble d’options fait partie de l’entrée, donc une question comportant soixante-deux options descriptives coûte plus cher par appel qu’un oui/non — vous payez pour la grille d’évaluation que vous avez rédigée, pas pour la réponse.

Pourquoi cette forme de sortie est la partie intéressante

Un scoreur de décision est un pari : la primitive dont les entreprises ont réellement besoin n’est pas un meilleur rédacteur, mais un juge moins cher et plus fiable. Ce pari ne rapporte que si la probabilité est fiable, car tout ce qui se trouve en aval d’un scoreur est un seuil : 0,7 est escaladé vers une personne, 0,95 est accepté automatiquement, et le coût d’une erreur sur ce seuil se paie en mauvaises décisions automatisées plutôt qu’en tokens. Un fournisseur qui livre le scoreur sans la table de calibration demande à chaque client de la recalculer sur ses propres données.

La documentation de Microsoft elle-même recommande exactement cela, ce qui adoucit la critique et renforce en même temps la conclusion pratique. Validez sur des données représentatives de votre cas d’usage. Fixez les seuils en fonction du coût de vos erreurs plutôt que d’une valeur par défaut. Incluez toujours une option d’abstention. Randomisez l’ordre des options lorsque l’ordre pourrait biaiser la réponse. Gardez un humain dans la boucle pour toute conséquence importante. C’est un conseil judicieux pour n’importe quel évaluateur. C’est le seul conseil disponible pour celui-ci.

L'essayer cette semaine sans m'engager

L'évaluation la moins coûteuse consiste à choisir une décision que vous prenez déjà à la main, à rassembler deux cents cas étiquetés avec les ensembles de réponses que votre application fournirait réellement, puis à les faire passer par un déploiement Foundry. Calculez l'erreur de calibration attendue sur la sortie et vous en saurez plus sur Microsoft-Decision-1 que tout ce que Microsoft a publié à son sujet, parce que vous l'aurez mesuré sur votre distribution plutôt que sur un ensemble de test interne tenu à l'écart. C'est un après-midi de travail, et cela met fin à toute la question du benchmark.

La place d'OrcaRouter se situe dans l'autre moitié d'une boucle de scoring, et c'est la moitié qui génère. Nous n'hébergeons pas Microsoft-Decision-1 et il ne figure pas dans notre catalogue — un modèle qui renvoie des probabilités au lieu de texte n'est pas un modèle vers lequel on route des chat completions, et rien ici ne doit être interprété comme une affirmation de disponibilité. Ce qui se trouve derrière notre unique clé compatible OpenAI, c'est le vivier de plus de 200 modèles qui fait le travail d'écriture : le modèle qui rédige la grille d'évaluation, les deux qui produisent les réponses candidates, celui qui émet l'appel d'outil Decision-1 puis évalue avant son exécution. Le prix catalogue des fournisseurs est répercuté avec 0 % de marge, donc une baisse de prix côté générateur est effective chez nous le jour même, et le basculement automatique en cas de panne maintient le volet génération en vie lorsqu'un fournisseur unique se dégrade — ce qui compte davantage dans un pipeline qui note tout ce qu'il voit que dans un pipeline qui répond occasionnellement à un utilisateur. Si vous préférez ne pas choisir un juge unique, le DSL de routage compose plusieurs modèles en un seul appel, et la fusion de modèles rapporte leur concordance sous forme de champ noté plutôt que de prose que vous devez lire.

Ce qui changerait cet article, c’est un tableau. Publiez les scores de Brier et l’ECE, ou laissez une exécution indépendante se retrouver dans un classement, et l’évaluation ci-dessus devient une confirmation au lieu de l’unique preuve existante. D’ici là, la description exacte de Microsoft-Decision-1 est étroite : les poids sont réels, le contrat est documenté mieux que ne le font la plupart des versions hébergées, l’option d’abstention est prévue dès la conception plutôt qu’ajoutée après coup, et l’affirmation de performance tient en une phrase — bien écrite, sans le moindre chiffre à l’appui.

L'essentiel

Microsoft-Decision-1 est passé en disponibilité générale sur Microsoft Foundry le 8 octobre 2026 en tant que moteur de notation de décisions texte uniquement, à 32 768 jetons, construit sur Qwen3.5-9B, renvoyant des probabilités calibrées sur vos propres ensembles d’options avec zéro jeton de sortie et aucun poids à télécharger. Ses points forts sont un contrat propre en une seule passe, un chemin d’abstention intégré dès la conception, et l’authentification, la facturation et la gouvernance Azure associées ; sa faiblesse est que personne en dehors de Microsoft n’a de chiffre publié sur la qualité de sa calibration, y compris Microsoft. Considérez ce lancement comme une API qui devient disponible, et non comme une capacité qui est établie, et faites passer vos propres cas étiquetés dans l’outil avant que quoi que ce soit en aval ne dépende d’un seuil.