WHOIS vs RDAP : comprendre les données de domaine ICANN (guide 2026)

Chaque domaine laisse une trace d'enregistrement et, pendant quarante ans, la façon de lire cette trace s'est appelée WHOIS. Le protocole censé le remplacer, RDAP, porté par l'ICANN, répond aux mêmes questions via une interface REST moderne et du JSON structuré. Tous deux sont conçus pour interroger un domaine à la fois — exactement le mauvais format pour de la recherche, du dimensionnement de marché ou de l'analyse d'infrastructure sur des millions de noms. Ce guide explique en quoi les deux protocoles diffèrent réellement, où chacun cesse d'être utile, et ce que les fichiers de domaines en masse apportent qu'un protocole de requête unitaire ne pourra jamais fournir.

En bref / Points clés

• WHOIS est un protocole en texte brut sur le port 43 : pas de schéma, pas de noms de champs normalisés, pas de format de date standard. Chaque registre et chaque registrar met en forme sa sortie un peu différemment, si bien que parser à grande échelle revient à maintenir un analyseur par source.
• RDAP est le successeur imposé par l'ICANN : RESTful, HTTPS uniquement, réponses JSON, codes d'erreur normalisés, prise en charge de l'internationalisation et renvois entre serveurs. Il résout le problème du parsing, pas celui de l'accès.
• Aucun des deux protocoles n'est une source de données en masse : leurs limites de débit sont volontaires. Interroger des millions de domaines via WHOIS ou RDAP se solde par du throttling et du blocage, et aucun registre ne propose cet usage comme cas pris en charge.
• L'anonymisation RGPD s'applique aux deux : depuis 2018, le nom, l'e-mail et l'adresse postale du titulaire sont masqués ou remplacés par un service de proxy dans les réponses publiques pour la plupart des domaines. Le WHOIS/RDAP public n'est pas une base de contacts.
• Aucun des deux ne dit quoi que ce soit sur la technologie d'un site : CMS, serveur web, CDN, fournisseur de messagerie et IP se situent tous hors de l'enregistrement de domaine. Ces informations proviennent de la résolution DNS et du fingerprinting HTTP, pas du registre.
• WebTrackly vend la couche « en masse » Le format de téléchargement dépend du package et figure sur la page produit.
• L'analyse vous appartient : les fichiers servent d'entrée à vos propres outils. Il n'y a ni générateur de requêtes en ligne, ni recherche domaine par domaine, ni données de contact.

Sommaire

1. Comprendre WHOIS : le protocole historique
2. RDAP : le standard moderne
3. WHOIS vs RDAP : comparatif
4. Là où les deux protocoles s'arrêtent
5. Ce que contiennent les fichiers de domaines en masse
6. Acheter et exploiter un package
7. Automatiser avec l'API catalogue
8. Erreurs fréquentes dans l'acquisition de données de domaines & comment les éviter
9. Foire aux questions (FAQ)
10. Ressources associées

Comprendre WHOIS : le protocole historique

WHOIS est un protocole de requête et de réponse permettant d'interroger les bases qui recensent les attributaires d'une ressource internet : un nom de domaine, un bloc d'adresses IP ou un numéro de système autonome. Il est né aux débuts de l'internet et a été normalisé par l'IETF au début des années 1980. Sa vocation était l'annuaire : permettre à quiconque d'identifier le responsable d'une ressource, principalement pour du dépannage réseau et du traitement d'abus.

Sa structure est volontairement simple. Un enregistrement WHOIS est un bloc de texte brut renvoyé sur le port TCP 43. Le client se connecte au serveur WHOIS exploité par le registrar ou le registre du domaine, envoie le nom de domaine et reçoit un bloc de texte en retour.

Un enregistrement WHOIS type contient :

• Informations sur le titulaire : nom, organisation, adresse, e-mail et téléphone du détenteur du domaine — aujourd'hui masqués pour la plupart des domaines.
• Contact administratif : la partie responsable des questions administratives.
• Contact technique : la partie responsable des questions techniques.
• Informations sur le registrar : la société par laquelle le domaine a été enregistré.
• Dates d'enregistrement : date de création, date de dernière modification, date d'expiration.
• Serveurs de noms : les serveurs DNS faisant autorité pour le domaine.
• Statut du domaine : les codes de statut EPP comme clientTransferProhibited ou pendingDelete.

Dans son intention d'origine, WHOIS apportait transparence et responsabilité. Si un site menait une activité malveillante, ou en cas de panne technique, WHOIS offrait un chemin vers la partie responsable. Pour la veille concurrentielle, il fournissait des faits de base : date d'enregistrement, registrar et serveurs de noms.

Ses limites pèsent bien plus lourd aujourd'hui. La principale est l'absence de schéma. Chaque registrar et chaque registre met en forme sa sortie à sa façon, avec des libellés de champs, des formats de date et un ordre de sections variables. Le parsing automatisé exige donc des expressions régulières et une logique dédiées à chaque source ; un analyseur écrit pour la sortie d'un registrar échoue souvent sur celle d'un autre.

Les limites de débit constituent la deuxième contrainte. Les serveurs WHOIS sont dimensionnés pour des requêtes unitaires, pas pour de l'extraction massive. Interroger des milliers ou des millions de domaines entraîne du throttling, du blocage d'IP ou des pages CAPTCHA intercalaires. Au-delà, la donnée elle-même vieillit : les titulaires déménagent, changent d'adresse, laissent leurs informations dériver, et les registrars n'imposent pas les mises à jour de façon stricte.

Le tournant décisif, pour qui espérait utiliser WHOIS comme source de contacts, est venu du RGPD en 2018. Pour s'y conformer, l'ICANN a imposé aux registrars de masquer les données personnelles dans les sorties WHOIS publiques des titulaires concernés. Pour la plupart des domaines aujourd'hui, le nom, l'e-mail et le téléphone du titulaire sont remplacés par « REDACTED FOR PRIVACY » ou par l'adresse de redirection d'un service de confidentialité. Le WHOIS public doit être considéré comme une source de faits techniques et d'enregistrement, pas de données personnelles.

RDAP : le standard moderne

Consciente de l'hétérogénéité des sorties WHOIS et du besoin croissant de contrôles d'accès, l'ICANN a piloté le développement de RDAP, le Registration Data Access Protocol. RDAP a été conçu comme un remplaçant normalisé, sécurisé et extensible. L'ICANN l'a adopté en 2017 et les registres comme les registrars le déploient progressivement depuis.

La différence architecturale fait tout. Au lieu de texte brut sur le port 43, RDAP est un service web RESTful qui renvoie des données structurées, normalement en JSON. Cela supprime le problème du parsing : avec un schéma défini, un système automatisé extrait un champ par son nom plutôt qu'en cherchant un motif dans un bloc de texte.

Principaux atouts de RDAP face à WHOIS :

• Format de données normalisé : la sortie JSON est lisible par machine et s'intègre directement dans un pipeline.
• Sécurité : RDAP fonctionne sur HTTPS et prend en charge l'authentification et l'autorisation, de sorte que des demandeurs accrédités peuvent en principe recevoir des réponses plus complètes que des requêtes anonymes.
• Internationalisation : prise en charge véritable des noms de domaine internationalisés et des données de contact multilingues.
• Gestion des erreurs : codes de statut HTTP et objets d'erreur normalisés, ce qui permet aux clients de distinguer un « non trouvé » d'un dépassement de limite de débit ou d'une erreur serveur.
• Renvois : une réponse RDAP peut orienter le client vers le serveur faisant autorité pour l'objet, ce qui rend les recherches inter-registres praticables.

La démarche de l'ICANN vise un accès uniforme et auditable aux données d'enregistrement. Pour quiconque interroge ces enregistrements par programme, RDAP représente un gain de fiabilité net par rapport à son prédécesseur.

RDAP ne change rien au contenu de l'enregistrement. Il relève des mêmes obligations de confidentialité que WHOIS : les données personnelles restent masquées dans les réponses publiques. Vous l'interrogez plus proprement, mais les champs de contact demeurent des proxys ou des valeurs de remplacement. La couverture est également inégale — tous les registres et registrars n'ont pas achevé leur déploiement RDAP, si bien que certains domaines ne sont encore joignables qu'en WHOIS. Et la charge utile reste une donnée d'enregistrement : rien sur la technologie en production, l'hébergement ou le contenu du site.

WHOIS vs RDAP : comparatif

Là où les deux protocoles s'arrêtent

Quelles que soient leurs différences, WHOIS et RDAP répondent à une seule question : que dit l'enregistrement du registre à propos de ce nom ? Plusieurs catégories de questions sortent entièrement de ce périmètre.

1. Aucune détection technologique. L'enregistrement indique qui a déposé un domaine, pas quel logiciel fait tourner le site. CMS, plateforme e-commerce, serveur web et bibliothèques JavaScript se découvrent en interrogeant le site, pas le registre.
2. Aucune donnée de contact exploitable. Le RGPD et les régimes comparables ont retiré les coordonnées des titulaires des réponses publiques. Des accès accrédités existent pour les autorités et les ayants droit ; ce n'est pas un canal généraliste.
3. Aucune vue sur l'infrastructure. Au-delà des serveurs de noms, les protocoles ne disent rien de l'IP résolue, du réseau d'hébergement, du CDN placé devant l'origine ni du fournisseur de messagerie derrière les enregistrements MX.
4. Aucune agrégation. Même avec le JSON propre de RDAP, couvrir des millions de noms suppose d'orchestrer des requêtes vers des centaines de serveurs, chacun avec ses limites de débit et sa disponibilité. C'est un projet d'infrastructure, pas une requête.
5. Aucune garantie de fraîcheur à grande échelle. Les protocoles n'ont aucun mécanisme pour vous dire ce qui a changé depuis votre dernier passage. Détecter le changement impose de tout réinterroger.
6. Aucune vue de population. Vous ne pouvez pas demander à WHOIS ou à RDAP « combien de domaines .de existent » ni « quels domaines résolvent vers ce réseau ». Ils ne répondent qu'à des questions portant sur un nom.

Ce sont précisément les questions auxquelles répondent les fichiers de domaines en masse, parce qu'un fichier est une population, pas une requête unitaire.

Vous travaillez sur des données de domaines à grande échelle ?
Le format de téléchargement dépend du package et figure sur la page produit.
Parcourir le catalogue → | Voir les tarifs →

Ce que contiennent les fichiers de domaines en masse

Le catalogue WebTrackly s'organise en trois ensembles :

• Fichiers de zone par TLD — 716 packages couvrant .com, .net, .de, .org et des centaines d'autres. Le package .com contient à lui seul 163,422,083 domaines. Voir Fichiers de zone par TLD.
• Listes technologies et CMS — 79 packages de domaines regroupés selon la plateforme détectée. Le package WordPress contient 21,639,326 domaines. Voir Domain Data.
• Jeux de données organisés — 27 packages, dont le jeu de données de tous les domaines enregistrés, soit 272,614,863 lignes. Voir Datasets.

Le format de téléchargement dépend du package et figure sur la page produit. Le fichier est généré au moment de l'achat : il reflète donc l'état des données sources à cette date, et non un instantané mis en cache lors d'un crawl antérieur. Les tarifs démarrent à $3.50 par package ; voir Pricing pour les niveaux d'abonnement.

Les champs auxquels vous attendre

Les colonnes varient selon le type de package — un fichier de zone est étroit, une liste technologique embarque les champs de détection et de résolution. Le tableau ci-dessous illustre la forme des données ; il ne garantit pas que chaque colonne figure dans chaque package.

Ce qui ne figure pas dans les fichiers : noms de personnes, adresses e-mail, numéros de téléphone, firmographies d'entreprise ou signaux d'intention comportementale. WebTrackly vend de la donnée de domaine. Tout ce qui touche aux personnes derrière un domaine est hors périmètre, par choix produit autant que par conformité.

Acheter et exploiter un package

Le parcours est volontairement court — aucun générateur de requêtes à apprendre, puisque l'analyse se fait sur votre machine avec vos propres outils.

1. Trouvez le package. Parcourez le catalogue, ou allez directement sur /zones/ pour les fichiers de zone par TLD, /domaindata/ pour les listes technologiques, ou /datasets/ pour les jeux de données organisés. Chaque fiche affiche le nombre de lignes, vous connaissez donc la taille avant d'acheter.
2. Achetez. Les achats à l'unité démarrent à $3.50. Les abonnements (Pro à $29/month, Enterprise à $99/month) incluent un quota mensuel de packages et de jeux de données ainsi qu'un quota d'appels API ; détails sur la page tarifs.
3. Téléchargez. Le ZIP est produit à la demande et disponible immédiatement après le paiement.
4. Traitez en local. Décompressez et exploitez le CSV avec les outils que vous utilisez déjà.

Sur un fichier de plusieurs centaines de millions de lignes, les outils en ligne de commande et un moteur en colonnes surclassent largement un tableur :

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

# filter rows by name server with plain grep
grep -i 'cloudflare' com-zone.csv > cloudflare-hosted.csv

# or query the CSV directly with DuckDB, no import step
duckdb -c "SELECT ns, count(*) AS n FROM 'com-zone.csv' GROUP BY ns ORDER BY n DESC LIMIT 20"

Pour des analyses répétées, chargez le fichier une bonne fois dans PostgreSQL ou ClickHouse via une copie en masse, puis indexez les colonnes sur lesquelles vous filtrez. Croiser deux packages — par exemple une liste technologique avec un fichier de zone — se résume à une jointure sur la colonne domain.

Automatiser avec l'API catalogue

Les formules d'abonnement incluent un accès API pour parcourir le catalogue et récupérer les métadonnées des packages par programme. Pro inclut 30,000 appels par mois, Enterprise 300,000. L'API est une interface de catalogue : elle liste et décrit les packages et les jeux de données. Ce n'est pas un service de recherche domaine par domaine.

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

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

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

La référence complète des endpoints, y compris ceux des jeux de données et du compte, se trouve sur la page de documentation de l'API.

Erreurs fréquentes dans l'acquisition de données de domaines & comment les éviter

Travailler sur des données whois vs rdap icann à une échelle réelle fait remonter toujours les mêmes erreurs. Voici celles qu'il vaut mieux éviter.

1. Prendre WHOIS ou RDAP pour une source en masse

   • Ce qui cloche : écrire un script qui parcourt une liste d'un million de domaines et interroge chacun d'eux via WHOIS ou RDAP.
   • Pourquoi cela échoue : les deux protocoles imposent des limites de débit par source et aucun registre ne prend en charge ce schéma d'usage. Vous serez bridé en quelques minutes, et l'exécution durera plus longtemps que la validité des données.
   • La solution : partez d'un fichier en masse qui contient déjà la population, et réservez les requêtes nom par nom au petit sous-ensemble pour lequel vous avez besoin de l'enregistrement de registre à jour.

2. Attendre des données de contact des enregistrements de domaine

   • Ce qui cloche : bâtir un workflow de prospection autour des e-mails des titulaires.
   • Pourquoi cela échoue : ces champs sont masqués ou remplacés par un proxy pour la plupart des domaines depuis 2018. Le plan bute sur la donnée, pas sur l'exécution.
   • La solution : utilisez la donnée de domaine pour ce qu'elle est — une cartographie des noms, de l'infrastructure et des technologies — et sourcez vos contacts via des canaux où le consentement et la provenance sont documentés.

3. Écrire un analyseur par registrar et appeler cela un pipeline

   • Ce qui cloche : un parsing WHOIS à base d'expressions régulières qui fonctionne sur les registrars testés et déforme silencieusement tous les autres.
   • Pourquoi cela échoue : WHOIS n'a pas de schéma. Libellés de champs, formats de date et ordre des sections varient tous, et changent sans préavis.
   • La solution : privilégiez RDAP là où le registre le prend en charge, puisque le schéma JSON est stable. Quand il vous faut un TLD entier, utilisez le fichier de zone plutôt que de le reconstituer nom par nom.

4. Sous-estimer la vitesse à laquelle la donnée vieillit

   • Ce qui cloche : réutiliser un fichier de l'an dernier pour l'analyse de cette année.
   • Pourquoi cela échoue : les domaines expirent, changent d'hébergeur, changent de CMS et passent derrière des CDN en permanence. Les conclusions tirées d'une population périmée décrivent un web qui n'existe plus.
   • La solution : retéléchargez quand l'analyse compte. WebTrackly génère le fichier au moment de l'achat : un nouveau téléchargement est donc une nouvelle extraction, pas une copie mise en cache.

5. Sous-estimer le coût de la couche de collecte

   • Ce qui cloche : décider de crawler et de fingerprinter le web en interne parce que chaque étape prise isolément paraît simple.
   • Pourquoi cela échoue : la résolution à grande échelle, la logique de nouvelle tentative, la maintenance des signatures, le stockage et la planification des re-crawls forment un engagement d'ingénierie permanent, pas un sprint.
   • La solution : achetez le fichier de population là où vous avez besoin de couverture, et ne développez en interne que là où vos besoins divergent réellement de ce qui existe sur étagère.

6. Charger des centaines de millions de lignes dans le mauvais outil

   • Ce qui cloche : ouvrir un CSV de plusieurs gigaoctets dans un tableur, ou le parcourir ligne à ligne dans un langage de script.
   • Pourquoi cela échoue : on parle ici de centaines de millions de lignes. Les outils qui chargent tout en mémoire n'iront pas au bout.
   • La solution : traitez le fichier en flux. Les filtres en ligne de commande, DuckDB directement sur le CSV ou un chargement en masse dans un magasin en colonnes encaissent cette volumétrie sans difficulté.

7. Faire l'impasse sur la revue juridique de ce que vous avez collecté

   • Ce qui cloche : supposer que parce qu'une donnée est publiquement accessible, tout usage en est permis.
   • Pourquoi cela échoue : le RGPD, le CCPA et les conditions d'utilisation des registres encadrent la manière dont les données d'enregistrement peuvent être traitées et republiées, indépendamment de la façon dont elles ont été obtenues.
   • La solution : gardez toute donnée personnelle hors du pipeline. Noms de domaine, enregistrements DNS, IP et signatures technologiques n'identifient pas des individus ; les coordonnées des titulaires, si.

Foire aux questions (FAQ)

Q : Quelle est la différence concrète entre WHOIS et RDAP ?
R : WHOIS renvoie du texte non structuré sur le port 43 et exige un analyseur dédié à chaque registrar. RDAP renvoie du JSON sur HTTPS selon un schéma défini, prend en charge l'authentification, utilise les codes d'erreur HTTP standard et sait rediriger un client vers le serveur faisant autorité. Pour un usage programmatique, RDAP est nettement plus simple à exploiter. Les deux restent soumis à la même anonymisation et aux mêmes limites de débit.

Q : Puis-je obtenir les e-mails ou téléphones des titulaires via l'un de ces protocoles ?
R : Pas pour la plupart des domaines. Depuis l'entrée en vigueur du RGPD en 2018, l'ICANN impose aux registrars de masquer les données personnelles dans les réponses WHOIS et RDAP publiques. Des voies d'accès accréditées existent pour certaines parties, comme les autorités judiciaires. WebTrackly ne vend aucune donnée de contact.

Q : WebTrackly propose-t-il une recherche sur un domaine unique ?
R : Non. Le produit, ce sont des fichiers en masse. Le format de téléchargement dépend du package et figure sur la page produit. Il n'existe pas d'interface de recherche domaine par domaine.

Q : Quel est le format des téléchargements et leur fraîcheur ?
R : Le format de téléchargement dépend du package et figure sur la page produit. Le fichier est généré au moment de l'achat plutôt que servi depuis un instantané préconstruit.

Q : Quelle est la taille du catalogue ?
R : 1 538 packages : 716 fichiers de zone par TLD, 79 listes technologies et CMS, et 27 jeux de données organisés. Pour l'ordre de grandeur, le package de zone .com contient 163,422,083 domaines, le package WordPress 21,639,326, et le jeu de données de tous les domaines enregistrés 272,614,863 lignes.

Q : Combien cela coûte-t-il ?
R : Les achats de packages à l'unité démarrent à $3.50. Pro est à $29/month et comprend 50 packages, 10 jeux de données et 30,000 appels API. Enterprise est à $99/month avec 200 packages, 50 jeux de données et 300,000 appels API. Les conditions à jour figurent sur la page tarifs.

Q : Existe-t-il une API ?
R : Oui, pour le catalogue. L'API liste les packages et les jeux de données et renvoie leurs métadonnées, avec une authentification par jeton bearer. Voir la documentation de l'API. Elle n'effectue pas de recherche de domaine.

Q : Comment traiter un fichier de plusieurs centaines de millions de lignes ?
R : En flux plutôt qu'en mémoire. Les outils en ligne de commande standard gèrent le filtrage et le comptage ; DuckDB interroge un CSV sur place, sans étape d'import ; pour des analyses répétées, chargez en masse dans PostgreSQL ou ClickHouse et indexez les colonnes sur lesquelles vous filtrez.

Conclusion

WHOIS et RDAP font le travail pour lequel ils ont été conçus : ils vous disent ce qu'un registre consigne à propos d'un nom. RDAP le fait avec un schéma, sur HTTPS, avec une vraie gestion des erreurs — un progrès réel, et une migration à envisager pour tout code interrogeant des données d'enregistrement. Ce qu'aucun des deux ne fera jamais, c'est vous livrer une population. Ce sont des protocoles de requête unitaire, bridés en débit par conception, vidés des données personnelles par la réglementation, et muets sur tout ce qui se passe après la résolution.

Dès lors que la question porte sur un TLD entier, une plateforme entière ou un segment entier du web, la bonne entrée est un fichier. C'est ce que publie WebTrackly : fichiers de zone, listes technologiques et jeux de données organisés, au format CSV, générés à l'achat, à analyser avec vos propres outils.

Commencez par le catalogue.
Le format de téléchargement dépend du package et figure sur la page produit.
Parcourir les packages → | Voir les tarifs →

Ressources associées

• Catalogue de packages — 1 538 bases de domaines téléchargeables
• Fichiers de zone par TLD — .com, .net, .de et 700+ autres
• Domain Data — listes de domaines par CMS et technologie
• Jeux de données organisés — tous les domaines enregistrés, serveurs MX, e-commerce
• Pricing — achats à l'unité à partir de $3.50