Recherche WHOIS : comment consulter les données de propriété d'un domaine

« Who is domain listings » : c'est ainsi que la plupart des gens désignent le fait de rechercher qui a enregistré un nom de domaine. Les systèmes sous-jacents sont WHOIS et son successeur structuré, RDAP. Cet article explique ce que ces protocoles renvoient réellement en 2026, pourquoi les coordonnées du titulaire sont presque toujours masquées, et quels types de données de domaines restent accessibles en masse — y compris ce que WebTrackly publie et, tout aussi important, ce qu'il ne publie pas.

EN BREF / POINTS CLÉS

• WHOIS répond à une seule question, très précise : ce qu'un registre et un bureau d'enregistrement consignent au sujet de l'enregistrement d'un domaine — dates de création et d'expiration, registrar, codes de statut et serveurs de noms.
• Les coordonnées du titulaire sont masquées. Depuis l'entrée en application du RGPD en 2018, la spécification temporaire de l'ICANN et la politique qui lui a succédé imposent à la plupart des réponses WHOIS/RDAP des gTLD de dissimuler le nom, l'adresse, le téléphone et la boîte mail du titulaire. Il n'existe aucun moyen légitime d'obtenir ces champs à grande échelle.
• RDAP a remplacé WHOIS comme protocole standard. Il renvoie du JSON via HTTPS au lieu de texte non structuré, avec un mécanisme de bootstrap documenté pour identifier le bon serveur.
• Ce qui passe vraiment à l'échelle, ce sont les données d'infrastructure : quels domaines existent dans un TLD, leurs serveurs de noms, leurs serveurs de messagerie, les adresses IP résolues, et le CMS ou la plateforme web détectés sur le site en ligne.
• WebTrackly publie ces données d'infrastructure sous forme de fichiers téléchargeables — Le format de téléchargement dépend du package et figure sur la page produit.
• Les fichiers ne contiennent aucune coordonnée personnelle. Ni noms de titulaires, ni adresses e-mail, ni numéros de téléphone, ni données d'intention d'achat. Si c'est ce qu'il vous faut, ce n'est pas le bon jeu de données.

SOMMAIRE

• Ce que signifie réellement « who is domain listings »
• Ce que contient un enregistrement WHOIS, champ par champ
• Pourquoi les coordonnées du titulaire sont masquées depuis le RGPD
• RDAP : le successeur structuré de WHOIS
• Les limites des requêtes domaine par domaine
• Ce que publie réellement WebTrackly
  • Structure du catalogue
  • Chiffres de couverture
  • Le schéma des fichiers
  • Ce que les fichiers ne contiennent pas
• Le vrai workflow : acheter, télécharger, traiter en local
• L'API : un catalogue, pas un moteur de recherche de domaines
• Tarifs et livraison
• Erreurs courantes dans l'exploitation des données de domaines
• Questions fréquentes
• RESSOURCES ASSOCIÉES

Ce que signifie réellement « who is domain listings »

Tout nom de domaine est enregistré auprès d'un registrar, qui déclare à son tour cet enregistrement au registre exploitant le domaine de premier niveau. Les deux parties conservent une trace de cet enregistrement et exposent toutes deux une interface d'interrogation publique. WHOIS, défini par la RFC 3912, est la plus ancienne de ces interfaces : un simple service TCP sur le port 43 qui prend un nom de domaine et renvoie du texte libre.

C'est ce texte que les gens désignent par « who is domain listing ». Il s'agit d'un enregistrement administratif, pas d'un profil d'entreprise. Il décrit la relation administrative entre un titulaire, un registrar et un registre. Il ne dit rien de l'activité du site web, des personnes qui y travaillent ou du modèle économique de l'entreprise — et il n'a jamais été conçu pour cela.

La confusion vient de ce que l'enregistrement comportait autrefois un nom, une adresse postale, un numéro de téléphone et une adresse e-mail pour le titulaire. Pendant une vingtaine d'années, WHOIS a ainsi fait office d'annuaire public de fait. Cette époque a pris fin en 2018, et la déception que ressentent aujourd'hui la plupart des utilisateurs face à une requête WHOIS remonte à ce changement.

Ce que contient un enregistrement WHOIS, champ par champ

Une réponse gTLD typique, qu'elle provienne de WHOIS ou de RDAP, comporte les catégories d'informations suivantes :

• Le nom de domaine et sa forme internationalisée, ainsi que l'identifiant interne du domaine au registre.
• Le registrar — nom, identifiant IANA, contact abus et serveur WHOIS propre au registrar.
• Les dates — création, dernière mise à jour et expiration. Ce sont les champs les plus systématiquement renseignés de tout l'enregistrement, et la raison pour laquelle les données de date d'enregistrement sont exploitables.
• Les codes de statut — statuts EPP tels que clientTransferProhibited, serverHold, pendingDelete ou redemptionPeriod. Ils décrivent l'état du cycle de vie de l'enregistrement et sont réellement informatifs : un domaine en redemptionPeriod a expiré et se trouve dans sa fenêtre de récupération.
• Les serveurs de noms — les serveurs DNS faisant autorité délégués pour le domaine. Ce champ est public par politique et reste l'un des rares à être complet.
• DNSSEC — la délégation est-elle signée ou non.
• Les objets de contact — titulaire, administratif, technique et facturation. Dans l'immense majorité des enregistrements gTLD, ce ne sont plus que des espaces réservés masqués.

La couverture varie selon le TLD. Les registres de ccTLD fixent leur propre politique : certains publient un enregistrement plus complet que les gTLD, beaucoup en publient nettement moins, et un certain nombre limitent le débit de leur service WHOIS ou le protègent par CAPTCHA. Il n'existe aucune norme mondiale unique définissant ce que doit contenir un « who is domain listing » au-delà du contrat ICANN, qui n'engage que les gTLD.

Pourquoi les coordonnées du titulaire sont masquées depuis le RGPD

Lorsque le Règlement général sur la protection des données est devenu applicable en mai 2018, publier les données personnelles de chaque titulaire de domaine résidant dans l'UE dans un annuaire interrogeable anonymement est devenu intenable. L'ICANN a adopté une spécification temporaire imposant aux parties contractantes de retirer la plupart des champs de contact du titulaire de la sortie publique, formalisée ensuite par la Registration Data Policy. En pratique, les registrars ont appliqué le masquage à l'échelle mondiale plutôt que de chercher à déterminer quels titulaires relevaient du droit européen.

Les conséquences concrètes pour quiconque bâtit un projet sur ces données :

• Le nom, l'organisation, la rue, la ville, le code postal, le téléphone et l'adresse e-mail du titulaire sont remplacés par des chaînes du type REDACTED FOR PRIVACY ou Data Protected.
• Le pays, et parfois l'État ou la région, subsistent dans de nombreux enregistrements, ce qui explique que les répartitions par pays restent partiellement dérivables des données d'enregistrement.
• Les registrars exposent généralement un relais anonymisé — un formulaire web ou une adresse de transfert propre au domaine — permettant de joindre le titulaire sans divulguer son identité. Ces relais ne constituent pas des coordonnées exploitables et sont limités en débit par conception.
• L'accès aux données non masquées n'existe que via des canaux fermés, sur demande, réservés aux parties justifiant d'une base légale démontrée, et évalués au cas par cas. Ce n'est pas un flux de masse, et aucun jeu de données commercial ne peut légalement s'y substituer.

Les services de confidentialité et de proxy sont antérieurs au RGPD et ajoutent une seconde couche : même là où un registre publierait des coordonnées, le titulaire peut avoir payé un proxy pour figurer comme détenteur nominal. Entre masquage et proxy, traiter WHOIS comme une source de coordonnées n'est plus une stratégie viable, à quelque échelle que ce soit.

RDAP : le successeur structuré de WHOIS

RDAP — le Registration Data Access Protocol, spécifié par les RFC 7480 à 7484 et les RFC 9082/9083 — a été conçu pour corriger les défauts structurels de WHOIS. Il fonctionne sur HTTPS, renvoie du JSON, gère correctement l'internationalisation et définit un fichier de bootstrap publié par l'IANA permettant à un client de déterminer quel serveur fait autorité pour un TLD ou une plage IP donnés. Tous les registres et registrars de gTLD sont tenus d'exploiter des services RDAP depuis 2019, et l'obligation de maintenir WHOIS sur le port 43 a été supprimée par la suite.

Une requête minimale ressemble à ceci :

# Find the authoritative RDAP base URL for the TLD
curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] == "com")'

# Query a domain
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  ldhName,
  status,
  events: [.events[] | {eventAction, eventDate}],
  nameservers: [.nameservers[].ldhName]
}'

Ce qu'il faut observer dans cette sortie, c'est la forme de ce qui revient. Les événements, les statuts et les serveurs de noms sont structurés et renseignés. Le tableau entities — où résident les contacts titulaire, administratif et technique — contiendra une entité registrar avec un contact abus, et une entité titulaire dont les champs vCard sont masqués. RDAP a changé l'encodage, pas la politique de divulgation.

RDAP est lui aussi limité en débit, requête par requête et domaine par domaine. C'est l'outil adapté pour investiguer un domaine, vérifier une date d'expiration ou contrôler un code de statut avant un transfert. C'est le mauvais outil pour constituer un jeu de données d'un million de domaines.

Les limites des requêtes domaine par domaine

Supposons que vous vouliez répondre à une question du type « combien de domaines de ce TLD tournent sous WordPress » ou « quels sont les serveurs de noms les plus répandus en .de ». Un protocole domaine par domaine ne peut pas y répondre. Il vous faudrait d'abord connaître la population de domaines, puis interroger chacun d'eux, puis récupérer chaque site web séparément, car WHOIS et RDAP ne disent rien du logiciel qui fait tourner le site.

Trois sources de données distinctes sont nécessaires :

1. La population — quels domaines existent dans une zone. Elle provient des fichiers de zone ou de listes équivalentes issues des registres, pas de WHOIS.
2. La résolution DNS — les serveurs de noms, les serveurs de messagerie et les enregistrements A de chaque domaine, obtenus par résolution.
3. La détection de plateforme — ce que renvoie le site en ligne, obtenu en le récupérant et en repérant des signatures dans le HTML, les en-têtes et les chemins d'assets.

Le faire soi-même est un véritable projet d'ingénierie : accords d'accès aux fichiers de zone ou sources équivalentes, ferme de résolveurs qui ne vous fera pas bannir pour excès de requêtes, crawler respectueux, et stockage pour des centaines de millions de lignes. Acheter le résultat de ce pipeline sous forme de fichier revient généralement moins cher que de le reconstruire.

Ce que publie réellement WebTrackly

Structure du catalogue

Le catalogue WebTrackly compte 1 538 packages, répartis en quatre types :

Les packages de zones sont consultables sur /zones/, les compilations sélectionnées sur /datasets/, et le catalogue complet sur /packages/.

Chiffres de couverture

• 285 582 781 domaines toutes zones confondues.
• 163 422 083 domaines rien qu'en .com.
• 21 639 326 domaines avec WordPress détecté.
• 567 680 domaines avec Joomla détecté.
• 272 614 863 lignes dans le jeu de données de l'ensemble des domaines enregistrés.

Ces chiffres méritent d'être lus attentivement. Le chiffre WordPress correspond au nombre de domaines sur lesquels WordPress a été détecté sur le site en ligne — ce n'est ni un décompte des installations WordPress existantes, ni l'affirmation que chaque domaine du catalogue a été analysé. La détection suppose un site web qui répond ; les domaines parqués, redirigés ou non résolus figurent dans les listes de zones mais ne portent aucune valeur de plateforme.

Le schéma des fichiers

Un package de zone enrichie est un CSV présentant globalement cette forme :

domain,created,ns,mx,ip,cms
example.com,2011-04-17,ns1.example-dns.net;ns2.example-dns.net,mx1.mailhost.net,203.0.113.14,WordPress
sample.com,,ns1.hoster.io;ns2.hoster.io,,198.51.100.7,

Quelques précisions sur les champs, car les réserves comptent plus que la ligne d'en-tête :

• domain — toujours présent. C'est la clé primaire.
• created — la date d'enregistrement, renseignée uniquement lorsque le registre la publie. Un grand nombre de ccTLD ne le font pas : attendez-vous à une colonne clairsemée en dehors des principaux gTLD.
• ns — les serveurs de noms délégués. Utile pour analyser l'hébergement et les fournisseurs DNS, et l'une des colonnes les plus complètes du fichier.
• mx — les enregistrements de messagerie du domaine : les noms d'hôte des serveurs qui acceptent le courrier pour lui, par exemple un point d'entrée Google Workspace ou Microsoft 365. Ce sont des noms de serveurs, pas des adresses e-mail.
• ip — l'adresse résolue au moment de la collecte. Les sites derrière un CDN se résolvent vers le nœud périphérique du CDN, ce qui renseigne sur le CDN, pas sur l'emplacement du serveur d'origine.
• cms — la plateforme détectée sur le site en ligne, vide lorsque rien n'a été détecté ou que le site n'a pas répondu.

Ce que les fichiers ne contiennent pas

Dit clairement, pour lever toute ambiguïté avant l'achat :

• Aucune coordonnée personnelle. Ni noms de titulaires, ni adresses e-mail, ni numéros de téléphone, ni personnes nommément identifiées au sein d'une entreprise. C'est un choix de conception délibéré et une conséquence du masquage décrit plus haut : ces données ne sont pas disponibles légalement à cette échelle, et tout fournisseur qui les propose en volume mérite d'être interrogé de près.
• Aucun signal d'intention ou d'achat. Rien qui indique qu'une organisation évalue un achat.
• Aucune estimation de trafic, de chiffre d'affaires ou d'effectif.
• Aucun service de requête domaine par domaine. Le produit, ce sont des fichiers en masse, pas une API d'interrogation sur des domaines individuels. Pour un domaine unique, utilisez directement RDAP comme montré plus haut.
• Aucune recherche par technologie dans l'interface. Le regroupement par technologie existe sous forme de packages préparés ; ce n'est pas un générateur de requêtes interactif.

Le vrai workflow : acheter, télécharger, traiter en local

Le parcours est volontairement simple, et tout ce qui suit le téléchargement se passe sur votre propre machine :

1. Choisissez un package sur /packages/, /zones/ ou /datasets/, selon la zone ou la plateforme qui vous intéresse.
2. Achetez-le. L'export est généré à neuf au moment de l'achat, plutôt que servi depuis une archive pré-construite et périmée.
3. Téléchargez le ZIP immédiatement — la livraison se fait par téléchargement direct, avec le CSV à l'intérieur de l'archive.
4. Décompressez et interrogez en local. Aucun aller-retour d'API, aucune facturation à la ligne.

unzip com-enriched.zip
wc -l com-enriched.csv

# Quick filtering with standard tools
grep -c ',WordPress$' com-enriched.csv
awk -F, '$6 == "Joomla" { print $1 }' com-enriched.csv > joomla-domains.txt

Au-delà de quelques millions de lignes, un moteur en colonnes est bien plus confortable que les outils shell. DuckDB lit le CSV directement, sans étape d'import :

-- DuckDB: top name server providers in a zone
SELECT
    regexp_extract(split_part(ns, ';', 1), '([^.]+\.[^.]+)$', 1) AS ns_domain,
    count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE ns IS NOT NULL AND ns <> ''
GROUP BY 1
ORDER BY domains DESC
LIMIT 25;

-- Registration cohorts, where the registry publishes creation dates
SELECT date_trunc('year', created) AS cohort, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE created IS NOT NULL
GROUP BY 1
ORDER BY 1;

ClickHouse est le meilleur choix si vous comptez garder plusieurs zones chargées et les interroger régulièrement :

CREATE TABLE domains
(
    domain  String,
    created Nullable(Date),
    ns      String,
    mx      String,
    ip      String,
    cms     LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY domain;

INSERT INTO domains
SELECT * FROM file('com-enriched.csv', 'CSVWithNames');

Analyses typiques rendues possibles : parts de marché de l'hébergement et du DNS par zone, répartition des CMS entre TLD, concentration des fournisseurs de messagerie, courbes de cohortes d'enregistrement pour les zones qui publient les dates de création, et regroupement par plages IP pour identifier les infrastructures exploitées par un même fournisseur.

L'API : un catalogue, pas un moteur de recherche de domaines

L'API expose le catalogue de packages. Elle permet de découvrir et d'inspecter ce qui est disponible et d'automatiser les décisions d'achat ; elle ne recherche pas de domaines individuels, car les données de domaines sont livrées sous forme de fichiers.

# List zone packages
curl -s "https://webtrackly.com/api/v1/packages/?type=zone" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Find technology packages matching a term
curl -s "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Inspect a single package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Un client Python minimal sur les mêmes points de terminaison :

import requests

BASE = "https://webtrackly.com/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

zones = requests.get(f"{BASE}/packages/", headers=HEADERS,
                     params={"type": "zone"}).json()

for pkg in zones.get("results", []):
    print(pkg["slug"], pkg.get("domains_count"))

detail = requests.get(f"{BASE}/packages/com/", headers=HEADERS).json()
print(detail)

La documentation complète des points de terminaison se trouve sur /api/.

Tarifs et livraison

Les packages individuels s'achètent à l'unité à partir de $3.50: Le format de téléchargement dépend du package et figure sur la page produit. Deux formules d'abonnement couvrent les usages récurrents :

Le détail à jour figure sur /pricing/.

Erreurs courantes dans l'exploitation des données de domaines

1. Attendre de WHOIS qu'il identifie une entreprise. Il identifie un enregistrement. Même avant le masquage, le titulaire était souvent un hébergeur, une agence ou un service de proxy plutôt que l'organisation derrière le site web. Utilisez les données d'enregistrement pour les questions de cycle de vie et de délégation, et les données d'infrastructure pour les questions portant sur le site lui-même.

2. Prendre une IP résolue pour le serveur d'origine. Tout domaine placé derrière un CDN ou un reverse proxy se résout vers le nœud périphérique. Agréger les IP sans en tenir compte produit un graphique sur l'adoption des CDN tout en donnant l'illusion de parler d'hébergement.

3. Supposer qu'une colonne CMS vide signifie « pas de CMS ». Vide signifie que rien n'a été détecté, ce qui recouvre aussi les sites qui n'ont pas répondu, ont redirigé ailleurs, ont bloqué la récupération, ou font tourner quelque chose sans signature fiable. Publiez les taux de détection à côté des volumes détectés, sinon le dénominateur ment en silence.

4. Interpréter l'absence de date de création comme un enregistrement récent. De nombreux registres de ccTLD ne publient tout simplement pas les dates de création. Une colonne clairsemée est un artefact de politique, pas un signal sur l'ancienneté du domaine.

5. Ignorer la vitesse à laquelle ces données vieillissent. Les domaines expirent, les serveurs de noms changent, les sites sont refondus. Tout instantané est une observation à un instant T. Si une décision dépend de l'état actuel, retéléchargez le package concerné plutôt que de réutiliser un fichier du trimestre dernier.

6. Charger des centaines de millions de lignes dans un tableur. Les tableurs atteignent leurs limites bien avant ces fichiers. Un moteur en colonnes sur un ordinateur portable traite la zone .com complète sans difficulté ; un tableur ne l'ouvrira tout simplement pas.

Questions fréquentes

Q : Puis-je obtenir le nom et les coordonnées du titulaire via une requête WHOIS ?
R : Pour la plupart des domaines gTLD, non. Les champs de contact du titulaire sont masqués depuis l'entrée en vigueur de la politique post-RGPD de l'ICANN en 2018. Les registrars proposent généralement un relais anonymisé pour joindre un titulaire sans divulguer son identité, et un accès sur demande, sous conditions, existe pour les parties justifiant d'une base légale démontrée. Ni l'un ni l'autre n'est une source de masse, et les fichiers WebTrackly ne contiennent aucune coordonnée personnelle, quelle qu'elle soit.

Q : Quelle est la différence entre WHOIS et RDAP ?
R : RDAP est le remplaçant normalisé. Il sert du JSON via HTTPS, gère correctement les textes internationalisés et publie un fichier de bootstrap IANA permettant aux clients de localiser le serveur faisant autorité pour n'importe quel TLD. WHOIS renvoie du texte non structuré sur le port 43, dans un format qui diffère d'un registre à l'autre. RDAP a changé l'encodage et le transport ; il n'a pas changé ce qui est divulgué.

Q : Dans quel format arrivent les packages WebTrackly ?
R : Le format de téléchargement dépend du package et figure sur la page produit. L'export est généré au moment de l'achat, plutôt que servi depuis une archive pré-construite.

Q : Combien de domaines sont couverts ?
R : 285 582 781 toutes zones confondues, dont 163 422 083 en .com. Le jeu de données de l'ensemble des domaines enregistrés compte 272 614 863 lignes. Les packages par technologie couvrent 21 639 326 domaines avec WordPress détecté et 567 680 avec Joomla.

Q : Puis-je consulter un domaine unique via WebTrackly ?
R : Non. Le produit, ce sont des fichiers en masse organisés par zone, par technologie ou en jeux de données sélectionnés. Pour un domaine unique, interrogez directement RDAP : c'est gratuit, cela fait autorité pour les données d'enregistrement, et cela tient en une requête HTTP.

Q : L'API permet-elle de filtrer les domaines par technologie ou par pays ?
R : L'API sert le catalogue de packages, pas un moteur de requêtes au niveau du domaine. Vous pouvez lister et filtrer les packages par type et par terme de recherche, puis acheter et télécharger ceux dont vous avez besoin. Le filtrage des lignes individuelles se fait en local, dans DuckDB, ClickHouse ou l'outil de votre choix.

Q : À quel point les données sont-elles à jour ?
R : Les exports sont générés au moment de l'achat à partir de l'état courant du catalogue. Le web évoluant en permanence, considérez chaque téléchargement comme un instantané et retéléchargez avant toute décision dépendant de l'état du jour.

Q : Quelles sont les limites des formules ?
R : Pro coûte $29/mois pour 50 packages, 10 jeux de données et 30 000 appels API. Enterprise coûte $99/mois pour 200 packages, 50 jeux de données et 300 000 appels API. Les packages individuels peuvent aussi être achetés à l'unité à partir de $3.50. Voir /pricing/.

WebTrackly publie des données de zones de domaines, de DNS et de détection de CMS sous forme de fichiers téléchargeables.
Explorer les données de domaines → | Voir les tarifs →

Ressources associées

• Catalogue de packages — plus de 1 500 bases de données de domaines téléchargeables
• Fichiers de zone par TLD — .com, .net, .de et plus de 700 autres
• Jeux de données sélectionnés — tous les domaines enregistrés, serveurs MX, e-commerce
• Tarifs — achats à l'unité à partir de $3.50