Métriques d’utilisation de GitHub Copilot

À propos Copilot des métriques d’utilisation

Copilot Les métriques d’utilisation aident les parties prenantes clés et les décideurs à comprendre comment leurs équipes adoptent et utilisent Copilot. En suivant les modèles d’utilisation au sein de l’entreprise, vous pouvez mesurer l’engagement, identifier les opportunités d’augmenter la valeur et évaluer la façon dont les flux de travail assistés par l’IA influencent le débit des demandes de tirage et le temps de fusion.

Les métriques sont disponibles via :

• Les Copilot API de métriques d’utilisation, qui fournissent des données détaillées et exportables au niveau de l’entreprise, de l’organisation, du référentiel et de l’utilisateur. Consultez « Points de terminaison d’API REST pour les métriques d’utilisation Copilot ».
• Le Copilot tableau de bord des métriques d’utilisation, qui visualise les tendances d’utilisation de 28 jours au sein de votre entreprise et de vos organisations. Consultez « Affichage du tableau de bord des métriques d’utilisation Copilot ».
• Le tableau de bord de génération de code, qui décompose la façon dont le code est généré par les utilisateurs et les agents au sein de votre entreprise et de vos organisations. Consultez « Affichage du tableau de bord de génération de code ».
• Le Copilot tableau de bord d’impact, qui regroupe les utilisateurs en cohortes d’adoption et connecte cette adoption à la sortie des demandes de tirage. Consultez « Affichage du tableau de bord d’impact Copilot ».
• L’export NDJSON des Copilot métriques d’utilisation, offrant des données brutes pour les outils décisionnels personnalisés ou le stockage à long terme.

Quelle est l’utilisation incluse ?

Copilot Les métriques d’utilisation sont dérivées de la télémétrie sur plusieurs Copilot surfaces, notamment l’IDE Copilot CLIet l’activité agent apps . La plupart des métriques proviennent de la télémétrie de l’IDE côté client et les utilisateurs finaux ont besoin de télémétrie activées dans leur IDE pour les données les plus riches de ces métriques.

Les métriques individuelles agent app sont disponibles dans les API de métriques d’utilisation et les exportations NDJSON. Ils ne sont pas disponibles dans les tableaux de bord des métriques d’utilisation. L’activité à partir de agent apps est déjà incluse dans les totaux quotidiens, hebdomadaires et mensuels d’utilisateurs actifs par le biais de données de télémétrie côté serveur. Les métriques individuelles fournissent une répartition détaillée, mais ne modifient pas ces totaux.

En outre, Copilot les métriques d’utilisation incorporent des données de télémétrie côté serveur pour identifier les utilisateurs actifs auxquels seules les données de télémétrie côté client peuvent manquer. Les conditions réseau, les configurations de proxy et les paramètres client peuvent empêcher les données de télémétrie du client d’atteindre GitHub. Par conséquent, les signaux côté serveur garantissent que ces utilisateurs apparaissent toujours dans vos rapports.

Les utilisateurs exposés par le biais de données de télémétrie côté serveur sont entièrement comptabilisés vers les totaux de vos utilisateurs actifs (par exemple, les utilisateurs actifs quotidiens, daily_active_users ). Lorsqu’ils sont disponibles, ils peuvent également apparaître totals_by_ide (y compris les dernières versions détectées de l’IDE et Copilot de l’extension dans les rapports par utilisateur). Toutefois, d’autres répartitions dimensionnelles, telles que totals_by_feature les métriques de lignes de code, restent vides jusqu’à ce que les données de télémétrie plus riches soient disponibles. Les totaux et les répartitions de niveau supérieur pour les utilisateurs déjà capturés par les données de télémétrie du client sont inchangées.

Les données n’incluent pas d’activité à partir d’autres Copilot surfaces, telles que :

• Copilot Chat sur GitHub.com
• GitHub Mobile

Les données de gestion des licences et des sièges ne sont pas incluses dans Copilot les rapports de métriques d’utilisation. Pour afficher ou gérer les attributions de licences, utilisez l’API Copilot de gestion des utilisateurs, qui est la source de vérité pour les informations de licence et de siège. Consultez « Points de terminaison d’API REST pour la gestion des utilisateurs Copilot ».

Résolution des problèmes liés aux données d’utilisation manquantes

Les répartitions détaillées dépendent des données de télémétrie côté client de l’IDE ou Copilot CLI. Cette télémétrie fournit des données sur les fonctionnalités, les langages, les modèles, les suggestions acceptées et les lignes de code. Les données de télémétrie côté serveur peuvent montrer qu’un utilisateur était actif, mais il ne peut pas observer ce qui se passe dans l’éditeur.

Si la télémétrie côté client est manquante, les rapports peuvent contenir des nombres inférieurs ou des répartitions vides même lorsque les données côté serveur affichent l’activité. Les causes courantes sont les suivantes :

Cause	Effet sur vos rapports	Ce que vous pouvez vérifier
La télémétrie est désactivée dans l’IDE, par exemple avec le telemetry.telemetryLevel paramètre dans VS Code.	L’IDE n’envoie aucune activité détaillée. L’utilisateur peut toujours être considéré comme actif par le biais de la télémétrie côté serveur, mais la fonctionnalité, la langue et les lignes de répartitions de code sont vides.	Vérifiez que la télémétrie IDE est activée pour vos développeurs.
Un proxy réseau, un pare-feu ou un VPN bloque le Copilot point de terminaison de télémétrie.	Identique au moment où la télémétrie est désactivée.	Autorisez le point de terminaison de télémétrie du Copilot client. Consultez « Référentiel de la liste d'autorisation de Copilot ».
Le client n’est pas un IDE pris en charge et n’envoie Copilot pas de données de télémétrie.	L’utilisateur peut être considéré comme actif par le biais de données de télémétrie côté serveur, mais le client n’apparaît pas dans totals_by_ide des répartitions détaillées.	Utilisez un IDE pris en charge pour les métriques complètes.

Si un écart persiste après avoir vérifié les causes ci-dessus, contactez nous par le biais du portail et incluez les utilisateurs concernés, les IDEs, les versions et les dates.

Pourquoi Copilot les métriques d’utilisation peuvent différer entre les ressources d’API

Les ressources API suivantes exposent des Copilotdonnées associées, mais elles ne sont pas interchangeables et ne doivent pas être comparées directement. Chaque ressource d’API est conçue pour un cas d’usage et un modèle de données spécifique, et les différences dans les totaux ou la couverture sont attendues. Utilisez ce tableau pour comprendre quelle ressource d’API correspond le mieux à vos besoins de création de rapports.

Ressource d’API	Scope	Fonctionnalités clés
Points de terminaison d’API REST pour les métriques d’utilisation Copilot	Données avancées de télémétrie d’événements d’entreprise et d’organisation avec des rapports au niveau du référentiel et de l’utilisateur	Fournit des données de télémétrie unifiées sur les modes de complétions, de chat et d’agent. Inclut l'utilisation, les métriques et les lignes de code dans tous les modes, langages et modèles IDE. Prend en charge les répartitions détaillées par fonctionnalité, IDE, langage, modèle et utilisateur, ainsi que les rapports d’activité de demande de tirage au niveau du référentiel, et est la ressource d’API principale en cours de développement et de maintenance.
Points de terminaison d’API REST pour la gestion des utilisateurs Copilot	Attribution de licence et de siège	Répertorie les sièges attribués Copilot pour une organisation ou une entreprise, y compris l’état de la licence, l’association d’utilisateurs et last_activity_at. Cette ressource d’API est la source de vérité pour les informations de licence et de place.

Comment les métriques sont-elles attribuées dans les organisations ?

Les métriques d’utilisation au niveau Copilot de l’organisation sont basées sur l’appartenance à l’organisation, et non sur l’endroit où des actions individuelles se produisent. Pour apparaître dans les métriques d’une entreprise, un utilisateur doit disposer d’un siège actif Copilot affecté au sein de cette entreprise (dans toute organisation appartenant à l’entreprise). Par conséquent, l’utilisation d’un seul utilisateur peut apparaître dans plusieurs tableaux de bord d’organisation, tandis que ce même utilisateur n’est compté qu’une seule fois dans le total au niveau de l’entreprise. Les analyses au niveau de l’organisation sont destinées à une visibilité de l’adoption et de l’utilisation au sein d’une organisation et ne sont pas conçues directement par rapport aux totaux au niveau de l’entreprise.

Les analyses au niveau Copilot de l'organisation sont disponibles à partir du 12 décembre 2025. Il s’agit de la première date à laquelle les rapports au niveau de l’organisation sont fournis.

Une fois qu’un utilisateur dispose d’un siège dans l’entreprise, son utilisation est attribuée à chaque organisation à laquelle il appartient, quel que soit l’emplacement auquel le siège est attribué.

Cela signifie :

• Si des licences sont attribuées dans une organisation « shell » dédiée à des fins d’administration au sein de l’entreprise, les utilisateurs apparaissent toujours dans les métriques de toutes les autres organisations de l’entreprise auxquelles ils appartiennent.
• Si un utilisateur dispose également d’un Copilot siège dans une organisation distincte en dehors de l’entreprise, son activité est toujours incluse dans les métriques au niveau de l’organisation de l’entreprise tant qu’elle dispose d’au moins un siège au sein de l’entreprise.

En bref : les utilisateurs doivent disposer d’une licence quelque part dans l’entreprise pour apparaître dans ses métriques. Une fois qu’elles le sont, les métriques reflètent l’endroit où elles travaillent (leur appartenance à l’organisation), et non l’organisation qui fournit le Copilot siège ou l’origine de l’activité.

IDEs pris en charge

Pour être inclus dans les Copilot métriques d’utilisation, les utilisateurs finaux doivent utiliser l’une des IDE et versions d’extension Copilot Chat suivantes.

Les versions antérieures peuvent ne pas envoyer tous les événements sur lesquels reposent les métriques d’utilisation, ou peuvent attribuer une activité à l’IDE incorrect. Conservez les IDEs et Copilot les extensions actuelles et utilisez les outils de gestion des appareils pour appliquer ces versions minimales si possible.

IDE	Version minimale de l’IDE	Version minimale Copilot Chat de l’extension
Eclipse	4.31	0.9.3.202507240902
JetBrains / IntelliJ	2024.2.6	1.5.52-241
Visual Studio	17.14.13	18.0.471.29466
VS Code	1.107.1	0.35.3
Xcode	14.3.1	0.40.0

Dans les rapports par utilisateur, chaque totals_by_ide entrée inclut last_known_ide_version et last_known_plugin_version. Utilisez ces champs pour identifier les développeurs qui ont besoin de mettre à jour. Consultez « Données disponibles dans les métriques d’utilisation Copilot ».

Configuration requise pour l’activité de l’agent basé sur le SDK

Certains IDE exécutent Copilot des sessions d’agent via le Copilot Kit de développement logiciel (SDK). Certaines versions de ces IDE ne s’identifient pas lorsqu’elles envoient l’activité de l’agent, de sorte que l’activité est laissée hors des métriques d’utilisation. Cela entraîne le sous-compte des interactions de l’agent et des lignes de code d’agent. Pour inclure cette activité, les utilisateurs finaux doivent utiliser l’une des versions suivantes ou ultérieures :

IDE	Version minimale pour l’activité de l’agent basé sur le SDK	Versions affectées
VS Code	1.139.0	1.134 à 1.138, lors de l’utilisation de la fenêtre de l’agent
Copilot plug-in pour les ID JetBrains	1.20.0	1.15.0 à 1.19.x
Visual Studio	18.12	Builds Insiders (préversion) avant la version 18.12

Si vous planifiez des mises à jour de l’IDE, déplacez les développeurs directement vers ces versions ou versions ultérieures. Les versions généralement disponibles ne Visual Studio sont pas affectées.

Pour les ID JetBrains, évitez Copilot les versions de plug-in 1.15.0 à 1.19.x.

Eclipse et Xcode n’exécutent pas de sessions d’agent via le Copilot Kit de développement logiciel (SDK), de sorte qu’elles ne sont pas affectées.

Les données manquantes ne peuvent pas être réremplies, car l’activité provenant de versions affectées n’identifie pas l’IDE à partir duquel elle provient.

Certaines de ces activités ont été comptabilisées comme Copilot CLI une activité à la place, ce qui peut gonfler Copilot CLI les métriques. Cela permet aux développeurs de mettre à jour les IDE affectés, mais les métriques antérieures Copilot CLI ne peuvent pas être corrigées. Copilot CLI les utilisateurs n’ont pas besoin de mettre à jour.

Ce problème affecte uniquement la façon dont l’activité est attribuée dans les métriques d’utilisation. La facturation n’est pas affectée.

Actualisation des données

Les données des tableaux de bord et des rapports d’API sont mises à jour selon une planification régulière.

Vous pouvez vous attendre à ce que les données soient disponibles dans les deux jours complets. Cela signifie que les données d’un jour donné sont traitées et mises à disposition dans un délai de deux jours UTC complets après la fermeture de ce jour.

Les données de télémétrie en cours de traitement peuvent rendre les derniers jours incomplets. Attendez que la fenêtre de traitement se ferme avant d’examiner un écart.

Qu’est-ce que les données mesurent ?

Copilot Les métriques d’utilisation peuvent être regroupées en quelques catégories principales : adoption, engagement, taux d’acceptation, lignes de code (LoC) et métriques de cycle de vie des demandes de tirage.

L’adoption mesure le nombre de développeurs sous licence qui utilisent Copilotactivement . Par exemple, les utilisateurs actifs quotidiens (DAU) vous indiquent combien d’utilisateurs uniques ont interagi avec Copilot un jour donné. Dans l’idéal, vous verrez une tendance à la hausse cohérente dans ces métriques lors du déploiement. Copilot code review l’adoption est suivie séparément, avec des nombres d’utilisateurs actifs et passifs distincts. Les utilisateurs actifs ont demandé manuellement une révision ou appliqué une suggestion ; les utilisateurs passifs ont été Copilot code review automatiquement associés pour passer en revue leur requête de tirage. Lorsqu’un utilisateur a les deux signaux dans la même période, il est comptabilisé comme actif uniquement. Pour une vue plus approfondie de la profondeur de l’adoption, les utilisateurs sont également regroupés en cohortes d’adoption. Consultez Comprendre les cohortes d’adoption.

Les mesures d’engagement décrivent la façon dont les développeurs utilisent Copilot profondément une fois qu’ils l’ont adopté. Les métriques d’engagement clés montrent non seulement la fréquence d’utilisation, mais également l’étendue des fonctionnalités. Par exemple, les demandes de conversation moyennes par utilisateur actif mesurent la fréquence à laquelle les utilisateurs ouvrent et interagissent avec Copilot Chat. Vous souhaitez voir une utilisation régulière et croissante des conversations entre les langues et les IDE.

Le taux d’acceptation mesure la fréquence à laquelle les développeurs acceptent Copilotles suggestions. Cela vous aide à comprendre si les suggestions sont pertinentes et approuvées. Par exemple, un taux d’acceptation élevé des suggestions inline indique que les suggestions sont pertinentes et utiles.

’Les métriques Lignes de code (LoC) mesurent le nombre de lignes Copilot suggérées, ajoutées ou supprimées dans l’éditeur, offrant une vue indicative de la production tangible de Copilot. Par exemple, « Lignes ajoutées » indique la quantité de code réellement acceptée et insérée dans l’éditeur.

Les métriques du cycle de vie des pull requests mesurent comment l'activité est liée aux résultats des pull requests et au flux de livraison. Ces métriques incluent la création de demandes de tirage, le nombre de fusions, le temps médian de fusion et l'activité de suggestion lors de la révision. En comparant l’activité globale des demandes de tirage avec les demandes de tirage créées par Copilot, vous pouvez évaluer comment les flux de travail assistés par l’IA influencent le débit et le temps de cycle au niveau de l’organisation ou de l’entreprise.

Les répartitions de modèles peuvent inclure des modèles que les développeurs n’ont pas sélectionnés directement. Par exemple, Copilot vous pouvez utiliser d’autres modèles pour la sélection automatique du modèle ou pour les tâches en arrière-plan.

Présentation des cohortes d’adoption

Au lieu de mesurer l’adoption en tant qu’un seul nombre d’utilisateurs actifs, Copilot regroupe les utilisateurs en cohortes d’adoption en fonction de la façon dont ils s’engagent, Copilotpas seulement s’ils s’engagent du tout. Un nombre d’utilisateurs actifs plats traite une personne qui accepte occasionnellement une saisie semi-automatique du code comme une personne qui orchestre plusieurs flux de travail pilotés par l’agent tout au long de la journée. La cohorte sépare ces deux utilisateurs, de sorte que vous pouvez voir si l’utilisation de votre organisation est approfondie au fil du temps plutôt que de passer à la première version d’évaluation.

Les utilisateurs sont regroupés dans les phases suivantes :

Phase	Ce qu’elle représente
Utilisateurs passifs	L’utilisateur n’a pas atteint le seuil d’engagement pour une phase pendant la période. Un utilisateur passif peut toujours utiliser Copilot régulièrement, par exemple en posant des questions en mode agent ou en Copilot Chat mode agent sans appliquer de modification de code. Dans l’API, cette phase est étiquetée No Cohort.
Phase 1 : Le code d'abord	L’utilisateur s’est engagé avec des saisies semi-automatiques de code et/ou des modifications de l’agent, où Copilot il écrit des modifications directement dans les fichiers de l’IDE. L’utilisation Copilot Chat ou le mode agent sans produire l’achèvement du code ou l’activité de modification de l’agent ne se qualifie pas seul.
Phase 2 : Priorité à l’agent	L’utilisateur s’est engagé avec une surface d’agent basée sur une seule GitHubbase, telle que Copilot cloud agent, Copilot code reviewou Copilot CLI. L’engagement actif avec Copilot code review et le fait qu’il soit automatiquement affecté pour passer en revue le nombre de demandes de tirage en tant que même surface.
Phase 3 : Multi-agent	L’utilisateur s’est engagé avec deux surfaces d’agent basées ou GitHubplus, ou avec le GitHub Copilot app.

Pour être regroupé dans une phase, un utilisateur doit respecter un seuil d’engagement d’au moins deux jours actifs hors de la fenêtre de fin de 28 jours, à l’aide des surfaces associées à cette phase. Un utilisateur n’a besoin que de deux jours éligibles sur les surfaces d’une phase supérieure pour passer à cette phase. L’utilisation de l’agent seul peut qualifier un utilisateur, sans jours distincts de saisie semi-automatique.

L’attribution de phase est recalculée quotidiennement à partir de la fenêtre de fin de 28 jours, de sorte que la phase d’un utilisateur peut passer d’un jour à l’autre à mesure que son activité dans cette fenêtre change. Ce comportement est attendu, et non une erreur de données.

Le tableau de bord d’impact compte chaque utilisateur actif pendant la fenêtre de fin de 28 jours et regroupe chaque utilisateur par sa phase actuelle. Les règles de classification de phase sont identiques, mais la population du tableau de bord est plus large que le totals_by_ai_adoption_phase.total_engaged_users champ des rapports API et NDJSON, ce qui compte les utilisateurs actifs sur une journée spécifique.

Les utilisateurs qui n’ont pas atteint le seuil de la phase sont regroupés en utilisateurs passifs, ce qui n’est pas une mesure de l’inactivité, mais un signal indiquant que l’engagement d’un utilisateur n’a pas encore atteint le niveau nécessaire pour classifier de manière fiable leur profondeur d’adoption. Par exemple, un utilisateur ayant moins de deux jours actifs dans la fenêtre de fin de 28 jours, ou un utilisateur qui utilise légèrement une surface comme Copilot Chat on GitHub.com, s’affiche en tant qu’utilisateur passif.

Étant donné que l’attribution de phase est basée sur les surfaces auxquelles un utilisateur s’engage, pas seulement le nombre d’actions qu’il effectue, un utilisateur avec un volume d’achèvement élevé, mais aucune utilisation de l’agent ne reste dans la phase 1, tandis qu’un utilisateur avec une utilisation plus légère mais plus large sur les surfaces de l’agent passe à la phase 2 ou à la phase 3.

Pour connaître les champs de schéma sous-jacents, consultez les champs de phase d’adoption de l’IA.

Le multiplicateur d’adoption du tableau de bord d’impact divise la quantité moyenne de demandes de tirage fusionnées pour les utilisateurs engagés, qui sont celles de la phase 1, 2 ou 3, par la quantité de demandes de tirage fusionnées pour les utilisateurs passifs.

Cela montre l’impact relatif de l’adoption plus approfondie, indépendamment du nombre d’utilisateurs qui entrent dans chaque phase. Il s’agit d’une mesure permettant de comprendre l’élévation potentielle qu’un utilisateur plus engagé peut fournir.

Par exemple, si les utilisateurs dans les cohortes engagées ont moyenné 20 demandes de tirage/utilisateur/mois et la cohorte passive moyenne 10, l’équation est 20 / 10 = multiplicateur 2x.

Présentation des comparaisons du secteur

Le widget de comparaison du tableau de bord du secteur d’impact compare deux mesures pour votre entreprise, ou pour une organisation qui n’appartient pas à une entreprise, avec des résultats agrégés de pairs participants :

• Adoption agentique : pourcentage d’utilisateurs actifs dans votre entreprise ou organisation qui sont des utilisateurs agent-first ou multi-agent.
• Tirez parti : rapport entre le taux de fusion des demandes de tirage (pull request) pour les utilisateurs agentiques et le taux pour les utilisateurs non agentiques (par utilisateur par mois). Par exemple, un score de levier de 4,1x signifie que les utilisateurs agentiques ont fusionné des demandes de tirage à 4,1 fois le taux d’utilisateurs non agentiques pendant la période de création de rapports.

Chaque comparaison couvre la période de rapport de 28 jours indiquée dans le widget. Les cohortes d’homologues utilisent la taille de l’entreprise et le secteur sélectionnés lorsque vous optez. Les options de taille de l’entreprise sont de 1 à 999, de 1 000 à 4 999 et de 5 000 employés, et il existe dix options sectorielles. Ces valeurs sont auto-signalées et ne sont pas vérifiées. Vous pouvez comparer avec des homologues de votre secteur sélectionné ou dans tous les secteurs.

Lorsque suffisamment d’homologues éligibles sont disponibles, chaque carte affiche :

• Où se classe votre score au sein de la cohorte.
• Différence entre votre score et la médiane de l’homologue.
• Différence entre votre score et le décile supérieur.

La comparaison du décile supérieur nécessite une cohorte d’homologues plus grande que la comparaison médiane, de sorte que la médiane peut être disponible lorsque le décile supérieur n’est pas. Les entreprises et les organisations avec très peu d’utilisateurs actifs peuvent afficher des comparaisons, mais elles ne sont pas comptées vers une cohorte d’homologues.

Le graphique trace le score de votre entreprise par rapport à la distribution des scores homologues et marque la médiane et le décile supérieur de l’homologue. Certains marqueurs peuvent ne pas être disponibles si la cohorte ne contient pas suffisamment d’homologues éligibles.

Pour les comparaisons au sein de votre secteur sélectionné, le tableau de bord développe la cohorte d’homologues dans cet ordre jusqu’à ce que suffisamment d’homologues éligibles soient disponibles :

1. Pairs participants ayant la même taille d’entreprise et le même secteur d’activité.
2. Pairs participants ayant la même taille d’entreprise, dans tous les secteurs d’activité.

Les comparaisons utilisent toujours des pairs avec la même taille d’entreprise. Le widget montre quelle cohorte d’homologues a été utilisée. Vous pouvez donc savoir quand une comparaison a été développée au-delà de votre secteur sélectionné.

Pour GitHub Enterprise Cloud la résidence des données, les cohortes d’homologues incluent uniquement les participants hébergés dans la même région de résidence des données. Le tableau de bord applique la même expansion de cohorte au sein de cette région et ne combine pas les données entre les régions.

Le tableau de bord n’utilise pas de cohorte basée uniquement sur l’industrie. Les comparaisons entre tous les secteurs utilisent des pairs participants, plutôt que tous les utilisateurs ou entreprises GitHub .

La participation est contrôlée par la stratégie de comparaison des métriques Copilot et est désactivée par défaut. Les entreprises et les organisations qui ne sont pas détenues par une entreprise peuvent participer. Les organisations détenues par une entreprise participent par le biais de leur entreprise. Les entreprises utilisées uniquement pour attribuer Copilot Business des licences ne peuvent pas participer, car l’utilisation ne peut pas être calculée pour eux. L’activation de la stratégie contribue à vos métriques agrégées aux cohortes d’homologues et vous permet d’afficher les comparaisons. Pour plus d’informations, consultez Affichage du tableau de bord d’impact Copilot.

Les classements ne s’affichent qu’une fois que suffisamment d’entreprises et d’organisations ont choisi de former une cohorte d’homologues. S’il n’y a pas suffisamment d’homologues éligibles après que le tableau de bord applique les cohortes de secours, il n’affiche pas de classement. Un classement n’est pas disponible lorsque votre propre score ne peut pas être calculé, par exemple lorsqu’il n’y a pas d’utilisateurs actifs dans la période de rapport ou qu’aucun utilisateur non agentique ne peut fournir une base de référence pour tirer parti.

Comment les comparaisons du secteur protègent vos données

• Opt-in uniquement. Rien n'est fourni jusqu'à ce qu'un propriétaire d'entreprise, ou le propriétaire d'une organisation qui n'appartient pas à une entreprise, active la stratégie de comparaison des métriques Copilot. Les entreprises utilisées uniquement pour attribuer Copilot Business des licences ne contribuent jamais.
• Seuls deux scores récapitulatives sont fournis. Chaque participant contribue à son adoption agentique et tire parti des scores pour la période de rapport de 28 jours. Aucun nom d’utilisateur, activité au niveau de l’utilisateur, code, contenu du référentiel ou contenu de demande de tirage (pull request) n’est fourni.
• Les résultats sont agrégés. Vos scores sont combinés avec ceux d’autres participants pour calculer les statistiques de cohorte, telles que la médiane et le décile supérieur. D’autres participants ne peuvent pas voir le nom de votre entreprise ou organisation, les entreprises et organisations qui participent, ou le nombre de participants dans une cohorte.
• Les statistiques de cohorte ne sont pas liées aux participants. Lorsque les statistiques de cohorte sont calculées, les scores des participants sont combinés en résultats stockés uniquement par date, taille de l’entreprise et industrie. Ces résultats ne contiennent aucun identificateur d’entreprise, d’organisation ou d’utilisateur. Ils ne peuvent donc pas être liés à un participant spécifique.
• Les classements sont calculés sur GitHubles serveurs. Vos propres scores sont stockés avec le reste de vos Copilot métriques d’utilisation. Pour afficher votre classement, GitHub compare vos scores aux statistiques de cohorte pour la même période de rapport. Les scores des autres participants ne sont jamais recherchés ou comparés individuellement.
• De petites cohortes sont supprimées. Les statistiques d’une cohorte sont affichées uniquement lorsqu’elle contient suffisamment de participants et d’utilisateurs. Les entreprises et les organisations avec très peu d’utilisateurs actifs ne sont pas comptabilisées dans une cohorte, donc un petit nombre de développeurs ne peuvent pas mettre en forme les résultats.
• La taille de l’entreprise et l’industrie restent privées. La taille de l’entreprise et l’industrie que vous sélectionnez sont utilisées uniquement pour regrouper les participants dans des cohortes. Ils ne sont pas affichés à d’autres participants ou vérifiés par GitHub.
• La résidence des données est respectée. Pour GitHub Enterprise Cloud la résidence des données, les données ne sont jamais combinées entre les régions de résidence des données.
• Les résultats restent dans le tableau de bord. Les comparaisons du secteur ne sont pas incluses dans les téléchargements, les exportations NDJSON ou l’API Copilot de métriques d’utilisation.
• Les résultats agrégés sont de courte durée. Les statistiques de cohorte sont recalculées quotidiennement et supprimées après 30 jours. Si vous optez, le tableau de bord cesse d’afficher immédiatement les comparaisons et vos données sont exclues des cohortes à partir de la prochaine mise à jour quotidienne. Chaque calcul quotidien utilise votre paramètre d’opt-in actuel. Par conséquent, si les résultats antérieurs sont recalculés après la désactivation, vos données ne sont pas ajoutées.

Estimation du retour potentiel sur investissement

La section Retour potentiel sur investissement du tableau de bord d’impact fournit une comparaison des résultats des demandes de tirage et de coût entre la phase 0-1 passive et les premiers utilisateurs du code et les premiers utilisateurs de l’agent de phase 2-3.

Pour chaque groupe de phases, le tableau de bord affiche le coût mensuel Copilot par développeur, en fonction de la consommation réelle AI credits et ce coût en pourcentage de la rémunération du développeur. Il affiche également la moyenne des demandes de tirage par développeur par mois.

Vous pouvez sélectionner une bande de compensation pour mettre à jour les estimations qui dépendent de la rémunération du développeur. Ces chiffres sont des estimations plutôt que des résultats financiers exacts, de sorte qu’ils sont interprétés en même temps que les comparaisons de code et de délai de fusion du multiplicateur d’adoption. Les estimations de retour sur investissement sont disponibles uniquement dans le tableau de bord et ne sont pas incluses dans l’API Copilot des métriques d’utilisation ou les exportations NDJSON.

Interprétation des métriques de cycle de vie des requêtes de tirage dans différents contextes.

Les métriques de cycle de vie des demandes de tirage sont disponibles au niveau de l’organisation et de l’entreprise. Lorsque vous comparez des rapports, gardez à l’esprit ce qui suit :

• Déduplication : les rapports au niveau de l’entreprise dédupliquent les utilisateurs au sein des organisations. Les rapports au niveau de l’organisation ne le font pas.
• Données des pull requests uniquement : les métriques du cycle de vie des pull requests peuvent apparaître même si les métriques d’utilisation de l’IDE sont absentes, car les données des pull requests sont dérivées de l’activité du référentiel.
• Moment de l’attribution : si un dépôt ou une organisation est transféré d’un propriétaire à un autre, la création des demandes de tirage, l’examen et les événements de fusion peuvent être attribués à différentes entités en fonction du moment où chaque événement s’est produit.

Comment puis-je utiliser ces métriques ?

Ces métriques peuvent être utilisées ensemble pour répondre à des questions clés sur l’utilisation de Copilot par vos équipes.

Question	Utiliser ces métriques
Mes équipes utilisent-elles Copilot régulièrement ?	Utilisateurs actifs quotidiens et hebdomadaires
Quelles fonctionnalités offrent la plus grande valeur ?	Demandes par mode de conversation, adoption de l’agent logiciel
Les développeurs font-ils confiance à la production de Copilot ?	Tendances des taux d’acceptation
Les efforts d’activation fonctionnent-ils ?	Croissance de l’adoption et de l’engagement après la formation ou les campagnes de communication
Influence-t-il Copilot la vitesse de livraison ou le débit des pull requests ?	Nombres d'intégrations des pull requests et durée médiane d'intégration
Comment Copilot code review est-il adopté ?	Nombre d’utilisateurs de révision de code actif ou passif
L’adoption de mon organisation est-elle approfondie au fil du temps ?	Tendances de distribution et d’engagement des cohortes d’adoption
Comment agir sur les insights du tableau de bord ?	Consultez Interprétation des métriques d’utilisation et d’adoption pour GitHub Copilot

Recherchez des modèles sur ces signaux plutôt que de vous concentrer sur n’importe quel nombre unique. Par exemple, une DAU stable associée à un taux d’acceptation croissant indique une confiance et une valeur croissantes.

Analyser vos métriques plus en détail

Lorsque vous devez expliquer ou valider vos résultats, utilisez les articles de référence pour vous aider à comprendre toutes les données disponibles, comment elles sont comparées entre les surfaces et comment elles doivent être interprétées. Consultez « GitHub métriques d’utilisation de Copilot ».