Les noms de domaine survivront aux sites web

Le 13 avril, un blogpost de Cloudflare passe à peu près inaperçu en dehors des cercles d'infrastructure. On y apprend que les premiers consommateurs de leurs APIs ne sont plus des développeurs humains mais des agents IA, et que l'entreprise refait son outillage en conséquence. Nouveau CLI unifié baptisé cf, schéma TypeScript pour trois mille opérations, commandes standardisées pour que les modèles de langage arrêtent de se planter sur des variantes qu'ils ne connaissent pas. La phrase est glissée sans théâtralité, comme une note de mise à jour. Ce qu'on lit, au fond, c'est que l'une des infrastructures qui tient internet a décidé que son interlocuteur principal n'était plus tout à fait humain.

Quelques jours plus tôt, dans un podcast enregistré à Palo Alto, Marc Andreessen avait annoncé la fin du navigateur qu'il avait lui-même inventé trois décennies plus tôt. Cofondateur d'a16z, aujourd'hui investisseur et porte-voix de la Silicon Valley, Andreessen construisait Mosaic en 1993 puis lançait Netscape Navigator en 1994. Il explique maintenant que les agents vont absorber le parcours recherche-clic-formulaire-panier. Le navigateur servait d'interface entre l'humain et le serveur. L'agent devient l'interface entre l'humain et le résultat.

Les deux événements, mis côte à côte, dessinent quelque chose qui dépasse la prospective. Pour ceux qui s'intéressent de près aux noms de domaine, la question arrive sans détour. Si le navigateur disparaît et que les plateformes d'infrastructure se réorganisent autour des agents, est-ce que le nom de domaine part avec ?

C'est une rengaine. On nous l'a servie au web 2.0 quand les plateformes allaient tuer les sites. Au web 3 quand la blockchain allait remplacer le DNS. Aujourd'hui au web agentique parce que les agents rendent les URL invisibles. À chaque itération, la même inquiétude traverse notre milieu. À chaque itération, une infrastructure qu'on croyait menacée finit par trouver une fonction nouvelle, rarement celle qu'on avait imaginée.

Un site web repose sur trois couches. L'interface, ce que le navigateur affiche. La logique, ce que le serveur exécute. L'adresse, ce qui permet de trouver le serveur.

Quand Andreessen parle de la mort du navigateur, il parle de la première couche. L'interface visuelle, la page qu'on regarde avec ses yeux et qu'on parcourt avec ses clics.

Les deux autres ne se contentent pas de survivre. Elles deviennent plus importantes. Un agent qui passe une commande, compare des prix ou vérifie une disponibilité interroge forcément un serveur. Ce serveur doit être trouvé, et le système qui permet de le trouver, c'est le DNS.

Le nom de domaine n'a jamais été seulement une adresse de site web. C'est une adresse de serveur. On a juste pris l'habitude de confondre les deux parce que, pendant trente ans, l'usage le plus visible du DNS a été d'afficher une page. Les MX records servent l'email depuis le premier jour. SPF, DKIM, DMARC authentifient chaque message via des enregistrements DNS. Les SRV records font tourner la VoIP. Le web n'a jamais été qu'un client bruyant parmi d'autres.

Les standards s'écrivent maintenant. Ce n'est pas de la prospective, c'est de la lecture de mailing-lists.

GoDaddy introduit en avril 2026 l'Agent Name Service, un standard ouvert de nommage, de vérification et de découverte d'agents, construit sur le DNS et l'infrastructure à clé publique existants. Cloudflare l'intègre dans son partenariat sur le web agentique. Le protocole A2A formalise de son côté la découverte de services via un fichier déposé à /.well-known/agent-card.json, même logique que robots.txt, sauf que le client n'est plus un crawler mais un agent autonome. La spécification agents.json, portée par wild-card-ai en version 0.1.0, ajoute une extension à OpenAPI orientée modèles de langage, hébergée à /.well-known/agents.json.

À l'IETF, pas un brouillon sur la découverte d'agents, mais onze drafts concurrents. Dans l'histoire du groupe, cette configuration signifie souvent qu'aucun ne s'impose tel quel. Mais la direction reste claire, et c'est elle qui compte : tout converge vers le DNS comme fondation, même si le chemin pour y arriver reste disputé. L'agent résout le domaine, puis interroge les fichiers de découverte. Le domaine est le premier maillon.

Jusqu'ici, un nom de domaine servait à deux choses. Être mémorisable par un humain. Être tapé dans une barre d'adresse. L'une comme l'autre présupposent un regard, une main, une intention humaine.

Dans un web d'agents, la mémorabilité devient secondaire. Ce qui compte, c'est la vérifiabilité. L'agent ne tape rien. Il résout, il vérifie, il fait confiance, ou pas. Le domaine cesse d'être une mnémonique. Il devient une ancre de confiance.

Trois implications se dessinent.

La première concerne le marché secondaire, qui pourrait se restructurer en profondeur. La valeur d'un domaine premium repose aujourd'hui sur sa mémorabilité, sur des noms comme hotel.com ou insurance.com. Si les agents ne tapent plus de domaines, ce n'est plus le nom mémorable qui porte la valeur, mais la réputation, l'ancienneté, la confiance accumulée. Un domaine actif depuis quinze ans avec un historique propre vaudrait plus qu'un exact match domain acheté hier.

La deuxième touche les registrars. On vend aujourd'hui des domaines à des humains qui veulent un site web. Demain, on vendrait des identités vérifiées à des services qui veulent être trouvés par des agents. Le cœur de valeur glisse du nom vers le certificat qui l'accompagne.

La troisième concerne les geoTLDs. Un agent qui cherche un artisan en Corse et tombe sur un domaine en .corsica récupère un signal de localisation vérifié par un registre qui applique des règles d'éligibilité. Vérifiable, structuré, non falsifiable. Le .corsica cesserait d'être seulement un marqueur culturel pour devenir un filtre de confiance géographique. Même logique pour .bzh, .cat, .eus, .gal. Les politiques d'éligibilité strictes, longtemps perçues comme un frein commercial, basculent du côté des atouts.

À ce jour, aucun agent, aucun modèle, aucun framework ne vérifie la politique d'éligibilité d'un TLD. C'est une projection, pas un état de fait. Mais les specs de découverte s'écrivent maintenant, et les métadonnées de confiance qu'elles transporteront devront venir de quelque part.

Il existe une autre catégorie d'extensions qui joue sur un registre différent, celui de la propriété. Plus de cinq cents brand TLDs ont été délégués depuis le round ICANN de 2012. Côté américain, .google, .amazon, .apple. Côté français, .leclerc, .sncf, .mma, parmi d'autres sur lesquels j'ai eu l'occasion de travailler. Tous fournissent par construction ce qu'aucun autre domaine ne peut offrir : une identité protocolaire vérifiable. Apple possède toutes les adresses en .apple parce que la Spec 13 d'ICANN l'y oblige. Pour un agent qui décide à qui faire confiance, ce n'est plus une estimation réputationnelle, c'est une certitude contractuelle. La fraude par typosquatting devient hors de portée, la surface d'attaque se réduit à un acteur unique, et le phishing classique, qui vit de l'œil humain défaillant, s'effondre dans ce modèle.

Le paradoxe historique mérite une note. Beaucoup de ces extensions cherchent encore leur usage depuis dix ans. La même question revient dans tous les comités de gouvernance : à quoi ça sert vraiment, au-delà du contrôle de marque ? Toutes se retrouvent aujourd'hui avec une infrastructure prête à activer pour un cas d'usage qui n'existait pas à l'époque. Au round 2026, le brand TLD se vendra comme ancre de confiance pour les agents, plus comme vitrine marketing. Les arguments auront changé. Les tarifs aussi.

Il y a un angle que la plupart des analyses oublient.

Les agents ne seront pas tous dans le cloud. La tendance forte aujourd'hui, c'est l'agent local, celui qui tourne sur ta machine, qui a accès à tes fichiers, qui connaît ton contexte. J'utilise Claude Code depuis des mois, un agent qui opère directement dans mon terminal de développement. Il lit mon code, exécute des commandes, corrige ses erreurs, tout sur ma machine.

Un agent local a toujours besoin du réseau. Pour interroger une API, pour vérifier une information, pour envoyer un email. Chaque interaction passe par un serveur distant, identifié par un nom de domaine. Plus les agents deviennent locaux et autonomes, plus ils ont besoin d'adresses distantes fiables. Le DNS ne disparaît pas avec les navigateurs. Il devient plus critique à mesure que les agents se multiplient.

C'est probablement le débat le plus difficile qui attend notre milieu.

Quand un agent décide de faire confiance à un interlocuteur, il veut savoir qui est derrière. RDAP est aujourd'hui le protocole qui expose ces données de registration. Depuis l'entrée en vigueur du RGPD en 2018, nous masquons volontairement l'essentiel de ces données. Nom, adresse et email du registrant sont occultés par défaut pour les personnes physiques, et de plus en plus pour les organisations aussi, par précaution. Un agent qui interroge un domaine obtient « REDACTED FOR PRIVACY » là où il y avait autrefois une identité.

La contradiction est nette. Les agents ont besoin de signaux de confiance vérifiables pour décider à qui parler. La réglementation européenne impose de ne pas exposer publiquement ces données. On ne résoudra pas ça en ajoutant des champs à RDAP.

C'est ici que les contributions de la communauté web3 deviennent pertinentes, au-delà de leur réputation mitigée. Les preuves à divulgation nulle de connaissance et les credentials vérifiables normalisés par le W3C (DID et VC, publiés en 2022) permettent à un registrant de prouver qu'il est, par exemple, une entreprise enregistrée en France, sans exposer son SIREN ni sa raison sociale. L'agent vérifie cryptographiquement la preuve, émise par une autorité tierce légitime comme l'INSEE, la chambre de commerce ou un registre accrédité. Il accède à la confiance sans accéder aux données sous-jacentes.

Cette couche n'existe pas encore dans RDAP. Elle est techniquement mûre, les briques sont publiées, les bibliothèques de référence disponibles. Ce qui manque, c'est le mandat politique et la coordination de l'industrie pour l'articuler.

Au-delà du nœud RDAP-RGPD, trois mouvements opérationnels se présentent.

Le plus évident concerne les services eux-mêmes. Pour exister dans un web d'agents, un service aura besoin d'un domaine, puisque c'est là que se posent les fichiers de découverte, agent-card.json, agents.json, les enregistrements ANS. Sans domaine, aucun agent ne peut le trouver ni vérifier qui il est. Le service peut tourner parfaitement, personne ne le saura. C'est l'équivalent de ne pas avoir de site web en 2005.

Il y a ensuite ce que les registres devront faire. Un registre qui enrichit ses domaines avec des données structurées sur l'éligibilité géographique, la catégorisation sectorielle, l'historique de confiance, fournit exactement ce dont les agents auraient besoin pour décider. Les autres proposent un bloc opaque que les systèmes autonomes ignoreront.

Et puis il y a la sécurité, qui est le chantier qu'on remet depuis vingt ans. DNSSEC plafonne autour de 40% d'adoption mondiale. Pour un humain qui tape un domaine dans un navigateur, le risque résiduel reste tolérable. Pour un agent qui déclenche une transaction automatisée sans vérification humaine, il ne l'est plus. Et les nouveaux protocoles de découverte posent des fondations fonctionnelles mais sans couche de sécurité mature. Usurpation d'identité d'agent, empoisonnement de fichiers de découverte, interception sur des points d'accès non authentifiés : ce sont les vecteurs que le DNS a dû résoudre, rejoués sur une nouvelle couche. L'expertise est chez nous. Reste à savoir si nous la mobilisons à temps.

Il faut aussi regarder sérieusement là où cette thèse pourrait vieillir mal.

Le scénario le plus dangereux pour notre milieu n'est pas que le DNS devienne inutile. C'est qu'il soit contourné. Par deux voies différentes, qui n'ont à peu près rien en commun, sauf de rendre le nom de domaine accessoire.

Le premier contournement est centralisé. Google, OpenAI, Anthropic et les autres fournisseurs d'agents pourraient très bien maintenir des registres privés de services, l'équivalent d'un App Store pour agents. L'agent interrogerait le catalogue de son fournisseur, pas le DNS. Le domaine existerait toujours en arrière-plan, mais deviendrait invisible et interchangeable, comme l'adresse IP l'est devenue derrière le CDN. C'est exactement ce qui s'est passé avec les apps mobiles : les domaines n'ont pas disparu, mais la découverte est passée par l'App Store, et le DNS a perdu la couche de valeur.

Le second contournement est décentralisé, et c'est probablement celui que nous sous-estimons. Les identifiants décentralisés (DID), les noms sur blockchain (ENS, Handshake), les credentials vérifiables conçus pour fonctionner sans autorité de nommage centrale : ces briques existent, elles mûrissent, elles trouvent leurs cas d'usage. Dans un monde où un agent n'a plus besoin du DNS pour résoudre une identité parce qu'il dispose d'un identifiant cryptographique auto-porteur, le nom de domaine devient une relique infrastructurelle, tolérée mais marginale.

Ces deux scénarios peuvent coexister. Ils peuvent même se renforcer mutuellement. Et si l'un ou l'autre s'impose, l'article que vous êtes en train de lire vieillira mal.

La seule réponse n'est pas défensive. Elle consiste à construire la couche de découverte agent sur le DNS avant que quelqu'un d'autre la construise ailleurs. C'est ce que tentent ANS et les specs .well-known/. La course est ouverte, et elle n'est pas gagnée.

Notre milieu a l'habitude des prophéties de mort. On nous annonce la fin des noms de domaine depuis les apps mobiles. Puis depuis les réseaux sociaux. Puis depuis les QR codes. Aujourd'hui depuis les agents.

À chaque fois, la même réponse. L'infrastructure survit aux interfaces qui la consomment. Le téléphone a changé une dizaine de fois de forme depuis Bell. Le numéro de téléphone est toujours là.

Le web va changer d'interface. Le navigateur va reculer. Les sites web tels qu'on les connaît vont se transformer. Mais tant qu'il y aura des serveurs, et il y en aura toujours, il y aura des noms de domaine, à condition qu'on les défende contre les deux contournements possibles.

La seule question, c'est de savoir si nous nous adaptons assez vite pour que le domaine reste pertinent dans la chaîne de valeur, ou si nous laissons d'autres construire la couche de confiance à notre place.

Les specs s'écrivent maintenant. C'est maintenant qu'on décide si on est à la table ou au menu.