GitHub exige une présence humaine, mais seulement pour certains comptes

Le 24 septembre 2026, GitHub a ouvert la préversion publique de Proof of Presence : les entreprises GitHub Enterprise Cloud utilisant Enterprise Managed Users (EMU) et Microsoft Entra ID peuvent imposer une nouvelle authentification avant certaines opérations sensibles. La création d’un jeton et la modification d’un webhook font partie des actions concernées.

La mesure s’adresse à un membre déjà connecté qui tente une opération protégée. Sa session GitHub ne suffit alors plus : il est renvoyé vers le fournisseur d’identité de son entreprise, et l’action ne reprend que si la politique d’authentification choisie est satisfaite. Ce contrôle doit être activé par l’entreprise; il n’est pas proposé à tous les comptes GitHub.

Quelles actions peuvent déclencher la vérification ?

Proof of Presence étend le mode sudo, la confirmation d’identité que GitHub associe à des actions ayant un effet important sur un compte ou une organisation. Pour la préversion, les exemples couvrent plusieurs manières de modifier les accès ou de préparer leur récupération :

• Créer un jeton d’accès. Ce jeton pourra ensuite servir dans la limite des autorisations qui lui sont accordées. La vérification intervient au moment de sa création, sans retirer les jetons déjà émis.
• Modifier un webhook. Changer sa configuration peut modifier la destination à laquelle des événements GitHub sont transmis. L’opération fait partie des changements soumis au contrôle.
• Changer les paramètres de sécurité d’une organisation. Ces réglages déterminent certaines protections appliquées aux membres et aux ressources de l’organisation.
• Consulter des codes de récupération. Leur affichage donne accès à des moyens destinés à retrouver un compte ou un accès SSO dans certaines situations.

Ces exemples ne constituent pas une liste exhaustive. Le critère documenté est le déclenchement du mode sudo : les actions qu’il protège peuvent aussi déclencher Proof of Presence dans une entreprise qui l’a activé. La fusion d’une pull request reste hors du périmètre annoncé; sa prise en charge est prévue ultérieurement, sans date de disponibilité.

Pourquoi la préversion exclut-elle la plupart des comptes ?

Le périmètre annoncé combine un type de compte, un hébergement et un fournisseur d’identité précis. Il faut une entreprise EMU sur github.com ou une entreprise GitHub Enterprise Cloud avec résidence des données, appelée GHEC-DR. Dans les deux cas, Microsoft Entra ID doit fournir l’authentification unique, via SAML ou OIDC. Détenir simplement une offre Enterprise Cloud ou utiliser Entra ID pour un compte personnel ne suffit donc pas à établir son admissibilité.

La documentation de configuration GitHub mentionne aussi, dans ses prérequis SSO, les entreprises dont les membres utilisent des comptes personnels. Cette rubrique décrit des parcours de configuration de l’authentification unique; elle ne confirme pas que ces comptes bénéficient de la préversion. Le périmètre EMU énoncé lors du lancement demeure la limite explicite à retenir.

Dans une entreprise admissible, un administrateur choisit l’exigence dans les paramètres de sécurité de l’authentification, et la politique s’applique à l’échelle de l’entreprise. Le choix porte sur une nouvelle authentification auprès d’Entra ID ou sur une authentification accompagnée d’un défi multifacteur. La portée pratique dépend ensuite des règles configurées dans ce fournisseur d’identité, et non du seul nom de l’option sélectionnée dans GitHub.

Ce que « présence humaine » vérifie réellement

Lorsqu’une opération protégée appelle un contrôle, GitHub attend le retour du membre depuis Entra ID avec la confirmation que la politique demandée a été satisfaite. Une session de navigateur détournée, ou un agent qui n’en possède que le cookie, peut ainsi être arrêté avant de créer un jeton ou de changer un webhook. L’obstacle n’est cependant pas identique dans toutes les entreprises : une simple nouvelle saisie du mot de passe peut suffire si la politique Entra ID l’autorise, tandis que l’option MFA demande un facteur supplémentaire.

L’analyse de WindowsForum rappelle qu’après une vérification réussie, les actions protégées peuvent se poursuivre pendant deux heures dans la même session du navigateur sans nouveau défi. Elle relève aussi que les comptes EMU ne recevaient pas la demande sudo ordinaire, faute d’identifiants stockés par GitHub pour ces membres. Le passage par Entra ID apporte donc à ces comptes un contrôle supplémentaire au moment d’entrer dans une période autorisant les opérations sensibles.

« Présence humaine » désigne ici une authentification interactive récente, pas l’approbation séparée de chaque modification. Si une session est détournée après une vérification réussie, les opérations couvertes peuvent rester accessibles durant la période où cette validation demeure valable. La protection réduit ainsi un risque précis lié à l’usage d’une session seule; elle ne garantit ni qu’une personne a examiné le contenu du changement ni qu’elle a approuvé chacune des actions effectuées ensuite.

La frontière pour les agents et les comptes de service

Pour une équipe qui automatise son travail sur GitHub, la distinction décisive est celle entre une action interactive d’un membre et une opération exécutée avec des droits déjà délégués. Si un agent utilise la session d’un membre admissible pour tenter de créer un jeton, il peut rencontrer la redirection vers Entra ID. S’il utilise un jeton existant, les descriptions de cette préversion ne permettent pas de conclure que chaque appel effectué avec ce jeton subira le même défi.

Le même doute vaut pour un compte de service opérant sans navigateur et pour une action lancée directement par API : le fonctionnement publié décrit la redirection d’un membre au cours d’une opération protégée, sans détailler ces autres parcours. Il serait donc excessif de présenter Proof of Presence comme un contrôle général de toutes les automatisations. Pour limiter ce qu’un agent peut faire sans intervention, les droits attribués à son identité et à ses jetons restent un contrôle distinct de la réauthentification du membre.

Un exemple hypothétique montre une autre limite : si un webhook GitHub déclenche ensuite une publication ou un paiement dans un service extérieur, la validation obtenue sur GitHub ne constitue pas une autorisation de cette étape. Une entreprise qui souhaite réserver cette décision à une personne doit prévoir un contrôle propre au service concerné. À ce stade, la préversion couvre les actions GitHub liées au mode sudo pour les entreprises EMU admissibles; GitHub n’a pas encore donné de date pour la vérification avant fusion d’une pull request ni confirmé l’ouverture à d’autres fournisseurs d’identité.

À lire aussi:

• GitHub bloque les secrets à la fusion, mais seulement avec une offre payante
• Meta lance Muse aux États-Unis : l’agent agit, mais exige votre confiance
• GPT‑5.6‑Cyber s’ouvre aux défenseurs, mais exige une identité vérifiée