Michael JohnsonDepuis le 3 novembre 2026, les administrateurs d’organisations et d’entreprises peuvent consulter séparément dans les rapports GitHub Copilot l’utilisation de leurs propres clés et des modèles personnalisés d’entreprise. La mise à jour de l’API des métriques d’utilisation de Copilot permet de distinguer les requêtes adressées aux modèles hébergés par GitHub de celles passant par le BYOK — « apportez votre propre clé » — ou par un modèle configuré par l’organisation.
Pour les entreprises, ce changement améliore concrètement le suivi : les dépenses liées à un fournisseur externe et à une exécution locale peuvent être séparées de l’utilisation des modèles gérés par GitHub. Les responsables et les administrateurs disposent d’une vue plus utile pour contrôler les méthodes d’utilisation de l’IA au sein des équipes. GitHub précise que les nouveaux champs isolent le BYOK des totaux existants sans modifier les compteurs eux-mêmes.
Les scénarios distingués par l’API
GitHub distingue deux cas de BYOK. Avec le BYOK local, le développeur configure sa propre clé ou un modèle local dans Copilot CLI ou l’application GitHub Copilot ; la requête est envoyée directement au fournisseur ou au serveur local. Pour ces requêtes, GitHub ajoute le champ utilisateur used_local_byok, les agrégats totals_by_local_byok et des compteurs du nombre d’utilisateurs actifs utilisant le BYOK local.
Parmi les modèles et outils locaux, GitHub cite Ollama, Foundry Local, LM Studio et llama-server. Les nouveaux champs détaillés sur le BYOK local concernent Copilot CLI et l’application Copilot : ils ventilent les sessions, les requêtes, les invites et les jetons selon le type de BYOK et l’interface utilisée, si le fournisseur transmet les données correspondantes. L’utilisation du BYOK local n’est pas ventilée par nom de modèle : le rapport indique donc l’existence et le volume de cette activité, mais pas le modèle local précis.
Le deuxième scénario concerne un modèle personnalisé d’entreprise, défini par un administrateur dans les paramètres de l’organisation ou de l’entreprise, auquel les requêtes sont acheminées par GitHub vers le fournisseur. GitHub a ajouté à cette fin le champ booléen is_custom_enterprise_model aux enregistrements de modèles dans totals_by_client. Ces requêtes étant observées côté serveur, le champ couvre différents clients, y compris les IDE.
Ce qui change dans l’utilisation des rapports
Auparavant, l’utilisation du BYOK pouvait être confondue avec les indicateurs des modèles hébergés par Copilot, en particulier lorsque les modèles avaient des noms similaires. Les nouveaux champs permettent de séparer ces catégories lors de la vérification des règles internes et de l’analyse de l’utilisation. GitHub indique que les données sont disponibles dans des rapports sur un et 28 jours, au niveau utilisateur ainsi que dans les agrégats de l’organisation ou de l’entreprise.
L’administrateur peut commencer par déterminer à quelle question le rapport doit répondre : qui utilise sa propre clé, quelle part des requêtes est adressée aux modèles locaux et dans quelle mesure cela modifie l’estimation des coûts. Il peut ensuite comparer les nouveaux champs aux indicateurs actuels et aux règles internes relatives au BYOK. Cela fournit une base plus concrète pour discuter du choix des modèles et de leur coût qu’un simple compteur d’activité Copilot.
L’accès aux métriques dépend du rôle : l’API est destinée aux propriétaires d’entreprise, aux responsables de facturation d’entreprise, aux propriétaires d’organisation et aux utilisateurs disposant du droit View Copilot Metrics. La stratégie d’utilisation des métriques Copilot doit également être activée. Ces données indiquent l’activité enregistrée, et non la qualité des réponses ou l’adéquation d’un modèle à une tâche donnée.
Pourquoi la précision des deux nouveaux indicateurs diffère
Le BYOK local a une limite de suivi précise : GitHub calcule ses champs à partir de la télémétrie côté client. Si celle-ci est désactivée, le nombre de ces requêtes sera inférieur au nombre réel ; certains fournisseurs locaux ne communiquent pas non plus le nombre de jetons. Ces données sont donc utiles pour détecter l’utilisation et en estimer l’ampleur, mais elles ne permettent pas un rapprochement financier exact.
Les modèles personnalisés d’entreprise sont suivis côté serveur et, selon GitHub, ne sont pas concernés par cette réserve liée à la télémétrie. Un même modèle peut apparaître sur deux lignes distinctes s’il est utilisé à la fois comme modèle hébergé par Copilot et comme modèle personnalisé d’entreprise. Cette séparation évite de fusionner des canaux différents au seul motif qu’ils portent le même nom.
Il faut aussi tenir compte d’un aspect temporel : GitHub n’ajoute pas le champ is_custom_enterprise_model aux rapports des jours précédant la publication de la mise à jour. Les données historiques ne sont pas automatiquement comparables aux nouvelles catégories ; pour analyser les tendances, indiquez la date de transition et comparez les périodes en tenant compte de l’évolution du schéma.
Cette mise à jour aide les organisations à mieux classer l’utilisation de Copilot avec leurs propres modèles ou des modèles locaux. Pour budgéter le BYOK local, il faudra toujours tenir compte des données manquantes de télémétrie côté client et des données du fournisseur ; les modèles personnalisés d’entreprise disposent désormais d’un indicateur distinct côté serveur dans le rapport.
