GitHub Copilot comptabilise l’utilisation via OpenCode et d’autres outils

Lorsqu’un développeur utilise Copilot par l’intermédiaire d’un outil tiers, les statistiques habituelles de l’IDE ne permettent pas toujours de savoir d’où proviennent les requêtes. Le 23 octobre 2026, GitHub a ajouté le champ totals_by_client à l’API Copilot usage metrics. Celui-ci regroupe l’utilisation des modèles par client, notamment OpenCode, Claude Code, Codex et Zed. Pour les administrateurs, c’est un moyen de mieux voir une partie de l’activité hors de l’éditeur et d’alimenter les discussions sur les règles internes d’utilisation de l’IA.

Ce que couvre cette nouvelle ventilation

Chaque élément de totals_by_client indique le client, le nombre d’appels réussis au modèle, le nombre de sessions et le volume de jetons de prompt et de sortie, ainsi que leur moyenne par appel. Le champ imbriqué totals_by_model ventile ces indicateurs par modèle et précise le mode de sélection : modèle choisi directement par l’utilisateur, sélection automatique ou modèle attribué par le produit.

Ce champ est disponible dans les rapports journaliers et sur 28 jours, aux niveaux entreprise, organisation et utilisateur pour chacun de ces niveaux. Dans le rapport agrégé sur 28 jours, la ventilation par client est fournie pour chaque journée. Il s’agit d’un ajout compatible avec l’existant : les anciens champs sont conservés et, en l’absence de données, le tableau reste vide. GitHub a présenté ces détails dans son annonce de la nouvelle ventilation des métriques.

Les questions auxquelles répondent ces données

Une équipe peut comparer le volume de requêtes et de jetons provenant de différents outils, puis décider quelles intégrations prendre en charge ou inclure dans ses règles d’entreprise. Par exemple, une hausse de la part d’OpenCode dans le rapport peut indiquer que les développeurs utilisent Copilot comme fournisseur de modèles en dehors de l’IDE. Le croisement des clients et des modèles aide à vérifier quels modèles génèrent effectivement la plus grande charge.

Pour analyser le budget, il est utile de commencer par les jetons et le nombre d’appels, puis de les comparer aux conditions tarifaires en vigueur. request_count compte les appels au modèle, pas les prompts des utilisateurs : un seul prompt peut générer plusieurs appels. Ce champ convient donc à l’analyse de la charge du service de modèles, mais pas au décompte direct des interactions des développeurs.

Intégrer la métrique au flux de travail

1. Vérifiez les accès. La politique Copilot usage metrics doit être activée. Les rapports sont accessibles aux propriétaires autorisés de l’entreprise ou de l’organisation, aux responsables de facturation et aux rôles disposant de l’autorisation de consulter les métriques concernées.
2. Comparez des périodes équivalentes. Utilisez un rapport journalier pour vérifier les changements après l’activation d’un outil et un rapport sur 28 jours pour observer la répartition de l’activité dans la durée. Dans chaque rapport, distinguez les appels, les jetons et les sessions : ce sont des mesures différentes de la charge.
3. Définissez des seuils d’analyse. Vous pouvez, par exemple, signaler un client dont la part des jetons ou des appels augmente sensiblement par rapport à sa propre période précédente. Fixez le seuil selon vos exigences et votre charge de référence ; GitHub ne propose pas de seuil universel.
4. Comparez le rapport aux paramètres d’accès. Cette nouvelle ventilation peut éclairer les discussions sur la prise en charge et la gestion des outils. Les rapports décrivent l’utilisation enregistrée, mais ne remplacent ni la vérification des autorisations ni l’inventaire des intégrations.

La documentation officielle de l’API Copilot usage metrics décrit les rapports, les autorisations requises et les ventilations disponibles. Avant d’automatiser le traitement, vérifiez-y le schéma à jour du rapport concerné et utilisez les autorisations appropriées.

Ce que signifie l’étiquette du client

GitHub détermine le client à partir de l’identifiant d’intégration que l’outil transmet avec la requête. L’entreprise précise que ce regroupement fournit une identification approximative : la valeur permet d’agréger le trafic, mais ne confirme à elle seule ni l’identité de l’utilisateur ni l’authenticité de l’application. Les clients inconnus sont regroupés sous other, tandis que les valeurs qui ne peuvent pas être normalisées peuvent apparaître sous unknown.

Il existe aussi des cas particuliers : les appels de Copilot code review et de Copilot cloud agent reçoivent le mode de sélection product_selected, puisque le produit choisit le modèle ; pour code review, le modèle peut apparaître comme unknown. Il faut en tenir compte lorsqu’on compare les ventilations par modèle entre différents outils.

En pratique, totals_by_client comble une lacune dans le suivi des appels serveur à Copilot effectués depuis des outils externes et fournit aux administrateurs de nouvelles données pour analyser la charge et décider des outils à prendre en charge. Pour obtenir une vision fiable de l’utilisation, confrontez ces détails aux autorisations et à d’autres sources internes, et considérez les noms des clients comme des catégories de trafic, non comme une preuve d’identité.