Pendant longtemps, utiliser une IA pour développer revenait à choisir un modèle : rapide, économique, puissant ou spécialisé. Cette logique commence à changer. Le développeur choisit de plus en plus un niveau de service attendu, tandis qu’un routeur sélectionne la ressource adaptée à chaque tâche.
Trois objectifs plutôt qu’un modèle précis
Le 14 septembre 2026, GitHub a annoncé trois niveaux pour la sélection automatique de modèles dans Copilot : Efficiency, Balance et Intelligence. Le premier privilégie le coût, le deuxième équilibre coût, qualité et latence, et le troisième privilégie la qualité pour les tâches complexes.
Les trois niveaux utilisent le même ensemble de modèles disponibles. Copilot évalue ensuite chaque prompt afin de sélectionner un modèle adapté. Une tâche simple peut donc être confiée à un modèle léger même lorsque le niveau Intelligence est choisi.
Le changement important
Le modèle le plus puissant n’est pas nécessairement le meilleur choix pour chaque tâche. L’important devient de sélectionner le niveau de capacité suffisant pour obtenir un bon résultat.
Pourquoi le modèle le plus puissant partout est rarement optimal
Un développeur ne demande pas toujours la même chose à son assistant : renommer une variable, générer des tests, expliquer une fonction, rechercher une régression ou analyser une architecture complète ne réclament pas le même niveau de raisonnement.
GitHub recommande d’ailleurs de réserver les modèles de raisonnement plus coûteux aux tâches qui en ont réellement besoin. Utiliser systématiquement le modèle le plus capable peut augmenter la consommation sans améliorer le résultat et, dans certains cas, introduire des changements inutilement complexes.
Le routeur devient une couche à part entière
La partie la plus intéressante n’est donc peut-être plus le modèle, mais le routeur. La sélection automatique de Copilot tient compte de la complexité de la tâche, de l’état des modèles en temps réel, de leur disponibilité et des politiques autorisées par l’organisation.
Cette architecture ressemble à un mécanisme classique d’infrastructure : une demande arrive, un composant l’évalue puis l’oriente vers la ressource la plus appropriée.
Le coût devient une contrainte d’architecture
À mesure que les assistants IA sont utilisés quotidiennement, le coût ne peut plus être pensé uniquement au niveau de l’abonnement. Il faut aussi le regarder tâche par tâche.
Un résumé simple, une classification ou une modification ciblée peuvent souvent être traités par un modèle léger. Une investigation complexe, une analyse multi-fichiers ou une décision nécessitant davantage de contexte peuvent justifier un modèle de raisonnement plus coûteux.
La bonne question devient alors moins « quel est notre meilleur modèle ? » que « quel modèle est suffisant pour résoudre correctement cette tâche ? ».
La latence compte autant que la qualité
Un modèle très capable peut aussi demander davantage de temps. Pour une correction immédiate dans un IDE, quelques secondes supplémentaires sont perceptibles. Pour une analyse ponctuelle d’architecture ou d’incident, ce délai est beaucoup plus acceptable.
Le routage permet donc d’adapter non seulement la qualité, mais aussi le temps de réponse au contexte réel d’utilisation.
Automatiser sans créer une boîte noire
Automatiser le choix du modèle ne doit pas supprimer la visibilité. Il reste utile de savoir quel modèle a traité une requête, pourquoi certaines opérations coûtent davantage, et quels modèles une organisation autorise.
GitHub permet d’identifier le modèle réellement utilisé pour une réponse et exclut du routage automatique les modèles interdits par les politiques d’une organisation, notamment lorsqu’elles imposent des contraintes de résidence des données ou de conformité.
Une architecture utile au-delà de Copilot
Cette approche dépasse largement GitHub. Un service utilisant plusieurs modèles pourrait appliquer une logique simple :
- tâche déterministe : aucun LLM ;
- résumé ou classification simple : modèle léger ;
- analyse technique : modèle intermédiaire ;
- investigation complexe : modèle de raisonnement avancé ;
- résultat sensible : validation supplémentaire ou intervention humaine.
Le modèle devient alors une ressource située derrière une couche d’orchestration plutôt que le produit lui-même.
Tous les problèmes ne nécessitent pas une IA
C’est probablement le garde-fou le plus important. Vérifier l’expiration d’un certificat TLS, parser un enregistrement DNS ou contrôler un code HTTP peut être réalisé de manière déterministe.
Dans ces situations, un programme classique reste généralement moins coûteux, plus rapide, plus reproductible et plus facile à tester. L’IA devient intéressante lorsque la tâche nécessite de l’interprétation, du contexte ou une synthèse difficile à formaliser par des règles fixes.
Ce que cela signifie pour des outils comme TechAtelier
Pour une plateforme de contrôle technique, une architecture saine consiste donc à conserver les vérifications déterministes au cœur du système, puis à utiliser éventuellement l’IA pour expliquer, contextualiser ou prioriser les résultats.
Cette séparation évite de transformer des contrôles fiables en réponses probabilistes tout en permettant de bénéficier de l’IA là où elle apporte réellement de la valeur.
Vers des assistants qui choisissent eux-mêmes leurs ressources
L’arrivée du routage automatique montre que l’écosystème de l’IA pour les développeurs mûrit. La question pourrait progressivement passer de « quel modèle dois-je sélectionner ? » à « quel niveau de coût, de vitesse et de qualité suis-je prêt à accepter ? ».
Pour ceux qui construisent des services utilisant l’IA, cela introduit une nouvelle responsabilité : décider quand utiliser une IA, quel niveau de modèle mobiliser et combien cette décision peut coûter.
Sources
- GitHub Changelog — Configure cost and quality in Copilot auto model selection
- GitHub Docs — About Copilot auto model selection
- GitHub Docs — Optimizing your AI usage
Publié le 15 septembre 2026.