ICANN RDAP expliqué : le protocole qui remplace WHOIS (guide 2026)

WHOIS n'a jamais été conçu pour être exploité par des machines et, après deux décennies de formats de sortie propres à chaque bureau d'enregistrement et une décennie de masquage imposé par la protection des données, il ne tient plus le rôle de source de données. Le Registration Data Access Protocol (RDAP) de l'ICANN en est le remplaçant normalisé : les mêmes données d'enregistrement, livrées en JSON sur HTTPS avec un schéma cohérent. Ce guide explique ce qu'est RDAP, ce que ses réponses contiennent réellement en 2026 (bien moins qu'on ne l'imagine), en quoi il diffère de WHOIS au niveau du protocole, et comment exploiter des données de domaines à grande échelle lorsque la consultation domaine par domaine n'est pas envisageable.

Points clés

• WHOIS est en fin de vie : le protocole renvoie du texte libre sans structure garantie, diffère d'un bureau d'enregistrement à l'autre et n'offre ni authentification, ni gestion d'erreurs, ni internationalisation standardisées.
• RDAP est le remplaçant imposé par l'ICANN : défini par les RFC 7480 à 7484, il renvoie du JSON sur HTTPS avec un modèle d'objets documenté, des codes de statut HTTP standard et un registre d'amorçage pour identifier le bon serveur.
• Le vrai gain, c'est la structure : bureau d'enregistrement, dates de création et d'expiration, serveurs de noms, codes de statut et enregistrements d'événements arrivent sous forme de champs nommés, au lieu d'un texte qu'il faut décortiquer à coups de motifs.
• Les données de contact ont pratiquement disparu : les réponses RDAP des gTLD sont masquées par défaut. Les noms, adresses e-mail et numéros de téléphone des titulaires ne sont pas récupérables à grande échelle via RDAP, et aucun outil légitime n'y change quoi que ce soit.
• La consultation domaine par domaine ne passe pas à l'échelle : les serveurs RDAP appliquent des limites de débit. Les questions posées à l'échelle d'une population entière (« combien de domaines en .de tournent sous WordPress ») exigent des fichiers en masse, pas des requêtes unitaires.
• Les fichiers en masse répondent à d'autres questions : les fichiers de zone et les jeux de données enrichis par zone livrent domaine, serveurs de noms, MX, IP et CMS détecté sur des TLD entiers, ce qui constitue la bonne matière première pour dimensionner un marché, analyser des infrastructures et construire des jeux de données.

Sommaire

1. ICANN RDAP : la base moderne des données de domaines, et pourquoi WHOIS est obsolète
2. Ce que RDAP ne vous donne pas : masquage, limites de débit et passage à l'échelle
3. Où les données au niveau du domaine sont réellement utiles
4. Ce que propose WebTrackly : des lots de données de domaines en masse
5. Schéma des données : ce que contient le CSV
6. Utiliser l'API du catalogue
7. Traiter les fichiers en local
8. Erreurs fréquentes dans l'exploitation des données RDAP
9. FAQ
10. Conclusion

ICANN RDAP : la base moderne des données de domaines et pourquoi WHOIS est obsolète

Internet repose sur les domaines, et savoir qui les détient, qui les administre et quand ils ont été enregistrés est fondamental pour une multitude d'activités en ligne, de la génération de leads B2B aux investigations en cybersécurité. Pendant des décennies, l'outil de référence pour cela a été WHOIS. Mais le protocole WHOIS traditionnel, conçu aux premiers temps d'Internet, est devenu une relique de moins en moins adaptée aux exigences du web moderne. Sa sortie en texte libre et incohérente, conjuguée à des réglementations sur la vie privée en constante évolution comme le RGPD, le rend notoirement difficile à analyser par programme et souvent incomplet pour des usages professionnels légitimes. C'est précisément pour cette raison que RDAP de l'ICANN, en remplacement de WHOIS, n'est pas une simple mise à niveau, mais une nécessité pour quiconque prend au sérieux le renseignement sur les domaines.

RDAP, ou Registration Data Access Protocol, est né des travaux de l'Internet Engineering Task Force (IETF) et de l'ICANN comme solution normalisée de nouvelle génération. Contrairement à WHOIS, qui exige souvent qu'un humain interprète des formats de sortie variables issus de centaines de bureaux d'enregistrement différents, RDAP livre des données structurées et lisibles par une machine, généralement au format JSON. Une requête renvoie un objet clairement défini : l'identifiant du domaine, un tableau events portant les horodatages d'enregistrement, d'expiration et de dernière modification, un tableau nameservers, un tableau status utilisant des valeurs normalisées dérivées d'EPP, et un tableau entities décrivant le bureau d'enregistrement et les éventuels contacts que le registre choisit de publier. Chaque champ a un nom, un type et une place dans le schéma — exactement ce que WHOIS n'a jamais eu.

C'est l'échelle qui rend la chose décisive. Des centaines de millions de noms de domaine sont enregistrés dans le monde, et vérifier manuellement les enregistrements WHOIS ne serait-ce que pour un millier d'entre eux est impraticable. Automatiser avec WHOIS, c'est écrire et maintenir des analyseurs pour des centaines de formats de sortie uniques : un combat permanent contre l'incohérence et les changements de format silencieux. La réglementation sur la vie privée a aggravé le problème : depuis l'entrée en vigueur du RGPD, les bureaux d'enregistrement masquent ou anonymisent systématiquement les champs de contact du titulaire dans la sortie WHOIS, et ce masquage se retrouve tel quel dans RDAP. Conséquence pratique : WHOIS a perdu l'essentiel de sa valeur résiduelle comme source de contacts, tandis que ses problèmes d'analyse sont restés exactement où ils étaient.

RDAP répond directement à ces difficultés. Il fournit un mécanisme de requête et de réponse cohérent, avec une structure normalisée pour les données d'enregistrement de domaine, quels que soient le bureau d'enregistrement ou le domaine de premier niveau (TLD). Cela comprend les informations sur le domaine, son bureau d'enregistrement, ses dates de création et d'expiration, ses serveurs de noms et, souvent, des informations de contact davantage structurées (lorsque la loi le permet) ou au minimum des identifiants organisationnels. Par exemple, au lieu d'essayer d'extraire un « e-mail du titulaire » d'un bloc de texte qui peut être étiqueté « Admin Contact », « Registrant Email » ou « Contact Email », RDAP fournit des champs JSON distincts pour ces attributs, ce qui rend l'extraction précise et fiable.

Prenons un scénario concret : une entreprise SaaS B2B spécialisée dans la sécurité des sites web souhaite identifier des clients potentiels qui exploitent des environnements d'hébergement anciens et peu sécurisés. Avec le WHOIS traditionnel, il lui faudrait extraire des milliers d'enregistrements, identifier manuellement les hébergeurs à partir des serveurs de noms (souvent opaques), puis tenter de trouver des coordonnées en se heurtant en permanence au masquage. Le processus est lent, source d'erreurs et produit des leads de faible qualité.

RDAP règle le problème de format, et uniquement celui-là. Il fournit des métadonnées techniques fiables et comparables : quel bureau d'enregistrement parraine un domaine, quand il a été créé et quand il expire, vers quels serveurs de noms il est délégué et quels codes de statut administratif s'y appliquent. C'est réellement utile pour l'analyse d'infrastructure, pour suivre les parts de marché des bureaux d'enregistrement et des fournisseurs DNS, et pour repérer les domaines dont le schéma d'enregistrement ou de délégation sort de l'ordinaire. Ce qu'il ne fait pas, c'est restaurer l'annuaire des titulaires qui existait avant 2018. Tout processus qui suppose que RDAP renverra une personne à contacter repose sur une prémisse fausse et échouera sur l'écrasante majorité des domaines gTLD.

Le passage à RDAP est un standard du secteur, documenté par des RFC telles que les RFC 7480, 7481, 7482, 7483 et 7484. Elles définissent le protocole, la structure des requêtes et des réponses ainsi que les considérations de sécurité, garantissant une base robuste et pérenne pour l'accès aux données de domaines. En adoptant RDAP, l'ICANN et la communauté Internet s'orientent vers une manière plus sûre, plus efficace et plus adaptée aux machines d'interroger et de recevoir des données d'enregistrement, indispensable au maintien de la stabilité et de l'utilité d'Internet. Pour les entreprises, cela signifie passer d'une approche manuelle et approximative à une stratégie automatisée et pilotée par la donnée pour identifier leur marché cible et l'aborder. WebTrackly met cette puissance directement entre vos mains, en transformant les données RDAP brutes en informations exploitables pour vos équipes commerciales, marketing et data.

Ce que RDAP ne vous donne pas : masquage, limites de débit et passage à l'échelle

Il vaut la peine d'expliciter les limites du protocole, car beaucoup de publications sur RDAP les passent discrètement sous silence.

• Les données de contact du titulaire sont masquées par défaut. En vertu de la politique de l'ICANN sur les données d'enregistrement, les réponses RDAP des gTLD omettent ou masquent les coordonnées des contacts titulaire, administratif et technique pour le grand public. Une réponse type contient une entité bureau d'enregistrement avec un contact abuse, et une entité titulaire dont les champs vCard sont supprimés ou remplacés par une adresse anonymisée. Aucun niveau d'accès public ne renvoie les valeurs sous-jacentes : les obtenir suppose une demande de divulgation accréditée, limitée à une finalité précise et traitée au cas par cas.
• La couverture est inégale selon les TLD. RDAP est obligatoire pour les gTLD. De nombreux registres de ccTLD le proposent volontairement, certains avec des champs réduits, et quelques-uns n'offrent encore que WHOIS ou un formulaire web. Le registre d'amorçage de l'IANA vous indique quel serveur fait autorité pour un TLD donné, mais il ne peut pas vous dire ce que ce serveur choisira de publier.
• Les limites de débit rendent la consultation en masse impossible. Les points d'accès RDAP des registres et des bureaux d'enregistrement sont protégés contre la collecte automatisée. Des consultations séquentielles se comptant en millions de domaines ne relèvent pas d'un usage pris en charge par le protocole, et toute tentative se solde par un bridage ou un blocage. C'est un choix de conception, pas un obstacle à contourner par l'ingénierie.
• Les réponses décrivent l'enregistrement, pas le site web. RDAP ignore tout du CMS utilisé par un site, du CDN placé devant lui ou même du fait qu'il résolve. Cette information provient de l'observation DNS et HTTP, qui constitue un problème de collecte distinct.

Ces limites déterminent quelles questions se traitent par une consultation et lesquelles exigent un jeu de données en masse. Demander « quel est le bureau d'enregistrement et la date d'expiration de ce domaine » relève de la consultation. Demander « combien de domaines de cette zone sont délégués à des serveurs de noms Cloudflare » est une question de jeu de données, et aucune quantité de requêtes n'en fera une consultation.

Où les données au niveau du domaine sont réellement utiles

Les données structurées d'enregistrement et d'infrastructure servent un ensemble de cas d'usage plus restreint, mais plus défendable, que ne le laisse entendre le discours marketing habituel sur le renseignement de domaines. Les trois exemples ci-dessous s'appuient sur ce qui est réellement disponible : des métadonnées techniques sur les domaines, et non des informations sur les personnes derrière eux.

Surface d'attaque et recherche sur les infrastructures

Public visé : prestataires de services de cybersécurité, sociétés de tests d'intrusion, équipes de réponse à incident, analystes en renseignement sur les menaces.

Problème : identifier les organisations qui exploitent une infrastructure potentiellement vulnérable ou obsolète est un travail manuel et chronophage. Les données WHOIS traditionnelles sont trop incohérentes et trop souvent masquées pour relier efficacement des domaines à leur pile technologique sous-jacente ou à des schémas de bureaux d'enregistrement révélateurs de risque. Les surfaces d'attaque sont immenses, et l'identification proactive de cibles présentant des configurations précises et exploitables est aussi critique que difficile.

Ce que les données permettent : les fichiers au niveau de la zone permettent à une équipe sécurité d'énumérer les domaines d'un TLD, de résoudre leur délégation et leur infrastructure de messagerie, et de recouper les plateformes CMS détectées avec les versions connues comme vulnérables. Travailler à partir d'une zone complète plutôt que d'une liste échantillonnée signifie que le dénominateur est réel : vous pouvez dire combien de domaines d'une zone utilisent tel opérateur de serveurs de noms ou tel fournisseur de messagerie, et non combien apparaissaient dans l'échantillon que vous avez réussi à réunir. RDAP vient ensuite compléter les métadonnées d'enregistrement, domaine par domaine, sur la liste restreinte issue de cette analyse — un volume que le protocole absorbe sans difficulté.

Ce que les données ne permettent pas : elles ne vous diront pas qui contacter au sein de ces organisations. Constituer une liste de prospection est un exercice distinct, qui doit s'appuyer sur les informations que ces organisations publient elles-mêmes, et ce n'est pas ce que fournit un jeu de données de domaines.

Dimensionnement de marché pour les fondateurs SaaS et les équipes produit

Public visé : fondateurs SaaS, product managers, analystes de marché, investisseurs en capital-risque.

Problème : valider une nouvelle idée de produit SaaS suppose une compréhension fine du marché : qui sont les clients potentiels, quelles technologies utilisent-ils aujourd'hui et quelle est la taille du marché adressable ? S'appuyer sur des observations anecdotiques ou des rapports sectoriels généraux ne suffit pas. Les fondateurs ont besoin de données granulaires sur l'adoption des technologies et l'infrastructure sous-jacente.

Ce que les données permettent : compter. Si votre produit vise les sites WordPress, la taille de la population adressable est une quantité dénombrable et non une estimation : sur l'ensemble des zones couvertes ici, 21,639,326 domaines sont détectés comme WordPress et 567,680 comme Joomla. Si votre produit est spécifique à une région, les fichiers par zone vous permettent de restreindre le décompte aux TLD qui comptent. Comparer les décomptes entre zones ou entre instantanés pris à des dates différentes montre où une plateforme gagne ou perd du terrain, ce qui alimente un business case bien plus solidement que le graphique de parts de marché publié par un éditeur.

Comment procéder : prenez le jeu de données enrichi pour les zones concernées, comptez les lignes par CMS détecté et par opérateur de serveurs de noms, puis recommencez avec un instantané ultérieur lorsque vous voulez une tendance plutôt qu'une valeur ponctuelle.

Constituer des jeux de données pour l'analyse et le machine learning

Public visé : data scientists, ingénieurs data, chercheurs, analystes en business intelligence.

Problème : construire des jeux de données complets pour l'analyse à grande échelle, des modèles de machine learning ou des prévisions de tendances se heurte à l'hétérogénéité des sources. Les données WHOIS traditionnelles ne sont pas structurées, exigent un nettoyage et une analyse syntaxique poussés, et manquent souvent de la cohérence nécessaire à des pipelines robustes. Intégrer des points de données disparates issus de sources web variées est complexe et chronophage.

Ce que les données permettent : un point de départ stable et tabulaire. Chaque fichier enrichi par zone est un CSV avec une ligne par domaine et un ensemble fixe de colonnes, qui se charge directement dans pandas, DuckDB, ClickHouse ou un entrepôt de données sans étape d'analyse syntaxique. Domaine, serveurs de noms, MX, IP et CMS détecté sont tous exploitables comme variables : la concentration des hébergeurs et des fournisseurs de messagerie, les schémas de délégation et le choix de plateforme sont des signaux informatifs pour des tâches de classification comme distinguer les domaines parqués des sites actifs, ou regrouper les domaines par opérateur d'infrastructure. Lorsqu'un registre publie les dates d'enregistrement, celles-ci sont incluses et donnent au jeu de données une dimension temporelle.

Réserves à intégrer d'emblée : la détection est observationnelle et accusera un retard pour les sites récemment modifiés ; un domaine présent dans un fichier de zone est enregistré, mais ne sert pas nécessairement de contenu ; et l'absence d'enregistrement MX signifie qu'aucune messagerie n'est configurée pour ce nom, pas que l'organisation n'a pas de messagerie.

Ce que propose WebTrackly : des lots de données de domaines en masse

WebTrackly est un catalogue de données de domaines téléchargeables, ni une interface de recherche, ni une base de contacts. Le catalogue compte 1,538 lots, répartis en quatre familles.

La couverture sur ces zones atteint 285,582,781 domaines. La plus grande zone à elle seule est .com, avec 163,422,083 domaines. Côté technologies, 21,639,326 domaines sont détectés comme WordPress et 567,680 comme Joomla. Le plus grand jeu de données organisé, l'ensemble des domaines enregistrés, contient 272,614,863 lignes.

La livraison est volontairement simple. Le format de téléchargement dépend du package et figure sur la page produit. Les achats à l'unité démarrent à $3.50. Deux abonnements existent pour un usage continu : Pro à $29/mois couvre 50 lots ainsi que 10 jeux de données et 30,000 appels API, et Enterprise à $99/mois couvre 200 lots ainsi que 50 jeux de données et 300,000 appels API.

Le catalogue se parcourt sur /packages/, les fichiers de zone étant listés sous /zones/, les listes par technologie sous /domaindata/ et les compilations multizones sous /datasets/. Le détail des offres se trouve sur /pricing/.

Schéma des données : ce que contient le CSV

Un lot enrichi par zone se décompresse en un CSV comportant une ligne par domaine et les colonnes suivantes.

Les lots de fichiers de zone simples ne contiennent que la colonne domain. Les listes par technologie contiennent les domaines sur lesquels une plateforme donnée a été détectée.

Il est tout aussi important de préciser ce que les fichiers ne contiennent pas :

• Aucun contact personnel, d'aucune sorte. Ni noms, ni adresses e-mail, ni numéros de téléphone, ni profils sociaux.
• Aucune donnée d'identité du titulaire. La date d'enregistrement est une métadonnée publiée par le registre ; le titulaire derrière un domaine ne fait pas partie de ces fichiers.
• Aucun signal d'intention, firmographique ou de taille d'entreprise.
• Aucune estimation de trafic, de positionnement ou de chiffre d'affaires.

Si votre besoin est une liste de personnes à contacter, ces jeux de données ne sont pas la bonne matière première, et aucun filtre ni option d'export n'y changera quoi que ce soit.

Utiliser l'API du catalogue

L'API dessert le catalogue : elle vous permet de découvrir les lots existants, d'inspecter leurs métadonnées et d'automatiser l'achat et le téléchargement. Ce n'est pas un point d'accès de consultation domaine par domaine, et il n'existe aucune interface de requête renvoyant des enregistrements de domaines individuels. Chaque requête porte un jeton bearer.

Lister les lots de fichiers de zone :

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

Rechercher parmi les lots technologiques :

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

Récupérer la fiche détaillée d'un lot, avec son nombre de lignes et son prix actuel :

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

Un schéma d'automatisation courant consiste à interroger périodiquement le catalogue pour les lots dont dépend votre pipeline, à comparer les nombres de lignes annoncés avec votre dernière ingestion, puis à déclencher un nouveau téléchargement lorsqu'une zone a sensiblement grossi ou diminué. Les quotas d'appels API sont de 30,000 par mois sur Pro et de 300,000 par mois sur Enterprise, ce qui est largement suffisant pour interroger le catalogue et bien au-delà des besoins d'un pipeline planifié. La documentation complète des points d'accès est sur /api/.

Traiter les fichiers en local

Le format de téléchargement dépend du package et figure sur la page produit. Comme les fichiers sont du CSV brut, les outils en ligne de commande standard suffisent pour un premier passage, et un moteur en colonnes prend le relais pour tout le reste.

Décompressez et observez la forme des données :

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

Pour un fichier portant sur une seule zone, grep et awk suffisent souvent :

# domains delegating to Cloudflare name servers
grep -i 'ns.cloudflare.com' com-enriched.csv | wc -l

# domains with Google Workspace mail
grep -i 'aspmx.l.google.com' com-enriched.csv | wc -l

Pour tout travail analytique, chargez le CSV dans DuckDB. Il lit le fichier sur place, sans étape d'import :

duckdb -c "
  SELECT cms, count(*) AS domains
  FROM read_csv_auto('com-enriched.csv')
  WHERE cms IS NOT NULL
  GROUP BY cms
  ORDER BY domains DESC
  LIMIT 20;
"

Pour des requêtes répétées sur de nombreuses zones à la fois, ClickHouse est plus adapté. Créez une table avec les six colonnes, chargez les CSV, et les agrégations sur des centaines de millions de lignes s'exécutent en quelques secondes :

clickhouse-client --query "
  CREATE TABLE domains (
    domain String, reg_date Nullable(Date),
    ns String, mx String, ip String, cms String
  ) ENGINE = MergeTree ORDER BY domain"

clickhouse-client --query "INSERT INTO domains FORMAT CSVWithNames" < com-enriched.csv

Une remarque sur les volumes : le jeu de données de l'ensemble des domaines enregistrés compte 272,614,863 lignes, prévoyez donc des dizaines de gigaoctets non compressés et utilisez un moteur en colonnes plutôt qu'un tableur. Les fichiers de zone pris individuellement sont bien plus légers et la plupart s'ouvrent confortablement dans DuckDB sur un ordinateur portable.

Erreurs fréquentes dans l'exploitation des données RDAP

RDAP est simple à interroger et facile à mal interpréter. Voici les erreurs qui produisent le plus souvent des conclusions trompeuses.

1. Erreur : trop compter sur les coordonnées directes issues du RDAP brut.

   • Ce qui cloche : beaucoup d'utilisateurs s'attendent à ce que RDAP fournisse des adresses e-mail et des numéros de téléphone directs et non masqués pour les titulaires. En raison des réglementations sur la vie privée (comme le RGPD) et des politiques des bureaux d'enregistrement, une grande partie de ces informations est souvent masquée, anonymisée (par exemple [email protected]) ou tout simplement indisponible via RDAP. S'appuyer uniquement sur le RDAP brut pour des coordonnées produira des listes de leads vides ou de très mauvaise qualité.
   • Pourquoi : la spécification temporaire de l'ICANN sur les données d'enregistrement des gTLD et diverses lois nationales sur la vie privée imposent la protection des données personnelles. Les bureaux d'enregistrement s'y conforment en masquant les coordonnées.
   • La solution : traitez RDAP comme une source de métadonnées techniques, et rien d'autre. Bureau d'enregistrement, dates, serveurs de noms et codes de statut sont fiables ; les champs de contact ne le sont pas. Si votre projet doit joindre des organisations, cela doit passer par les informations que ces organisations publient elles-mêmes, collectées sur la base juridique applicable à votre juridiction et à votre usage. Aucun produit de données de domaines, celui-ci compris, ne fournit les contacts des titulaires, et tout fournisseur prétendant les extraire de RDAP décrit quelque chose que le protocole ne fait pas.

2. Erreur : négliger les subtilités des codes de statut RDAP.

   • Ce qui cloche : RDAP fournit des codes de statut détaillés (par exemple clientDeleteProhibited, serverHold, pendingDelete). Les mal interpréter conduit à cibler des domaines inactifs, en litige ou sur le point d'expirer. Cibler un domaine en pendingDelete pour une approche commerciale, par exemple, est une perte de temps.
   • Pourquoi : ces codes indiquent l'état administratif courant d'un domaine. Ils sont essentiels pour comprendre sa disponibilité et sa stabilité.
   • La solution : apprenez le vocabulaire de statuts EPP que RDAP réutilise. clientTransferProhibited est un verrouillage normal et ne dit rien de négatif sur un domaine ; serverHold signifie que le domaine n'est pas publié dans le DNS ; pendingDelete signifie qu'il est dans le cycle de suppression et sera libéré sous peu ; redemptionPeriod signifie qu'il a déjà expiré mais peut encore être restauré par son titulaire. Décidez explicitement quels statuts votre analyse inclut et consignez cette décision avec vos résultats, afin que les chiffres soient reproductibles.

3. Erreur : supposer que la fraîcheur des données est universelle et instantanée.

   • Ce qui cloche : croire que toutes les données RDAP sont en temps réel et mises à jour simultanément chez tous les bureaux d'enregistrement. Si RDAP est conçu pour l'accès programmatique, les cycles de mise à jour varient d'un bureau d'enregistrement à l'autre et des délais de propagation existent.
   • Pourquoi : les données d'enregistrement de domaine transitent par plusieurs acteurs (titulaire, bureau d'enregistrement, registre). Les mises à jour ne sont pas toujours instantanées dans l'ensemble de la chaîne.
   • La solution : traitez chaque jeu de données et chaque consultation comme un instantané horodaté, et stockez cet horodatage avec les données. Les fichiers en masse reflètent l'état d'une zone au moment où l'export a été généré ; RDAP reflète l'état d'un domaine au moment de la requête. Ni l'un ni l'autre n'est un flux en direct. Pour le travail sur les tendances, c'est un avantage plutôt qu'une limite, puisque comparer des instantanés datés est précisément ce qui rend une tendance mesurable.

4. Erreur : ignorer les limites de débit et les politiques d'usage équitable.

   • Ce qui cloche : interroger agressivement les serveurs RDAP, directement ou via l'API d'une plateforme, sans tenir compte des limites de débit peut entraîner des bannissements d'IP, des blocages temporaires ou une dégradation du service. C'est particulièrement vrai si l'on tente d'extraire du RDAP brut en masse.
   • Pourquoi : les serveurs RDAP, comme toute API publique, sont protégés contre les abus. L'API de WebTrackly elle-même applique des limites de débit pour garantir un usage équitable à tous les clients.
   • La solution : n'essayez pas d'énumérer en masse via RDAP. Réservez les consultations aux cas où vous avez besoin d'un détail à jour et faisant autorité sur un domaine précis, appliquez alors un backoff exponentiel et respectez les en-têtes Retry-After, et utilisez les fichiers en masse pour tout ce qui relève de l'échelle d'une population. Tenter de reconstituer une zone par des requêtes domaine par domaine est à la fois plus lent et moins complet que de télécharger la zone.

5. Erreur : confondre « bureau d'enregistrement » et « hébergeur ».

   • Ce qui cloche : confondre l'entité auprès de laquelle le domaine a été enregistré (le bureau d'enregistrement, présent dans RDAP) avec celle qui héberge le contenu du site (l'hébergeur, identifié via le DNS et l'IP). Un domaine enregistré chez GoDaddy peut très bien être hébergé sur AWS, et inversement.
   • Pourquoi : ce sont deux services distincts. Un bureau d'enregistrement gère le nom de domaine lui-même, tandis qu'un hébergeur sert les fichiers du site.
   • La solution : conservez les deux attributs dans des colonnes séparées et n'en déduisez jamais l'un à partir de l'autre. Le bureau d'enregistrement vient de RDAP. L'hébergeur et le fournisseur de messagerie se déduisent des colonnes serveurs de noms, MX et IP d'un fichier en masse. Un fichier de zone vous montrera par exemple qu'un domaine est délégué à des serveurs de noms Cloudflare alors que son A-record pointe vers un tout autre fournisseur — exactement le genre de distinction qui se perd lorsque les deux notions sont confondues.

6. Erreur : négliger la conformité juridique et éthique (RGPD, CCPA, usage acceptable).

   • Ce qui cloche : utiliser les données extraites, en particulier des coordonnées, sans tenir compte des réglementations sur la vie privée ni des politiques d'usage acceptable des fournisseurs de données. Cela peut entraîner des sanctions juridiques, une atteinte à la réputation et la résiliation du compte.
   • Pourquoi : les lois sur la protection des données sont strictes. Même publiquement accessibles, les données doivent être collectées et utilisées conformément à des textes comme le RGPD et le CCPA.
   • La solution : sachez quel régime juridique s'applique aux données que vous détenez. Domaine, serveurs de noms, MX, IP et CMS détecté sont des attributs techniques d'infrastructure, pas des données personnelles relatives à des individus identifiables, ce qui rend les fichiers de domaines en masse relativement simples à manipuler. Dès l'instant où vous les combinez à des informations sur des personnes, vous traitez des données personnelles et le RGPD, le CCPA et les régimes équivalents s'appliquent pleinement. Gardez cette frontière visible dans votre propre pipeline plutôt que de la découvrir lors d'un audit.

Éviter ces erreurs rend une analyse fondée sur RDAP défendable : juste sur ce que le protocole rapporte, explicite sur ce qu'il omet et honnête sur la différence entre un instantané et une vue en direct.

FAQ

Q : qu'est-ce que RDAP exactement, et en quoi diffère-t-il de WHOIS ?
R : RDAP (Registration Data Access Protocol) est le remplaçant moderne et normalisé du protocole WHOIS, aujourd'hui dépassé. La différence essentielle est que RDAP fournit des données structurées et lisibles par une machine (généralement au format JSON), là où WHOIS produit du texte libre et incohérent qui varie fortement selon le bureau d'enregistrement. Ce format structuré rend les données RDAP bien plus faciles à analyser, à exploiter et à intégrer dans des systèmes automatisés. RDAP offre en outre des fonctions de sécurité renforcées et une prise en charge de l'internationalisation, ce qui le rend supérieur pour l'accès programmatique et le renseignement mondial sur les domaines.

Q : puis-je obtenir les noms, e-mails ou numéros de téléphone des titulaires via RDAP ?
R : non, pas à une échelle utile. Les réponses RDAP des gTLD sont masquées par défaut en vertu de la politique de l'ICANN, et la plupart des registres renvoient une valeur anonymisée ou vide pour les champs de contact du titulaire. La divulgation n'existe que sous la forme d'une demande accréditée, limitée à une finalité précise et traitée au cas par cas. Les jeux de données de WebTrackly ne contiennent pas non plus de contacts personnels : domaine, date d'enregistrement lorsqu'elle est publiée, serveurs de noms, MX, IP et CMS détecté constituent l'intégralité de ce que portent les fichiers.

Q : WebTrackly propose-t-il une consultation par domaine ou une interface de recherche ?
R : non. Le produit est un catalogue de lots téléchargeables. Le format de téléchargement dépend du package et figure sur la page produit. Il n'existe pas d'interface pour interroger un domaine isolé ni de recherche filtrée sur les lignes sous-jacentes ; le filtrage se fait de votre côté, après le téléchargement.

Q : quels formats et quels modes de livraison sont disponibles ?
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 : il reflète donc l'état courant des données et non un fichier pré-construit d'âge inconnu. L'API renvoie les métadonnées du catalogue en JSON.

Q : quelle est la taille des jeux de données ?
R : la couverture est de 285,582,781 domaines répartis sur 716 zones. La seule zone .com représente 163,422,083 domaines. Le jeu de données de l'ensemble des domaines enregistrés contient 272,614,863 lignes. Les listes par technologie sont plus petites et plus ciblées : 21,639,326 domaines pour WordPress, 567,680 pour Joomla.

Q : que fait l'API du catalogue ?
R : elle expose le catalogue de lots. GET /api/v1/packages/?type=zone liste les lots de zones, GET /api/v1/packages/?type=technology&q=wordpress recherche parmi les lots technologiques, et GET /api/v1/packages/{slug}/ renvoie la fiche détaillée d'un lot. Les requêtes sont authentifiées par un en-tête Authorization: Bearer YOUR_API_KEY. Les quotas sont de 30,000 appels par mois sur Pro et de 300,000 sur Enterprise.

Q : combien cela coûte-t-il ?
R : les achats de lots à l'unité démarrent à $3.50. Pour un usage continu, deux offres existent : Pro à $29/mois, qui couvre 50 lots ainsi que 10 jeux de données et 30,000 appels API, et Enterprise à $99/mois, qui couvre 200 lots ainsi que 50 jeux de données et 300,000 appels API. Le détail figure sur la page tarifs.

Q : comment charger un fichier aussi volumineux ?
R : décompressez-le et interrogez-le avec un moteur en colonnes. DuckDB lit le CSV sur place et traite confortablement un fichier de zone unique sur un ordinateur portable ; ClickHouse est le meilleur choix pour des agrégations répétées sur de nombreuses zones ou sur la compilation multizones complète. À ces volumes de lignes, les tableurs ne sont pas une option réaliste.

Conclusion

Le passage de WHOIS à RDAP est une véritable avancée, mais une avancée étroite. Il règle le problème de format : les métadonnées d'enregistrement arrivent désormais en JSON, avec un schéma documenté, une sémantique HTTP standard et un registre d'amorçage qui indique où poser la question. Il ne règle pas le problème d'accès, et n'a jamais eu vocation à le faire. Les données de contact des titulaires ont été retirées des registres publics d'enregistrement par décision politique, et RDAP reproduit fidèlement cette décision.

Concrètement, cela signifie que les données de domaines sont des données techniques. Bureau d'enregistrement, dates, serveurs de noms, configuration de messagerie, adresses résolues et plateformes détectées sont tous réels, comparables et disponibles à grande échelle. Les questions formulées dans ces termes trouvent une réponse précise. Celles qui présupposent un annuaire des titulaires n'en trouvent aucune, avec aucun outil.

Si votre travail exige des réponses à l'échelle d'une population entière sur l'infrastructure des domaines, les fichiers en masse sont la voie pratique : choisissez la zone, la liste par technologie ou la compilation dont vous avez besoin dans le catalogue de lots, téléchargez le CSV et analysez-le en local avec les outils que vous maîtrisez déjà.

Ressources associées

• Catalogue de lots — 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 organisés — tous les domaines enregistrés, serveurs MX, e-commerce
• Tarifs — achats à l'unité à partir de $3.50