GitHub ajoute une troisième identité aux commits : qui a réellement fait le push

GitHub a commencé à enregistrer durablement l'utilisateur authentifié qui a effectué un push, et affiche cette identité dans l'interface et l'API, à côté des champs author et committer déjà existants. La fonction s'appelle push attribution et n'est pour l'instant disponible qu'en limited public preview. L'annonce a été publiée le 12 octobre 2026 dans le GitHub Changelog. Chaque commit porte désormais trois identités au lieu de deux, et l'une d'elles est confirmée par la plateforme.

Ce qui change concrètement

Dans git, les champs author et committer sont renseignés côté client. Leurs valeurs viennent de la configuration locale ou des variables d'environnement, et rien n'empêche d'y indiquer le nom et l'adresse e-mail de quelqu'un d'autre. GitHub associe ces adresses à des comptes et peut marquer un commit comme Verified s'il est signé, mais loin de tous les commits le sont. Savoir « qui a envoyé cela dans le dépôt » ne pouvait auparavant se reconstituer qu'indirectement dans l'historique public, par exemple via les événements du dépôt ou les journaux d'audit.

La push attribution comble ce manque. La plateforme sait qui s'est authentifié lors du push et conserve désormais cette information dans les données du commit. Le champ pusher apparaît dans l'UI et est accessible via l'API.

Pourquoi c'est utile à l'ère des agents

L'annonce ne détaille pas la motivation : ce qui suit relève donc de la logique d'ingénierie, pas de déclarations de GitHub. Un commit typique passe aujourd'hui entre plusieurs mains. L'auteur peut être un développeur, le committer change lors d'un rebase, d'un squash ou d'un cherry-pick, et le push est effectué par un jeton de service ou par un agent d'IA agissant au nom d'un utilisateur. Les trois champs apportent trois réponses différentes à la question « à qui appartient ce code ».

Pour l'analyse d'incidents et les contrôles de sécurité, la distinction est fondamentale. Si un commit malveillant, ou simplement défaillant, atterrit dans une branche, l'auteur indiqué dans les métadonnées ne prouve rien. Le pusher montre quels identifiants ont servi à livrer le code. Pour les organisations soumises à des exigences de conformité, c'est aussi un moyen de distinguer le travail d'un humain de celui d'une automatisation, sans recoupement manuel des journaux.

Ce que l'on sait et ce que l'on ignore

• Statut : limited public preview, annonce du 12 octobre 2026
• Nouvelle valeur : pusher, c'est-à-dire l'utilisateur authentifié qui a effectué le push
• Où la voir : interface GitHub et API, à côté d'author et de committer
• Source des données : authentification côté serveur, et non le git config du client
• Non précisé dans l'annonce : tarifs, liste des comptes et organisations éligibles, comportement pour les anciens commits, format exact du champ dans REST et GraphQL, représentation des GitHub Apps et des bots

Le dernier point est le plus intéressant. La valeur pratique de la fonction, pour ceux qui construisent des automatisations autour des dépôts, dépendra de la manière dont le champ présentera les applications et les agents.

Ce que les équipes peuvent vérifier dès maintenant

Tant que la fonction reste en preview, il est trop tôt pour l'intégrer à des processus critiques, mais on peut se préparer. Premièrement, vérifiez si la preview est disponible pour votre organisation et testez-la sur un dépôt non stratégique. Deuxièmement, identifiez les intégrations qui poussent dans votre code : jetons personnels, GitHub Apps, runners de CI, agents.

Ce que vous verrez dans le champ pusher en dépend. Troisièmement, si vous disposez de scripts d'audit qui reconstituent aujourd'hui « qui a poussé » à partir des événements et des journaux, évaluez s'il sera possible de les remplacer par des requêtes à l'API une fois le format du champ stabilisé. Enfin, n'abandonnez pas la signature des commits : le pusher indique qui a livré le code, mais ne prouve pas qui l'a écrit.