GitHub Copilot Fusion prend en charge le choix des modèles et divise par deux le coût des tâches de code
Le 28 octobre 2026, à GitHub Universe, GitHub a rendu disponible Copilot Fusion, un système qui sélectionne et orchestre les modèles de code à la place du développeur. Pour les équipes DevOps, la question n’est plus de choisir le bon modèle, mais de verrouiller la politique d’entreprise qui encadre cette délégation.
28 octobre 2026. À GitHub Universe, GitHub rend disponible Copilot Fusion, un système qui choisit et orchestre les modèles de code à la place du développeur. Septembre 2026. Le projet de recherche HydraFusion avait déjà montré la mécanique d’orchestration des modèles au moment de l’exécution. 60 — le score de Fusion Max sur l’index Artificial Analysis Coding Agent, à deux points de Claude Code équipé d’Opus 5.5 Max, pour environ la moitié du coût moyen par tâche. Le point qui compte : le routage de modèles devient le réglage par défaut de l’outillage de développement, et ce que l’on délègue à l’outil est désormais une décision de gouvernance, pas de performance.
Ce que Fusion décide à votre place
Copilot Fusion fusionne deux briques que GitHub développait séparément. La première, Project HydraFusion, orchestre les modèles au moment de l’exécution : elle peut enchaîner plusieurs modèles sur une même tâche, en fonction de ce qui convient à chaque étape. La seconde, Copilot Auto Model Selection, choisit le modèle adapté à la tâche. Le résultat est un système auquel le développeur délègue l’intégralité de la chaîne de décision — quel modèle, pour quelle étape, à quel moment.
La mécanique d’orchestration mérite d’être lue de près, car elle change le contrat de travail du développeur. Le système peut se contenter d’un modèle unique qui exécute toute la tâche. Il peut opter pour un flux en cascade, où un contrôle qualité évalue la réponse d’un modèle puis décide de l’accepter ou de la faire escalader vers un modèle plus puissant. Il peut enfin choisir un flux de critique, où un modèle relit le travail d’un autre avant de le valider. Dans les trois cas, l’arbitrage coût‑performance est retiré des mains de la personne qui tape le code.
L’argument commercial de GitHub est un gain de temps réel. Hari Pokhrel, ingénieur logiciel principal chez AT&T, décrit dans un communiqué la dérive que le système corrige : « Avant, les développeurs choisissaient souvent un modèle plus puissant pour une tâche complexe et oubliaient de revenir en arrière pour les tâches courantes. » Ce n’est pas une anecdote isolée. Le coût d’un mauvais choix de modèle est silencieux — il s’accumule en tokens facturés, pas en erreurs visibles.
Trois niveaux d’effort, un seul arbitre
Ce que le développeur garde sous son contrôle, c’est le niveau d’effort. Copilot Fusion expose trois crans : Fusion Standard pour le code courant, Fusion High pour les tâches exigeantes et le raisonnement plus profond, Fusion Max pour les travaux les plus lourds. L’effort est la seule variable que l’humain fixe ; le choix du modèle et son orchestration reviennent au système.
Les chiffres avancés par GitHub donnent la promesse. Fusion Max atteint 60 sur l’index Artificial Analysis Coding Agent, à deux points de Claude Code équipé d’Opus 5.5 Max. Il y parvient pour environ la moitié du coût moyen par tâche, avec environ deux fois moins de tokens consommés et 40 % de temps en moins par tâche. Ce sont des mesures produites par GitHub lui‑même, sur un benchmark tiers, et non une comparaison indépendante — mais l’écart de prix est suffisamment large pour mériter d’être vérifié sur sa propre charge.
Chez AT&T, toujours selon le communiqué, Fusion Standard aurait amélioré l’efficacité en tokens, réduit les dépenses inutiles et préservé la capacité de calcul pour les travaux à plus forte valeur. C’est exactement la promesse économique du routage : ne plus payer un modèle « Max » là où un modèle « Standard » suffit, sans exiger du développeur qu’il y pense à chaque requête.
La gouvernance reste la ligne rouge
La partie la plus importante de l’annonce n’est pas technique, elle est administrative. Les administrateurs d’entreprise peuvent contrôler la liste des modèles que Copilot Fusion a le droit de choisir, désactiver certains modèles pour Fusion sans les désactiver pour toute l’équipe, ajuster l’état de politique de chaque modèle indépendamment, et décider si Fusion est ou non le modèle par défaut des utilisateurs de Copilot.
Cette granularité est ce qui sépare un simple raccourci d’un outil déployable en entreprise. Déléguer le choix du modèle, c’est déléguer une décision budgétaire. Sans la possibilité de borner la liste des modèles autorisés, une équipe accepterait qu’un système choisisse librement de facturer plus cher en échange d’une latence ou d’une qualité qu’elle n’a pas validée. Avec la politique d’entreprise, la délégation reste encadrée : l’outil optimise à l’intérieur d’un périmètre que la direction a verrouillé.
Il faut aussi lire l’annonce dans la trajectoire plus large de GitHub, qui a présenté le même jour l’application GitHub Copilot, Copilot Projects et Copilot Automations. Fusion n’est pas un produit isolé : c’est la pièce qui rend le choix de modèle invisible à l’échelle d’une plateforme entière, et qui transforme « lequel choisir » en une question de configuration d’équipe.
Le routage devient le réglage par défaut
GitHub n’est pas seul sur cette pente. En octobre 2026, Ramp a décrit le déplacement de la sélection de modèles vers Open SWE, son agent de code open source. Cet été, Replit a fait de même en rendant son routage de modèles « intelligent » par défaut sur tous les comptes. Le mouvement est unanime : le choix manuel du modèle, qui était il y a deux ans un signe de maîtrise technique, devient un résidu de friction.
Pour une équipe DevOps, le signal est clair. Le coût cognitif de la sélection de modèles est en train de devenir un coût que les plateformes absorbent à votre place, exactement comme l’orchestration de conteneurs a absorbé le placement manuel des processus. La conséquence n’est pas de rendre la performance sans importance — elle est de déplacer l’attention de l’équipe vers ce qui reste sous son contrôle : le niveau d’effort, la liste des modèles autorisés, et la mesure de ce que chaque cran coûte réellement.
Le revers de la délégation est la perte d’un signal. Un développeur qui choisit ses modèles apprend, même grossièrement, ce que chacun sait faire et combien il coûte. Un routage qui décide à sa place efface cette mémoire. La parade est la même que pour tout système autonome — brancher la télémétrie de l’outil, la consommation de tokens par cran d’effort et par tâche, sur le tableau de bord de coûts de l’équipe, et alerter quand la dépense dérive. Sans cette boucle de mesure, déléguer le choix du modèle revient à signer un chèque sans regarder le montant.
Verdict
Si votre équipe est déjà sur GitHub Copilot, activez Fusion et verrouillez la politique de modèles le jour même : vous récupérez l’essentiel du gain — la fin des allers‑retours manuels entre modèles — sans rien lâcher sur le budget, tant que l’administrateur borne la liste des modèles autorisés. Si vous êtes sur Claude Code ou sur un routage manuel, ne changez pas sur la foi des chiffres de GitHub : les mesures de Fusion Max sont celles de l’éditeur sur un benchmark tiers, pas une comparaison indépendante sur votre charge — mesurez avant de migrer. Et si votre direction ne peut pas vous donner la granularité de politique par modèle, ne déployez pas Fusion : déléguer le choix du modèle sans pouvoir le borner, c’est renoncer au contrôle d’une ligne de coût. Le routage de modèles devient la norme ; ce qui distinguera les équipes, c’est la qualité du garde‑fou qu’elles posent autour.