GitHub étend l'analytique de Copilot à neuf scénarios d'utilisation

Les responsables de l'ingénierie observent souvent l'adoption de Copilot à travers une fenêtre trop étroite : combien de licences ont été attribuées, combien de suggestions ont été acceptées et combien de lignes de code ont été générées. Cette vision laissait de côté les personnes qui discutent régulièrement d'une tâche avec Copilot Chat ou lancent un scénario agentique dans VS Code. Résultat : le travail avançait, mais le tableau de bord ne le voyait qu'en partie.

GitHub a ajouté au Copilot impact dashboard deux sources d'activité manquantes : Copilot Chat et la fenêtre Agents de VS Code. Le graphique couvre désormais neuf scénarios d'utilisation. Les mêmes indicateurs apparaissent dans les rapports sur 28 jours pour les entreprises et les organisations, via les champs chat et vscode_agent.

Ce que cela donne en pratique

Imaginons une équipe de 20 développeurs. Cinq d'entre eux utilisent à peine l'autocomplétion, mais ouvrent régulièrement le chat, analysent des erreurs et demandent à l'agent de modifier plusieurs fichiers. Auparavant, ces collaborateurs pouvaient passer pour des utilisateurs passifs de Copilot. Désormais, leur activité apparaît séparément.

GitHub a également renommé la cohorte Passive users en Chat-first users. Ce nom est plus juste : il ne s'agit pas nécessairement de personnes qui ignorent l'outil. Elles sont actives dans Copilot, mais n'ont pas utilisé, au moins deux jours sur les 28 jours analysés, la fonctionnalité requise pour accéder à l'une des phases d'adoption.

La règle d'engagement est simple : un utilisateur est considéré comme actif dans un scénario donné s'il y a eu recours au moins deux jours distincts sur une période de 28 jours. Une même personne peut figurer dans plusieurs indicateurs. Par exemple, un développeur qui utilise le mode agent dans Copilot Chat sera comptabilisé dans les statistiques du chat, tandis que son travail via la fenêtre Agents distincte sera compté dans l'indicateur VS Code Agent.

Ce qu'il ne faut pas confondre

L'ajout de ces données ne modifie pas le modèle des étapes d'adoption de Copilot. Chat et la fenêtre Agents apparaissent comme une activité par fonctionnalité, mais ne font pas à eux seuls passer l'utilisateur à l'étape suivante. La taille des cohortes n'a pas changé non plus, et dans l'API, le groupe Chat-first continue d'être renvoyé sous la valeur No Cohort.

C'est une limite importante. La hausse de la courbe Chat ne peut pas être interprétée automatiquement comme un gain de maturité de l'équipe ni comme la preuve d'une accélération du développement. Le tableau de bord indique où les collaborateurs utilisent Copilot, mais ne dit pas s'ils gagnent du temps, s'ils livrent plus vite ni si le nombre de défauts a diminué.

Il existe aussi des contraintes techniques. Les nouveaux champs ne sont disponibles que dans les rapports sur 28 jours au niveau de l'organisation et de l'entreprise. Les rapports historiques générés avant la mise à jour conserveront les sept scénarios précédents. L'accès est réservé aux propriétaires, aux responsables de la facturation ou aux membres dotés d'un rôle autorisant la consultation des métriques Copilot ; la politique de collecte des statistiques doit être activée.

Que faire en tant que responsable de l'ingénierie

Vérifiez d'abord que la part d'utilisateurs « passifs » n'était pas due à une télémétrie incomplète. Rapprochez ensuite chat et vscode_agent de résultats d'ingénierie concrets : délai de traitement des pull requests, durée des tâches, nombre de retours pour reprise et défauts après la mise en production.

Une expérience utile consiste à choisir deux équipes comparables et, pendant un mois, à comparer non pas le nombre de sollicitations de Copilot, mais l'évolution du cycle de travail. Cette nouvelle analytique permet de mieux distinguer les modes d'utilisation de l'outil. Mais la décision de renouveler les licences doit toujours reposer sur les résultats du développement, et non sur une belle courbe d'activité en hausse.