L’API de métriques Copilot sépare le BYOK et les modèles d’entreprise : le BYOK local est un minimum sans détail par modèle ; les anciens jours de rapport ne reçoivent pas rétroactivement le marqueur is_custom_enterprise_model

Le 3 novembre 2026, le journal des modifications de GitHub a annoncé que l’API de métriques d’usage de Copilot affiche désormais séparément l’usage « apportez votre propre clé » (BYOK), pour que les administrateurs le distinguent de l’usage des modèles hébergés par Copilot. Jusqu’ici, les modèles locaux et personnalisés portaient souvent le même nom que ceux de Copilot, et l’usage BYOK se fondait dans les totaux hébergés. La mise à jour sépare le BYOK en deux types. Le BYOK local est configuré par les développeurs dans leur propre client. Les modèles personnalisés d’entreprise sont configurés par les administrateurs dans les paramètres GitHub. Les deux apparaissent dans les rapports d’entreprise et d’organisation, au niveau utilisateur et agrégé, sur 1 jour et sur 28 jours.

Le BYOK local couvre la clé de fournisseur d’un développeur et les modèles locaux servis par des outils comme Ollama, Foundry Local, LM Studio et llama-server. Les requêtes partent de Copilot CLI ou de l’application GitHub Copilot directement vers la clé de fournisseur ou le modèle local du développeur, sans passer par GitHub. Les champs sont used_local_byok, qui indique si un utilisateur a fait au moins une requête BYOK locale dans Copilot CLI ou l’application Copilot ce jour-là (rapports utilisateur) ; totals_by_local_byok, qui donne les nombres de sessions, requêtes, invites et jetons par byok_kind (local_managed, local_user, local_auto ou remote_user) et par surface (copilot_cli ou copilot_app) ; et les nombres d’utilisateurs BYOK locaux actifs par jour, semaine et mois dans les rapports agrégés.

Les modèles personnalisés d’entreprise sont configurés par les administrateurs dans les paramètres GitHub, et les requêtes passent par GitHub vers votre fournisseur. Le nouveau champ is_custom_enterprise_model est un booléen sur chaque entrée de modèle de totals_by_client, vrai lorsque la requête a utilisé un modèle personnalisé configuré pour l’entreprise ou l’organisation. GitHub observe ces requêtes côté serveur : le champ couvre donc tous les clients, y compris les IDE. Un modèle utilisé à la fois comme modèle hébergé par Copilot et comme modèle personnalisé apparaît en deux entrées, et les entrées de modèles personnalisés portent de vrais nombres de requêtes et de jetons.

Cela aide la gouvernance et l’analyse des coûts. Les administrateurs voient qui envoie des requêtes vers ses propres clés de fournisseur, des modèles locaux ou des modèles personnalisés d’entreprise, et le comparent à leur politique BYOK. Ils séparent l’usage hébergé par Copilot de l’usage facturé par leur propre fournisseur ou exécuté sur des modèles locaux gratuits, de sorte que le coût par utilisateur ne reflète que ce que Copilot fournit. Ils peuvent aussi voir l’usage de tous les outils dans une seule vue. Les champs sont toutefois des nombres de sessions, de requêtes, d’invites et de jetons ; l’article ne décrit pas de champ en dollars, ce n’est donc pas une facture.

Plusieurs limites figurent dans les « notes importantes ». D’abord, les totaux existants ne changent pas : l’usage BYOK était déjà compté, le BYOK local est un sous-ensemble de totals_by_cli et totals_by_copilot_app, et l’usage des modèles personnalisés figure déjà dans totals_by_client. Ensuite, le BYOK local est un minimum, car ces champs reposent sur la télémétrie du client et sous-comptent si elle est désactivée, et les jetons peuvent être sous-comptés parce que certains fournisseurs locaux ne les déclarent pas. Les comptes des modèles personnalisés d’entreprise sont observés côté serveur et n’ont pas cette limite. Troisièmement, les noms de modèles suivent la normalisation existante, les noms non reconnus apparaissent comme unknown, et le BYOK local n’est pas ventilé par nom de modèle. Quatrièmement, il n’y a pas de rétroactivité : les jours de rapport antérieurs n’ont pas is_custom_enterprise_model, et l’article ne dit pas si ces jours ont les champs du BYOK local. Enfin, l’accès est réservé aux propriétaires d’entreprise, aux gestionnaires de facturation, aux propriétaires d’organisation et aux titulaires d’un rôle personnalisé avec la permission View Copilot Metrics, et la politique de métriques d’usage de Copilot doit être activée.

La règle du sous-ensemble a une conséquence pratique : le double comptage. Comme le BYOK local est déjà inclus dans totals_by_cli et totals_by_copilot_app, et l’usage des modèles personnalisés déjà dans totals_by_client, un tableau de bord qui ajoute les nouveaux champs aux anciens totaux compterait deux fois les mêmes requêtes. Les nouveaux champs sont des tranches à soustraire ou à filtrer, pas des lignes à ajouter. Les deux types diffèrent aussi par leur fiabilité. Les comptes des modèles personnalisés sont observés côté serveur par GitHub, tandis que ceux du BYOK local viennent d’une télémétrie client qu’un développeur ou une politique peut désactiver : une courbe de BYOK local qui baisse peut signifier moins d’usage ou moins de télémétrie, et le rapport seul ne permet pas de trancher.

La documentation REST d’appui est plus précise sur les points d’accès. Les rapports sont des fichiers NDJSON obtenus par des liens signés à durée limitée. Les points d’accès d’entreprise exigent que la politique « Copilot usage metrics » soit sur Enabled everywhere pour l’entreprise. La permission fine s’appelle « View Enterprise Copilot Metrics » pour l’entreprise et « View Organization Copilot Metrics » pour l’organisation, et l’historique remonte jusqu’à un an, depuis le 10 octobre 2025. Cette page REST ne définit pas elle-même les nouveaux champs BYOK : dans les sources captées, seul le journal des modifications les décrit, et son nom de permission « View Copilot Metrics » ne correspond pas exactement aux deux noms de la documentation. L’article ne donne aucune correspondance : vérifiez les paramètres de votre propre compte GitHub avant de configurer l’accès.