Gestion des règles d'éligibilité
398 vues
10.02.2026 
Web / Nom de domaine
Pour suivre ce guide, vous devez déjà vous connecter à l'API OVHcloud. Vous trouverez plus de détails sur la page d'introduction à l'API.
Sommaire
- Introduction
- Commander un nom de domaine
- Gestion des tâches
- Gestion des contacts d'un nom de domaine
- Gestion des règles d'éligibilité
- Configurer l'affichage de ses données dans le Whois
- Configurer les DNS de son nom de domaine
- Transférer un nom de domaine
Nous vous rappelons que les liens vers les routes d'API donnés dans ce document renvoient vers l'API européenne. Pensez à remplacer https://eu.api.ovh.com par https://ca.api.ovh.com dans les URLs d'API pour pouvoir utiliser l'API avec votre identifiant.
Introduction
L'obtention et la détention d'un nom de domaine sont accompagnées d'obligations légales telles que :
- les règles d'utilisation d'un nom de domaine : un
.traveldoit nécessairement avoir un lien avec l'industrie du tourisme. - les règles d'éligibilité : l'adresse du contact titulaire d'un
.eudoit se situer au sein de l'Union Européenne.
Ces règles sont fixées par l'opérateur de l'extension, le registre, et varient selon les extensions tout en évoluant au fil du temps.
Concernant les règles d'éligibilité, elles concernent des éléments connus du registrar tels que le nom de domaine, les contacts ou encore la procédure d'enregistrement. Ces règles d'éligibilité s'appliquent :
- Sur les données du contact titulaire, administrateur et technique. Par exemple, l'adresse du titulaire doit se situer au sein de l'Union Européenne pour un nom de domaine
.eu. - Sur des données liées à la procédure de demande de création, de transfert, de changement de titulaire. Par exemple, la raison de la création d'un nom de domaine en
.frreprésentant un nom de ville.
Avec un nombre d'extensions grandissant d'année en année, il devient nécessaire d'automatiser la gestion de ces règles afin de garantir des délais de traitement raisonnables et d'éviter des frais d'installation supplémentaires. En définissant une description de ces différentes règles dans un format technique, il est possible d'automatiser la génération des différents formulaires requis ainsi que la validation des données saisies.
Représentation technique
Les conditions d'éligibilité d'un nom de domaine peuvent être représentées sous la forme d'un objet JSON récursif.
Voici l'exemple de la représentation JSON du .com que l'on peut obtenir via l'API suivante:
Le format de règle sera expliqué et détaillé dans les sections suivantes.
Cliquez sur "Afficher" pour voir le JSON
Format des objets constituant une règle d'éligibilité
Dans un premier temps, regardons les éléments qui composent la représentation JSON des conditions d'éligibilité.
rule: objet principal représentant les conditions d'éligibilité. Il contient les autres objets décrits ci-dessous.description: informations détaillées concernant le champ.label: indique sur quel élément s'applique une règle :authInfo,OWNER_CONTACT,vat,firstName,lastName, etc. Une liste exhaustive est disponible dans la section Labels.type: indique le format attendu d'un label :string,number,bool,contact, etc. Une liste exhaustive est disponible dans la section Types.constraint: représente les contraintes appliquées à la valeur d'un label.operator: représente le type de contrainte appliquée au label. Une liste exhaustive est disponible dans la section Contraintes.
condition: spécifie les conditions d'application sous forme deruled'un label ou d'une contrainte. Si la condition est respectée, alors la règle associée doit être appliquée.fields: règles à appliquer sur les champs constituant un élément de typecontactoudomain.placeholder: exemple de valeur possible.and,or: permet de combiner des règles.
Labels
| Label | Représentation suggérée | Description |
|---|---|---|
ACCEPT_CONDITIONS | Case à cocher | Conditions particulières à accepter |
REASON | Champ texte multi-lignes | Raison de l'achat du nom de domaine |
CLAIMS_NOTICE | Case à cocher | Information concernant la claim notice à accepter |
PROTECTED_CODE | Champ texte | Code demandé lorsqu'un nom de domaine est protégé par le registre |
AUTH_INFO | Champ texte | Code lié au domaine pour une demande de transfert |
DOMAIN_CONFIG | Formulaire | Liste de champs liés à un nom de domaine |
OWNER_CONTACT | Formulaire | Liste de champs liés au contact titulaire |
ADMIN_ACCOUNT | Formulaire | Liste de champs liés au contact administrateur |
TECH_ACCOUNT | Formulaire | Liste de champs liés au contact technique |
OWNER_LEGAL_AGE | Case à cocher | Le titulaire doit être majeur |
Types
| Type | Représentation suggérée | Description |
|---|---|---|
string | Champ texte | - |
string[] | Liste de champs texte | - |
text | Champ texte multi-lignes | - |
bool | Case à cocher | - |
number | Champ numérique | - |
date_ISO8601 | Champ date | Format ISO8601 |
contact | Formulaire | Contient les champs liés au contact |
domain | Formulaire | Contient les champs liés au domaine |
Le type domain n'est aujourd'hui utilisé que pour les extensions ac.uk et gov.uk.
Ces noms de domaine ont un processus de création, des conditions d'appropriation et des conditions d'utilisation très particuliers.
Contraintes
| Contrainte | Représentation suggérée | Comment |
|---|---|---|
required | astérisque rouge | Le champ est requis |
readonly | champ grisé | Le champ est en lecture seule |
eq | - | Le champ doit être égal à la valeur associée |
ne | - | Le champ doit être différent de la valeur associée |
gt | - | Le champ doit être supérieur à la valeur associée |
lt | - | Le champ doit être inférieur à la valeur associée |
minlength | - | La longueur du champ doit être supérieure à la valeur associée |
maxlength | - | La longueur du champ doit être inférieure à la valeur associée |
between | - | La longueur du champ doit être comprise entre les valeurs associées |
contains | - | Le champ doit être égal à au moins une des valeurs associées |
notcontains | - | Le champ ne doit être égal à aucune des valeurs associées |
empty | - | Le champ doit être vide |
notempty | - | Le champ ne doit pas être vide |
match | - | Le champ doit satisfaire l'expression régulière contenue dans la valeur associée |
shouldbetrue | case à cocher | Le champ doit avoir la valeur true, 1 ou "1" |
Explications pas à pas
Contrainte sur un label de type primitif
Partons d'un exemple n'imposant qu'une seule règle pour la commande d'un nom de domaine. Cette règle nous demande d'accepter des conditions particulières.
Avec cette règle, lors de la commande, le domaine doit obligatoirement avoir une configuration ayant pour label ACCEPT_CONDITIONS avec une valeur booléenne à true, 1 ou "1".
Les opérateurs "and" et "or"
Partons maintenant sur un exemple de règle sur deux labels : ACCEPT_CONDITIONS et REASON.
Les deux règles peuvent être écrites individuellement de la façon suivante :
Ces deux règles peuvent êtres combinées à l'aide de l'opérateur and de l'objet rule. L'opérateur impose que tous les labels respectent leurs contraintes respectives. Par exemple :
L'opérateur or, de la même manière, nécessite qu'au moins un des labels respecte ses contraintes respectives afin que la règle soit valide.
Contrainte sur un label de type complexe
La gestion des contraintes sur un type complexe (contact, domain) s'applique à un ensemble de champs primitifs (un contact est composé d'un nom, d'un prénom, etc.).
Pour représenter les règles sur un objet, le nœud fields est utilisé. Chaque champ est représenté par un objet de type rule. Un objet de ce type contient plusieurs champs qui sont toujours appliqués en utilisant l'opérateur and. Voici un exemple de règle sur un objet de type contact :
Cliquez sur "Afficher" pour voir le JSON
Cette règle indique :
- Qu'une configuration
OWNER_CONTACTest obligatoire - Qu'elle doit être constituée de tous les champs suivants :
firstNamed'une taille maximum de 255 caractèreslastNamed'une taille maximum de 255 caractèresemaild'une taille maximum de 255 caractèreslegalFormayant l'une des valeursassociation,corporation,individualouotheraddress.countryayant l'une des valeursFR,DEouCAaddress.line1d'une taille maximum de 255 caractères- et
address.zipd'une taille maximum de 255 caractères
Le champ "constraints": [] indique simplement qu'aucune contrainte supplémentaire ne s'applique sur le nœud.
Conditions
Parfois, nous avons besoin de préciser dans quelles circonstances une règle s'applique. Par exemple, le nom de l'organisme (organisationName) est obligatoire pour un contact ne représentant pas un individu (legalForm différent de individual). Pour cela, nous allons utiliser une condition. Il s'agit d'une règle (l'objet rule) qui, si elle est valide, active la règle qu'elle conditionne.
Exemple simple
Voici un exemple simple purement fictif : un registre veut que les conditions spécifiques (ACCEPT_CONDITIONS) soient obligatoirement acceptées uniquement s'il n'y a pas de raison (REASON).
Cette règle indique que la configuration ACCEPT_CONDITIONS est obligatoire (contrainte required) uniquement si la configuration REASON est non renseignée (contrainte empty). La configuration ACCEPT_CONDITIONS devient optionnelle mais peut tout de même être renseignée.
Exemple sur un contact
Prenons maintenant l'exemple plus concret énoncé au début de cette section : le nom de l'organisme (organisationName) est obligatoire pour un contact professionnel/associatif (legalForm différent de individual).
Cliquez sur "Afficher" pour voir le JSON
Exemples réels
Suite à cette première partie expliquant la représentation technique des règles d'éligibilité, voici quelques exemples concrets et réels.
Règles génériques
La plupart des extensions (gTLDs et newGTLDs principalement) ont les mêmes règles d'éligibilité. Avoir un contact titulaire respectant celles-ci permet de commander la plupart des extensions disponibles à la vente.
Création d'un nom de domaine
Cliquez sur "Afficher" pour voir le JSON
Transfert d'un nom de domaine
Cliquez sur "Afficher" pour voir le JSON
Mise à jour du contact titulaire
Cliquez sur "Afficher" pour voir le JSON
Changement de titulaire
Cliquez sur "Afficher" pour voir le JSON
Règles spécifiques
Une partie des ccTLDs ont des règles d'éligibilité spécifiques, notamment au niveau du pays de résidence du titulaire du nom de domaine.
Cas du .berlin
Le cas du .berlin est intéressant car il dispose de règles d'éligibilité particulières. En effet, pour disposer d'un .berlin, l'administrateur ou le contact titulaire du nom de domaine doit résider à Berlin.
Pour ce faire, nous conditionnons la contrainte de la valeur des champs address.country et address.city du contact titulaire aux valeurs des champs address.country et address.city de l'administrateur, et vice-versa.
Cela se traduit de cette manière. Pour une raison de clarté, les règles sur les autres champs et labels ont été retirées.
Cliquez sur "Afficher" pour voir le JSON
Routes d'API
Deux interfaces sont à votre disposition pour manipuler et valider les règles de noms de domaine :
- Une pour récupérer les règles d'éligibilité d'un nom de domaine pour une action (création, transfert, etc.).
- Une pour valider des données pour un nom de domaine et pour une action.
Récupération d'une règle d'éligibilité
Commençons par l'API permettant la récupération d'une règle d'éligibilité. Le retour de celle-ci correspond au format de règle JSON vu dans la partie précédente.
| Paramètre | Obligatoire | Description |
|---|---|---|
action | oui | L'action souhaitée (create, transfer, trade, update) |
domain | oui | Le nom de domain concerné |
createest utilisée lors de la création d'un nom de domainetransferest utilisée lors du transfert entrant d'un nom de domaine depuis un autre registrartradeest utilisée lors du changement de contact titulaire d'un nom de domaineupdateest utilisée lors de la mise à jour des informations du nom de domaine ou d'un contact
Validation d'une règle d'éligibilité
Bien qu'il soit possible de vérifier les règles côté client, vous pouvez également utiliser l'API ci-dessous pour vérifier que la configuration pour une action donnée respecte bien les règles d'éligibilité.
En paramètre de requête, nous retrouvons l'action et le domaine souhaité.
| Paramètre | Obligatoire | Description |
|---|---|---|
action | oui | L'action souhaitée (create, transfer, trade, update) |
domain | oui | Le nom de domain concerné |
En body de requête, nous retrouvons les objets suivants.
| Body | Description |
|---|---|
owner | Objet représentant les données du contact titulaire |
adminAccount | Objet représentant les données du contact administratif |
techAccount | Objet représentant les données du contact technique |
domain | Données concernant le nom de domaine |
extras | Données additionnelles |
Pour plus d'informations sur les différents types de contact, veuillez consulter la documentation associée.
Chacun de ces objets est optionnel. Si le moteur de règles a besoin de l'un deux pour vérifier une règle, une erreur sera retournée.
Une particularité existe pour les actions trade et transfer : si un objet requis est manquant, celui-ci sera récupéré automatiquement depuis le service actuellement existant.
Si vous souhaitez tester qu'un nom de domaine déjà enregistré sur votre compte respecte bien ses règles d'éligibilité, vous pouvez faire appel à cette API sur l'action update avec un body vide. Le moteur de règles effectuera une validation en utilisant les données actuelles du service.
L'API de validation retourne un statut 200 si la règle est respectée. Dans le cas contraire, elle retourne un statut 400 accompagné d'une erreur détaillée, au format suivant :
Configurer les DNS de son nom de domaine
531