GitHub Copilot : prix, modèles et prise en main de Fusion

Informations vérifiées dans la documentation et les annonces de GitHub le 29 octobre 2026. Cette analyse s’appuie sur ces sources, et non sur un benchmark réalisé en conditions réelles.

Ce que change GitHub Copilot Fusion

GitHub Copilot Fusion prend en charge le choix du modèle et, lorsque c’est utile, la coordination entre plusieurs modèles. Imaginez un responsable technique qui décide si une modification demande une implémentation rapide, une revue ou un examen plus poussé. Vous gardez la main sur la tâche à accomplir et sur l’acceptation du code produit.

GitHub a lancé Fusion en disponibilité générale le 28 octobre 2026, en réunissant l’orchestration de Project HydraFusion et la sélection automatique de modèle Auto. Les sélections Auto, HydraFusion et HydraFusion Max existantes basculent vers les niveaux d’effort Fusion correspondants. La préversion de recherche d’octobre est donc le prédécesseur de Fusion, pas un produit distinct à utiliser en parallèle. Annonce de Fusion par GitHub.

Les schémas d’exécution définissent la répartition du travail :

• Single : un modèle traite directement la tâche.
• Cascade : une première proposition passe devant un évaluateur, qui l’accepte ou demande un traitement plus poussé.
• Critique : une première proposition reçoit une critique indépendante, puis son auteur la révise.

Ces schémas sont issus des recherches de GitHub sur HydraFusion. La documentation actuelle de Fusion décrit des évaluateurs qui travaillent en parallèle, puis dont les retours sont réunis. Cela ne signifie pas que chaque prompt déclenche tous les schémas. Fonctionnement de Fusion.

Corriger un libellé et enquêter sur une condition de concurrence ne devraient pas automatiquement mobiliser les mêmes moyens. Fusion effectue cet arbitrage au cours de la session. Notre guide du routage de modèles détaille le principe : confier le travail à des capacités adaptées, puis mesurer si ce choix a été utile.

Où utiliser Fusion et comment l’activer ?

Fusion s’utilise dans l’application Copilot, Visual Studio Code, Copilot CLI ou les IDE JetBrains. GitHub cite ces environnements et annonce une disponibilité dans les différentes offres Copilot. Cela ne garantit pas que tous les comptes aient accès aux mêmes niveaux d’effort : les modèles restent soumis à votre abonnement et aux règles applicables. Disponibilité actuelle.

Mettez votre client à jour avant de suivre ces instructions. Les anciens réglages de la préversion HydraFusion ne correspondent plus à la procédure d’activation de Fusion.

Dans l’application GitHub Copilot

Cliquez sur le nom du modèle sous le champ de saisie du prompt, activez Copilot Fusion, puis choisissez l’un des niveaux d’effort proposés. Pour revenir à un modèle précis, désactivez l’option et sélectionnez ce modèle. L’application mémorise votre choix pour les sessions suivantes. Sélection du modèle dans l’application.

Dans Visual Studio Code

Dans les paramètres, vérifiez que chat.copilot.dynamicAutoTiers.enabled est activé. Lancez une nouvelle conversation avec le Copilot harness, l’environnement d’exécution qui relie le modèle aux outils de l’agent. Sélectionnez Copilot Fusion dans le sélecteur de modèle, puis un niveau disponible. Le réglage ne crée aucun droit d’accès : le sélecteur peut continuer à afficher Auto si aucun niveau Fusion n’est accessible à votre compte. Configuration dans VS Code.

Dans GitHub Copilot CLI

Au cours d’une session interactive, saisissez /model, choisissez Fusion et son niveau d’effort, puis confirmez. Pour un premier essai bien délimité, GitHub documente la structure de commande suivante. Cet exemple demande une analyse sans modification des fichiers :

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

Il s’agit de l’option Fusion actuelle, sans l’ancien indicateur expérimental HydraFusion. Sélection du modèle dans la CLI.

Quels modèles Fusion peut-il utiliser ?

La liste de modèles Claude/GPT nommément cités correspond à un état daté, pas à une garantie de routage permanente. Dans sa mise à jour HydraFusion du 14 octobre 2026, GitHub mentionnait explicitement :

• Claude Opus 5.5 d’Anthropic.
• GPT-6 Astra d’OpenAI.
• GPT-6.1 Sol d’OpenAI.
• GPT-6 Luna d’OpenAI.

Cette mise à jour introduisait aussi HydraFusion Max et un effort de raisonnement plus poussé pour la rédaction et la revue. Ce sont les noms vérifiés dans l’annonce de la préversion. Mise à jour d’octobre sur les modèles disponibles.

La présentation actuelle de Fusion ne publie pas de liste fixe et exhaustive des modèles cloud utilisables. Elle précise que cette liste évolue et permet de voir les modèles employés en survolant le libellé d’effort sous une réponse. Le catalogue complet des modèles Copilot ne vaut donc pas promesse que Fusion puisse tous les solliciter. Fonctionnement actuel de la sélection de modèles.

Pour un responsable d’ingénierie, la liste qui compte est celle des modèles autorisés sur son propre compte. Les propriétaires d’entreprise peuvent ouvrir AI controls → Copilot → Models → Configure Copilot Fusion models. Ces choix restent soumis aux autres règles d’accès aux modèles qui s’appliquent à l’utilisateur. Contrôle des modèles en entreprise.

Une préversion distincte propose le routage vers des modèles locaux. Elle prend en charge certaines configurations utilisant MAI Code 1.1 Flash ou Qwen3.8 Flash Next avec Standard. Ajouter un modèle local quelconque ne le rend pas éligible. Et l’inférence locale ne permet pas d’utiliser Fusion hors ligne : le routage s’effectue toujours dans le cloud. Limites de la prise en charge des modèles locaux.

Commencez par Standard, puis ajustez l’effort

Partez de Standard ; ne passez à High ou Max que si la revue supplémentaire répond à un besoin précis. GitHub destine Standard au développement quotidien, High aux tâches complexes et au raisonnement approfondi, et Max aux travaux les plus exigeants. Définition des niveaux d’effort.

Les tâches proposées ci-dessous sont des recommandations éditoriales, pas des résultats de performance mesurés :

Une demande vague d’amélioration de toute une application constitue un mauvais essai de Max. Sans critère de réussite, impossible de savoir si le raisonnement supplémentaire a servi. Ciblez un problème observable, par exemple supprimer un chemin de requête dupliqué tout en préservant le comportement des nouvelles tentatives.

Fusion Max désigne un niveau d’effort, pas un abonnement obligatoire. Fusion Fast existe également, mais l’utilisateur ne peut pas le sélectionner et son usage se limite au chat intégré dans l’éditeur de VS Code. Niveaux d’effort disponibles.

GitHub Copilot : prix de Fusion et crédits IA

La facturation dépend du travail effectué par les modèles sélectionnés. Les tokens d’entrée, de sortie et mis en cache sont tarifés selon le modèle, avec des frais d’écriture du cache lorsqu’ils s’appliquent, puis convertis en crédits IA. Aucun coût fixe en crédits n’est publié pour une tâche Fusion. Mécanismes de facturation de GitHub.

Fusion ne facture pas de frais d’orchestration distincts. Les offres Copilot payantes bénéficient actuellement d’une réduction de 30 % sur le coût des modèles utilisés par Fusion jusqu’au 30 novembre 2026. Facturation de Fusion. Retrouvez le détail des abonnements et des quotas inclus dans notre guide des tarifs de GitHub Copilot.

La rédaction d’une première proposition, sa critique et sa révision contribuent chacune à la consommation. L’effort de raisonnement, la taille du contexte, l’activité des outils et la mise en cache jouent aussi un rôle. Une exécution en plusieurs passes peut donc consommer davantage de crédits qu’une requête adressée à un seul modèle, même si le routage fonctionne comme prévu. Explications de VS Code sur la consommation de crédits IA.

Pendant votre essai, comptabilisez aussi les tentatives infructueuses et les prompts de correction. Une première proposition peu coûteuse qui exige de multiples reprises peut revenir plus cher qu’une exécution plus onéreuse produisant une modification acceptable. À l’inverse, payer une critique pour un simple renommage peut n’apporter aucun bénéfice. Comparez le travail mené à bien, pas le prix de la réponse la moins chère.

Que montre vraiment le benchmark de GitHub ?

GitHub annonce un résultat prometteur, mais il ne permet pas de calculer les économies sur votre dépôt. Dans son annonce Universe, GitHub déclare :

L’évaluation citée est l’Artificial Analysis Coding Agent Index. Il s’agit d’un résultat de benchmark rapporté par GitHub, pas d’un test indépendant réalisé pour cet article. Annonce de GitHub Universe.

Le changelog détaillé précise que la comparaison porte sur Claude Code avec Opus 5.5 Max et que la mesure de coût correspond au coût API moyen par tâche. C’est une affirmation bien plus précise que de dire que Fusion divise une facture Copilot par deux. Contexte du benchmark de GitHub.

On peut en déduire que l’orchestration permet peut-être d’obtenir de bons résultats plus efficacement qu’en choisissant systématiquement une configuration lourde. En conclure que chaque correction de bug sera plus rapide ou moins chère n’est pas étayé. La nature de vos tâches, vos critères d’acceptation et le travail de correction détermineront si le gain se retrouve chez vous. La promotion temporaire sur la facturation et la comparaison du benchmark sont également deux éléments distincts : ne les additionnez pas pour promettre une économie.

Ce qui change pour les développeurs, les responsables et les acheteurs

Les développeurs peuvent déléguer le choix du modèle. Si vous interrompez régulièrement votre travail pour décider quel modèle devrait traiter la tâche suivante, Fusion mérite un essai ciblé. Décrivez clairement le problème, le comportement attendu et les critères de revue. Déléguer la sélection doit réduire les interruptions, sans rendre la tâche moins précise.

Les responsables d’ingénierie ont besoin de règles sur l’effort et d’un suivi des modifications acceptées. Une base utile : Standard pour le travail courant, High pour les modifications délimitées qui demandent une revue, et Max sur décision explicite. Notez pourquoi le passage à un niveau supérieur a aidé. Sinon, choisir le niveau le plus élevé risque de devenir une habitude sans preuve que cela améliore le travail livré.

Les acheteurs qui comparent Copilot à Claude Code ou Cursor doivent tester le workflow qu’ils adopteraient. Un benchmark justifie d’évaluer une option, pas de faire migrer une organisation. Mesurez la charge de revue, l’adéquation au dépôt et les résultats obtenus, en plus des crédits consommés. Notre comparatif Claude Code et GitHub Copilot éclaire le choix global ; Fusion n’en modifie qu’un aspect.

Quelles promesses relativiser, et quand désactiver Fusion ?

Faire intervenir davantage de modèles ne vous décharge pas de la responsabilité du diff. GitHub documente une limite particulièrement importante : des propositions écartées peuvent laisser des modifications dans les fichiers. Fusion ne dispose pas non plus de sa propre fenêtre de contexte combinée et ne lance pas de sous-agents. Limites de Fusion.

Désactivez Fusion lorsque vous avez besoin d’un modèle précis pour une comparaison contrôlée, une investigation reproductible ou un workflow explicitement approuvé. Fixez le choix du modèle pour que le routage n’ajoute pas une variable. Cela ne rend pas le modèle de langage déterministe ; vous éliminez simplement une source de variation.

Si une configuration connue, avec un modèle précis, traite déjà votre tâche bien délimitée en demandant peu de corrections, rien ne justifie de changer tant qu’un essai n’a pas montré de gain concret. Vous n’avez aucune obligation de passer à Fusion.

Attendez également si votre workflow doit fonctionner hors ligne, ou si vous ne savez pas définir et contrôler une modification acceptable. Pour de toutes petites demandes courantes, le meilleur réglage peut être de conserver Standard sans utiliser les niveaux d’effort qui mobilisent beaucoup d’orchestration. Désactiver Max et désactiver Fusion sont deux décisions différentes.

Tutoriel GitHub Copilot Fusion : testez un dépôt cette semaine

Limitez l’essai pour pouvoir examiner chaque résultat. Choisissez un dépôt que vous connaissez, puis comparez Fusion à la configuration de modèle que vous utilisez déjà.

Cette semaine, affectez un développeur et une personne chargée de la revue à ce dépôt, convenez des critères de validation et ne choisissez le réglage par défaut qu’après avoir examiné les modifications obtenues. Une décision documentée clairement est plus utile qu’une capture d’écran de la réponse la plus rapide.

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur le choix et l’utilisation des outils de développement IA.