PACT veut distinguer humains et robots sans compte ni CAPTCHA

PACT, pour Private Access Control Tokens, propose de prouver qu’une requête humaine ou automatisée est légitime sans communiquer directement l’identité de son auteur au site visité. Le mécanisme ne certifie pas qu’un client est humain : il lui attribue une capacité limitée, utilisable tant que son comportement respecte la politique d’accès du service.

La promesse « sans compte ni CAPTCHA » signifie que le site destinataire pourrait accepter une preuve obtenue auprès d’un autre acteur, sans imposer sa propre connexion ou un défi interactif. Ce scénario n’est pas encore universel : PACT reste une proposition à standardiser, intégrer aux navigateurs et adopter côté sites.

Ce que PACT cherche réellement à prouver

PACT veut distinguer le trafic acceptable du trafic abusif, et non tracer une frontière absolue entre personnes et logiciels. Un internaute, un agent agissant pour son compte ou un service automatisé reconnu pourraient recevoir un accès, tandis qu’une activité humaine menée à une échelle abusive pourrait être limitée.

La preuve serait liée à une ressource difficile à multiplier à faible coût : un abonnement, un compte en règle ou un numéro de téléphone vérifié, par exemple. Cette rareté permettrait d’appliquer une limite sans révéler au site la ressource exacte ni l’identité qui lui est associée.

Dans son annonce du 22 juin 2026, Cloudflare présente PACT comme une initiative développée avec Mozilla, Google, Microsoft et Shopify afin d’aider humains et bots autorisés à prouver que leur trafic n’est pas malveillant, avec l’objectif de soumettre le protocole à la standardisation.

Le parcours entre l’Anchor, le navigateur et le site

La proposition technique publiée par Mozilla répartit les responsabilités entre le navigateur, un Anchor, un Moderator et le site destinataire. Cette séparation vise à transmettre une preuve exploitable sans permettre à un seul intermédiaire d’en connaître simultanément l’origine précise et toutes les destinations.

1. Au cours d’une interaction ordinaire, l’Anchor constate que le client dispose d’une ressource jugée suffisamment rare. Il remet au navigateur un lot de jetons anonymes appelés Endorsements.
2. Lorsqu’un site demande une preuve, le navigateur dépense un Endorsement auprès du Moderator choisi par ce site. Le Moderator vérifie que le jeton provient de l’un des Anchors qu’il accepte, sans savoir lequel, puis délivre une Credential.
3. Le navigateur présente cette Credential au site. Le Moderator gère la limite d’usage et peut faire évoluer l’état interne de la Credential selon que le comportement paraît normal ou suspect.

Le site destinataire n’a pas besoin de recevoir le nom, l’adresse électronique ou le compte détenu auprès de l’Anchor. Il apprend essentiellement si la Credential est valide et se trouve encore dans les limites prévues. Le site peut assurer lui-même le rôle de Moderator ou utiliser un intermédiaire commun à plusieurs services.

Humain, agent autorisé et bot malveillant

Pour un internaute, la Credential représenterait un droit borné à effectuer certaines actions. Un agent logiciel piloté par cette personne pourrait transporter la même Credential : ses opérations seraient alors imputées à la capacité accordée à l’utilisateur, sans obtenir automatiquement des privilèges supplémentaires.

Un opérateur d’agents pourrait également devenir Anchor et garantir ses logiciels. Cette garantie n’imposerait pas leur acceptation à l’ensemble du Web : chaque Moderator choisirait les Anchors auxquels il fait confiance, et chaque site déterminerait l’accès associé à une Credential valide.

Un bot malveillant chercherait plutôt à accumuler des preuves ou à dépasser la capacité reçue. PACT tente de rendre cette stratégie plus difficile en rattachant l’émission à une ressource rare et en autorisant le Moderator à réduire l’accès, voire à ne pas renouveler une Credential lorsque le comportement se dégrade. La résistance aux abus dépendrait donc des règles d’émission et de limitation autant que de la cryptographie.

L’anonymat ne supprime pas les relations de confiance

La propriété centrale recherchée est la non-corrélation. Le Moderator ne devrait pas connaître l’Anchor précis qui a fourni l’Endorsement, et les présentations successives d’une Credential ne devraient être reliables ni entre elles ni à son émission. L’objectif est de communiquer un résultat minimal sur la capacité disponible, pas de construire un historique de navigation.

Cette architecture répartit la confiance au lieu de l’éliminer. Un Anchor trop permissif pourrait fournir des Endorsements à des acteurs abusifs ; un Moderator trop sévère pourrait pénaliser des clients légitimes. Comme l’accès initial doit rester uniforme entre les Anchors masqués au sein d’un même ensemble, l’Anchor le moins fiable peut limiter le niveau de confiance accordé au départ.

La concentration reste également possible. Si quelques Anchors ou Moderators devenaient incontournables, ils acquerraient un pouvoir important sur les conditions d’accès, même sans connaître directement l’identité des visiteurs. L’anonymat des jetons ne neutraliserait pas non plus les autres moyens de suivi employés par un site, notamment les données volontairement fournies ou certains signaux techniques.

Pourquoi PACT ne signifie pas encore la fin des CAPTCHA

De nombreux éléments restent à définir et l’architecture doit encore faire l’objet d’analyses de sécurité et de confidentialité. Les protocoles cryptographiques sous-jacents sont destinés à l’IETF et l’interface Web au W3C, mais cette trajectoire de travail ne constitue ni un standard achevé ni la garantie d’un déploiement dans tous les navigateurs et services.

Les critères d’émission, la gouvernance des intermédiaires et les conséquences d’un refus devront notamment être encadrés. l’analyse de The Register souligne que les détails techniques restent en cours d’harmonisation et qu’une mise en œuvre défavorable pourrait créer une nouvelle barrière d’accès pour certains navigateurs, comportements ou agents.

Le modèle prévoit d’ailleurs un retour aux mécanismes actuels lorsqu’un navigateur ne possède aucun Endorsement acceptable. Un CAPTCHA, une création de compte ou une connexion fédérée pourraient alors servir à initialiser une Credential. PACT doit donc être compris comme une piste pour réduire ces frictions dans les cas couverts, non comme l’abolition déjà acquise des CAPTCHA ; ses garanties dépendront du futur standard, de la diversité des intermédiaires et des choix d’implémentation.

À lire aussi:

• Google My Activity : effacer le compte ne vide pas le navigateur