GitHub Copilot Enterprise : guide des Spaces et de l’API des métriques d’usage

Qu’est-ce que GitHub Copilot Enterprise ?

GitHub Copilot Enterprise se situe au sommet de la hiérarchie des offres Copilot de GitHub.

Comparé à GitHub Copilot Business ou Pro+, Enterprise met fortement l’accent sur la gouvernance, le contexte organisationnel et les capacités de mesure. Il est conçu pour les entreprises qui exploitent de vastes environnements d’ingénierie, plutôt que pour des développeurs individuels ou de petites équipes.

Deux capacités comptent surtout en pratique :

1. Un contexte organisationnel personnalisé via les Spaces
2. Une télémétrie à l’échelle de l’organisation via l’API des métriques d’usage

Ces deux fonctionnalités font passer Copilot d’un simple « autocomplétion intelligente » à quelque chose qui s’apparente davantage à une plateforme d’ingénierie IA interne.

Les entreprises qui tirent le plus de valeur de GitHub Copilot Enterprise l’intègrent comme un élément clé de leur infrastructure interne. Elles soignent la configuration du contexte organisationnel, mesurent l’adoption en continu et adaptent leurs politiques à partir des données d’usage, pas d’hypothèses.

Pour une vue d’ensemble de l’écosystème GitHub, je vous recommande notre guide Introduction to GitHub Products.

En quoi Enterprise diffère de Business et Pro+

GitHub Copilot Enterprise étend l’abonnement Business avec des fonctionnalités supplémentaires telles que :

• Métriques d’usage au niveau de l’organisation
• Contrôles de gouvernance étendus
• Héritage des politiques à l’échelle de l’entreprise
• Quota plus élevé de requêtes premium (1 000 contre 300 en offre Business)
• Accès et gestion de modèles supplémentaires

Enterprise nécessite GitHub Enterprise Cloud en plus de l’abonnement Copilot Enterprise lui-même. Cela ajoute un coût supplémentaire par utilisateur ; assurez-vous donc que votre organisation a réellement besoin de gouvernance, de télémétrie et d’administration à l’échelle entreprise.

Remarque : les abonnés Business accèdent à l’API des métriques d’usage au niveau de l’organisation (/orgs/{org}/…). Les abonnés Enterprise accèdent en plus à des rapports agrégés pour l’ensemble de l’entreprise (/enterprises/{enterprise}/…) couvrant toutes les organisations dans une vue unifiée.

Pour qui est GitHub Copilot Enterprise

GitHub Copilot Enterprise s’adresse aux organisations disposant d’environnements GitHub déjà matures.

Profils types de clients Enterprise :

• Grandes organisations d’ingénierie
• Secteurs réglementés
• Équipes plate-forme multi-équipes
• Entreprises avec des standards de développement internes
• Organisations exigeant une gouvernance centralisée

Notez que cela n’améliore pas intrinsèquement les performances de Copilot. Cette nuance est importante : beaucoup d’équipes surdimensionnent leur achat au départ. Elles pensent que Enterprise signifie « meilleur Copilot », alors qu’en réalité Enterprise ajoute surtout des outils de gouvernance et de mesure.

Copilot Spaces : un contexte sur mesure pour votre organisation

Les Copilot Spaces résolvent l’une des principales faiblesses des assistants de codage IA généralistes.

Par défaut, Copilot comprend correctement les connaissances publiques en programmation. Il ne comprend pas automatiquement vos API internes, vos choix d’architecture, vos conventions de code, vos workflows de déploiement ou votre documentation d’onboarding.

Les Spaces fournissent un contexte organisationnel sélectionné que Copilot peut mobiliser lors des conversations et de l’assistance au codage.

Concrètement, les Spaces aident Copilot à répondre à des questions comme :

• « Comment structurons-nous en interne nos gestionnaires d’API ? »
• « Quelle bibliothèque d’authentification notre équipe plate-forme recommande-t-elle ? »
• « Quel workflow de déploiement ce microservice doit-il utiliser ? »
• « Quelles conventions de nommage notre équipe backend applique-t-elle ? »

Ce que prennent en charge les Spaces

Les Spaces couvrent un éventail plus large de contenus organisationnels que l’ancien système Knowledge Bases.

Types de contenus pris en charge :

• Fichiers de code
• Documentation Markdown
• Fichiers JSON
• Fichiers téléversés
• Images
• GitHub Issues
• Pull requests

Chaque type de contenu apporte une contribution différente.

Les fichiers de code aident Copilot à comprendre les schémas d’implémentation. Les fichiers Markdown apportent des explications d’architecture et des guides d’onboarding. Les pull requests exposent les discussions de revue et les décisions d’ingénierie historiques. Cette combinaison améliore la compréhension par Copilot des pratiques de développement de votre organisation.

Point subtil mais important : les Spaces ne sont pas de simples bases vectorielles greffées à GitHub. Ils incluent des contrôles de partage et des workflows de gouvernance organisationnelle conçus pour les environnements entreprise.

La fin des Knowledge Bases

GitHub a retiré l’ancienne fonctionnalité Copilot Knowledge Bases le 1er novembre 2025.

Les Spaces ont remplacé Knowledge Bases avec :

• Un support de contenu plus large
• De meilleurs contrôles de partage
• Une administration améliorée
• Une gestion plus flexible au niveau de l’organisation

Vous trouverez encore de la documentation et des articles de blog dépassés faisant référence à Knowledge Bases. Soyez prudent avec les anciens tutoriels : de nombreux endpoints et workflows ont changé lors de la période de transition 2025-2026.

Création et configuration des Copilot Spaces

Côté administration, la création d’un Copilot Space est plutôt simple. La vraie difficulté, c’est d’en gérer des dizaines, voire des centaines, à travers les équipes.

La structure que vous choisissez au départ a tendance à perdurer. J’ai vu des organisations créer par inadvertance une « prolifération documentaire » dans les Spaces parce qu’aucune règle de responsabilité n’avait été posée en amont.

N’importe qui peut créer un Copilot Space ; testons-en la création dans un dépôt personnel. Ces étapes sont similaires au niveau Enterprise, avec quelques écrans différents.

Configurer un Space

La création d’un Space suit généralement ce workflow :

1. Accédez à la page Copilot Spaces dans votre zone d’administration Enterprise
2. Créez un nouveau Space

3. Sélectionnez les dépôts et sources de contenu, y compris les MCP et autres outils utiles

4. Ajoutez des sources en cliquant sur le bouton « + Add sources » sur la droite

5. Vous pouvez choisir de partager le space ou de définir les paramètres de partage à cette étape

6. Vérifiez que Copilot peut référencer le contenu lors des interactions de chat

Note pour les utilisateurs Enterprise : votre administrateur peut désactiver le partage des Spaces personnels. Si vous utilisez votre propre compte, cela peut limiter votre capacité à partager un Copilot Space qui n’utilise pas les dépôts de l’entreprise.

Après la configuration, les administrateurs doivent tester le Space avec des invites concrètes.

Par exemple :

How does our authentication middleware handle token refresh logic?

Ou :

Show me an example of how our backend services structure database migrations.

Si Copilot ne peut pas répondre avec précision, la cause tient généralement à :

• Dépôts manquants
• Qualité de documentation insuffisante
• Autorisations incorrectes
• Temps d’indexation insuffisant

Partage et contrôles d’accès

Les Spaces proposent deux grands modèles de visibilité :

• Spaces individuels
• Spaces à l’échelle de l’organisation

Les membres d’une entreprise peuvent voir leurs spaces individuels gérés par les paramètres de l’entreprise. Les administrateurs Enterprise peuvent également gérer de façon centrale les politiques d’accès anticipé et de disponibilité des fonctionnalités.

Les Spaces privés conviennent aux équipes expérimentales ou aux initiatives internes sensibles. Les Spaces à l’échelle de l’organisation sont idéaux pour les standards d’ingénierie, la documentation d’onboarding ou les cadres techniques communs.

Une erreur fréquente que j’observe est la sur-centralisation. Un Space unique, tentaculaire et à l’échelle de toute l’entreprise peut devenir bruyant et difficile à exploiter efficacement par Copilot.

Organiser les Spaces par équipe ou par domaine

Il n’existe pas de structure organisationnelle universellement correcte.

Des schémas courants incluent un space par équipe, un space par pôle produit ou des spaces partagés de standards. Chacun a un périmètre différent et utilise peu ou prou les mêmes paramètres de manière adaptée.

Un Space par équipe

Utile lorsque les groupes d’ingénierie opèrent de façon relativement indépendante.

Exemples :

• Ingénierie plate-forme
• Ingénierie des données
• Développement mobile

Un Space par pôle produit

Utile pour les organisations structurées autour des produits plutôt que des départements.

Exemples :

• Paiements
• Analytique
• Infrastructure
• Plate-forme client

Un Space de standards partagés

Beaucoup d’organisations entretiennent un Space partagé séparé pour :

• Lignes directrices de sécurité
• Conventions de codage
• Workflows de déploiement
• Standards d’architecture

En pratique, les approches hybrides fonctionnent généralement le mieux. Chaque équipe peut avoir son propre space, avec de grands spaces de standards partagés entre équipes.

L’API Copilot Usage Metrics

Les Spaces résolvent le problème de contexte. L’API des métriques d’usage résout le problème de la mesure. Elle a remplacé plusieurs systèmes de télémétrie plus anciens que GitHub a retirés lors de la consolidation des API en 2026.

Sans mesures claires, les organisations perdent vite en visibilité sur la réussite de l’adoption de Copilot. Les directions veulent des preuves que l’investissement améliore les workflows des développeurs, et pas seulement une ligne d’abonnement supplémentaire.

Le tableau de bord est généralement disponible depuis février 2026 et accessible via votre compte enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics, dans l’onglet Insights.

Exemple de tableau de bord Copilot Usage Metrics sur github.blog

Ce que mesure l’API

L’API des métriques d’usage expose plusieurs catégories de télémétrie opérationnelle.

Métriques courantes :

• Utilisateurs actifs
• Lignes de code suggérées vs lignes de code acceptées
• Schémas d’usage des IDE
• Utilisation des modèles
• Interactions avec les agents
• Répartition par langages

Cela offre une vision bien plus nuancée que de simples volumes de licences.

Une équipe avec 100 licences attribuées mais seulement 15 utilisateurs actifs n’a pas du tout le même profil d’adoption qu’une équipe avec un usage quotidien soutenu et de forts taux d’acceptation.

La transition d’API 2026

GitHub a retiré plusieurs API de télémétrie antérieures (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) durant la période 2025-2026, avec une extinction complète en avril 2026.

Cela incluait :

• L’ancienne Metrics API
• Les Feature Engagement APIs
• Les Direct Data Access APIs

Les nouveaux endpoints Usage Metrics, disponibles depuis février 2026, ont consolidé ces systèmes de reporting dans un modèle unifié, incluant la versionnage des API en cas de changements incompatibles.

C’est important car de nombreux billets de blog et exemples GitHub anciens font encore référence à des endpoints dépréciés. Lorsque vous travaillez avec l’API Usage Metrics, vérifiez toujours la documentation par rapport aux références API les plus récentes de GitHub avant de bâtir des automatisations dessus.

Interroger l’API des métriques d’usage

Maintenant que l’objectif de l’API des métriques d’usage est clair, voyons comment l’utiliser concrètement.

Authentification et autorisations

Les endpoints GitHub Copilot Usage Metrics exigent généralement quelques autorisations pour votre Personal Access Token (PAT). Cela peut passer par un PAT classique ou un PAT à portée fine.

• Pour les PAT classiques, votre administrateur enterprise doit vous accorder les autorisations suivantes : manage_billing:copilot et read:org.

• Pour les jetons d’accès à portée fine, assurez-vous d’utiliser le jeton d’accès utilisateur d’application GitHub ou le jeton d’installation avec l’autorisation Enterprise Copilot metrics enterprise permissions (read).

En général, les jetons à portée fine sont préférables car ils réduisent l’exposition inutile des autorisations.

Endpoints au niveau organisation

Les deux rapports les plus courants au niveau organisation sont :

• organization-1-day

• organization-28-day

Rapport organisationnel sur un jour

Le rapport sur un jour est adapté au suivi opérationnel et à l’analyse de tendances court terme. Des données historiques sont disponibles depuis le 10 octobre 2025, consultables jusqu’à un an à partir de la date courante.

La commande curl ci-dessous appelle l’API du rapport 1 jour et renvoie une réponse JSON avec des liens de téléchargement des rapports d’usage. Vous devez renseigner YOUR_TOKEN pour le Bearer auth et choisir un DAY pour la date du rapport au format YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

Les URL dans download_links sont signées et à durée limitée : elles expirent peu après leur récupération. Votre workflow doit récupérer l’URL puis télécharger le fichier immédiatement dans la même exécution ; vous ne pouvez pas stocker ces URL pour plus tard.

La réponse peut ne contenir que download_links et report_day, mais voici le schéma possible au complet :

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

Rapport organisationnel sur 28 jours

Le rapport sur 28 jours aide à dégager des schémas d’adoption plus larges et des évolutions d’usage de plus long terme. Les commandes sont très proches, avec un léger changement d’endpoint.

Exemple de requête :

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Vous obtiendrez une réponse similaire, à ceci près qu’elle inclura response_start_day et response_end_day.

Structure des rapports au niveau organisation

Les rapports JSON pour les périmètres 1 jour et 28 jours peuvent ressembler à ceci :

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Comme vous le voyez, cela fournit une vue d’ensemble des utilisateurs d’une organisation donnée, de leur équipe et de leurs tags d’équipe.

Endpoints au niveau utilisateur

Les rapports au niveau utilisateur offrent une visibilité plus granulaire de l’adoption. Vous pouvez ainsi comprendre, à haut niveau, comment chaque personne utilise Copilot.

Endpoints courants :

• users-1-day

• users-28-day

• user-teams-1-day

Ces rapports aident les administrateurs à identifier :

• Les utilisateurs très actifs
• Les équipes à faible adoption
• Les opportunités de formation
• Les tendances d’usage au niveau des départements

Ces requêtes sont très proches de celles des rapports 1 jour et 28 jours au niveau organisation ; elles pointent simplement vers d’autres endpoints.

Rapport utilisateur sur un jour

Exemple d’appel API users-1-day :

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

Rapport utilisateur sur 28 jours

Exemple d’appel API users-28-day :

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Rapport user-teams sur un jour

Un endpoint user-teams-1-day existe aussi, qui relie chaque utilisateur à ses appartenances d’équipe. Il ne contient pas de métriques d’usage ; il sert de clé de jointure lorsque vous souhaitez agréger les données par utilisateur au niveau équipe.

Structure des rapports au niveau utilisateur

Le niveau de détail de ces rapports est bien plus élevé, puisqu’ils reflètent les données d’usage d’un utilisateur :

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Ces métriques sont surtout utiles comme signaux d’adoption au niveau équipe. Les taux d’acceptation et volumes d’usage sont des indicateurs opérationnels, pas des mesures de qualité des développeurs.

Pour la liste potentielle complète des métriques, consultez la documentation sur les données des métriques d’usage GitHub la plus à jour.

Les rapports au niveau utilisateur incluent des données d’interaction avec le CLI. Si vos équipes utilisent Copilot en ligne de commande, notre GitHub Copilot CLI Tutorial couvre la configuration et les workflows fréquents.

Construire un workflow de reporting Copilot

Appeler l’API manuellement est utile pour expérimenter et comprendre le schéma. Pour être actionnable, il vaut mieux créer un workflow automatisé.

Les équipes qui tirent le plus de valeur de Copilot Enterprise mettent en place des pipelines de reporting légers qui combinent télémétrie d’usage et métriques d’ingénierie internes.

Métriques clés pour prouver le ROI

Toutes les métriques Copilot n’ont pas la même importance. Les plus utiles sont généralement :

• Croissance des utilisateurs actifs
• Tendances des taux d’acceptation
• Code suggéré vs code conservé
• Amélioration des temps de cycle des PR
• Fréquence d’engagement dans l’IDE

GitHub a publié des référentiels tels que :

• 55 % de réduction du temps de réalisation des tâches
• 88 % de taux de rétention du code

Ces chiffres montrent des gains de productivité significatifs. Vos résultats varieront selon les équipes et les workflows ; c’est précisément pour cela que l’API Usage Metrics existe. Une équipe backend d’infrastructure n’utilisera pas Copilot comme une équipe frontend de prototypage.

Des données brutes à un tableau de bord équipe

Un workflow de reporting léger ressemble souvent à ceci :

1. Appel API planifié
2. Stockage des réponses dans une base ou une feuille de calcul
3. Transformation des données en tables de reporting
4. Visualisation dans une plateforme de BI existante

La pile technologique compte moins que la régularité.

Même un simple enchaînement de scripts Python planifiés et d’exports CSV peut offrir une visibilité opérationnelle utile.

Architecture type :

GitHub API

  ↓

Script Python planifié

  ↓

PostgreSQL / CSV / Feuille de calcul

  ↓

Power BI / Tableau / Looker

Pour conclure

GitHub Copilot Enterprise vise avant tout à bâtir une infrastructure prête pour l’IA autour de votre code. Les Spaces apportent le contexte organisationnel qui rend Copilot plus utile en environnement d’ingénierie réel. L’API des métriques d’usage fournit la télémétrie nécessaire pour évaluer la réussite de l’adoption.

Les organisations qui obtiennent les meilleurs résultats avec Copilot Enterprise partagent un même schéma :

• Elles soignent la curation du contexte interne
• Elles suivent l’adoption en continu
• Elles prennent la gouvernance de Copilot au sérieux
• Elles mesurent les résultats au lieu de présumer des gains de productivité

Cet état d’esprit compte bien plus que la simple attribution de licences.

Pour aller plus loin avec Copilot et l’IA, nous vous recommandons le cours Software Development with GitHub Copilot ou le parcours de compétences complet AI for Software Engineering.