GitHub a annoncé le 4 septembre 2026 le Project HydraFusion, un projet disponible en préversion de recherche dans GitHub Copilot pour coordonner des modèles d’intelligence artificielle de plusieurs fournisseurs lors de l’exécution de tâches de programmation. Au lieu de sélectionner à l’avance un seul modèle, HydraFusion élabore un plan d’exécution et détermine si la tâche nécessite une solution directe, une révision indépendante ou une transmission à un modèle plus performant.
Cette initiative intervient après la fonctionnalité Auto model selection lancée plus tôt dans l’année par GitHub pour choisir le modèle le mieux adapté à chaque tâche. Mais HydraFusion étend cette idée, en passant de la sélection d’un modèle à la construction d’un workflow complet qui équilibre la qualité du résultat, le coût et le temps de réponse, tandis que la complexité opérationnelle reste masquée pour le développeur qui choisit HydraFusion comme n’importe quel autre modèle dans Copilot.
Trois parcours pour exécuter la tâche
Le système évalue des signaux liés au raisonnement, à la génération de code, au débogage et à l’utilisation des outils, puis choisit l’un des trois modes d’exécution suivants :
- Single : un seul modèle prend directement en charge la résolution de la tâche lorsque ses capacités sont suffisantes.
- Cascade : un modèle plus efficace commence par formuler la solution, puis une passerelle de qualité décide de l’accepter ou de transmettre la tâche à un modèle plus puissant.
- Critique : un modèle formule une solution initiale, puis un modèle indépendant d’une autre famille l’examine dans un contexte en lecture seule, avant que le premier modèle n’effectue une seule révision de la solution.
GitHub affirme que l’objectif de cette sélection est de n’utiliser des appels supplémentaires que lorsqu’ils sont censés améliorer le résultat. Ainsi, le parcours direct préserve la rapidité et l’efficacité, tandis que les deux autres ajoutent une révision ou une transmission pour les tâches qui peuvent en bénéficier.
Ce que les tests ont montré
GitHub a évalué des politiques fixes de HydraFusion sur trois tests d’agents de programmation : TerminalBench 2.1, DeepSWE et CheckpointBench, un test interne fondé sur de véritables sessions dans GitHub Copilot. Les résultats ont été comparés à deux références : Claude Opus 5 et GPT-5.6 Sol, avec des entrées, des outils, des limites d’exécution, des hypothèses tarifaires et des conditions d’évaluation identiques.
Dans TerminalBench 2.1, HydraFusion a obtenu une amélioration de 4,9 points de pourcentage de la qualité des tâches vérifiées, tout en réduisant de 67 % le coût estimé du workflow par rapport à Claude Opus 5. Dans DeepSWE, qui se concentre sur des tâches d’ingénierie logicielle à l’échelle d’un dépôt et sur la compréhension des dépendances entre les fichiers, le système s’est rapproché d’Opus 5 avec un écart de 1,5 point de pourcentage, pour un coût inférieur de 36 %. Quant à CheckpointBench, l’écart de qualité n’était que de 0,1 point de pourcentage, contre une réduction des coûts de 65 %.
Le calcul des coûts inclut toutes les étapes de l’exécution, notamment la formulation, la révision, la modification, la transmission, les nouvelles tentatives et les plans de repli. Toutefois, GitHub décrit ces résultats comme des tests hors ligne, limités par les versions des tests, les paramètres des workflows, l’ensemble de modèles et les hypothèses tarifaires utilisés.
Contrôles opérationnels et limites de la préversion
GitHub a conçu HydraFusion autour de contrôles comprenant l’enregistrement du coût et de l’utilisation pour chaque étape, la définition de délais d’annulation et d’exécution, ainsi que l’isolation des étapes de révision dans des contextes qui ne disposent d’aucun outil et ne modifient pas le dépôt. Le système vérifie également au préalable les définitions des workflows, la liaison des modèles, le comportement des solutions de remplacement et la disponibilité des modèles, et n’applique aucune correction si l’opération est annulée ou si la vérification échoue.
GitHub recommande actuellement de commencer l’expérimentation avec des tâches de programmation importantes et bien définies, envoyées dans une seule invite à Copilot en mode d’exécution automatique. L’entreprise prévoit ensuite de se concentrer sur l’amélioration des performances des sessions comportant plusieurs rôles et de plus longue durée. Elle prévient également que les modèles, les workflows, les noms, la disponibilité et le comportement du produit peuvent changer pendant la période de préversion.
Lecture éditoriale : du choix du modèle à la conception du workflow
Le changement le plus important ici n’est pas l’ajout d’un nouveau modèle, mais le transfert de la décision d’exécution du développeur vers une couche de coordination qui détermine quand une seule tentative suffit et quand la tâche justifie le coût d’une révision ou d’une transmission. Si les résultats des tests se vérifient dans l’utilisation réelle, cela pourrait offrir aux développeurs une qualité proche de celle des modèles les plus puissants pour certaines tâches, sans en payer le coût à chaque requête.
Mais les chiffres ne démontrent pas encore une supériorité générale dans tous les modes de programmation ; ils sont liés à des tests précis, à des politiques contrôlées et à des résultats hors ligne. Des questions restent ouvertes concernant le temps de réponse, la fiabilité, le comportement du système dans les sessions longues, l’efficacité de la mise en cache et la sécurité, autant d’aspects que GitHub a déclaré mesurer pendant la préversion.