GitHub Copilot sait désormais relier la télémétrie à un utilisateur sans collecter les prompts

GitHub Copilot dispose d'un nouveau paramètre qui sépare deux questions longtemps confondues dans la télémétrie d'entreprise : qui utilise l'assistant, et ce qu'il lui écrit exactement. Le paramètre telemetry.capture.identity, dans les managed settings, permet aux administrateurs Enterprise d'attribuer l'activité de Copilot à un utilisateur précis, sans collecter les prompts, les réponses ni le contenu des outils. Il ajoute trois options de configuration. Leur liste est tronquée dans l'extrait publié de l'annonce : mieux vaut donc vérifier les noms et valeurs exacts dans l'entrée d'origine du GitHub Changelog datée du 12 octobre 2026.

Ce qui change concrètement

Jusqu'ici, les entreprises qui déployaient des assistants IA pour développeurs faisaient face à un choix peu satisfaisant. Soit elles collectaient la télémétrie sous forme anonymisée, sans savoir quels collaborateurs utilisaient réellement l'outil. Soit elles activaient une collecte détaillée : avec l'attribution, les logs recevaient aussi le texte des requêtes, des fragments de code et les résultats des appels d'outils. Dans ce second cas, le stockage de télémétrie peut finir par contenir tout ce que le développeur a montré au modèle : API internes, noms de clients, morceaux de logique non publique.

Le nouveau paramètre fait de l'identité un axe distinct. L'administrateur peut conserver le lien entre un événement et un utilisateur sans récupérer le contenu de l'interaction. La configuration se définit de façon centralisée via les managed settings : le développeur ne la change pas en local.

À quoi cela sert aux entreprises

L'attribution sans contenu répond à plusieurs besoins classiques d'un déploiement en entreprise :

• suivi des licences : on voit quelles places achetées sont réellement utilisées et lesquelles restent inactives ;
• mesure de l'efficacité : l'activité peut être rapprochée des équipes et des projets, sans lire les échanges eux-mêmes ;
• analyse d'incidents : en cas de comportement anormal d'un client, on sait sur quel poste il est apparu ;
• conformité aux politiques internes : l'équipe sécurité n'a pas besoin de stocker le code et les prompts pour répondre à la question « qui, et quand ».

Un autre argument tient à la réglementation. Pour les entreprises européennes, les données personnelles présentes dans la télémétrie et le contenu des échanges de travail relèvent généralement de régimes de concertation différents avec les salariés et les syndicats. Quand la collecte de l'identifiant est séparée de celle des textes, elle est plus facile à justifier : la finalité est claire, le volume de données limité.

Ce qui reste flou

L'annonce, dans la version disponible, ne détaille pas plusieurs points. On ignore quelles sont exactement les trois options proposées par telemetry.capture.identity, et sous quelle forme l'identifiant est stocké : login, ID interne ou hash. Le texte n'indique pas non plus à quels clients Copilot le paramètre s'applique, ni comment il interagit avec les paramètres de collecte de contenu déjà existants. Ces points déterminent si le paramètre convient à des politiques strictes ; il faut les vérifier avant de l'activer.

Comment procéder côté administrateurs

Voici la marche à suivre :

1. Lire l'entrée complète du GitHub Changelog et la documentation sur les managed settings, puis relever les trois valeurs du paramètre. 2. Définir l'objectif de l'attribution : suivi des licences, sécurité ou analyse de la productivité. Le choix du mode en dépend. 3. Valider l'usage avec les juristes et les représentants des salariés. L'identifiant utilisateur reste une donnée personnelle, même lorsque les logs ne contiennent aucun prompt. 4. Vérifier sur un groupe pilote que le contenu n'arrive bien pas dans la télémétrie, par exemple en examinant les événements réels dans le collecteur de logs. 5. Fixer la durée de conservation et le périmètre d'accès aux données : l'attribution seule permet déjà de construire des profils d'activité.

Pour le marché, le bilan est pragmatique. Les assistants IA d'entreprise se choisissent de plus en plus selon le contrôle qu'ils offrent sur les données, et pas seulement selon la qualité du modèle. Pouvoir répondre à « qui utilise » sans répondre à « qu'a-t-il écrit » retire l'un des arguments les plus fréquents des équipes sécurité contre un déploiement à grande échelle.