Pourquoi les accès se collectent avant la première modification
Le premier réflexe d'une agence qui reprend un client est de se connecter quelque part et de corriger. C'est aussi le moment où l'on casse le plus : un enregistrement MX supprimé par erreur coupe la messagerie, un changement de serveurs de noms fait disparaître une zone que personne n'avait exportée, un renouvellement échoue parce que l'e-mail du titulaire ne répond plus.
Le client, lui, ne sait pas toujours où sont ses accès. Le domaine a été acheté par un ancien prestataire, le DNS est servi par un tiers, l'hébergement est un cPanel dont le mot de passe dort dans un message vieux de deux ans. L'agence apprend cet état réel en touchant à quelque chose, ce qui est le pire moment pour l'apprendre.
Une checklist d'onboarding fixe un ordre simple : on relève l'état public, on exporte ce qui peut l'être, on obtient les droits strictement nécessaires, on consigne le tout, et seulement ensuite on modifie. Quand le portefeuille dépasse ce qu'une personne garde en tête, ce rituel devient la seule mémoire fiable de l'agence.
Ce que l'inventaire d'accès vous évite
- La messagerie coupée — un enregistrement MX, SPF ou DKIM supprimé ou écrasé sans relevé préalable interrompt le courrier du client dans l'heure.
- La zone perdue — changer de serveurs de noms sans export complet de la zone fait disparaître des sous-domaines que personne ne se rappelait.
- Le domaine expiré — le titulaire inscrit est un ancien prestataire, et les avis de renouvellement partent vers une adresse morte.
- Le transfert bloqué — un verrou actif ou un e-mail de contact invalide empêche de valider un transfert au moment où vous en avez besoin.
- L'accès trop large — un mot de passe root transmis par e-mail reste valable des années après la fin de la mission.
- Le dossier introuvable — sans tableau d'accès, personne d'autre dans l'agence ne peut reprendre le client en cas d'absence.
Qui est propriétaire : le client reste titulaire, l'agence reçoit des accès délégués
L'objection revient à chaque onboarding : qui tient la relation et qui possède le domaine ? La réponse est la même pour tous les clients. Le client reste titulaire du domaine, c'est lui le registrant inscrit, et l'agence reçoit des accès délégués. Vous gérez la relation et les opérations courantes ; l'infrastructure d'hébergement relève de la plateforme ; le client garde la propriété de ce qui porte son nom.
Cette répartition protège les deux parties. Si la mission s'arrête, le client repart avec son domaine sans négociation. Si le client change de contact, l'agence n'est pas tenue pour responsable d'un nom qu'elle ne possédait pas.
Reste l'argument que vous entendrez : demander des accès paraît lourd. Répondez par une liste minimale et un message type (plus bas). Ne demandez que ce dont la mission a besoin, couche par couche, avec le droit le plus faible qui suffit. Le tableau ci-dessous sert de base.
Niveau de droits à demander par couche
Faites défiler le tableau
| Couche | Droit à demander | Mode de transmission |
|---|---|---|
| Registrar | Accès délégué ou contact technique, lecture du statut, déverrouillage ponctuel pour un transfert | Invitation depuis la console du registrar, jamais le compte du client partagé |
| Zone DNS | Édition des enregistrements et export complet de la zone | Compte nominatif chez le fournisseur DNS, ou délégation de zone |
| Hébergement cPanel / WHM | Compte cPanel du site ; WHM seulement si l'agence administre le serveur | Utilisateur dédié, mot de passe dans le gestionnaire partagé |
| Boîtes e-mail | Accès administrateur à la console de messagerie, sans lecture des boîtes | Compte admin dédié, jamais le mot de passe d'une boîte personnelle |
| Application (CMS) | Compte administrateur nominatif | Création d'un compte au nom de l'intervenant |
| Contact de renouvellement | Adresse de contact lue par l'agence, mode de paiement laissé au client | Alias de groupe plutôt qu'une adresse individuelle |
| Sauvegardes | Accès à la dernière sauvegarde complète | Lien ou stockage chiffré, durée de vie limitée |
Relever l'état réel avant de toucher à quoi que ce soit
Avant de demander un seul mot de passe, vous pouvez déjà lire beaucoup de choses publiquement. Lancez ces commandes depuis votre poste et conservez la sortie dans un fichier daté : c'est votre état de référence.
dig +short NS votre-domaine.com renvoie les serveurs de noms qui servent la zone, en général deux à quatre lignes. Ils disent qui tient le DNS, ce qui peut différer du registrar. dig +short A votre-domaine.com renvoie l'adresse IP du site : comparez-la à celle de l'hébergement annoncé par le client. dig +short MX votre-domaine.com renvoie une priorité suivie d'un nom de serveur ; une réponse vide signifie qu'aucun courrier n'est routé par ce domaine.
dig +short TXT votre-domaine.com affiche l'enregistrement SPF, qui commence par v=spf1, et les jetons de vérification des services tiers. La politique DMARC se lit avec dig +short TXT _dmarc.votre-domaine.com. Une clé DKIM se lit avec dig +short TXT selecteur._domainkey.votre-domaine.com, mais il faut connaître le sélecteur : il se trouve dans l'en-tête d'un message envoyé par le client.
Puis whois votre-domaine.com donne le registrar, la date d'expiration et les statuts. Pour une extension .ma, la sortie publique est plus limitée : la documentation de l'ANRT fait foi, et il ne faut pas supposer qu'elle suit les règles d'un .com.
La checklist d'onboarding, étape par étape
Identifier le titulaire et le registrar
Demandez au client le nom du titulaire du domaine et le registrar où il a été acheté, avant tout accès. Notez la réponse même si elle est approximative : elle sera comparée au whois.
Relever le DNS public
Lancez
dig +short NS,A,MXetTXTsur le domaine, puis_dmarcen TXT. Enregistrez la sortie brute dans un fichier daté du jour.Relever le whois
Exécutez
whois votre-domaine.comet recopiez le registrar, la date d'expiration, les statuts et l'e-mail de contact. Comparez avec ce que le client a annoncé.Exporter la zone complète
Depuis la console du fournisseur qui sert la zone, exportez-la en entier. Un transfert de zone AXFR est presque toujours refusé, l'export passe donc par l'interface. Mettez à part une capture des enregistrements MX, SPF, DKIM et DMARC.
Demander les accès par couche, au droit minimal
Reprenez le tableau des droits et ne demandez que ce que la mission exige : registrar, DNS, hébergement, messagerie, application.
Faire transmettre sans mot de passe en clair
Créez un coffre par client dans un gestionnaire de mots de passe partagé et faites déposer les accès dedans. Activez la double authentification sur chaque compte nominatif.
Tester chaque accès en lecture seule
Connectez-vous à chaque couche, constatez que l'accès fonctionne, puis déconnectez-vous sans rien modifier. Notez la date du test.
Consigner et planifier les échéances
Remplissez le tableau récapitulatif, puis reportez les dates d'expiration dans le suivi des renouvellements. Dans l'Espace agence ServOrbit.com, la vue portefeuille centralise ces échéances.
Lire le whois : verrou, titulaire et e-mail de contact
Le whois contient quatre informations qui décident de la suite. La première est le registrar, qui dit chez qui se trouve réellement le domaine. La deuxième est la date d'expiration : un domaine proche de l'échéance passe avant tout le reste.
La troisième est le statut. clientTransferProhibited est le verrou de transfert : le registre rejette toute demande de déplacement vers un autre registrar. Il est normal et protecteur, mais il faut demander son retrait au registrar avant un transfert. clientUpdateProhibited bloque les modifications. clientHold coupe la résolution DNS, et redemptionPeriod ou pendingDelete signalent un domaine en cours de suppression : c'est une urgence, pas un point d'onboarding. La définition de chaque statut est publiée par l'ICANN.
La quatrième est le titulaire et son e-mail de contact. Si le titulaire est un ancien prestataire ou un salarié parti, notez-le : le client doit régulariser. Un e-mail de contact mort empêche de valider un transfert ou un renouvellement, car les messages de confirmation partent vers une adresse que personne ne lit. Le code de transfert, lui, n'apparaît pas dans le whois : il se demande au registrar, et la politique de transfert de l'ICANN encadre les règles qui s'appliquent.
Transmission des accès
Aucun mot de passe par e-mail, par messagerie instantanée ou dans un ticket. Passez par un coffre partagé, un compte nominatif par intervenant et la double authentification, puis révoquez chaque accès à la fin de la mission. Un accès sans date de fin devient une dette de sécurité.
Le message type à envoyer au client
Le message doit être court et prévisible. Voici un modèle à adapter : « Bonjour, pour démarrer la mission nous avons besoin de cinq éléments : le nom du titulaire de votre domaine, l'accès à la gestion du domaine chez votre registrar, l'accès à la zone DNS, l'accès à l'hébergement et celui de la console de messagerie. Nous ne demandons que le droit nécessaire à chaque couche, et nous vous proposons de déposer les accès dans un coffre partagé que nous créons à votre nom. Vous restez titulaire du domaine, et nous ne modifions rien avant d'avoir relevé et exporté l'existant. »
Ce texte dit ce qui est demandé, pourquoi, comment transmettre et ce que le client garde. Il répond à l'objection avant qu'elle soit formulée. Envoyez-le avec le lien vers votre coffre, pas avec les accès eux-mêmes.
Tableau récapitulatif des accès
Faites défiler le tableau
| Couche | Propriétaire et droit accordé | Date et expiration |
|---|---|---|
| Registrar | Client titulaire ; accès délégué en lecture et déverrouillage | Accordé le JJ/MM ; revue au renouvellement |
| Zone DNS | Fournisseur DNS ; édition et export | Accordé le JJ/MM ; compte nominatif |
| Hébergement cPanel | Agence ; compte du site, sans accès root | Accordé le JJ/MM ; fin à la fin de mission |
| Messagerie | Client ; console admin, boîtes non lues | Accordé le JJ/MM ; fin à la fin de mission |
| Application (CMS) | Client ; compte administrateur au nom de l'intervenant | Accordé le JJ/MM ; fin à la fin de mission |
| Contact de renouvellement | Agence ; alias de groupe | Mis à jour le JJ/MM ; échéance du domaine consignée |
Dépannage : les erreurs qui reviennent à l'onboarding
status: NXDOMAIN dans la sortie de dig signifie que le nom n'existe pas dans le DNS public. Vérifiez d'abord l'orthographe, puis le whois : un domaine expiré ou en clientHold répond ainsi. Le remède se trouve chez le registrar, pas dans la zone.
status: SERVFAIL indique le plus souvent des serveurs de noms injoignables ou un DNSSEC cassé. Relancez avec dig +cd votre-domaine.com : si la réponse revient avec cette option, la validation DNSSEC est en cause, et il faut contrôler l'enregistrement DS chez le registrar.
Un whois qui répond No match for indique un nom non enregistré, ou une extension que votre client whois ne sait pas interroger. Essayez le service whois du registre concerné avant de conclure.
Une connexion cPanel refusée alors que le mot de passe est correct vient souvent du pare-feu de l'hébergeur, qui bloque l'adresse IP de l'agence après quelques essais ratés, ou d'un compte suspendu. Demandez à l'hébergeur de lever le blocage et ne multipliez pas les tentatives.
Enfin, un transfert refusé alors que tout semble prêt renvoie presque toujours à clientTransferProhibited encore actif, ou à un e-mail de contact qui ne reçoit pas la confirmation.
Faire de la checklist un geste de routine
La valeur de cette liste vient de sa répétition. Gardez-la dans votre base de connaissance, versionnez-la, et appliquez-la à l'identique à chaque client, y compris celui qui paraît simple. Après une dizaine d'onboardings, les étapes deviennent un réflexe et le tableau d'accès devient la première page du dossier client.
Une fois les accès consignés, le suivi des échéances prend le relais : l'article sur la gestion des renouvellements de domaines clients décrit les alertes à poser, et celui sur la migration d'un site WordPress détaille la suite lorsque le client change d'hébergeur. Pour choisir entre mutualisé et VPS, le dernier article lié compare les deux selon le profil du site.
Retenez l'ordre : relever, exporter, demander le droit minimal, tester en lecture, consigner, puis modifier.
