Le problème d'inscription des agents IA que personne n'évoque

Vous connaissez robots.txt. Il guide les robots depuis 1994 sur les zones accessibles d'un site. Il y a aussi llms.txt pour les modèles IA, ou security.txt pour signaler les failles. Mais rien n'existe pour qu'un site dise à un agent IA : "Tu peux créer un compte pour mon utilisateur, à condition que..."

Ce vide pose un vrai souci. En 2026, les agents IA ne se contentent plus de lire des pages. Ils agissent pour un humain : ils remplissent des formulaires, s'inscrivent, testent des API, lancent des essais. Du point de vue du serveur, ça ressemble à du spam pur. Pas étonnant que sites et créateurs d'agents soient perdus.

Les standards actuels ne suffisent pas

Les fichiers de politique web sont éclatés.

• robots.txt gère les crawlers des moteurs de recherche.
• llms.txt donne des règles d'usage aux IA.
• Les sitemaps listent les URLs à indexer.
• OpenAPI et MCP exposent des interfaces utilisables.
• security.txt indique les contacts pour les vulnérabilités.

Aucun ne traite de la création de comptes. Or, c'est un acte actif qui :

• Modifie l'état persistant de votre plateforme.
• Déclenche des limites de taux ou détections d'abus.
• Impacte vos stats d'inscription.
• Engage l'utilisateur à vos conditions.
• Risque des comportements imprévus.

Un simple oui/non ne marche pas. Les enjeux varient trop.

Voici l'Agent Policy Manifest

Une proposition expérimentale, /.well-known/agent-policy.json, apporte une solution. C'est un fichier lisible par machine, avec des permissions détaillées pour agents IA.

L'idée clé ? Des niveaux de permission, pas un binaire.

Le fichier répond à :

• Que font les agents en navigation publique ? (Lire pages, liens, prix).
• Qu'exige un accès API ? (Sandboxes, modes test, flux dédiés).
• Quelles conditions pour une inscription déléguée ? (Intentions humaines vérifiées, identité claire, traces d'audit).
• Quand s'arrêter net ? (Paiement, identité fictive, clauses engageantes).

Comment fonctionnent ces niveaux

Vous gérez un SaaS ? Votre politique pourrait indiquer :

Exploration publique : Activée par défaut. Les agents lisent docs, prix, fonctionnalités.

Automatisation déclarée : Seulement via API officielle ou sandbox.

Inscription déléguée : Conditionnelle. Possible pour essais si :

• Intention humaine prouvée (pas auto).
• Identité agent transparente (pas d'usurpation).
• Email traçable, genre user+agent-mon-domaine@exemple.com.
• Audit visible par l'utilisateur.
• Arrêt avant paiement ou clauses sérieuses.

Distinction vitale :

• Cases anodines (acceptation RGPD) : OK avec transparence.
• Clauses lourdes (responsabilité légale, paiements) : Humain obligatoire.

L'architecture du fichier

Un agent-policy.json réel commence par des métadonnées (version, domaine, date d'expiration). Puis des sections. Celle account_creation est centrale.

Elle définit :

• Mode par défaut (si pas de fichier).
• Modes disponibles et conditions.
• Log des acceptations de termes.
• Points d'arrêt absolus.

Ces arrêts incluent :

• Captchas ou défis anti-bot.
• Clauses interdisant les comptes auto.
• Identités fictives.
• Paiements.
• Vérifications phone.
• Posts publics.
• Acceptations engageantes.
• Termes inconnus.

L'agent s'arrête et passe la main à l'humain.

Règles de traitement pour les agents

Le projet guide les agents précisément :

Pas de fichier ? Exploration publique seulement. Lire, résumer, mais pas s'inscrire.

Autorisation explicite ? Avancer dans les limites précisées. Logger l'URL du fichier et l'humain concerné.

Case routinière ? OK si autorisé, avec log.

Clauses majeures ? Stop net. Pas d'engagement pour l'utilisateur.

Pourquoi ça compte pour les devs

Pour les créateurs d'agents : un repère clair. Vérifiez le fichier, parsez les niveaux, gérez les cas sans politique, assurez des audits fiables.

Pour les plateformes : contrôle fin. Favorisez les inscriptions aidées sans risques, segmentez par type d'utilisateur, respectez les régulations, tracez les limites.

Pour les utilisateurs : visibilité totale. Vous voyez ce que l'agent peut faire pour vous, et vous contrôlez les logs.

Phase expérimentale : et après ?

C'est un brouillon de wkdomains.com, ouvert aux débats entre propriétaires de domaines, bot-makers, standards bodies et agent-builders. Expérimental, donc évolutif.

Expiration fixée au 1er novembre 2026 pour itérer vite, sans figer trop tôt.

La vision d'ensemble

On est à un tournant. Les agents IA deviennent des utilisateurs délégués, pas de simples robots. L'infra web des permissions traîne. robots.txt marche car incentives alignés : visibilité pour tous.

Mais inscriptions par agents ? Incentives complexes : sécurité pour plateformes, transparence pour users, rails clairs pour agents. Un agent-policy.json ne règle pas tout, mais crée un langage commun.

Si votre plateforme accepte les agents, publiez une politique. Si vous en construisez, vérifiez-la. Devs standards : venez contribuer.

Sinon ? On devine. Avec des agents plus malins, deviner ne suffit plus.