--- id: "epp-status-codes" kind: "glossary-term" title: "codes de statut EPP" language: "fr" category: "Transferts et EPP" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/fr/glossaire/codes-statut-epp/" translations: en: "https://tldlog.com/glossary/epp-status-codes/" es: "https://tldlog.com/es/glosario/codigos-estado-epp/" de: "https://tldlog.com/de/glossar/epp-statuscodes/" it: "https://tldlog.com/it/glossario/codici-stato-epp/" pt-BR: "https://tldlog.com/pt/glossario/codigos-status-epp/" ru: "https://tldlog.com/ru/glossariy/kody-statusov-epp/" zh-Hans: "https://tldlog.com/zh/cihui/epp-zhuangtaima/" --- # codes de statut EPP Libellés standard d'un nom de domaine qui indiquent son état et les actions autorisées, comme le transfert, la mise à jour, le renouvellement ou la suppression. Les codes qui commencent par client sont fixés par le bureau d'enregistrement, et ceux qui commencent par server par le registre. Ils apparaissent dans les résultats RDAP. Tout nom de domaine porte au moins un code de statut : une courte étiquette, comme ok ou clientTransferProhibited, qui indique dans quel état se trouve l'enregistrement et quelles actions sont bloquées. Ces codes viennent d'EPP, le langage standard que les bureaux d'enregistrement utilisent pour communiquer avec les registres. Les lire permet de comprendre pourquoi un domaine a cessé de fonctionner, s'il est protégé contre le vol et s'il approche de la suppression. ## Ce que sont les codes de statut et où les consulter Les codes sont définis dans la norme EPP pour les noms de domaine, la RFC 5731, et dans son extension sur les périodes de grâce, la RFC 3915, qui ajoute les codes de la période de grâce de rédemption (RGP). Pour les gTLD, l'endroit où vérifier est une recherche RDAP, comme ICANN Lookup ou l'outil de recherche d'un bureau d'enregistrement. Depuis le 28 janvier 2025, le RDAP a remplacé le WHOIS comme source de référence des données d'enregistrement des gTLD (en octobre 2026). Le RDAP écrit les codes en mots minuscules séparés par des espaces : clientTransferProhibited apparaît ainsi sous la forme « client transfer prohibited », et ok sous la forme « active ». Les bureaux d'enregistrement doivent afficher tous les statuts qui s'appliquent à un domaine. Les ccTLD fixent leurs propres règles et peuvent présenter les statuts différemment. Cette fiche suit EPP et les politiques applicables aux gTLD. ## Codes client et codes server : qui les a posés Le premier mot d'un code indique qui l'a posé. - Les codes qui commencent par client sont posés par le bureau d'enregistrement qui gère le domaine, parfois automatiquement à l'enregistrement, parfois à la demande du titulaire. - Les codes qui commencent par server sont posés par le registre. Ils priment : un bureau d'enregistrement ne peut pas modifier un code server, alors qu'un registre peut passer outre un code client en vertu de ses propres politiques. - Les codes sans préfixe, comme ok, inactive et les codes pending, sont gérés par le registre. Dans les deux cas, le titulaire s'adresse au bureau d'enregistrement. Pour un code server, le bureau d'enregistrement transmet la demande au registre, si bien que le retrait prend généralement plus de temps. ## Codes de verrouillage : ce qui est bloqué et pourquoi Quatre paires de codes bloquent chacune une action. Tant que l'un d'eux est posé, le registre rejette la demande correspondante : - clientTransferProhibited et serverTransferProhibited : un transfert vers un autre bureau d'enregistrement. - clientUpdateProhibited et serverUpdateProhibited : les modifications du domaine, comme les contacts ou les serveurs de noms, à part le retrait du verrou lui-même. - clientDeleteProhibited et serverDeleteProhibited : la suppression. - clientRenewProhibited et serverRenewProhibited : le renouvellement. Les verrous client de transfert, de modification et de suppression aident à se protéger contre le détournement et la fraude. Les verrous de renouvellement sont rares : ils apparaissent généralement lors de litiges juridiques ou avant une suppression. Pour les gTLD, la Politique de transfert de l'ICANN (Transfer Policy), dans sa version publiée le 21 février 2024 et en vigueur en octobre 2026, encadre clientTransferProhibited. Si le bureau d'enregistrement ne propose aucun moyen en libre-service de le retirer, il doit le retirer dans les cinq jours calendaires suivant la demande du titulaire, et il ne peut pas refuser au seul motif d'un litige de paiement. En octobre 2026, des modifications de la Politique de transfert ont été adoptées mais ne sont pas en vigueur. Le Conseil d'administration de l'ICANN les a adoptées le 7 juin 2026 (résolution 2026.06.07.04), et aucune date d'entrée en vigueur n'a été annoncée. Elles comprennent une restriction obligatoire des transferts pendant les 720 premières heures (30 jours) suivant l'enregistrement. Le bureau d'enregistrement peut confirmer quelles règles s'appliquent. Les verrous server sont peu courants. L'ICANN cite comme motifs habituels les litiges juridiques, la demande du titulaire lui-même et un domaine en redemptionPeriod. Certains registres proposent un service de verrouillage au niveau du registre (registry lock), demandé par l'intermédiaire du bureau d'enregistrement, qui utilise les codes server comme protection supplémentaire. ## Codes de suspension : pourquoi un domaine cesse de fonctionner clientHold et serverHold demandent au registre de ne pas publier la délégation du domaine dans le DNS. Le site web et la messagerie cessent de fonctionner, mais le domaine reste enregistré. clientHold est peu courant. Les documents de l'ICANN le relient au non-paiement, aux litiges juridiques, à une suppression en cours, à des coordonnées non vérifiées et à la lutte contre l'utilisation malveillante du DNS. serverHold est posé par le registre ; les recommandations de conformité de l'ICANN indiquent que les registres devraient en général renvoyer d'abord les cas d'abus au bureau d'enregistrement. Deux autres situations se ressemblent : - inactive : aucun serveur de noms n'est associé, donc le domaine ne se résout pas, mais l'enregistrement est en règle. Si cela dure plusieurs jours, l'ICANN conseille de contacter le bureau d'enregistrement ; certains TLD exigent d'abord des documents. - L'expiration : après l'expiration, le bureau d'enregistrement doit empêcher la résolution du domaine pendant une partie du temps où le titulaire peut encore renouveler, lorsque le registre le permet. Le domaine peut n'afficher aucun code de suspension. ## Codes en attente et codes de période de grâce Les codes en attente (pendingCreate, pendingUpdate, pendingRenew, pendingTransfer et pendingDelete) signifient qu'une demande a été reçue mais n'est pas terminée. Pendant une période sunrise, pendingCreate peut signifier que le nom sera attribué à la fin de cette période. Les codes de période de grâce (addPeriod, renewPeriod, autoRenewPeriod et transferPeriod) sont informatifs. Si le bureau d'enregistrement supprime le domaine pendant l'une de ces périodes, le registre lui accorde un crédit correspondant au coût de l'enregistrement, du renouvellement ou du transfert. Le crédit va au bureau d'enregistrement, pas au titulaire. Chaque registre fixe la durée de chaque période de grâce. La suppression suit ces étapes dans les gTLD (en octobre 2026) : 1. Le bureau d'enregistrement supprime le domaine. Le statut EPP devient pendingDelete et le statut RGP devient redemptionPeriod, qui dure 30 jours, sauf dans les gTLD parrainés. Le domaine ne se résout pas et ne peut pas être transféré. 2. Si le bureau d'enregistrement demande une restauration, le statut devient pendingRestore pendant que le registre attend un rapport de restauration, un délai que l'ICANN décrit comme étant souvent de sept jours. Si le rapport arrive, le domaine revient à ok ou à son statut antérieur. Sinon, il repasse en redemptionPeriod. 3. Si le domaine n'est pas restauré, il reste en pendingDelete pendant cinq jours calendaires après la fin de redemptionPeriod, puis il est retiré de la base de données du registre et devient disponible à l'enregistrement. ## Que faire face à un statut inattendu - Rechercher le domaine dans ICANN Lookup, noter s'il s'agit d'un code client ou server, et contacter le bureau d'enregistrement. Pour les codes server, c'est le bureau d'enregistrement qui traite avec le registre. - pendingTransfer ou pendingUpdate non demandé par le titulaire : contacter immédiatement le bureau d'enregistrement et, s'il s'agit d'un transfert, lui demander de refuser la demande. - redemptionPeriod : contacter sans attendre le bureau d'enregistrement pour examiner les options. Pour un cas précis, le titulaire doit se renseigner auprès du bureau d'enregistrement, du registre ou d'un avocat. Un exemple concret : ICANN Lookup affiche example.com comme « client transfer prohibited », et le titulaire veut changer de bureau d'enregistrement. Il retire le verrou dans son compte ou demande au bureau d'enregistrement de le retirer. Une fois le transfert demandé, le domaine affiche pendingTransfer ; si le bureau d'enregistrement actuel ne répond pas dans les cinq jours calendaires, le registre finalise le transfert. Ensuite, le domaine peut afficher transferPeriod, ce qui ne demande aucune action. ## Sources - [EPP Status Codes | What Do They Mean, and Why Should I Know?](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) - [Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [Approved Resolutions | Regular Meeting of the ICANN Board | 7 June 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-06-2026-en) - [Expired Registration Recovery Policy](https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-28-02-2013-en) ## termes associés - [EPP](https://tldlog.com/fr/glossaire/epp/) - [clientHold](https://tldlog.com/fr/glossaire/clienthold/) - [serverHold](https://tldlog.com/fr/glossaire/serverhold/) - [clientTransferProhibited](https://tldlog.com/fr/glossaire/clienttransferprohibited/) - [RDAP](https://tldlog.com/fr/glossaire/rdap/)