Créer un sous-domaine avec OVH : tutoriel complet pour bien démarrer
- Créer un sous-domaine avec OVH : tutoriel complet
- Comment Créer un sous Domaine Ovh ?
- Étape 1 - Créer l'entrée DNS du sous-domaine (A, AAAA ou CNAME)
- Étape 2 - Déclarer le sous-domaine côté hébergement OVH (si vous servez un site)
- Étape 3 - Vérifier la propagation et tester le sous-domaine
- Cas pratiques : quel type de sous-domaine pour quel usage ?
- Erreurs fréquentes (et comment les éviter)
- Dernier réglage utile : sécuriser et «rendre propre» le sous-domaine
Un sous-domaine, c'est comme une pièce supplémentaire que vous ajoutez à votre maison «nomdedomaine.tld» : vous gardez la même adresse principale, mais vous créez une entrée dédiée pour un usage précis (blog, boutique, extranet, préprod...). Chez OVHcloud, la création se joue surtout dans deux endroits : la zone DNS (pour dire «où doit pointer le sous-domaine») et la configuration de l'hébergement (pour dire «quoi servir quand on y arrive»). Si vous suivez l'ordre, c'est simple, propre, et vous évitez les pièges classiques de redirections et d'erreurs 404.
Créer un sous-domaine avec OVH : tutoriel complet
L'objectif est clair : faire répondre «sousdomaine.votredomaine.tld» vers un service (un hébergement web OVH, un serveur dédié/VPS, une IP de reverse proxy, une plateforme SaaS...). La méthode varie selon la cible, mais la logique reste la même : ajouter un enregistrement DNS adapté, attendre la propagation, puis vérifier que le contenu servi correspond bien à votre besoin.
Comment Créer un sous Domaine Ovh ?
Dans l'espace client OVHcloud, tout commence par le choix du nom du sous-domaine. Prenez quelque chose de lisible et «évident» : blog, shop, api, dev. Évitez les noms trop longs ou ambigus, et gardez en tête que ce sous-domaine peut aussi vivre dans vos e-mails, vos certificats TLS et vos règles de sécurité.
Ensuite, vous devez décider vers quoi il pointe : un hébergement mutualisé, un serveur dédié, un CDN, ou une autre destination. Cette décision conditionne le type d'entrée DNS (A/AAAA, CNAME...) et la suite de la configuration.
Avant de commencer : ce qu'il vous faut (vraiment)
Pour avancer sans blocage, assurez-vous d'avoir accès à : l'espace client OVHcloud, la gestion du nom de domaine concerné, et la gestion de la zone DNS. Si votre domaine n'utilise pas les DNS d'OVH (cas fréquent quand on délègue ailleurs), vous pourrez toujours créer un sous-domaine, mais il faudra le faire dans le panneau DNS qui fait autorité.
Enfin, gardez une notion en tête : la propagation DNS n'est pas instantanée. Selon le TTL et les caches, vous pouvez voir le changement rapidement... ou attendre un peu. Ce n'est pas un bug : c'est juste le DNS qui fait son travail.
Étape 1 - Créer l'entrée DNS du sous-domaine (A, AAAA ou CNAME)
Dans OVHcloud, ouvrez la section du domaine puis la zone DNS. Vous allez ajouter un nouvel enregistrement pour votre sous-domaine. Le bon choix dépend de la cible :
- A : pour pointer vers une IPv4 (souvent un serveur dédié, un VPS, ou une IP fixe).
- AAAA : pour pointer vers une IPv6 (si votre service l'expose).
- CNAME : pour pointer vers un autre nom (pratique quand la cible change d'IP, ou pour certains services managés).
Exemple concret : si «api.votredomaine.tld» doit aller vers votre serveur, vous créerez en général un enregistrement A (et éventuellement AAAA). Si «blog.votredomaine.tld» doit suivre une cible gérée ailleurs par un nom canonique, un CNAME est souvent plus adapté.
Pensez DNS comme à un annuaire : vous n'y «installez» rien, vous y écrivez simplement la destination.
Le détail qui évite les erreurs : la valeur et le champ «sous-domaine»
Dans l'interface OVHcloud, vous saisissez généralement «blog» (sans le domaine complet) dans le champ du sous-domaine, puis la cible (IP ou nom) dans la valeur. Vérifiez bien les points finaux éventuels sur les CNAME (selon l'UI, OVH les gère, mais une confusion sur le nom peut créer un mauvais domaine «concaténé»).
Étape 2 - Déclarer le sous-domaine côté hébergement OVH (si vous servez un site)
Si votre sous-domaine doit afficher un site hébergé chez OVHcloud (mutualisé notamment), il faut aussi le déclarer dans l'hébergement : on associe le sous-domaine à un répertoire (dossier) ou à une racine spécifique. C'est là que vous choisissez ce que «blog.votredomaine.tld» affichera réellement : un WordPress dans /blog, une landing page dans /lp, une appli dans /app, etc.
Une configuration propre consiste à créer un dossier dédié, puis à y déployer vos fichiers. Ça évite le fameux mélange «tout est à la racine» qui devient vite ingérable quand on multiplie les sous-domaines.
Si votre idée derrière un sous-domaine est de publier un blog, une page produit ou une base de connaissances, WordPress reste un choix courant sur l'hébergement OVHcloud. Le point important, ce n'est pas juste d'installer, c'est de relier correctement le dossier du site au sous-domaine et de vérifier le certificat TLS ensuite. Une fois en place, vous pouvez isoler votre contenu, vos thèmes et vos extensions sans toucher au site principal. Installation de WordPress sur OVH aide justement à cadrer cette partie de façon propre, surtout si vous avez plusieurs environnements (prod/préprod).
Étape 3 - Vérifier la propagation et tester le sous-domaine
Après avoir ajouté l'entrée DNS, laissez un peu de temps. Puis testez : ouvrez le sous-domaine dans un navigateur, ou utilisez une commande de type «nslookup/dig» si vous êtes à l'aise. L'idée est de confirmer que le nom résout vers la bonne cible. Quand tout est bon, vous devriez voir soit votre site, soit la réponse de votre service (API, reverse proxy, page par défaut...).
Si vous tombez sur une page inattendue, ce n'est pas rare : cela signifie souvent que le DNS pointe bien, mais que le serveur en face n'a pas encore de vhost ou de configuration dédiée au nom (cas fréquent sur un serveur dédié avec Nginx/Apache). Dans ce cas, le serveur reçoit la requête, mais ne sait pas quel site servir. [ A lire en complément ici ]
Cas pratiques : quel type de sous-domaine pour quel usage ?
Un sous-domaine est une étiquette fonctionnelle. Vous gagnez en clarté, en séparation, et parfois en sécurité. Quelques usages courants :
- Préproduction (ex. preprod.) pour tester une mise à jour avant la mise en ligne.
- API (api.) pour isoler des endpoints et appliquer des règles réseau spécifiques.
- Webmail / mail pour accéder à un service lié à la messagerie.
- Statique (cdn., assets.) pour servir des ressources séparément.
Sur un site orienté «serveur dédié», le sous-domaine devient aussi un outil d'architecture : vous pouvez faire pointer «app.» vers un reverse proxy sur votre machine, «db-admin.» vers une interface protégée, et «status.» vers une page de supervision. C'est propre, lisible, et plus facile à maintenir.
Le point SEO : sous-domaine ou sous-répertoire ?
Pour le référencement, un sous-domaine peut être perçu comme une entité distincte du domaine principal dans certains contextes. Si votre but est de renforcer le site principal avec un blog, un sous-répertoire (/blog) est souvent privilégié. Si votre but est d'isoler un produit, une appli, un support, ou un environnement technique, le sous-domaine est très cohérent. Ici, la bonne décision dépend surtout de votre organisation et de votre stratégie de contenu, pas d'une règle unique.
Erreurs fréquentes (et comment les éviter)
Les ratés les plus courants viennent rarement d' OVHcloud lui-même, mais d'un petit détail :
- Mauvais type d'enregistrement : CNAME au lieu de A (ou l'inverse), ou oubli de AAAA si votre service fonctionne en IPv6.
- Conflit d'entrées : plusieurs enregistrements pour le même sous-domaine qui se contredisent.
- Service non configuré côté serveur : le DNS pointe bien, mais le serveur ne sert pas le bon site.
- Certificat TLS manquant : le site marche en HTTP mais affiche une alerte en HTTPS. Pensez à générer/associer un certificat pour le sous-domaine.
Une bonne habitude : notez ce que vous changez. Le DNS, c'est un peu comme des panneaux sur une route ; quand on en bouge un, on veut pouvoir expliquer pourquoi, et revenir en arrière si besoin.
Quand vous créez un sous-domaine, vous touchez presque toujours au DNS, et la plupart des blocages viennent d'une incompréhension sur la signification des champs (TTL, cible, priorités, valeurs). Comprendre la lecture d'une zone permet de diagnostiquer vite : un CNAME qui masque un A, une entrée dupliquée, ou une cible qui n'est plus valide. C'est aussi utile quand vous jonglez entre mutualisé, serveur dédié et services externes. Zone DNS expliquée chez OVH s'inscrit bien dans cette logique de dépannage propre, sans tâtonner.
Dernier réglage utile : sécuriser et «rendre propre» le sous-domaine
Une fois le sous-domaine actif, pensez à deux finitions qui font la différence : activer le HTTPS (certificat couvrant le sous-domaine) et vérifier que la version choisie est unique (avec ou sans www selon votre cas). Si le sous-domaine héberge un back-office, ajoutez une barrière simple mais efficace : restriction par IP, authentification, ou au minimum un mot de passe côté serveur. Un sous-domaine bien rangé, c'est un peu comme un atelier : quand chaque outil a sa place, vous gagnez du temps à chaque intervention.

