Ce que les développeurs doivent savoir avant d'acheter un nom de domaine

Acheter un nom de domaine revient à choisir trois éléments distincts : le registrar (bureau d’enregistrement) que vous payez chaque année, le fournisseur DNS qui répond aux requêtes pour ce nom, et l’hébergeur qui sert le site. Il n’est pas nécessaire que ce soit la même entreprise.

La page de paiement donne l’impression d’un achat unique. Elle affiche un seul prix attractif et un seul bouton, alors que le projet perso n’a même pas encore de README. Un an plus tard, l’e-mail de renouvellement arrive, le domaine apex ne résout toujours pas, et vous constatez que vous possédez plus de domaines que de dépôts ayant reçu des commits ce trimestre.

Ce guide explique comment acheter un nom de domaine sans ces mauvaises surprises. Il présente les trois rôles, les pièges liés aux tarifs et aux transferts à vérifier avant de payer, la migration du DNS vers Cloudflare, les enregistrements nécessaires pour Vercel, Netlify et Cloudflare Pages, ainsi qu’une règle pour faire le tri dans votre collection.

Quelle est la différence entre un registrar, un fournisseur DNS et un hébergeur ?

Le registrar détient votre enregistrement et vous facture. Le fournisseur DNS répond aux requêtes portant sur vos enregistrements. L’hébergeur sert les fichiers eux-mêmes. L’ICANN accrédite les registrars, qui enregistrent les noms auprès du registre gérant chaque TLD. Par ailleurs, les serveurs de noms que vous définissez chez le registrar indiquent au reste du monde quel fournisseur DNS fait autorité pour le domaine.

Vous pouvez vérifier qui répond pour n’importe quel domaine :

# Which nameservers are authoritative for this domain?
dig +short NS example.com

Si vous avez besoin de réviser les types d’enregistrements, consultez le guide des bases du DNS. La suite de cet article suppose que vous savez à quoi servent les enregistrements A, CNAME et NS.

Comment acheter un nom de domaine sans tomber dans les pièges habituels

Avant d’acheter, vérifiez quatre points : le prix de renouvellement, la tarification du TLD, le verrou de transfert et l’inclusion ou non de la confidentialité WHOIS. Chaque vérification prend environ trente secondes, soit moins que l’animation de confettis de la page de paiement.

Le prix de renouvellement, pas le prix au paiement. Les promotions de première année sont courantes chez les registrars, et les renouvellements coûtent souvent beaucoup plus cher. Repérez la ligne de renouvellement sur la page de tarifs ou dans le panier avant de payer.

La tarification du TLD. Les prix des .com et .net sont plafonnés par leurs accords de registre, de sorte que les hausses restent limitées et prévisibles. De nombreux gTLD plus récents, ainsi que certains TLD de code pays prisés des développeurs comme le .io, peuvent coûter cher au renouvellement, et c’est leur registre qui fixe le prix. Les domaines premium définis par le registre conservent souvent leur tarif premium à chaque renouvellement. Les domaines achetés sur le marché secondaire coûtent généralement plus cher une seule fois, puis se renouvellent au tarif standard. Pour un projet perso, les noms premium sont rarement rentables.

Le verrou de transfert. En vertu de la Transfer Policy actuelle de l’ICANN, votre registrar peut refuser de transférer un enregistrement gTLD vers un autre registrar pendant 60 jours maximum après son enregistrement. Les modifications de la Transfer Policy approuvées par le GNSO Council de l’ICANN en 2025 remplaceraient ce délai par un verrou fixe de 30 jours une fois entrées en vigueur. Les TLD de code pays fixent leurs propres règles. La modification du nom, de l’organisation ou de l’adresse e-mail du titulaire déclenche également un verrou de 60 jours selon la politique actuelle. Certains registrars vous permettent de vous soustraire à ce verrou, et ces mêmes modifications de la politique le supprimeraient.

La confidentialité WHOIS. De nombreux registrars l’incluent gratuitement, tandis que d’autres la facturent chaque année. Vérifiez dans quelle catégorie se situe le vôtre avant de vous laisser abuser par le total du panier.

Comment migrer son DNS vers Cloudflare ?

Pour migrer votre DNS vers Cloudflare, ajoutez le domaine à Cloudflare, remplacez les serveurs de noms chez votre registrar par les deux serveurs attribués par Cloudflare, puis patientez. L’enregistrement reste là où il est. Seul le DNS faisant autorité est déplacé.

1. Ajoutez le site dans Cloudflare. Deux serveurs de noms vous sont attribués.
2. Vérifiez les enregistrements importés. L’analyse automatique peut en omettre certains.
3. Si DNSSEC est activé, désactivez-le d’abord chez votre registrar. Si vous changez de serveurs de noms alors que DNSSEC est encore actif, le domaine risque de ne plus être résolu.
4. Remplacez les serveurs de noms chez votre registrar.
5. Patientez. Cela peut prendre de quelques minutes à plusieurs heures, selon les TTL et les caches des résolveurs.

Si cela ne fonctionne pas encore, votre machine conserve peut-être une réponse en cache. Interrogez directement des résolveurs publics, et consultez comment vider le cache DNS dans Chrome :

# Skip your local cache and ask public resolvers directly
dig +short NS example.com @1.1.1.1
dig +short NS example.com @8.8.8.8

Vous devriez voir les deux serveurs de noms que Cloudflare a attribués à votre zone.

Les développeurs migrent leur DNS vers Cloudflare pour trois raisons : un DNS faisant autorité gratuit et rapide, le CNAME flattening à l’apex sur toutes les offres, et un tableau de bord unique pour le DNS, Pages et le CDN (consultez les meilleurs CDN pour les applications web modernes pour voir comment ce réseau se compare aux autres).

Cloudflare Registrar vend les domaines à prix coûtant et prend en charge aussi bien les nouveaux enregistrements (depuis le tableau de bord Cloudflare) que les transferts entrants. Chaque domaine enregistré chez lui doit utiliser les serveurs de noms de Cloudflare : si vous souhaitez un autre fournisseur DNS, vous devez transférer le domaine vers un autre registrar.

Pourquoi le domaine apex ne peut-il pas être un CNAME ?

www peut être un CNAME pointant vers votre plateforme, mais pas l’apex nu (example.com). Un CNAME ne peut partager son nom avec aucun autre enregistrement selon la RFC 1034 §3.6.2 et la RFC 2181 §10.1, et l’apex de chaque zone doit contenir des enregistrements NS et SOA. C’est pourquoi cette configuration n’est pas valide :

; NOT allowed by standard DNS
example.com.   IN  NS     ns1.example-dns.net.
example.com.   IN  CNAME  <platform-target>.

Pour faire pointer un domaine apex vers Vercel ou Netlify, vous disposez de trois options :

; www points at the platform with a CNAME
www.example.com.   3600  IN  CNAME  <your-project-target-from-platform-dashboard>.

; Pick ONE for the apex:
; Option A: A record to the IP your platform documents
example.com.       3600  IN  A      192.0.2.10   ; replace with the platform's documented IP

; Option B: ALIAS / ANAME (provider-specific, not a standard record type)
; example.com.     ALIAS  <platform-target>.

; Option C: On Cloudflare, create a CNAME at "@" and Cloudflare flattens it

Pour Vercel, sa base de connaissances recommande d’utiliser l’option A à l’apex, ou bien de confier les serveurs de noms du domaine à Vercel. Vercel publie également des valeurs DNS par défaut, mais de nombreux projets reçoivent leurs propres valeurs : copiez donc celles qui figurent sur l’écran de paramètres de votre domaine. Les paramètres de domaine de Netlify indiquent de la même manière leurs propres cibles. Les enregistrements ALIAS et ANAME permettent à un apex de se comporter comme un CNAME, mais seuls certains fournisseurs DNS les proposent.

Cloudflare Pages fonctionne différemment. Pour un domaine apex sur Pages, le domaine doit être une zone Cloudflare dans le même compte que le projet Pages, avec ses serveurs de noms pointant vers Cloudflare. Un enregistrement A ou ALIAS chez un fournisseur externe ne fonctionnera pas. Un sous-domaine, en revanche, ne nécessite qu’un CNAME chez votre fournisseur DNS actuel.

Enfin, choisissez soit l’apex, soit www comme nom d’hôte canonique et redirigez l’autre vers celui-ci, afin que chaque visiteur, cookie et résultat de recherche aboutisse à une seule adresse. La documentation de Vercel suggère de faire de www le nom d’hôte principal et d’y rediriger le domaine nu. Pour vérifier la redirection :

# Expect a 301/308 from the non-canonical host to the canonical one
curl -sI http://example.com | grep -i -E '^(HTTP|location)'

Soixante domaines, trois projets

Chaque domaine se renouvelle tous les ans, qu’un projet y soit déployé ou non : une collection de noms inutilisés vous coûte donc un peu plus chaque année où vous la conservez. Ce nom acheté à 1 h du matin pour un outil CLI que vous n’avez jamais commencé continue de vous être facturé.

Fixez-vous une règle et respectez-la. Par exemple : si le dépôt n’a reçu aucun commit depuis un an, laissez le domaine expirer. Une fois par an, exportez vos domaines et leurs dates d’expiration depuis le tableau de bord du registrar et comparez-les à vos dépôts. N’activez le renouvellement automatique que pour les domaines qui vous manqueraient, c’est-à-dire ceux qui hébergent un projet actif, une messagerie ou qui reçoivent des liens entrants.

Si vous regroupez vos domaines chez un même registrar, n’oubliez pas que chaque transfert déclenche un nouveau verrou : vous ne pouvez donc pas faire passer rapidement un domaine d’un registrar à l’autre. Planifiez vos transferts en fonction des dates de renouvellement.

Conclusion

Un nom de domaine implique trois rôles. Le registrar vous facture, les serveurs de noms déterminent qui répond aux requêtes DNS, et les enregistrements DNS pointent vers votre hébergeur. Gardez ces rôles bien distincts, et la plupart des problèmes de configuration deviennent plus faciles à comprendre, y compris la règle du CNAME à l’apex. Avant votre prochain achat impulsif, lisez le prix de renouvellement. Ensuite, ouvrez le tableau de bord de votre registrar et désactivez le renouvellement automatique de chaque domaine qui ne vous manquerait pas.

FAQ

Que se passe-t-il si un domaine expire avant que je le renouvelle ?

Pour la plupart des gTLD, un domaine expiré entre d'abord dans une période de grâce de renouvellement automatique, pendant laquelle vous pouvez encore le renouveler auprès de votre registrar. Si le registrar le supprime ensuite, l'Expired Registration Recovery Policy de l'ICANN impose une Redemption Grace Period de 30 jours. Pendant cette période, la résolution DNS est désactivée et les transferts sont bloqués. Restaurer le domaine durant cette fenêtre entraîne souvent des frais de rédemption supplémentaires. Les gTLD sponsorisés et les ccTLD suivent leurs propres règles.

Est-ce que je perds la durée d'enregistrement restante lorsque je transfère un domaine vers un autre registrar ?

Non. Pour la plupart des gTLD comme .com, .net et .org, un transfert ajoute un an à la date d'expiration actuelle et ne redémarre pas la durée d'enregistrement. La plupart des registres plafonnent la durée à 10 ans : un transfert peut donc être refusé si l'année supplémentaire dépasse ce plafond. Un transfert effectué dans les 45 jours suivant le renouvellement d'un domaine expiré peut ne pas ajouter cette année. Les TLD de code pays fixent leurs propres règles.

Quelle est la différence entre le CNAME flattening et un enregistrement ALIAS ou ANAME ?

Les deux résolvent le problème de l'apex de la même manière. Le fournisseur DNS faisant autorité résout lui-même le nom d'hôte cible et répond avec des enregistrements A et AAAA, si bien que les résolveurs ne voient jamais de CNAME. Cloudflare appelle cela le CNAME flattening, Route 53 parle d'alias record, et d'autres fournisseurs parlent d'ALIAS ou d'ANAME. Comme c'est le fournisseur qui effectue la résolution, une cible avec routage géographique peut renvoyer des adresses choisies en fonction de la localisation du fournisseur, et non de celle du visiteur.

Le changement de serveurs de noms déclenche-t-il le verrou de transfert de 60 jours ?

Non. Le verrou de changement de titulaire de l'ICANN ne s'applique que lorsque le nom, l'organisation ou l'adresse e-mail du titulaire change, et les serveurs de noms ne font pas partie des données du titulaire. Faire pointer un domaine vers Cloudflare ou tout autre fournisseur DNS ne modifie ni le registrar, ni l'enregistrement, ni la date d'expiration. Pour les gTLD, les blocages de transfert habituels sont un nouvel enregistrement, un transfert récent ou une modification de ces champs relatifs au titulaire.