L'API REST de GitHub ajoute la recherche du centre de coûts par utilisateur, organisation, dépôt ou équipe d'entreprise, mais le journal et la documentation décrivent différemment l'accès des rôles personnalisés

Le 3 novembre 2026, GitHub a ajouté un point de terminaison d'API REST qui indique à quel centre de coûts appartient une ressource. Le journal des modifications dit que l'on peut interroger un utilisateur, une organisation, un dépôt ou une équipe d'entreprise. Auparavant, il fallait lister tous les centres de coûts et parcourir les ressources de chacun. Désormais, on passe le type et le nom de la ressource à un seul point de terminaison, et la réponse donne l'identifiant et le nom du centre de coûts. Si la ressource n'appartient à aucun centre de coûts, le tableau memberships revient vide.

La documentation REST apporte les détails. La requête est un GET sur le chemin de facturation de l'entreprise pour les appartenances aux centres de coûts, avec deux paramètres de requête : resource_type, qui peut valoir user, repository, organization ou team, et name. Pour les utilisateurs et les organisations, le nom est l'identifiant de connexion, pour un dépôt il s'écrit propriétaire/dépôt, et pour une équipe c'est le slug de l'équipe d'entreprise. L'entreprise est donnée par son slug, et l'exemple documenté envoie la version d'API 2026-03-10. Les codes d'état documentés sont 200, 400, 403, 404, 500 et 503. Un exemple de réponse 200 montre l'utilisateur octocat avec une appartenance désignant un centre de coûts nommé Engineering Team.

Pour l'accès, les deux sources doivent être lues ensemble, car elles ne disent pas exactement la même chose. Le journal dit que les propriétaires d'entreprise, les gestionnaires de facturation et les GitHub Apps ayant un accès en lecture à la facturation de l'entreprise peuvent interroger n'importe quelle ressource de l'entreprise. Il dit ensuite que les propriétaires d'organisation, et les utilisateurs dotés de rôles personnalisés incluant la lecture de la facturation, ne peuvent interroger que les ressources et centres de coûts qu'ils voient déjà. La page REST dit que les propriétaires d'entreprise, les gestionnaires de facturation et les propriétaires d'organisation de l'entreprise peuvent consulter les appartenances, qu'un titulaire de rôle personnalisé avec un accès fin en lecture à la facturation de l'entreprise peut aussi les consulter, et qu'un jeton d'installation de GitHub App avec cet accès peut obtenir l'appartenance de n'importe quelle ressource de l'entreprise. La page limite les propriétaires d'organisation aux organisations qu'ils possèdent, aux utilisateurs de ces organisations, aux dépôts qu'ils voient et aux équipes d'entreprise visibles. Elle ne fixe pas de limite pour les titulaires de rôle personnalisé. La portée d'un rôle personnalisé est donc décrite d'une façon dans le journal et laissée ouverte dans la documentation : testez avec un vrai rôle personnalisé avant de vous y fier.

Les jetons sont eux aussi restreints. La documentation dit que le point de terminaison fonctionne avec deux types de jetons à granularité fine, les jetons d'accès utilisateur de GitHub App et les jetons d'accès d'installation de GitHub App, et exige l'autorisation de facturation d'entreprise en lecture. Elle ne liste aucun autre type de jeton pour ce point de terminaison : un script qui utilise une autre identité doit donc être vérifié avant de passer au nouvel appel.

Qu'est-ce que cela change en pratique ? Une équipe financière ou de plateforme qui tient un inventaire de dépôts et d'utilisateurs peut maintenant poser la question directe « quel centre de coûts paie ce dépôt », au lieu de télécharger et de croiser la liste des ressources de chaque centre. Cela devrait réduire les appels et simplifier les audits, mais aucune des deux sources ne donne de chiffre sur le gain de vitesse. Le point de terminaison ne fait que lire les données des centres de coûts : il ne change pas ce qu'un centre facture et n'affecte pas une ressource à un centre. Le tableau memberships vide est un signal utile, car il désigne une ressource couverte par aucun centre, et une équipe peut rechercher ces cas pour repérer les dépenses non réparties.