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.