À qui appartiennent les domaines .com ? Comprendre les données d'enregistrement .com

"Qui possède .com" est une seule question qui appelle deux réponses très différentes. Au niveau du registre, la réponse est précise et publique : .com est exploité par Verisign dans le cadre d'un contrat avec l'ICANN, et le registre publie un fichier de zone recensant les domaines qui existent. Au niveau du titulaire individuel, la réponse est en grande partie indisponible : depuis le RGPD, la plupart des enregistrements WHOIS en .com sont masqués. Cet article explique ce que contiennent réellement les données d'enregistrement .com, ce que l'on peut en tirer ou non, et ce que propose WebTrackly — des jeux de données de zones et d'enrichissement téléchargeables, dont 163,422,083 domaines .com.

TL;DR / À retenir

• Registre et bureau d'enregistrement : Verisign exploite le registre .com ; des bureaux d'enregistrement comme GoDaddy ou Namecheap vendent et gèrent les enregistrements. Les données du titulaire sont détenues par le bureau d'enregistrement, pas dans le fichier de zone.
• Le fichier de zone répond à "ce qui existe" : il recense les domaines délégués et leurs serveurs de noms — ni noms, ni adresses, ni contacts.
• WHOIS ne répond plus à "qui" : les coordonnées du titulaire d'un .com sont masquées par défaut pour des raisons de confidentialité ; une recherche de propriété domaine par domaine à grande échelle n'est donc pas réaliste.
• L'enrichissement répond à "ce que le site fait tourner et où il est hébergé" : les enregistrements NS et MX, l'IP et le CMS détecté sont dérivés des réponses DNS et HTTP, et constituent le substitut concret aux données de propriété.
• Ce que propose WebTrackly : Le format de téléchargement dépend du package et figure sur la page produit. La seule zone .com représente 163,422,083 domaines.
• Ce qu'il ne propose pas : aucun contact personnel, aucune donnée d'intention, aucune recherche domaine par domaine, aucune recherche technologique interactive.

Sommaire

• Qui possède réellement .com : registre, bureau d'enregistrement, titulaire
• Ce que publie le fichier de zone .com — et ce qu'il ne publie pas
• Pourquoi WHOIS ne répond plus à la question de la propriété
• De "ce qui existe" à "ce que ça fait tourner" : enrichissement DNS et technologique
• Ce que fournit réellement WebTrackly
  • Couverture et types de packs
  • Schéma des données et ce que les fichiers ne contiennent pas
• Exploiter les données : acheter, télécharger, traiter en local
• L'API : un catalogue de packs
• Erreurs fréquentes dans l'exploitation des données de domaines
• Foire aux questions (FAQ)
• Conclusion
• Ressources associées

Qui possède réellement .com : registre, bureau d'enregistrement, titulaire

Trois parties distinctes interviennent dans chaque domaine .com, et les confondre est à l'origine de la plupart des idées fausses sur les données de domaines.

• Le registre exploite le TLD lui-même. Pour .com, il s'agit de Verisign, dans le cadre d'un contrat de registre avec l'ICANN. Le registre tient la base de données faisant autorité sur les noms .com délégués et sur les serveurs de noms vers lesquels ils pointent, et il exploite l'infrastructure DNS faisant autorité pour la zone.
• Le bureau d'enregistrement est la société accréditée qui vend un enregistrement à un client final — GoDaddy, Namecheap, Tucows, Cloudflare et des centaines d'autres. C'est lui qui détient la relation client, les informations de facturation et la fiche de contact du titulaire.
• Le titulaire est la personne ou l'organisation qui détient le droit d'usage du nom pendant la durée de l'enregistrement. Personne ne "possède" un domaine à proprement parler : un enregistrement est un droit renouvelable, pas une propriété pleine et entière.

Cette répartition a des conséquences très concrètes. Le registre peut vous dire, de façon exhaustive, quels noms existent. Il ne peut pas vous dire qui se trouve derrière, car il ne détient jamais cette information sous une forme qu'il publie. Le bureau d'enregistrement détient l'identité du titulaire, mais ne la diffuse que via WHOIS/RDAP, sous réserve du masquage pour confidentialité.

Ce que publie le fichier de zone .com — et ce qu'il ne publie pas

Un fichier de zone est la liste des délégations DNS d'un domaine de premier niveau. Pour .com, il énumère chaque nom de deuxième niveau doté de serveurs de noms actifs, ainsi que les enregistrements NS qui le délèguent et les enregistrements glue A/AAAA lorsque ces serveurs de noms se situent à l'intérieur de la zone elle-même. L'accès aux fichiers de zone des registres de gTLD passe par le Centralized Zone Data Service de l'ICANN, réservé aux parties approuvées.

Ce qu'un fichier de zone vous apporte :

• L'ensemble complet des noms délégués sous le TLD — ce qui existe de plus proche d'un recensement du web au niveau du nommage.
• Les serveurs de noms auxquels chaque domaine est délégué, signal fort du fournisseur DNS et souvent de la plateforme d'hébergement derrière le site.
• Une base fiable pour la comparaison : les noms qui apparaissent ou disparaissent entre deux instantanés.

Ce qu'un fichier de zone ne vous apporte pas :

• Les noms des titulaires, leur organisation, leur adresse postale ou toute autre coordonnée.
• Les dates d'enregistrement ou d'expiration — elles proviennent du service WHOIS/RDAP du registre, et seuls certains registres les publient en masse.
• Les noms enregistrés sans serveur de noms configuré. Un domaine peut être enregistré sans être délégué ; il sera alors simplement absent de la zone.
• Toute information sur le contenu, le modèle économique ou la taille du site.

Autrement dit, le fichier de zone répond à "ce qui existe", et de façon exceptionnellement complète. Il ne répond pas — et n'a jamais été conçu pour répondre — à "qui le possède".

Pourquoi WHOIS ne répond plus à la question de la propriété

La réponse traditionnelle à "qui possède le domaine .com X" était une requête WHOIS : une interrogation de la base du bureau d'enregistrement ou du registre renvoyant le nom du titulaire, son organisation, son adresse postale et les dates d'enregistrement. Cette réponse a largement cessé de fonctionner.

• Masquage pour confidentialité. Depuis le RGPD, bureaux d'enregistrement et registres masquent par défaut les champs de contact du titulaire pour la plupart des domaines. Une réponse WHOIS .com typique affiche aujourd'hui le bureau d'enregistrement, les codes de statut, les serveurs de noms et les dates — et "REDACTED FOR PRIVACY" à la place de l'identité.
• Services de confidentialité et de proxy. Lorsqu'un enregistrement n'est pas masqué, le nom est fréquemment enregistré via un service de proxy : le titulaire visible est alors le prestataire de proxy.
• Limites de débit. Les points d'accès WHOIS et RDAP sont conçus pour des recherches ponctuelles à l'unité. Interroger des millions de noms n'est ni autorisé ni praticable.
• Obsolescence. Les fiches de titulaires sont déclaratives et ne sont souvent jamais mises à jour après l'enregistrement initial.

Les alternatives plus anciennes ne valent pas mieux. Les recherches manuelles ne passent pas à l'échelle et sont soumises à des limites de débit ; le scraping sur mesure est gourmand en ressources, fragile et juridiquement ambigu ; et les listes statiques achetées se périment vite, sans provenance vérifiable.

Le constat honnête : identifier la propriété domaine par domaine à grande échelle n'est plus quelque chose que les données publiques permettent. Ce qui reste disponible, et réellement utile, ce sont les données d'infrastructure et de technologie.

De "ce qui existe" à "ce que ça fait tourner" : enrichissement DNS et technologique

Si la propriété est fermée, la couche observable, elle, reste ouverte. Tout site actif répond aux requêtes DNS et HTTP, et ces réponses décrivent la stack :

• Les enregistrements NS identifient l'opérateur DNS — souvent une plateforme d'hébergement, un CDN ou un hébergeur WordPress infogéré.
• Les enregistrements MX identifient la plateforme de messagerie : Google Workspace, Microsoft 365, la messagerie par défaut d'un hébergeur, ou rien du tout. Un domaine sans enregistrement MX est fréquemment parqué ou inactif.
• Les enregistrements A/AAAA résolvent vers une IP, qui correspond à un ASN et donc à un hébergeur, une région cloud ou un point de présence CDN.
• Les réponses HTTP exposent les empreintes du CMS et de la plateforme — balises meta generator, chemins caractéristiques, noms de cookies, motifs d'en-têtes.

Rien de tout cela n'est une donnée personnelle. Il s'agit d'une description d'infrastructure, pas de personnes — ce qui explique précisément pourquoi ces informations peuvent être compilées et distribuées en masse, contrairement à l'identité WHOIS.

Ce que fournit réellement WebTrackly

WebTrackly n'est pas un moteur de recherche sur des personnes. C'est un catalogue de jeux de données téléchargeables, construits à partir des données de zone et de l'enrichissement d'infrastructure.

Couverture et types de packs

Le catalogue compte actuellement 1,538 packs :

• 716 fichiers de zone TLD — les listes brutes de domaines, une par domaine de premier niveau.
• 716 ensembles enrichis par zone — les mêmes zones, avec NS, MX, IP et CMS détecté.
• 79 listes de sites par CMS ou technologie — par exemple toutes les installations WordPress ou Joomla détectées.
• 27 jeux de données curés — des compilations inter-zones, comme la liste complète des domaines enregistrés.

Chiffres de couverture clés :

Schéma des données et ce que les fichiers ne contiennent pas

Un pack de zone enrichie est un CSV comportant, par ligne :

• domain — le nom enregistré.
• registration_date — lorsque le registre la publie ; vide pour les registres qui ne le font pas.
• ns — les serveurs de noms délégués.
• mx — les serveurs de messagerie, lorsqu'ils existent.
• ip — l'adresse résolue de l'enregistrement apex.
• cms — le système de gestion de contenu ou la plateforme détectée, lorsqu'elle est identifiée.

Pour le dire simplement, les fichiers ne contiennent aucun contact personnel : ni personnes nommées, ni fiches de contact d'entreprise, ni signaux comportementaux ou d'intention. Il n'existe pas d'outil de recherche domaine par domaine, ni de recherche technologique interactive. Ce que vous obtenez, c'est le fichier en masse ; tout ce que vous en faites ensuite se passe sur votre propre machine.

Exploiter les données : acheter, télécharger, traiter en local

Le parcours est volontairement simple et tient en quatre étapes.

1. Choisissez un pack dans le catalogue, ou rendez-vous directement sur les fichiers de zone par TLD, les données de domaines ou les jeux de données curés.
2. Achetez-le. Les achats à l'unité démarrent à $3.50. Des abonnements sont disponibles : Pro à $29/mois inclut 50 packs, 10 jeux de données et 30,000 appels API ; Enterprise à $99/mois inclut 200 packs, 50 jeux de données et 300,000 appels API. Voir les tarifs.
3. Téléchargez. Le format de téléchargement dépend du package et figure sur la page produit.
4. Traitez-le en local. Ce sont de gros fichiers plats, que l'outillage en ligne de commande et analytique standard gère très bien.

Un fichier à l'échelle de .com est bien trop volumineux pour un tableur : commencez donc en ligne de commande :

unzip com_zone_enriched.zip
wc -l com_zone_enriched.csv
head -3 com_zone_enriched.csv

# domains delegated to Cloudflare name servers
grep -i 'ns\.cloudflare\.com' com_zone_enriched.csv > cloudflare.csv

# how many use Google Workspace for mail
grep -ic 'aspmx\.l\.google\.com' com_zone_enriched.csv

Pour tout traitement analytique, chargez le CSV dans DuckDB ou ClickHouse plutôt que dans une base transactionnelle généraliste — les deux lisent le CSV directement et gèrent des centaines de millions de lignes sur une seule machine :

-- DuckDB
CREATE TABLE com AS SELECT * FROM read_csv_auto('com_zone_enriched.csv');

SELECT cms, count(*) AS sites
FROM com
WHERE cms IS NOT NULL
GROUP BY cms
ORDER BY sites DESC
LIMIT 20;

-- share of the zone that resolves at all
SELECT count(*) FILTER (WHERE ip IS NOT NULL) AS resolving,
       count(*)                                AS total
FROM com;

Comme chaque achat régénère l'export, comparer un ancien téléchargement à un plus récent vous donne directement le différentiel des noms apparus et disparus, ou des migrations de plateforme au sein d'une zone.

L'API : un catalogue de packs

L'API expose le catalogue — quels packs existent, ce qu'ils couvrent et comment les récupérer. Ce n'est pas un point d'accès de recherche de domaines, car il n'y a aucun produit de recherche domaine par domaine derrière. Toutes les requêtes sont authentifiées par un jeton bearer.

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

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

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

La même chose en Python — lister les packs technologiques correspondant à un mot-clé, puis en inspecter un avant l'achat :

import requests

API = "https://webtrackly.com/api/v1"
headers = {"Authorization": "Bearer YOUR_API_KEY"}

# 1. find technology packages matching a keyword
resp = requests.get(f"{API}/packages/",
                    params={"type": "technology", "q": "wordpress"},
                    headers=headers)
packages = resp.json()

for pkg in packages["results"]:
    print(pkg["slug"], pkg["name"])

# 2. inspect a single package
slug = packages["results"][0]["slug"]
detail = requests.get(f"{API}/packages/{slug}/", headers=headers).json()
print(detail["slug"], detail.get("rows"), detail.get("price"))

La documentation des points d'accès se trouve sur /api/. Les quotas d'appels suivent la formule : 30,000 par mois en Pro, 300,000 en Enterprise.

Erreurs fréquentes dans l'exploitation des données de domaines

1. Erreur : attendre de WHOIS qu'il identifie le propriétaire

   • Ce qui se passe mal : un workflow est conçu autour de la récupération des noms de titulaires pour une liste de domaines. Il fonctionne sur une poignée d'enregistrements anciens, puis s'effondre.
   • Pourquoi ça échoue : la plupart des champs titulaire en .com sont masqués, de nombreux noms passent par un proxy, et les requêtes en masse sont soumises à des limites de débit.
   • La solution : s'appuyer plutôt sur les signaux d'infrastructure — serveurs de noms, plateforme de messagerie, IP d'hébergement et CMS détecté. Ils sont observables, cohérents et disponibles en masse.

2. Erreur : prendre un fichier de zone pour une liste de sites actifs

   • Ce qui se passe mal : un décompte de noms délégués est présenté comme un décompte de sites actifs.
   • Pourquoi ça échoue : une large part des domaines délégués sont parqués, redirigés ou enregistrés à titre défensif, sans aucun contenu.
   • La solution : filtrer sur les colonnes d'enrichissement. Exiger une IP qui résout, un enregistrement MX ou un CMS détecté ramène une zone à quelque chose de bien plus proche des sites réellement en activité.

3. Erreur : supposer qu'un instantané reste exact

   • Ce qui se passe mal : un fichier téléchargé il y a des mois est traité comme s'il était à jour.
   • Pourquoi ça échoue : les domaines sont enregistrés et abandonnés en continu, et les migrations de plateforme ou d'hébergement sont permanentes.
   • La solution : retélécharger dès que la fraîcheur compte. Les exports sont générés au moment de l'achat : un nouveau téléchargement est donc un nouvel instantané — et deux instantanés vous donnent un différentiel.

4. Erreur : charger des centaines de millions de lignes dans le mauvais outil

   • Ce qui se passe mal : le CSV est ouvert dans un tableur, ou importé ligne à ligne dans une base transactionnelle.
   • Pourquoi ça échoue : les tableurs saturent bien avant l'échelle de .com, et les insertions ligne à ligne prennent des heures pour des agrégations qu'un moteur colonnaire traite en quelques secondes.
   • La solution : utiliser le traitement en flux en ligne de commande pour filtrer, et DuckDB ou ClickHouse pour agréger. Les deux lisent le CSV nativement.

5. Erreur : prendre la détection de CMS pour une certitude

   • Ce qui se passe mal : une plateforme détectée est traitée comme un fait vérifié sur une entreprise.
   • Pourquoi ça échoue : la détection repose sur des empreintes. Les configurations headless, la mise en cache agressive, les CDN et les développements sur mesure peuvent masquer ou imiter une plateforme.
   • La solution : traiter la colonne CMS comme un signal fort pour la segmentation et le dimensionnement de marché, et vérifier au cas par cas avant d'agir sur un enregistrement isolé.

6. Erreur : négliger les aspects juridiques et éthiques

   • Ce qui se passe mal : acquérir et utiliser des données sans maîtriser les réglementations sur la vie privée (RGPD, CCPA) ni les conditions d'utilisation. Cela peut entraîner des problèmes juridiques, une atteinte à la réputation et des suspensions de compte.
   • Pourquoi ça échoue : l'ignorance n'est pas une défense. La protection des données est une préoccupation sérieuse partout dans le monde, et les entreprises sont tenues responsables de la manière dont elles collectent et utilisent les données personnelles.
   • La solution : respecter systématiquement le cadre légal. Les jeux de données décrits ici contiennent des données d'infrastructure publiquement observables et aucun contact personnel, ce qui place les données elles-mêmes hors du champ de la plupart des règles sur les données personnelles — mais ce que vous y associez, et la façon dont vous les exploitez, reste sous votre responsabilité.

Foire aux questions (FAQ)

Q : Ces données me permettent-elles de savoir à qui appartient un domaine .com précis ?
R : Non. L'identité du titulaire d'un .com est masquée dans WHOIS pour la grande majorité des domaines, et elle ne fait partie ni des données de zone ni des données d'enrichissement. Ce que les données vous disent, c'est qu'un domaine existe, où il est délégué, où il résout, quelle plateforme de messagerie il utilise et quel CMS il semble faire tourner.

Q : Que reçois-je exactement lorsque j'achète un pack ?
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 actuel du jeu de données, et non un fichier préconstruit d'âge inconnu.

Q : Les fichiers contiennent-ils des coordonnées personnelles ?
R : Non. Les données ne contiennent aucun contact personnel, d'aucune sorte. Les colonnes sont : domaine, date d'enregistrement lorsque le registre la publie, serveurs de noms, enregistrements MX, IP et CMS détecté.

Q : Quelle part de l'espace de noms .com est couverte ?
R : Le pack de la zone .com couvre 163,422,083 domaines. Sur l'ensemble des 716 zones, le total atteint 285,582,781 domaines, et le jeu de données curé de tous les domaines enregistrés compte 272,614,863 lignes.

Q : Existe-t-il une interface permettant de filtrer les domaines par technologie ?
R : Il n'y a pas d'interface de filtrage interactive. Le catalogue est organisé en packs prêts à l'emploi — fichiers par zone, ensembles enrichis par zone, listes de sites par technologie et jeux de données curés — et le filtrage se fait de votre côté, une fois le CSV téléchargé.

Q : À quoi sert l'API ?
R : Elle sert le catalogue : lister les packs par type, les rechercher par mot-clé et renvoyer le détail d'un pack donné. Les points d'accès sont GET /api/v1/packages/?type=zone, GET /api/v1/packages/?type=technology&q=wordpress et GET /api/v1/packages/{slug}/, authentifiés avec un en-tête Authorization: Bearer.

Q : Combien coûtent les formules ?
R : Les packs individuels s'achètent à l'unité à partir de $3.50. Pro coûte $29/mois et inclut 50 packs, 10 jeux de données et 30,000 appels API. Enterprise coûte $99/mois et inclut 200 packs, 50 jeux de données et 300,000 appels API. Tous les détails figurent sur la page tarifs.

Q : Pourquoi certaines lignes n'ont-elles pas de date d'enregistrement ?
R : Parce que tous les registres ne publient pas les dates d'enregistrement sous une forme compilable en masse. Lorsque le registre la publie, le champ est renseigné ; sinon, il est laissé vide plutôt qu'estimé.

Conclusion

La question "qui possède .com" appelle une réponse institutionnelle nette — Verisign exploite le registre, des bureaux d'enregistrement accrédités vendent les noms, les titulaires détiennent des droits à durée limitée — et une réponse individuelle largement fermée, puisque l'identité du titulaire est masquée par défaut. Exploiter utilement les données .com suppose de l'accepter et de déplacer légèrement la question : non pas qui se trouve derrière un domaine, mais ce qui existe et ce que ça fait tourner.

Le format de téléchargement dépend du package et figure sur la page produit. Commencez par le catalogue de packs ou la liste des fichiers de zone.

Ressources associées

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