Le 28 octobre, pendant GitHub Universe, GitHub a rendu Copilot Fusion disponible pour tous1. Le principe tient en une ligne : le développeur ne choisit plus de modèle. Il sélectionne « Fusion » et un niveau d'effort, puis Copilot décide quels modèles traitent la tâche. Pour une équipe qui maintient des modules Odoo, la nouveauté pose une question pratique que la démo ne règle pas : qui sait encore quel modèle a écrit le code qui part en revue ?
Ce que GitHub a annoncé
Fusion succède à Project HydraFusion, une préversion de recherche lancée début septembre 2026, selon la couverture de DEV Community et de plusieurs agrégateurs. La version générale est proposée sur tous les forfaits Copilot, dans VS Code, l'application Copilot, Copilot CLI et les IDE JetBrains, d'après les résumés publiés par Unite.ai et Datastudios.
Le développeur règle un seul paramètre, le niveau d'effort. Trois valeurs existent : Standard, High et Max. Derrière ce curseur, Fusion choisit pour chaque tâche l'un de trois schémas d'exécution, que décrivent les articles de Cellcog et de Sumus :
| Schéma | Fonctionnement | Coût et latence |
|---|---|---|
| Single | Un seul modèle traite la tâche directement | Le plus rapide |
| Cascade | Un modèle économique rédige, un contrôle qualité accepte ou escalade vers un modèle plus fort | Variable selon l'escalade |
| Critique | Un modèle rédige, un second relit, le premier corrige | Plus lent, plusieurs appels |
Côté facturation, Fusion n'ajoute pas de ligne propre. Chaque modèle mobilisé est facturé à son tarif standard, avec une remise de 30 % sur les forfaits payants jusqu'au 30 novembre 2026, selon Cellcog et Explainx. Daily.dev parle seulement d'une remise temporaire, et l'échéance reste donc à confirmer dans votre console d'administration.
Pour les entreprises, Fusion respecte les politiques de modèles définies au niveau de l'organisation. DEV Community signale aussi une liste de modèles propre à Fusion et un niveau d'effort par défaut géré par l'administrateur.
Le chiffre de performance vient de GitHub
L'argument commercial repose sur un score. GitHub indique que Fusion Max obtient 60 sur le Coding Agent Index d'Artificial Analysis, à deux points de Claude Code avec Opus 5.5, pour environ la moitié du coût moyen par tâche2. Ce résultat est une déclaration de l'éditeur, relayée par la presse spécialisée. Aucune évaluation indépendante de la version générale n'avait été publiée au moment de la rédaction, comme le relèvent Techjack Solutions et Sumus.
Il faut donc lire ce « moitié prix » comme une moyenne sur un benchmark public. Sur un dépôt Odoo, avec ses héritages de modèles, ses vues XML et ses règles d'accès, la proportion de tâches qui escaladent en Cascade peut être très différente.
Ce qui inquiète un praticien
Le premier point concerne la traçabilité. Explainx note que le changelog ne décrit pas de trace par requête des décisions de routage. Un relecteur qui reçoit une pull request ne saura donc pas forcément si le diff vient d'un petit modèle validé par un contrôle automatique ou d'un modèle haut de gamme.
Le deuxième point touche à la reproductibilité. Avec un modèle fixe, on peut rejouer une tâche et comparer. Avec un routeur qui change de stratégie selon la demande, deux exécutions identiques peuvent suivre deux chemins. Le débogage s'allonge d'autant, et Sumus range la composition future du pool de modèles parmi les questions ouvertes.
Le troisième point porte sur la frontière d'escalade. Techjack Solutions estime que l'annonce ne traite pas les modes d'échec du schéma Cascade. Si le contrôle qualité accepte un brouillon médiocre, la tâche ne remonte jamais vers le modèle fort et l'économie se paie en revue humaine.
Enfin, une précision évite un malentendu fréquent. Même avec la sélection de modèles locaux, la décision de routage se fait dans le cloud, selon les résumés du changelog associé. Une session Fusion ne fonctionne donc pas hors ligne, ce qui compte pour les clients soumis à des contraintes de souveraineté.
Comment l'aborder dans une équipe Odoo
Nous conseillons de traiter Fusion comme un réglage d'infrastructure plutôt que comme une préférence personnelle. Concrètement, quatre décisions méritent d'être prises avant le 30 novembre :
- Fixer l'effort par défaut au niveau de l'organisation. Laisser chaque développeur choisir Max aboutit vite à une consommation imprévisible.
- Restreindre le pool via les politiques de modèles. Si votre contrat client exclut certains fournisseurs, Fusion ne doit pas pouvoir les appeler.
- Mesurer pendant la période de remise. Comparez sur deux semaines la consommation et le taux de retouche en revue entre Fusion et votre modèle habituel, sur les mêmes types de tickets.
- Conserver un modèle fixe pour les tâches sensibles. Les migrations de données, les règles d'accès et les calculs comptables gagnent à rester sur un chemin reproductible.
La remise de 30 % rend l'essai peu coûteux. Elle rend aussi les chiffres du mois de novembre trompeurs : un budget calibré sur des prix réduits devra être revu en décembre.
Notre lecture
Fusion déplace une décision technique du développeur vers l'éditeur. Pour une PME qui n'a ni le temps ni l'envie de suivre la valse des modèles, c'est un vrai service : le routage absorbe une partie de la veille. Pour une ETI qui doit justifier ses choix auprès d'un client ou d'un auditeur, la perte de visibilité sur le modèle utilisé constitue un risque qu'il faut compenser par des politiques strictes et par une revue qui ne présume rien de la provenance du code.
Le score de 60 et le « moitié prix » restent des affirmations de GitHub tant qu'aucun test indépendant ne les confirme. Notre recommandation est simple : activez Fusion sur un périmètre limité, mesurez votre propre taux d'escalade et vos retouches, puis décidez en décembre avec des chiffres qui sont les vôtres. Si vous structurez déjà vos revues autour de l'IA, notre article sur la revue du code produit par l'IA donne quelques repères complémentaires.
Sources
- GitHub Changelog, Route and orchestrate models with GitHub Copilot Fusion : https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion
- Unite.ai, GitHub Makes Copilot Fusion Generally Available at Universe 2026 : https://www.unite.ai/github-makes-copilot-fusion-generally-available-at-universe-2026/
- DEV Community, From Project HydraFusion to GitHub Copilot Fusion : https://dev.to/pwd9000/project-hydrafusion-github-copilot-stops-picking-a-model-and-starts-building-a-workflow-4lh5
- Cellcog, GitHub Copilot Fusion: How It Routes, What It Costs : https://cellcog.ai/blog/github-copilot-fusion/
- Techjack Solutions, GitHub Copilot Fusion Reaches General Availability : https://techjacksolutions.com/ai-brief/github-copilot-fusion-ga-universe-2026-multi-model-routing/
- Sumus, GitHub Copilot Fusion: What It Is, How Routing Works & Cost : https://sumus.im/blog/github-copilot-fusion
- Explainx, Copilot Fusion GA: Half the Cost of Claude Code? : https://explainx.ai/blog/github-copilot-fusion-generally-available-effort-levels-single-cascade-critique-30-percent-discount-2026
- Datastudios, GitHub Copilot Fusion: automatic model routing, effort levels, pricing and availability : https://www.datastudios.org/post/github-copilot-fusion-generally-available-automatic-model-routing-all-plans
Footnotes
-
GitHub Universe 2026 s'est tenu les 28 et 29 octobre à San Francisco. La disponibilité générale de Fusion est annoncée dans le changelog GitHub du 28 octobre 2026. ↩
-
Le Coding Agent Index d'Artificial Analysis est un benchmark public d'agents de code. Le score cité est communiqué par GitHub et n'a pas été reproduit indépendamment à la date de publication. ↩