11 min de lecture - Mesures BYOK de Copilot : réconciliez les écarts avant de piloter l’usage

GitHub a ajouté les données « Bring Your Own Key » (BYOK) et celles des modèles personnalisés d’entreprise à l’API de mesure de Copilot le 3 novembre 2026. Un responsable de l’ingénierie peut désormais isoler de l’usage hébergé par Copilot les requêtes par clé personnelle ou modèle local émises depuis Copilot CLI et l’application Copilot, ainsi que les requêtes vers des modèles personnalisés d’entreprise depuis tous les clients, IDE compris. Les totaux existants ne changent pas et incluent toujours cet usage.

Ces nouveaux champs résolvent un problème d’attribution, sans constituer pour autant un registre complet des usages de l’IA. GitHub précise que les chiffres du BYOK local dépendent de la télémétrie du client, qu’ils peuvent être sous-évalués lorsque cette télémétrie est désactivée et qu’ils peuvent omettre des jetons si le fournisseur local ne les communique pas. Un rapport peut donc décrire correctement ce qu’il a observé tout en restant incomplet sur ce qui s’est réellement passé.

Les équipes de sécurité et de finance doivent traiter l’API comme une pièce d’une réconciliation, pas comme l’unique inventaire ni comme la facture de référence.

Ce que GitHub a ajouté, et où se trouve la limite

La note de publication du 3 novembre de GitHub sépare deux parcours.

Le BYOK local couvre la clé d’un développeur ou un modèle servi au moyen d’outils tels qu’Ollama, LM Studio, Foundry Local ou llama-server. Les nouveaux rapports peuvent indiquer qu’un BYOK local a été utilisé, puis ventiler les requêtes, les sessions et les jetons déclarés par type de BYOK et par surface, Copilot CLI ou application Copilot ; les IDE ne sont pas encore couverts. Ils n’identifient pas le modèle local par son nom.

Les modèles personnalisés d’entreprise empruntent une autre voie. Les administrateurs les configurent dans GitHub, puis les requêtes passent par GitHub avant d’atteindre le fournisseur. GitHub marque ces entrées comme personnalisées et observe côté serveur leurs requêtes et leurs jetons, y compris depuis les environnements de développement. Un même nom de modèle peut apparaître une fois comme modèle hébergé par Copilot et une seconde fois comme modèle personnalisé de l’entreprise.

La qualité des preuves diffère donc selon le parcours. GitHub décrit les chiffres du BYOK local comme une borne basse, car la télémétrie du client peut être désactivée et certains fournisseurs locaux ne renvoient pas l’usage des jetons. Les comptes des modèles personnalisés d’entreprise ne subissent pas cette limite liée au client. L’indicateur de modèle personnalisé n’est pas rétroactif : les jours antérieurs à la mise à jour n’incluent pas is_custom_enterprise_model. Un nom de modèle personnalisé non reconnu peut apparaître sous la valeur unknown.

La documentation générale sur les mesures Copilot pose d’autres limites. La plupart des détails dépendent de la télémétrie du client. Des règles réseau, un proxy ou les réglages du poste peuvent bloquer ces événements, alors qu’un signal côté serveur continue de compter la personne parmi les utilisateurs actifs. Les ventilations par fonctionnalité, langage et lignes de code peuvent alors rester vides : une ventilation vide peut donc signifier « non observé » plutôt que « non utilisé ». Certaines surfaces, comme Copilot Chat sur GitHub.com et GitHub Mobile, sont exclues des données, et le détail par application d’agent n’apparaît que dans les API et les exports NDJSON, pas dans les tableaux de bord d’usage.

Conservez quatre registres plutôt qu’un seul tableau de bord

Une vision défendable de l’IA destinée aux développeurs repose sur quatre registres qui répondent chacun à une question différente.

Ne forcez pas ces registres à coïncider. Une licence ne prouve pas l’usage, un modèle local peut fonctionner sans facture, et le fournisseur peut facturer des requêtes émises hors de Copilot. Même un grand nombre de requêtes ne prouve aucun résultat accepté.

L’inventaire doit conserver ces écarts. Le profil volontaire de gestion des risques de l’IA générative du NIST suggère (action GV-1.6-003) de prendre en compte dans les entrées d’inventaire, entre autres éléments, les modèles de fondation sous-jacents, leurs versions et leurs modes d’accès, les rôles et responsabilités de supervision humaine, ainsi que les droits particuliers liés à la propriété intellectuelle, aux œuvres sous licence et aux données personnelles, privilégiées, propriétaires ou sensibles. Il ne présente pas le flux de télémétrie d’un fournisseur comme l’inventaire lui-même. L’API d’usage de Copilot couvre désormais les trois parcours, mais ses chiffres de BYOK local se limitent à Copilot CLI et à l’application Copilot et restent une borne basse : elle ne peut pas tenir lieu d’inventaire à elle seule.

Définissez un contrat d’événement réduit

La réconciliation échoue lorsque chaque source nomme différemment la même activité. Avant de construire le tableau de bord, convenez d’un contrat minimal :

• une fenêtre temporelle et un identifiant pseudonyme de personne ou d’équipe ;
• la surface cliente, le fournisseur, le modèle demandé et le modèle renvoyé lorsqu’ils sont disponibles ;
• le mode d’accès : hébergé par Copilot, personnalisé par l’entreprise, clé personnelle ou point de terminaison local ;
• l’état de la requête, les jetons d’entrée et de sortie lorsque la source les fournit ;
• le dépôt ou la classe de travail, la décision de règle et un identifiant de corrélation ;
• le système source, la méthode de collecte et un champ qui signale une estimation ou une donnée manquante.

N’intégrez pas par défaut les instructions, le code généré ou les arguments d’outils. Ils peuvent contenir du code source, des données personnelles, des secrets ou des informations client. Conservez seulement les identifiants et les comptages nécessaires à la finalité déclarée, avec des accès et une durée de conservation adaptés.

Le registre OpenTelemetry des attributs d’IA générative propose des noms communs pour le fournisseur, l’opération, le modèle demandé, le modèle renvoyé et l’usage des jetons. Le registre indique désormais que ces attributs ont été déplacés vers un dépôt dédié aux conventions GenAI et marque encore au statut « Development » les valeurs connues des opérations et des fournisseurs : figez donc la version ou le commit adopté plutôt que de supposer que toutes les bibliothèques émettent les mêmes champs. Le registre signale aussi le caractère sensible des messages et appels d’outils. Des noms communs facilitent les rapprochements ; ils n’autorisent pas à collecter le contenu.

Réconciliez chaque semaine en rendant l’incertitude visible

Commencez par une équipe d’ingénierie et une fenêtre fixe de sept jours. Exportez les usages Copilot, les licences et les règles applicables. Récupérez l’usage et la facturation des clés administrées auprès des fournisseurs, puis les compteurs agrégés de chaque passerelle locale approuvée. Reliez ensuite les registres selon le temps, l’équipe et le mode d’accès, sans écraser les valeurs sources.

Classez chaque écart au lieu de le combler en silence :

Qualifiez la couverture obtenue. Une équipe peut, par exemple, indiquer que les requêtes des modèles personnalisés ont été observées côté serveur, que l’activité BYOK locale constitue une borne basse et que les coûts fournisseurs ne couvrent que les clés administrées. Cette formulation est moins nette qu’un total unique, mais elle dit au décideur ce que le chiffre permet réellement de conclure.

Définissez un seuil de revue pour les écarts inexpliqués. Ce seuil dépend de la décision : la finance peut se concentrer sur une dépense non attribuée significative, tandis que la sécurité peut examiner tout fournisseur ou mode d’accès non approuvé. Cet article ne propose pas de pourcentage universel, car les sources n’en établissent aucun.

Ne confondez pas consommation et résultat

Les requêtes et les jetons décrivent une consommation. Ils ne montrent pas si le code a passé les tests, résisté à la revue ou raccourci le délai de livraison. La documentation de GitHub sépare les mesures d’usage des vues relatives à l’impact et à la génération de code ; même ces indicateurs demandent une interprétation prudente.

Reliez le registre à quelques résultats : pull requests acceptées, reprise demandée, défauts échappés, délai et retour arrière. Comparez des tâches similaires plutôt que de classer les développeurs selon leurs jetons. Les fournisseurs peuvent compter les jetons différemment, certains fournisseurs locaux n’en déclarent aucun, et une session longue peut correspondre à une tâche plus difficile.

Notre guide du coût par tâche acceptée explique comment intégrer la revue et la reprise au lieu de s’arrêter au prix de l’API. Le guide d’inventaire des agents traite de la responsabilité et de la classification des accès.

Une mise en œuvre sur deux semaines

Pendant les trois premiers jours, recensez licences Copilot, parcours BYOK approuvés, modèles personnalisés, comptes fournisseurs et points de terminaison locaux. Notez le responsable de chaque clé ou serveur sans copier le secret.

Durant le reste de la semaine, exportez les quatre registres d’une équipe pilote. Faites passer une requête connue par chaque parcours approuvé et vérifiez où elle apparaît. Dans un profil de test, si les règles l’autorisent, désactivez la télémétrie pour observer les données manquantes. Ne modifiez pas le poste de production d’un développeur.

La deuxième semaine, mettez en place le contrat d’événement et la table des écarts. Examinez les usages fournisseurs inexpliqués, les noms de modèles inconnus, les licences inactives et les traces sans résultat de travail. Terminez par une décision signée : étendre la collecte, corriger une lacune, réduire les parcours autorisés ou maintenir le pilote.

Le livrable est un registre qui indique l’activité observée, les coûts attribués, les usages encore hors couverture et la personne responsable du prochain contrôle.

Découvrez les services IA et d’ingénierie d’Exceev si votre équipe doit cartographier les accès à l’IA des développeurs, instrumenter un pilote ou relier l’usage à des résultats de livraison relus.

Sources et limites

Nous avons ouvert et vérifié chaque source ci-dessous les 5 et 6 novembre 2026.

• La note GitHub sur le BYOK et les modèles personnalisés est la source primaire pour la mise à jour, ses champs, l’absence de rétroactivité de l’indicateur de modèle personnalisé, le traitement des noms de modèles et ses limites de télémétrie.
• Le guide conceptuel des mesures Copilot décrit les surfaces, la télémétrie, les détails manquants et les exports.
• La référence GitHub des données d’usage définit les champs actuels des tableaux de bord, API et exports. La couverture du produit et les schémas peuvent évoluer.
• Le profil du NIST sur l’IA générative apporte un cadre indépendant et volontaire pour les inventaires d’IA. Il n’évalue pas GitHub Copilot et n’impose pas cette méthode de réconciliation.
• Le registre OpenTelemetry pour l’IA générative fournit des avertissements sur les données sensibles et renvoie vers le dépôt des conventions GenAI, qui contient désormais les définitions des champs. Ces conventions évoluent encore : vérifiez et figez la version adoptée.

Nous n’avons accédé ni à un environnement Copilot d’entreprise, ni à une facture fournisseur, ni à une passerelle de modèles locaux, et nous n’avons pas testé les nouveaux champs. Le modèle à quatre registres, les contrôles d’écarts et la séquence de deux semaines constituent l’analyse d’Exceev, pas des exigences de GitHub, du NIST ou d’OpenTelemetry. Cet article ne promet aucun résultat en matière de sécurité, de vie privée, de conformité, d’économie ou de productivité.