Depuis le 5 novembre, les équipes qui utilisent GitHub Copilot Code Review peuvent consulter dans les rapports de l’API les commentaires auxquels les développeurs ont donné suite. Le même jour, GitHub a ajouté des champs qui aident les administrateurs à repérer les lacunes de télémétrie et les versions obsolètes des éditeurs. Ces mises à jour donnent aux responsables et aux propriétaires d’organisations un moyen plus concret d’évaluer le fonctionnement de la revue par l’IA et l’exhaustivité des données d’utilisation de Copilot.

Comment mesurer les suites données aux commentaires de l’IA
Un objet `copilot_code_review` a été ajouté à la ligne quotidienne de rapport par dépôt `repos-1-day`. Il comprend notamment `total_comments_evaluated`, le nombre de commentaires évalués, et `total_comments_addressed`, le nombre de commentaires auxquels un développeur a donné suite. Pour calculer la proportion de commentaires traités pour un dépôt, il faut diviser la seconde valeur par la première. Les nouveaux champs sont décrits dans la mise à jour de l’API Copilot usage metrics.
GitHub comptabilise une suite lorsqu’un développeur applique la correction proposée, demande à Copilot de la mettre en œuvre, modifie lui-même le code ou répond que la correction sera intégrée à la prochaine pull request. Le rapport ventile aussi les commentaires par gravité, niveau de revue, type de remarque et présence d’instructions ou d’outils supplémentaires. L’équipe peut ainsi étudier, par exemple, si les commentaires sur la sécurité suscitent des réactions différentes des autres remarques, ou quelles catégories nécessitent davantage de travail manuel.
Cette mesure indique qu’une action a été enregistrée, et non que la correction a été validée comme étant de qualité. Il est donc utile de la consulter en parallèle de la revue du code et de l’état de la pull request : une forte proportion de commentaires traités signifie qu’ils ont suscité une réaction, mais ne prouve pas à elle seule que toutes les modifications sont correctes ou nécessaires. Autre point important : les commentaires sont comptabilisés le jour de la fusion de la pull request, et non le jour où Copilot les a publiés.
Pourquoi le taux de traitement diffère de l’adoption des suggestions
Les champs précédents comptabilisaient les exécutions de Copilot Code Review et les cas où un utilisateur cliquait sur le bouton pour appliquer une suggestion prête à l’emploi. Le nouvel indicateur couvre davantage de formes de réaction : le développeur peut apporter lui-même la correction, demander à Copilot de le faire ou reporter la modification à la prochaine pull request. Ainsi, `total_comments_addressed` renseigne sur les suites données aux commentaires, tandis que `total_copilot_applied_suggestions` ne porte que sur les suggestions applicables en une seule action.
Le rapport contient également `total_merged_no_human_change_request_after_review` : le nombre de pull requests fusionnées après avoir été examinées par Copilot, sans qu’aucun humain n’ait demandé de modification après la première revue. Ces indicateurs décrivent différentes étapes du travail et gagnent à être consultés ensemble : le premier reflète la réaction aux commentaires, le second le déroulement de la revue jusqu’à la fusion.
Les nouveaux champs révèlent les raisons des rapports incomplets
Une autre mise à jour, publiée le 5 novembre, ajoute des informations sur la télémétrie côté client et les versions des outils. Le champ `client_telemetry_present` indique si des événements provenant de l’éditeur de l’utilisateur ont été reçus un jour donné ; `usage_metrics_requirements` précise si l’IDE et les extensions répondent aux exigences minimales de version pour les métriques. Les administrateurs obtiennent aussi le nombre quotidien d’utilisateurs sans télémétrie et celui des utilisateurs ayant au moins un composant obsolète. Les détails figurent dans la note sur les lacunes des données Copilot.
Cela permet de distinguer l’activité des utilisateurs de l’exhaustivité des rapports. GitHub précise qu’un utilisateur peut être comptabilisé comme actif même si aucun événement de l’éditeur n’a été reçu ; dans ce cas, le rapport perd des détails comme la répartition de l’utilisation par fonctionnalité et par modèle. Les causes possibles incluent une version obsolète de l’IDE ou de l’extension, la désactivation de la télémétrie de l’éditeur, ou encore un proxy ou un pare-feu qui bloque les événements.
Les deux compteurs de lacunes ne doivent pas être additionnés pour obtenir le nombre d’utilisateurs uniques : une même personne peut figurer dans les deux groupes. De plus, disposer d’une version correcte de l’éditeur ne garantit pas la réception de la télémétrie ; des restrictions réseau, par exemple, peuvent persister. Si une valeur est absente ou égale à `null`, GitHub la signale comme une donnée indisponible, et non comme un zéro ou comme l’absence de problème.
Ce que cela change pour les équipes
Ces nouveautés permettent de remplacer un indicateur général d’activité de Copilot par deux vérifications plus concrètes : ce qu’il advient des commentaires de Code Review et la fiabilité des données utilisées dans les rapports internes. Les responsables des équipes d’ingénierie peuvent comparer les types de commentaires et les dépôts, tandis que les administrateurs peuvent repérer les utilisateurs qui doivent mettre à jour leur IDE ou leur extension, ou vérifier leurs paramètres réseau.
Les rapports sont accessibles au niveau de l’organisation et de l’entreprise aux utilisateurs disposant des autorisations nécessaires pour consulter les métriques Copilot ; la politique Copilot usage metrics doit être activée. Les données de Code Review figurent dans les lignes `repos-1-day`, tandis que les champs de télémétrie et de version apparaissent dans les rapports utilisateurs sur un et 28 jours. Cette mise à jour est donc surtout utile aux organisations qui administrent déjà Copilot de manière centralisée : elles peuvent désormais étudier non seulement l’utilisation de l’assistant, mais aussi les réactions à ses revues et les raisons pour lesquelles les mesures sont incomplètes.