Gestion des noms de domaine pour agences : propriété, accès et renouvellements sans panne à 2 heures du matin

Comment les agences doivent gérer les domaines de leurs clients : à qui doit appartenir l'enregistrement, les modèles d'accès qui fonctionnent, un journal des modifications DNS, les règles de transfert qui piègent, un calendrier de renouvellement, une liste de passation et un modèle de registre pour chaque domaine que vous touchez.

Les agences perdent rarement un client à cause du design. Elles le perdent à cause d'un site tombé un samedi parce qu'un domaine a expiré sur une carte résiliée, d'un enregistrement DNS que personne ne se souvient d'avoir modifié, ou d'un identifiant de registraire appartenant à un designer parti en 2021. Les domaines sont une petite partie ennuyeuse du travail, au rayon d'impact inhabituellement large. Ce guide présente un modèle de propriété, des règles d'accès, les pièges des transferts et les routines qui empêchent les domaines de mettre fin à une relation client.

Règle numéro un : le domaine appartient au client

Le titulaire d'un domaine, la personne ou l'organisation nommée dans l'enregistrement, en est le détenteur légal. Si votre agence enregistre le domaine d'un client à son propre nom, c'est vous qui détenez l'adresse de sa marque. C'est pratique jusqu'à la fin de la relation, quand le client croit que vous le tenez en otage, ou jusqu'au jour où c'est votre agence qui change de mains.

Le modèle qui vieillit le mieux :

Titulaire : l'entité juridique du client, avec une adresse e-mail générique qu'il contrôle ([email protected], pas la boîte d'une personne).
Compte chez le registraire : détenu par le client, avec votre agence ajoutée comme délégué ou membre d'équipe si le registraire le permet.
Facturation : la carte du client, ou la vôtre avec une refacturation écrite, mais jamais la carte personnelle d'un employé.
DNS : géré là où c'est le plus logique sur le plan opérationnel, souvent chez vous, mais documenté pour que n'importe qui puisse reprendre la main.

Certains petits clients insisteront pour que vous « vous en occupiez ». Vous le pouvez, tant que l'enregistrement est à leur nom et que votre contrat précise que le domaine leur appartient et que vous le transférerez à leur demande.

Quatre modèles d'accès comparés

Modèle	Fonctionnement	Adapté à	Risque
Compte du client, agence déléguée	Le client détient le compte chez le registraire ; vous avez votre propre identifiant avec des permissions.	La plupart des clients	Tous les registraires ne proposent pas l'accès délégué ; vérifiez avant de commencer.
Compte du client, identifiants partagés	On vous donne l'identifiant du client.	Personne, idéalement	Aucune traçabilité, double authentification cassée, et le personnel part avec le mot de passe.
Compte revendeur de l'agence, client titulaire	Vous enregistrez via votre propre compte revendeur ou agence, avec le client comme titulaire.	Les agences qui ont beaucoup de petits clients	Le client ne peut pas se connecter lui-même ; les transferts sortants dépendent de votre réactivité.
Le client garde le registraire, seul le DNS est délégué	Le client fait pointer ses serveurs de noms vers un hébergeur DNS que vous gérez.	Les grands clients dotés d'une équipe informatique	Deux parties à coordonner à chaque changement.

Quel que soit votre choix, activez la double authentification sur chaque compte de registraire et conservez les codes de récupération dans votre gestionnaire de mots de passe, dans un coffre partagé et non celui d'une personne.

Les règles de transfert qui piègent les agences

La politique de transfert de l'ICANN fixe les règles pour déplacer les domaines génériques de premier niveau (.com, .net, .org et autres) d'un registraire à un autre. Les domaines nationaux (.ca, .co.uk, .de) suivent les règles de leur propre registre ; vérifiez-les un par un.

60 jours après un enregistrement ou un transfert. Un registraire peut refuser un transfert demandé dans les 60 jours suivant la création du domaine, ou dans les 60 jours suivant un précédent transfert de registraire. Ne planifiez pas la migration d'un domaine enregistré le mois dernier.
60 jours après un changement de titulaire. La politique impose un verrou de transfert de 60 jours après un changement de titulaire. Le registraire peut permettre au titulaire d'y renoncer, mais seulement avant que le changement soit demandé. Si vous faites passer un domaine au nom du client et chez un nouveau registraire, faites d'abord le transfert, ou renoncez d'abord au verrou.
Le code d'autorisation. Le registraire doit fournir le code de transfert (AuthInfo) et, lorsque le titulaire ne peut pas le générer lui-même, le fournir dans un délai de cinq jours civils suivant la demande. Il ne peut pas refuser de le communiquer au seul motif d'un litige de paiement. Les agences ne devraient pas essayer non plus ; cela détruit aussi la confiance.

L'ICANN révise ses règles de transfert : consultez la politique en vigueur et les pages d'aide de votre registraire avant une migration importante. Nos guides nom de domaine ou hébergement et connecter un domaine personnalisé couvrent les bases pour les clients qui découvrent le sujet.

DNS : notez chaque modification

La plupart des incidents de domaine ne sont pas des expirations ; ce sont des modifications DNS. Quelqu'un ajoute un enregistrement de messagerie pour un nouvel outil d'e-mail et casse l'ancien. Quelqu'un change l'enregistrement A pendant un lancement et oublie la version www. Tenez un journal des modifications par domaine, même sous forme de tableur :

Date	Domaine	Enregistrement	Ancienne valeur	Nouvelle valeur	Pourquoi	Qui	Vérifié par
2026-10-02	client.com	CNAME www	old-host.example	new-host.example	Relance du site	AB	CD, chargé en données mobiles
2026-10-09	client.com	TXT (SPF)	v=spf1 include:mail-a ~all	v=spf1 include:mail-a include:mail-b ~all	Nouvel outil de newsletter	CD	AB, e-mail de test réussi

Trois habitudes évitent la plupart des pannes :

Exportez la zone avant d'y toucher. Une copie de chaque enregistrement, datée, est votre bouton d'annulation.
Réduisez la durée de vie (TTL) la veille d'un déplacement prévu pour que les modifications s'appliquent vite, puis remontez-la ensuite.
Ne supprimez jamais les enregistrements de messagerie lors d'un changement de site. Les enregistrements MX, SPF, DKIM et DMARC concernent l'e-mail. Un lancement de site n'a pas besoin d'y toucher.

Renouvellements : un calendrier, pas un espoir

Le renouvellement automatique est nécessaire mais pas suffisant : les cartes expirent et les avis de renouvellement partent vers la personne qui a enregistré le domaine il y a des années. Tenez un calendrier de renouvellement :

90 jours avant l'expiration : confirmez que la carte enregistrée est valide et que le client veut toujours le domaine.
30 jours avant : confirmez que le renouvellement automatique est actif ; s'il est manuel, renouvelez maintenant.
Le lendemain de l'échéance : vérifiez que la date d'expiration a bien avancé. Sinon, agissez aujourd'hui. Les registraires accordent généralement un délai pour renouveler après l'expiration, mais sa durée et ses frais varient selon le registraire et l'extension, et le site comme l'e-mail peuvent cesser de fonctionner pendant ce temps.

Envisagez de renouveler vos domaines importants pour plusieurs années d'un coup. Le coût annuel est le même et cela supprime plusieurs occasions d'échec. Le renouvellement du domaine et celui d'un éventuel certificat SSL sont deux événements distincts ; la plupart des hébergeurs modernes renouvellent les certificats automatiquement, mais vérifiez que c'est le cas du vôtre.

Un registre pour chaque domaine que vous touchez

On ne gère pas ce qu'on n'a pas listé. Tenez un registre unique pour l'agence. Les colonnes qui se rentabilisent :

Domaine	Client	Titulaire (raison sociale)	Registraire	Propriétaire du compte	Accès de l'agence	Expiration	Renouvellement auto	Hébergeur DNS	Pointe vers	Fournisseur e-mail	Notes
harborbakery.example	Harbor Bakery	Harbor Bakery Ltd	Registraire A	Client	Délégué	2027-04-11	Oui	Registraire A	Plateforme du site	Google Workspace	Carte expirant en 2027-01, prévenir le client
harbor-bakery.example	Harbor Bakery	Harbor Bakery Ltd	Registraire A	Client	Délégué	2027-04-11	Oui	Registraire A	Redirection vers le principal	-	Enregistrement défensif

Révisez-le chaque mois. La révision prend dix minutes, et c'est là que vous repérez le domaine payé par la carte d'un ancien employé.

Listes d'arrivée et de départ d'un client

Quand un nouveau client arrive

Recensez tous les domaines du client, y compris les anciens domaines de campagne et les enregistrements de fautes de frappe.
Relevez pour chacun le titulaire, le registraire et la date d'expiration actuels.
Exportez la zone DNS de chacun avant toute modification.
Convenez par écrit de qui détient, qui paie et qui peut modifier le DNS.
Ajoutez chaque domaine au registre.

Quand un client part

Fournissez rapidement le code de transfert, ou retirez votre accès délégué, selon le cas.
Remettez l'export de la zone DNS et le journal des modifications.
Signalez tout enregistrement qui dépend d'un service que vous résiliez (par exemple un outil de formulaires ou votre hébergement).
Remettez-lui une copie de son site et de ses contenus. Notre plan de sortie d'un prestataire liste ce que comprend une passation équitable.
Retirez le domaine de votre registre et de votre calendrier de renouvellement.

Gérer les domaines clients sur une plateforme en marque blanche

Si vous hébergez de nombreux sites clients, la gestion des domaines de la plateforme fait partie de votre processus. Sur la plateforme en marque blanche de We.Inc, votre marque peut tourner sur votre propre domaine, et chaque site client peut être connecté à un domaine appartenant au client depuis le panneau des domaines de l'éditeur. Une option par client détermine si le client peut connecter lui-même son domaine ou si vous le faites pour lui.

Un panneau de domaine dans l'éditeur de site intitulé Donnez une vraie adresse à votre site, avec une option pour connecter un domaine que vous possédez — Le début du panneau de domaine dans l'éditeur d'un client. Le client connecte un domaine qu'il possède déjà ; l'enregistrement reste le sien.

Les réglages d'un client avec des interrupteurs pour publier, utiliser son propre domaine, voir le code et d'autres fonctions — Les options par client, dont la possibilité pour ce client de connecter son propre domaine.

L'accueil partenaire vous invite à installer votre marque sur votre propre domaine, pour que vos clients se connectent à votre adresse.

Options de déploiement montrant non publié, publier en aperçu, connecter un domaine personnalisé et exporter — Les options de publication se trouvent à côté des choix de domaine personnalisé et d'export : un lancement et un changement de domaine peuvent être planifiés ensemble.

La plateforme ne remplace ni votre registre ni votre calendrier de renouvellement : les domaines enregistrés ailleurs se renouvellent toujours ailleurs. Pour voir les réglages de domaine et de permissions sur une marque de démonstration, réservez une démo. Pour la vue d'ensemble destinée aux agences, consultez la marque blanche pour les agences.

Sources

Dernière vérification le 2026-10-25.

ICANN, Transfer Policy (restrictions de 60 jours après la création et après un transfert, verrou et renonciation lors d'un changement de titulaire, règles du code AuthInfo). L'ICANN signale une version mise à jour et une révision de la politique en cours ; vérifiez le texte en vigueur avant une migration.

Ce guide fournit des informations générales et ne constitue pas un avis juridique.

Questions fréquentes

Une agence doit-elle enregistrer les domaines de ses clients à son propre nom ?

Non. Enregistrez le domaine avec l'entité juridique du client comme titulaire, idéalement dans un compte de registraire appartenant au client où votre agence est déléguée. Cela évite les litiges à la fin de la relation.

Pourquoi ne puis-je pas transférer un domaine enregistré le mois dernier ?

La politique de transfert de l'ICANN permet à un registraire de refuser un transfert demandé dans les 60 jours suivant la création d'un domaine ou un précédent transfert de registraire. Les domaines nationaux suivent les règles de leur propre registre.

Un registraire ou une agence peut-il retenir un code de transfert pour une facture impayée ?

Selon la politique de transfert de l'ICANN, un registraire ne peut pas refuser de communiquer le code AuthInfo au seul motif d'un litige de paiement, et doit le fournir dans un délai de cinq jours civils lorsque le titulaire ne peut pas le générer.

Comment éviter que les domaines de nos clients expirent ?

Tenez un registre de tous les domaines avec leurs dates d'expiration, activez le renouvellement automatique sur une carte valide, programmez des rappels à 90 et 30 jours, et vérifiez le lendemain de l'échéance que la date a bien avancé. Renouveler les domaines importants pour plusieurs années aide.

Les clients peuvent-ils utiliser leurs propres domaines sur la plateforme en marque blanche de We.Inc ?

Oui. Un client peut connecter un domaine qu'il possède déjà depuis le panneau des domaines de l'éditeur, et une option par client détermine s'il peut le faire lui-même. Votre marque peut aussi tourner sur votre propre domaine.