On y est : sur GitHub Copilot, routage et orchestration convergent.

Par « routage », il faut entendre le mode Auto. Introduit en début d’année. Il a connu deux incarnations. La v1 utilisait un encodeur ModernBERT pour aiguiller les requêtes en fonction de la disponibilité des modèles et de leurs capacités. La v2, appelée HyDRA (Hybrid Dynamic Routing Architecture), exploite le même type de classifieur, mais entraîné pour évaluer les besoins, sur 4 dimensions : raisonnement, génération de code, débogage et utilisation d’outils. Elle intègre par ailleurs des contraintes d’exploitation comme la continuité de session et le filtrage dynamique des pannes.

La partie orchestration est plus récente. GitHub avait commencé à l’expérimenter début septembre, sous le nom HydraFusion. Promesse : pour chaque prompt, choisir non pas le modèle optimal, mais le workflow optimal, entre trois options :

• Réalisation de la tâche par un modèle unique
• Intervention d’un LLM juge qui peut valider ou décider de confier la tâche à un autre modèle
• Boucle d’itération avec un modèle critique n’intervenant qu’en lecture

Les modèles locaux restent en preview

De la convergence des deux briques naît le mode Fusion. ll peut fonctionner à quatre niveaux d’effort : Standard, High, Max et Fast, ce dernier n’étant pas réglable par l’utilisateur (il est réservé au chat inline de VS Code).

Le niveau Standard est accessible sur tous les forfaits Copilot. Les niveaux High et Max ne sont disponibles que sur les abonnements Pro+, Max, Business et Enterprise. Tandis que le mode Auto octroyait 10 % de réduction sur le prix des modèles, GitHub propose 30 %… mais pour une durée limitée (jusqu’à fin nonvembre).

Côté admin, on peut choisir d’activer Fusion par défaut dans le sélecteur. Et contrôler le pool de modèles, ainsi que le niveau d’effort par défaut pour les nouvelles conversations.

L’intégration des modèles locaux reste en preview. Elle en concerne pour le moment deux :

• MAI Code 1.1 Flash, utilisable sur Windows via le CLI et l’application GitHub Copilot ou VS Code
• Qwen3.8 Flash, utilisable sur Windows, Mac et Linux via le CLI

Premiers résultats mitigés chez Michelin

Les quelques semaines de test ont fait ressortir, entre autres points de frustration, le manque de feed-back pendant l’exécution des tâches. GitHub a notamment pris le parti de ne pas afficher les résultats des étapes intermédiaires. Motif : éviter qu’on les perçoive comme du travail fini…

On a aussi suggéré à GitHub d’exposer, plutôt que la chaîne de pensée, de la télémétrie structurée. Par exemple, la stratégie d’exécution choisie, les familles de modèles utilisées ou les motifs de rejet de résultats.

Michelin a fait partie des entreprises qui ont essayé HydraFusion. Il en a témoigné mi-septembre. Son bilan était mitigé. De son avis, cet orchestrateur n’était pas un substitut au mode Auto, mais un « mécanisme de qualité »… au prix nettement plus élevé.

Nombre de retours utilisateurs lui ont fait écho. Dans les grandes lignes : HydraFusion a tendance à choisir des modèles trop performants. Et à ne pas exploiter de sous-agents « économiques » à moins qu’on le demande explicitement.

Illustration générée par IA

The post GitHub Copilot fusionne finalement routeur et orchestrateur appeared first on Silicon.fr.

Michelin a tranché : sur son GitHub Copilot, la sélection automatique du modèle n’est plus activée par défaut.

Cette décision fait suite à une expérience qui a englobé environ 700 requêtes, de trois types :

• Demandes simples (appels copilot -p)
• Tâches vérifiables (agrégation pandas, flaky test, injection SQL…)
• Sessions de chat (à 7 tours)

L’anayse des logs a montré que le choix du modèle se fait côté serveur. Un classifieur attribue à chaque requête un score sur 4 axes :

• Niveau de raisonnement nécessaire
• Quantité de code à produire
• Requête ayant trait à du diagnostic / débogage
• Besoin d’utiliser des outils

Une fourchette de modèles… puis un tirage au sort

Il est apparu que le mode Auto n’interprète pas les tâches, mais les mots. Qu’importe l’environnement et la méthode d’invocation, une même phrase a toujours les mêmes scores.

Les scores déterminent une fourchette de modèles adéquate, au sein de laquelle GitHub Copilot semble piocher aléatoirement. Ainsi, le même jour et pour un même prompt (destiné à renommer une variable), le mode Auto a choisi tantôt MAI-Flash, tantôt GPT-5.6 Terra. Avec le premier, il en a coûté 0,23 crédit. Avec le second, 3,24.

Lorsque le score de raisonnement était supérieur ou égal à 0,55, le routeur n’a jamais sélectionné de « petit » modèle. Il l’a au contraire fait la plupart du temps (41 fois sur 46) lorsque le score était inférieur à 0,3. Entre les deux, ç’aura été la loterie : dans 14 cas sur 19, le modèle a changé d’une répétition à l’autre.

« Attention, requête complexe » : une déclaration sans grand effet

Michelin a essayé d’ajouter au début de ses requêtes une déclaration de complexité (« Complex architecture question :». Bilan : cela fait peu évoluer les scores. Jamais assez, en tout cas, pour changer de fourchette. Dire à l’inverse qu’une requête est simple a un peu plus d’effet : 7 downgrades sur un échantillon de 12 tâches.

Un scoring qui ne tient pas compte du contexte

Ces 12 mêmes tâches ont permis de constater que les scores ne tiennent pas compte du contexte. Ils sont les mêmes, qu’on se trouve dans un dossier vide ou dans un espace de travail avec fichiers d’instructions et serveurs MCP. Cela n’a pas empêché que le mode Auto change le modèle dans trois cas.

10 % d’économies, mais…

GitHub promet 10 % de remise lorsqu’on utilise le mode Auto. À modèle identique, c’est vrai, conclut Michelin en donnant l’exemple de Claude Sonnet 5 (sur 6 requêtes, 11,9 % moins cher en moyenne).

Sauf que cette ristourne ne compense pas toujours le surcoût du mode Auto. On le perçoit d’autant plus lors des sessions de chat à plusieurs tours.

Michelin a posé les 7 mêmes questions, dans deux ordres différents.
En ouvrant sur une question difficile, le mode Auto a choisi Claude Sonnet ou GPT Sol… puis s’y est tenu, pour un coût moyen de 13,7 crédits. En commençant par une question simple (exemple : « Renomme cette variable »), il choisit au contraire un modèle plus petit (GPT Luna) et s’y tient là aussi assez souvent, pour un coût moyen de 0,78 crédit.

Changer de modèle en cours de session a un coût

Les quelques fois où le modèle change au cours de la session, ce n’est pas sur la base de la dernière question, mais de toute la conversation jusque-là. La bascule a un coût non négligeable : le cache étant vidé, il faut renvoyer le contexte.

On peut supposer que la charge sur les serveurs de GitHub Copilot influe dans le choix du modèle. Un test réalisé sur une trentaine d’heures semble démontrer que non. Toutes les heures, Michelin a envoyé la même requête, de 225 caractères. Sur 29 appels effectivement arrivés, Claude Sonnet 5 a été choisi 13 fois, comme GPT Sol. Claude Opus 5 l’a été 3 fois.

Pour baisser le score de raisonnement, faire du remplissage

Pour comprendre ce qui fait vraiment évoluer les scores du classifieur, Michelin est parti d’une phrase neutre de 112 caractères. Puis il a modifié quatre éléments. Les voici récapitulés, avec leurs principaux effets :

Le mode Auto, « filet de sécurité » plus que source d’économies

Michelin estime que sur les tâches unitaires que ses développeurs réalisent au quotidien, GPT Luna est un « choix défendable ». Il délivre, pour 6 à 18 fois moins cher, les mêmes résultats que le mode Auto. Qui, sur ce périmètre, est donc un « filet de sécurité » plutôt qu’une « façon d’économiser de l’argent ».

L’auteur de l’expérimentation le reconnaît : il ne s’agit pas d’un benchmark. Les conclusions valent pour un catalogue spécifique de modèles (Michelin en autorise 11, moins qu’il n’en bloque), sur un abonnement et une version de CLI donnés. GitHub a lui-même fait évoluer son offre au cours de l’expérience (Luna était absent au démarrage).

HydraFusion, un orchestrateur expérimental… nettement plus cher que le mode Auto

En marge, Michelin a testé une option actuellement à l’état expérimental : HydraFusion. Plus qu’un routeur, c’est un orchestrateur. Chaque requête génère un plan dont les différentes phases sont chacune assignées à un modèle. Aucun score n’apparaît dans les traces que laisse GitHub Copilot.

Sur les tâches simples, HydraFusion a presque toujours choisi GPT Sol. Sur celles en cascade, un « petit » modèle (Luna notamment) ébauche le travail, tandis que GPT Sol fait office de juge et, le cas échéant, de correcteur. La correction représente 72 à 90 % du coût de la session.

Dans deux cas, HydraFusion a choisi Claude Opus 5 pour ébaucher et pour réviser en fonction des critiques de GPT Sol. Il en a coûté 16 et 28 crédits, là où le mode Auto en aurait consommé 3. Cet écart fait dire à Michelin qu’il ne s’agit pas d’un substitut, mais d’un « mécanisme de qualité »… qui a un prix.

Quelques jours après l’expérimentation, GitHub a assoupli le mode Auto avec trois niveaux « Efficiency », « Balance » et « Intelligence ». Ce système conserve le cache entre modèles.

Illustration générée par IA

The post Pourquoi Michelin a coupé le mode Auto de GitHub Copilot appeared first on Silicon.fr.

C’était pressenti, c’est acté : GitHub Copilot change de modèle économique.

Le 1^er juin 2026, des quotas de crédits remplaceront les quotas de requêtes premium actuellement intégrés dans les abonnements payants.

Un crédit équivaudra à 0,01 $. Ce qui donnera les quotas suivants :

Cette enveloppe de base pourra être élargie au besoin, dans des conditions que GitHub ne détaille pas en l’état.

Les forfaits annuels iront à terme avec un quota de requêtes… mais un usage restreint

Par défaut, les forfaits individuels souscrits sur base annuelle conserveront, jusqu’à échéance, des quotas de requêtes premium. Mais une bonne partie des modèles en consommeront davantage. Voici un aperçu des multiplicateurs qui s’appliqueront au 1^er juin pour les trois principales familles (Claude, Gemini, GPT).

Des pools de crédits sur les offres entreprise

Les titulaires de forfaits individuels contractés sur base annuelle pourront aussi les résilier et obtenir un remboursement au prorata. S’ils attendent l’échéance, le renouvellement ne sera pas automatique (passage sur le forfait gratuit).

Sur les forfaits GitHub Copilot pour les entreprises, les quotas de tous les utilisateurs seront regroupés en un pool au niveau de l’entité facturée. Ajouter des licences augmentera immédiatement la capacité de ce pool. En supprimer ne la réduira qu’au démarrage du cycle de facturation suivant.

Pour accompagner la transition, GitHub accordera, sur juin, juillet et août, 3000 crédits par mois pour chaque utilisateur sur le forfait Business et 7000 sur le forfait Enterprise. Début mai, il mettra à disposition des admins des projections de coûts, sur la base de l’usage du moins d’avril. Des budgets pourront être définis à quatre niveaux : entreprise, organisation GitHub, centre de coût et utilisateur.

Prévoir les coûts de la revue de code sera difficile

Saisie semi-automatique et suggestions d’édition ne consommeront pas de crédits, tout comme elles ne consomment actuellement pas de requête premium.

Il y aura, en revanche, une zone d’ombre sur la fonctionnalité de revue de code. La non-divulgation du modèle utilisé rend impossible de prévoir exactement les coûts. Ceux-ci se répercutent sur deux plans. D’un côté, les crédits. De l’autre, les minutes GitHub Actions que consomme l’infrastructure agentique (hors exécuteurs autohébergés).

Le passage aux crédits éliminera la possibilité actuelle de repli vers un modèle « low cost » en cas d’épuisement du quota de requêtes. Il faudra acheter des crédits supplémentaires. Chose que, d’ailleurs, qu’on ne devrait pas pouvoir faire si on a souscrit à GitHub Copilot via l’app mobile.

Tarifs applicables au 1^er juin pour les modèles GPT

Pour les modèles Claude

Pour les modèles Gemini

Illustration générée par IA

The post GitHub Copilot passe (essentiellement) à la facturation à l’usage appeared first on Silicon.fr.