Domain Intelligence

Domain listening : surveiller les données de domaines à grande échelle

blureshot avril 05, 2026 13 min de lecture 795 vues

La plupart des questions que l'on se pose sur le web sont en réalité des questions sur le changement. Quels TLD progressent. Si un CMS gagne ou perd du terrain. Combien de domaines sont passés derrière tel CDN ce trimestre. Aucune de ces questions ne trouve de réponse dans une requête unitaire, ni d'ailleurs dans un fichier unique : il faut mesurer deux fois la même population. Cette pratique, qui consiste à prendre des instantanés périodiques des données de domaines et à les comparer, c'est ce que ce guide appelle le domain listening. C'est sans panache, entièrement mécanique, et c'est la seule façon fiable de voir le web bouger.

EN BREF / À RETENIR

  • Le domain listening consiste à surveiller une population de domaines dans le temps en comparant des instantanés, plutôt qu'en interrogeant des noms individuels.
  • L'unité de travail est un fichier, pas une requête. Le format de téléchargement dépend du package et figure sur la page produit.
  • L'échelle est tout l'enjeu : le package de la zone .com contient 163 422 083 domaines, la liste WordPress 21 639 326, et le jeu de données de tous les domaines enregistrés 272 614 863 lignes.
  • Les fichiers sont générés au moment de l'achat : chaque téléchargement est donc un extrait frais et non un instantané mis en cache. C'est ce qui rend la comparaison d'une période à l'autre pertinente.
  • L'analyse se fait chez vous. Il n'y a ni générateur de requêtes, ni recherche par domaine, ni interface de filtrage. Vous achetez un fichier et vous le traitez avec vos propres outils.
  • Uniquement des données de domaines : noms, dates d'enregistrement lorsqu'elles sont publiées, serveurs de noms, MX, IP et technologies détectées. Aucun contact personnel, aucun numéro de téléphone, aucun signal d'intention.
  • Le ticket d'entrée est faible : packages à l'unité dès $3.50, Pro à $29/mois, Enterprise à $99/mois.

Sommaire

Ce qu'est réellement le domain listening

Le domain listening est la pratique qui consiste à observer une population de domaines définie à intervalles réguliers et à consigner ce qui a changé entre deux relevés. Cette population peut être un TLD entier, l'ensemble des domaines détectés comme fonctionnant sous un CMS donné, ou tous les domaines pointant vers un jeu de serveurs de noms particulier. L'intervalle peut être hebdomadaire, mensuel ou trimestriel, selon la vitesse à laquelle évolue le signal qui vous intéresse.

La mécanique reste la même quel que soit le sujet. Vous prenez un instantané, vous le stockez, vous en prenez un autre plus tard, puis vous calculez trois ensembles : les lignes présentes dans les deux, celles qui sont apparues et celles qui ont disparu. Tout ce qui est intéressant sort de ces trois ensembles. La croissance, c'est l'ensemble des apparitions. Le churn, c'est l'ensemble des disparitions. La migration, c'est une ligne présente dans les deux mais dont un champ a changé.

C'est une discipline différente de la requête unitaire par domaine. WHOIS et RDAP répondent à la question « que dit le registre à propos de ce nom en ce moment », et ils sont justement soumis à des limites de débit pour que personne ne les utilise afin d'énumérer une population. Un fichier de zone ou une liste technologique constitue la population, livrée sous forme de fichier. Le compromis porte sur l'immédiateté : vous ne pouvez pas interroger un fichier tant que vous ne l'avez pas chargé, mais une fois chargé, vous pouvez lui poser des questions auxquelles aucun protocole de requête ne répondra jamais.

Deux conséquences pratiques en découlent. D'abord, la rigueur de stockage compte davantage que l'habileté dans les requêtes : si vous jetez le fichier du trimestre dernier, vous ne pourrez pas reconstituer l'état du trimestre dernier. Ensuite, la comparaison n'est valide que si les deux instantanés ont été produits de la même façon. Comparer un extrait frais à la copie en cache périmée d'un fournisseur revient à mesurer la politique de cache du fournisseur, pas le web.

Ce que l'on peut mesurer avec des instantanés

Les points suivants trouvent tous une réponse à partir de deux instantanés ou plus du même package. Aucun ne nécessite de données de contact, aucun ne nécessite d'interface de requête.

Croissance et churn d'un TLD

Comparez un fichier de zone à une copie antérieure du même fichier. Les nouvelles lignes correspondent aux enregistrements apparus dans la zone ; les lignes manquantes aux noms qui en sont sortis. Agrégez par mois et vous obtenez une tendance d'enregistrement pour ce TLD, indépendante des statistiques publiées par qui que ce soit.

Parts de marché des plateformes dans le temps

Les packages technologiques regroupent les domaines selon la plateforme détectée. Compter les lignes du package WordPress à deux moments distincts donne un chiffre de mouvement absolu. Faire de même pour plusieurs plateformes et normaliser par rapport au fichier de zone d'un TLD donne la part de chacune au sein de ce TLD. C'est l'un des rares moyens de mesurer l'empreinte d'une plateforme sans dépendre de ses propres chiffres marketing.

Migration d'infrastructure

Lorsqu'un jeu de données comporte les champs serveur de noms, MX ou IP, une ligne présente dans les deux instantanés avec une valeur modifiée constitue un événement de migration. Agrégés, ces événements montrent quels fournisseurs DNS, prestataires de messagerie et réseaux d'hébergement gagnent des domaines et lesquels en perdent.

Dimensionner une population avant de construire

Avant d'engager des moyens d'ingénierie sur une intégration ou un produit de niche, le nombre de lignes d'un package technologique constitue une borne supérieure directe de l'ensemble de sites adressables. Ce chiffre est un fait mesuré sur le fichier, pas une projection.

Recherche et travail sur la surface d'attaque

La recherche en sécurité part souvent de « quels domaines résolvent vers ce bloc d'adresses » ou « quels domaines utilisent cette plateforme ». Les fichiers en masse répondent aux deux, sous forme de filtre sur une colonne. Ce qu'ils ne vous disent pas, c'est la version du logiciel ou le niveau de correctif : cela suppose de sonder les hôtes vous-même, et les fichiers constituent alors la liste de cibles de ce travail plutôt qu'un substitut.


Commencez à écouter.
1 538 packages — 716 fichiers de zone par TLD, 79 listes technologiques, 27 jeux de données. 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

Le catalogue compte trois groupes :

Les colonnes dépendent du package. Un fichier de zone est étroit ; un jeu de données résolu embarque les champs DNS et IP. Le tableau ci-dessous décrit la forme des données plutôt qu'il ne garantit la présence de chaque colonne dans chaque package — chaque fiche indique son propre nombre de lignes et son contenu avant l'achat.

Champ Exemple de valeur Où il apparaît
domain example.com Tous les packages
created / date d'enregistrement 2014-03-18 Lorsque le registre la publie
ns ns1.cloudflare.com Fichiers de zone, jeux de données
mx aspmx.l.google.com Jeux de données avec données de messagerie
ip 93.184.216.34 Jeux de données de domaines résolus
cms / technology WordPress Packages technologiques

Ce que les fichiers ne contiennent pas : noms de personnes, adresses e-mail, numéros de téléphone, données firmographiques ou signaux d'intention comportementale. WebTrackly publie des données de domaines. Les données personnelles des titulaires sont masquées au niveau du registre pour la plupart des domaines en application du RGPD, et elles ne font pas partie du produit.

Acheter et traiter un package

  1. Choisissez le package. Parcourez le catalogue, ou rendez-vous directement sur /zones/, /domaindata/ ou /datasets/. Chaque fiche indique son nombre de lignes.
  2. Achetez-le. Les achats à l'unité démarrent à $3.50. Pro est à $29/mois (50 packages, 10 jeux de données, 30 000 appels API) ; Enterprise à $99/mois (200 packages, 50 jeux de données, 300 000 appels API). Voir les tarifs.
  3. Téléchargez. L'archive ZIP est produite à la demande et disponible immédiatement après le paiement.
  4. Traitez-le en local. Décompressez et exploitez le CSV dans votre propre environnement.

À ces volumes de lignes, les outils en flux surpassent largement ceux qui chargent tout en mémoire :

unzip wordpress-domains.zip
wc -l wordpress-domains.csv

# top name servers, straight from the CSV
duckdb -c "SELECT ns, count(*) AS n FROM 'wordpress-domains.csv'
           GROUP BY ns ORDER BY n DESC LIMIT 20"

Pour tout ce que vous comptez interroger de façon répétée, chargez une fois dans PostgreSQL ou ClickHouse et indexez les colonnes sur lesquelles vous filtrez. Joindre deux packages — une liste technologique et un fichier de zone, par exemple — revient à une jointure sur la colonne domain.

Mettre en place un workflow de comparaison

Un dispositif de surveillance repose sur trois éléments : une convention de nommage, un endroit où conserver les instantanés, et une étape de comparaison.

Nommez par package et par date. com-zone-2026-07.csv, wordpress-2026-07.csv. La date est celle du téléchargement, pas celle de l'analyse.

Conservez les fichiers bruts. Un CSV compressé coûte peu, et un instantané supprimé ne peut pas être régénéré rétroactivement : le fichier reflète l'état au moment où il a été produit.

Comparez sur la colonne clé. Pour une analyse des apparitions et des disparitions, une comparaison triée suffit :

cut -d, -f1 wordpress-2026-06.csv | sort -u > old.txt
cut -d, -f1 wordpress-2026-07.csv | sort -u > new.txt

comm -13 old.txt new.txt > appeared.txt   # in new, not in old
comm -23 old.txt new.txt > disappeared.txt # in old, not in new
wc -l appeared.txt disappeared.txt

Pour détecter les changements au niveau d'un champ — un domaine qui est resté mais a changé de serveurs de noms — passez par du SQL :

SELECT n.domain, o.ns AS old_ns, n.ns AS new_ns
FROM new_snapshot n
JOIN old_snapshot o USING (domain)
WHERE n.ns IS DISTINCT FROM o.ns;

Deux précautions. Normalisez avant de comparer : passez le domaine en minuscules, supprimez les points finaux et fixez un encodage unique pour les noms internationalisés, faute de quoi vous fabriquerez du churn qui n'existe pas. Et considérez un intervalle isolé comme du bruit : le signal utile, c'est la tendance sur plusieurs intervalles, pas l'écart entre deux fichiers pris au hasard.

Automatiser avec l'API catalogue

Les abonnements incluent un accès API pour exploiter le catalogue par programmation : lister les packages et les jeux de données et lire leurs métadonnées. Pro inclut 30 000 appels par mois, Enterprise 300 000. L'API est une interface de catalogue ; elle n'effectue pas de requêtes 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/datasets/"

La référence des endpoints se trouve sur la page de documentation de l'API. Une tâche cron mensuelle qui lit le catalogue, récupère les packages que vous suivez et les dépose dans des fichiers datés suffit à faire tourner un pipeline de listening sans intervention.

Les erreurs courantes en domain listening et comment les éviter

  1. Prendre un seul instantané et appeler cela de la surveillance

    • Ce qui cloche : un fichier unique est téléchargé et analysé une fois.
    • Pourquoi : un instantané isolé décrit un état. Toute question de croissance, de churn ou de migration en exige au moins deux.
    • Le correctif : fixez l'intervalle avant le premier téléchargement, et conservez chaque fichier récupéré.
  2. Comparer des instantanés qui n'ont pas été produits de la même façon

    • Ce qui cloche : un extrait frais est comparé à un fichier plus ancien provenant d'une autre source ou d'un autre package.
    • Pourquoi : l'écart traduit alors des différences de méthodologie plutôt qu'un changement réel.
    • Le correctif : comparez le même package à lui-même, et notez la date de téléchargement avec chaque fichier.
  3. Sauter l'étape de normalisation avant la comparaison

    • Ce qui cloche : des différences de casse, des points finaux ou un encodage IDN incohérent produisent d'énormes ensembles fantômes d'apparitions et de disparitions.
    • Pourquoi : la comparaison de chaînes est exacte ; le même domaine sous deux formes, ce sont deux lignes.
    • Le correctif : passez en minuscules, supprimez les points finaux et choisissez une seule représentation IDN au chargement.
  4. Charger des centaines de millions de lignes dans le mauvais outil

    • Ce qui cloche : un CSV de plusieurs gigaoctets est ouvert dans un tableur ou parcouru ligne à ligne dans un langage de script.
    • Pourquoi : les volumes atteignent ici des centaines de millions de lignes. Tout outil qui garde le fichier en mémoire n'ira pas au bout.
    • Le correctif : traitez-le en flux — filtres en ligne de commande, DuckDB directement sur le CSV, ou chargement en masse dans un moteur en colonnes.
  5. Lire une détection technologique comme une indication de version

    • Ce qui cloche : une liste technologique est prise pour une liste d'hôtes exécutant une version vulnérable précise.
    • Pourquoi : les packages regroupent les domaines par plateforme détectée, pas par niveau de correctif.
    • Le correctif : servez-vous de la liste comme d'un ensemble de cibles et déterminez vous-même la version ou l'exposition, dans le cadre des autorisations qu'exige votre travail.
  6. S'attendre à trouver des données de contact quelque part dans le fichier

    • Ce qui cloche : un workflow est conçu autour d'adresses e-mail ou de numéros de téléphone rattachés aux domaines.
    • Pourquoi : ces données ne figurent pas dans les packages, et les coordonnées des titulaires sont masquées au niveau du registre pour la plupart des domaines en application du RGPD.
    • Le correctif : utilisez les données de domaines pour ce qu'elles sont — une cartographie des noms, des infrastructures et des plateformes — et traitez toute collecte de contacts via des canaux dont le consentement et la provenance sont documentés.

Questions fréquentes

Q : Que vend exactement WebTrackly ?
R : Des données de domaines en masse, téléchargeables. 1 538 packages au total : 716 fichiers de zone par TLD, 79 listes de technologies et de CMS, et 27 jeux de données organisés. Le format de téléchargement dépend du package et figure sur la page produit.

Q : Quelle est la fraîcheur d'un téléchargement ?
R : Le fichier est généré au moment de l'achat et non servi depuis un instantané préconstruit : il reflète donc l'état des données source le jour de votre achat.

Q : Existe-t-il un champ de recherche pour interroger un seul domaine ?
R : Non. Il n'y a ni recherche par domaine, ni interface de filtrage. Vous choisissez un package dans le catalogue, vous l'achetez, vous téléchargez le CSV et vous le filtrez avec vos propres outils.

Q : Quelle est la taille des fichiers ?
R : Cela varie selon le package. Le package de la zone .com contient 163 422 083 domaines, la liste technologique WordPress 21 639 326, et le jeu de données de tous les domaines enregistrés 272 614 863 lignes. Chaque fiche indique son nombre de lignes avant l'achat.

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

Q : Les fichiers contiennent-ils des coordonnées ?
R : Non. Aucun nom, aucune adresse e-mail, aucun numéro de téléphone, aucune donnée personnelle de titulaire. En application du RGPD, ces données sont masquées dans les registres publics d'enregistrement pour la plupart des domaines, et elles sortent du périmètre de ce que publie WebTrackly.

Q : Y a-t-il une API ?
R : Oui, pour le catalogue. Elle 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 requêtes sur les domaines.

Q : Comment détecter ce qui a changé entre deux téléchargements ?
R : Normalisez la colonne domain, puis comparez les deux instantanés sur cette colonne. Les lignes présentes uniquement dans le fichier le plus récent sont des apparitions ; celles présentes uniquement dans le plus ancien, des disparitions ; celles présentes dans les deux avec un champ modifié, des migrations. La commande comm gère la comparaison d'ensembles, et une jointure SQL la détection des changements au niveau d'un champ.

Conclusion

Le domain listening n'est pas une fonctionnalité produit, c'est une habitude : téléchargez le même package selon un calendrier régulier, gardez chaque copie et comparez-les. Le format de téléchargement dépend du package et figure sur la page produit. Ce que vous obtenez en retour, c'est une mesure du web qui ne dépend ni des statistiques publiées par qui que ce soit, ni d'un protocole de requête soumis à des limites de débit.

Choisissez la population qui vous intéresse, prenez le premier instantané et lancez le chronomètre.

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

Partager cet article

Articles associés

Commentaires (0)

Laisser un commentaire

Aucun commentaire pour le moment. Soyez le premier à commenter !

support_agent
WebTrackly Support
Usually replies within minutes
Bonjour !
Envoyez-nous un message, nous vous répondrons au plus vite.