Après les sites et les e-mails, le DNS pourrait-il devenir la racine de confiance des agents IA ?

Pendant des décennies, le nom de domaine a permis de trouver un site, d’acheminer un e-mail ou d’identifier un service. L’arrivée des agents d’intelligence artificielle pose désormais une nouvelle question : comment vérifier qu’une machine est réellement autorisée à agir au nom d’une organisation ? Un projet émergent, ApertoID, propose une réponse qui mérite notre attention : revenir au DNS.

Depuis trente ans, le domaine répond essentiellement à quelques questions simples.

Où se trouve ce service ? Où faut-il acheminer cet e-mail ? À quelle organisation rattacher cette présence numérique ?

L’essor des agents autonomes en ajoute une quatrième, beaucoup plus délicate :

Qui a réellement autorisé cette machine à agir ?

Imaginons qu’un agent contacte demain une banque, une administration ou un fournisseur et affirme :

« Je suis un agent autorisé par cette entreprise et je peux réaliser cette opération en son nom. »

Le problème n’est plus seulement de savoir où se trouve le service.

Il faut vérifier l’autorité qui se trouve derrière lui.

C’est précisément le problème auquel s’attaque ApertoID.

Une question simple : qui parle réellement ?

L’intelligence artificielle évolue progressivement d’une logique de consultation vers une logique d’action.

Nous connaissons les assistants auxquels nous demandons de produire un texte, d’analyser un document ou de rechercher une information.

Mais une autre génération de systèmes apparaît : des agents capables d’interroger des services, d’appeler des API, d’échanger avec d’autres agents et, potentiellement, d’effectuer certaines opérations avec une autonomie croissante.

Lorsqu’un humain se présente comme le représentant d’une organisation, il existe toute une chaîne de vérification possible.

Pour une machine, cette chaîne reste beaucoup moins évidente.

Un agent peut techniquement déclarer :

« J’agis pour example.com. »

Cela ne signifie pas pour autant que le titulaire de example.com l’a autorisé.

Cette différence entre identité revendiquée et identité vérifiable pourrait devenir l’un des grands problèmes de confiance de l’Internet des agents.

Le projet ApertoID part précisément de ce constat : l’infrastructure actuelle ne fournit pas encore de mécanisme standard permettant de vérifier qu’un agent prétendant représenter un domaine a réellement été autorisé par celui-ci.

ApertoID : appliquer aux agents une logique déjà connue pour l’e-mail

L’idée d’ApertoID est intéressante parce qu’elle ne cherche pas à reconstruire Internet.

Elle réutilise une infrastructure déjà universelle : le DNS.

Le principe rappelle volontairement l’évolution de la sécurité de l’e-mail.

Pendant longtemps, n’importe quel serveur pouvait prétendre envoyer un message depuis un domaine qu’il ne contrôlait pas.

Des mécanismes comme SPF, DKIM puis DMARC ont progressivement permis aux titulaires de domaines de publier des informations d’autorisation, des clés cryptographiques et des politiques de traitement.

ApertoID transpose cette logique aux agents.

Une organisation pourrait d’abord publier une politique générale sous son domaine :

_apertoid.example.com

Cette politique indiquerait notamment ce qu’un système doit faire lorsqu’un agent ne peut pas être vérifié :

• none : ne pas appliquer de mesure particulière et observer,
• warn : accepter mais signaler l’échec de vérification,
• reject : rejeter l’agent qui ne passe pas la vérification.

Puis chaque agent autorisé disposerait de sa propre déclaration DNS :

assistant._apertoid.example.com

L’enregistrement pourrait notamment préciser :

• l’URL officielle de l’agent,
• sa clé publique,
• son type,
• la date d’expiration de sa clé,
• son éventuelle délégation à un fournisseur tiers.

Le draft prévoit notamment l’utilisation de clés publiques Ed25519 et des mécanismes permettant l’expiration, la rotation et la révocation des clés.

Un document compagnon, ApertoID-Signature, complète l’architecture en proposant qu’un agent puisse signer cryptographiquement les requêtes qu’il émet.

On passe alors d’une simple déclaration à une logique beaucoup plus forte.

Le domaine ne dit plus seulement : « cet agent est autorisé à agir pour moi ».

L’agent peut également être amené à démontrer qu’il possède bien la clé privée correspondant à la clé publique publiée par l’organisation dans le DNS.

Le domaine pourrait devenir une racine d’autorité pour les machines

C’est probablement la conséquence la plus importante de cette réflexion.

Nous avons longtemps considéré le domaine comme une adresse.

Puis comme un actif de marque.

Puis comme une infrastructure de sécurité, notamment avec DNSSEC, SPF, DKIM, DMARC, DANE ou les certificats.

Les agents IA pourraient ouvrir une nouvelle étape.

Le domaine deviendrait potentiellement le point auquel une organisation rattache publiquement les machines autorisées à agir en son nom.

Le prochain enjeu des noms de domaine ne sera peut-être plus seulement de protéger l’endroit où une organisation est visible, mais aussi l’endroit depuis lequel elle délègue son autorité numérique.

Ce changement peut paraître subtil.

Il ne l’est pas.

Car derrière une identité d’agent se trouvent potentiellement des capacités d’action :

• interroger des données,
• accéder à des services,
• communiquer avec d’autres systèmes,
• déclencher des processus,
• transmettre des instructions,
• réaliser certaines transactions,
• interagir avec des clients, des fournisseurs ou des administrations.

La question du domaine se rapproche alors directement de celle de l’autorité numérique.

Pourquoi revenir encore au DNS ?

À chaque nouveau problème numérique apparaît la tentation de créer une nouvelle plateforme centrale.

On pourrait imaginer un immense registre mondial contenant les agents IA, leurs propriétaires, leurs clés et leurs autorisations.

Mais une question apparaîtrait immédiatement :

qui contrôlerait ce registre ?

Une entreprise technologique ? Une autorité publique ? Une organisation internationale ? Plusieurs acteurs concurrents ?

ApertoID choisit une autre philosophie.

Le titulaire du domaine déclare lui-même les agents qu’il autorise.

Il n’est donc pas nécessaire, dans le modèle proposé, de confier la racine de cette déclaration à une nouvelle plateforme commerciale mondiale.

Cette approche possède plusieurs qualités :

• elle réutilise une infrastructure déjà déployée mondialement,
• elle respecte la logique de délégation propre au DNS,
• elle permet à chaque organisation de conserver le contrôle de sa zone,
• elle évite la création obligatoire d’un registre central des agents,
• elle peut fonctionner avec différents protocoles applicatifs utilisés par les agents.

C’est une différence importante. La confiance n’est pas construite autour d’une nouvelle plateforme.

Elle est rattachée à une infrastructure distribuée déjà au cœur d’Internet.

DNSSEC devient alors beaucoup plus qu’une bonne pratique

Mais cette architecture fait apparaître une conséquence immédiate.

Si nous demandons au DNS de publier les clés permettant de vérifier l’identité d’agents, il faut pouvoir faire confiance aux réponses DNS elles-mêmes.

Le draft ApertoID recommande donc que les enregistrements soient protégés par DNSSEC.

Il va même plus loin : la validation DNSSEC est considérée comme nécessaire pour atteindre le niveau complet de vérification cryptographique envisagé par le protocole.

Ce point mérite une attention particulière. Pendant longtemps, DNSSEC a parfois été perçu par les entreprises comme une amélioration technique importante mais relativement éloignée des usages visibles.

Le développement d’identités machines adossées au DNS pourrait modifier profondément cette perception.

Car si le DNS devient un endroit où sont publiés :

• les agents autorisés,
• leurs clés publiques,
• leurs politiques,
• leurs délégations,
• leurs révocations,

alors la protection de cette infrastructure devient directement liée à la confiance accordée aux machines.

La sécurité du DNS devient une composante de la sécurité de l’intelligence artificielle.

Une nouvelle discipline de gouvernance pourrait apparaître

Cette évolution pourrait également transformer la gestion des portefeuilles de noms de domaine.

Aujourd’hui, une gouvernance sérieuse doit déjà maîtriser :

• les registrars,
• les accès aux comptes,
• les serveurs DNS,
• DNSSEC,
• les sous-domaines,
• les certificats,
• SPF, DKIM et DMARC,
• les domaines défensifs,
• les expirations et renouvellements.

Demain pourraient s’ajouter :

• l’inventaire des agents autorisés,
• les sélecteurs associés à chaque agent,
• les clés cryptographiques,
• leur rotation,
• leurs dates d’expiration,
• les procédures de révocation,
• les délégations vers des agents tiers,
• les politiques de vérification,
• la surveillance des identités machines.

Ce n’est plus seulement du Domain Asset Management.

Cela commence à ressembler à de la gouvernance d’autorité numérique.

Et lorsqu’un agent tiers est utilisé, le sujet devient encore plus intéressant. Le draft prévoit en effet un mécanisme permettant à un domaine de déléguer la déclaration d’un agent vers l’infrastructure d’un fournisseur externe.

Une nouvelle chaîne de dépendance apparaît alors.

Qui contrôle le domaine ? Qui contrôle le DNS ? Qui contrôle la clé ? Qui peut révoquer l’agent ? Que se passe-t-il lorsque l’on change de fournisseur ?

Ces questions deviendront stratégiques si les agents autonomes acquièrent de réelles capacités d’action.

Il existe aussi des risques

Utiliser le DNS comme infrastructure publique d’identité implique naturellement des compromis.

Les déclarations ApertoID seraient publiquement consultables.

Elles pourraient donc révéler :

• l’existence de certains agents,
• leurs points d’accès,
• l’utilisation de systèmes d’IA par une organisation,
• certains éléments de son architecture technique ou organisationnelle.

Le draft recommande d’ailleurs l’utilisation de sélecteurs non prévisibles et d’URL suffisamment génériques lorsque les organisations souhaitent limiter cette exposition.

La gestion des clés constitue un autre enjeu majeur.

Si la clé privée d’un agent est compromise, l’organisation doit pouvoir réagir rapidement.

ApertoID prévoit un mécanisme de révocation explicite ainsi que des recommandations de TTL courts afin de réduire la période pendant laquelle une ancienne information pourrait rester en cache.

La capacité à révoquer rapidement une identité machine devient alors aussi importante que celle de la créer.

Pour l’Afrique, le sujet dépasse largement l’intelligence artificielle

Si cette architecture, ou des modèles similaires, venait à s’imposer, une conséquence devrait retenir l’attention des États et des écosystèmes numériques africains.

Les ccTLD, les infrastructures DNS nationales et leur niveau de sécurité pourraient progressivement participer à une économie dans laquelle des machines devront prouver pour quelles organisations elles sont autorisées à agir.

La résilience des extensions nationales ne concernerait donc plus uniquement :

• les sites gouvernementaux,
• les entreprises,
• les services publics,
• la messagerie,
• les plateformes numériques.

Elle pourrait demain concerner également l’identité des agents logiciels qui interagissent avec ces infrastructures.

Cela renforcerait encore l’importance de plusieurs sujets déjà stratégiques pour le continent :

DNSSEC, sécurité des registres, gouvernance des registrars, protection des accès, gestion des clés, continuité DNS et maîtrise des noms de domaine institutionnels.

Si l’identité des agents de demain s’ancre dans le DNS, gouverner correctement ses noms de domaine ne sera plus seulement protéger sa présence numérique. Ce sera protéger sa capacité à déléguer une action numérique.

Pour les États, cela pose également une question de souveraineté.

Si demain les administrations, entreprises stratégiques ou infrastructures critiques utilisent massivement des agents autonomes, il faudra pouvoir déterminer :

• quelle organisation les autorise ;
• sur quel domaine cette autorité repose ;
• qui contrôle la zone DNS ;
• quelle chaîne de confiance protège cette information ;
• comment l’identité peut être révoquée en cas d’incident.

L’identité numérique des machines pourrait ainsi rejoindre progressivement la gouvernance des infrastructures Internet critiques.

Ne faisons pourtant pas d’ApertoID un standard avant l’heure

Il faut conserver une distinction essentielle.

ApertoID est actuellement un Internet-Draft. La version publiée le 9 août 2026 est draft-ferro-dnsop-apertoid-01.

Le document peut encore évoluer, être remplacé, ne jamais devenir RFC ou être dépassé par une autre architecture.

D’autres travaux explorent parallèlement la découverte et l’authentification des agents.

ApertoID lui-même se présente comme complémentaire de plusieurs approches, notamment DNS-AID pour la découverte des agents ainsi que de protocoles applicatifs comme MCP ou A2A.

L’important n’est donc pas de prédire qu’ApertoID deviendra le standard dominant. L’important est d’observer la direction prise par l’architecture Internet.

Une question nouvelle est désormais posée :

comment une machine prouvera-t-elle qu’elle est autorisée à représenter une identité Internet ?

Et plusieurs travaux commencent à regarder vers le DNS pour apporter une partie de la réponse.

C’est cela qu’il faut surveiller.

Après nommer et trouver, le DNS pourrait aider à autoriser

Internet a grandi autour d’une idée remarquablement simple : séparer les applications des fondations permettant aux machines de se trouver et de communiquer.

Le DNS fait partie de ces fondations.

Il a traversé les différentes générations du Web parce qu’il remplit une fonction plus profonde que celle d’un simple annuaire : il rattache des noms à une autorité distribuée.

Les agents IA pourraient donner à cette fonction une importance nouvelle.

Hier, nous demandions au DNS :

Où se trouve ce service ?

Puis :

Qui peut envoyer un e-mail pour ce domaine ?

Demain, nous pourrions également lui demander :

Cette machine est-elle réellement autorisée à agir pour cette organisation ?

ApertoID n’est encore qu’une proposition.

Mais la question qu’il pose est beaucoup plus importante que le projet lui-même.

Car si les prochaines interactions numériques s’effectuent de plus en plus entre machines autonomes, nous aurons besoin d’une infrastructure permettant de rattacher leurs actions à des identités responsables.

Et dans cette future économie de confiance, le nom de domaine pourrait découvrir une fonction que nous n’avions pas encore pleinement envisagée :

devenir l’une des racines de l’identité des machines sur Internet.

Nous avons longtemps protégé les domaines parce qu’ils conduisaient vers nos sites et nos e-mails. Nous pourrions demain les protéger parce qu’ils diront aussi quelles machines ont le droit de parler et d’agir en notre nom.