Comment ajouter un sous-domaine à votre domaine

Un sous-domaine est un préfixe ajouté à un domaine racine qui crée un espace de noms distinct et adressable indépendamment sous le même nom de domaine. Par exemple, pour le domaine racine example.com, le nom d’hôte blog.example.com est un sous-domaine pleinement qualifié où blog est l’étiquette de troisième niveau. Les sous-domaines sont résolus via des enregistrements DNS — généralement un enregistrement A pointant vers une adresse IPv4, un enregistrement AAAA pour IPv6, ou un enregistrement CNAME créant un alias vers un autre nom d’hôte — et ils ne nécessitent aucun frais d’enregistrement de domaine supplémentaire.

D’un point de vue pratique, les sous-domaines vous permettent d’exécuter des applications web distinctes, des environnements de staging, des sites régionaux ou des microservices sous un seul domaine enregistré, avec des racines de documents indépendantes, des certificats SSL et des configurations serveur. Ce guide couvre l’ensemble du processus technique : création d’enregistrements DNS, configuration de l’hébergement, provisionnement SSL, vérification de la propagation et les modes d’échec courants que la plupart des tutoriels omettent.

Qu’est-ce qu’un sous-domaine et en quoi diffère-t-il d’un sous-répertoire

Avant de toucher au DNS, il est utile de comprendre la différence architecturale entre un sous-domaine et un sous-répertoire, car ce choix affecte le référencement, la configuration du serveur et la portée SSL.

John Mueller de Google a confirmé que Google traite généralement les sous-domaines comme faisant partie du même site lorsque le contenu est clairement lié, mais le budget de crawl, l’indexation et le comportement de l’équité des liens peuvent différer. Pour un contenu étroitement intégré comme un blog d’entreprise, un sous-répertoire est souvent le choix le moins contraignant. Pour une application distincte — un portail client, une passerelle API ou un environnement de staging — un sous-domaine est la décision architecturale correcte.

Cas d’utilisation courants des sous-domaines

• Environnements de staging et d’assurance qualité : staging.example.com ou dev.example.com — isolés de la production, souvent protégés par HTTP Basic Auth ou une liste d’autorisation d’IP.
• Points de terminaison API : api.example.com — permet un déploiement indépendant, une limitation du débit et une terminaison TLS.
• Portails clients ou tableaux de bord SaaS : app.example.com — contexte d’authentification et cookies de session séparés.
• Sites régionaux ou spécifiques à une langue : de.example.com, us.example.com — prend en charge le ciblage hreflang et le routage serveur géo-spécifique.
• Documentation et support : docs.example.com, support.example.com — souvent servis depuis des plateformes comme GitBook, Zendesk ou un wiki auto-hébergé.
• CDN ou diffusion de médias : cdn.example.com, static.example.com — pointés via CNAME vers un réseau de périphérie CDN.
• Infrastructure de messagerie : mail.example.com — utilisé comme nom d’hôte pour les services SMTP/IMAP, distinct des enregistrements MX.

Étape 1 : Accéder à votre interface de gestion DNS

Les enregistrements DNS d’un domaine sont gérés là où les serveurs de noms faisant autorité du domaine sont hébergés. Ce n’est pas toujours au même endroit que votre hébergement web. Le serveur de noms faisant autorité est défini par les enregistrements NS auprès de votre registraire de domaine.

Déterminez où votre DNS est géré :

dig NS example.com +short

Si la sortie affiche des serveurs de noms appartenant à votre registraire (par exemple, ns1.registrar.com), gérez le DNS chez le registraire. Si elle affiche des serveurs de noms appartenant à un hébergeur ou à un service comme Cloudflare, gérez le DNS là-bas à la place.

Une fois que vous avez identifié le bon panneau de contrôle :

1. Connectez-vous à l’interface de gestion DNS.
2. Localisez la section Éditeur de zone DNS, Gestion DNS ou Fichier de zone.
3. Sélectionnez le domaine pour lequel vous souhaitez créer le sous-domaine.

Si votre domaine est enregistré via l’enregistrement de domaine AlexHost, l’éditeur de zone DNS est accessible directement depuis le tableau de bord de votre espace client.

Étape 2 : Créer l’enregistrement DNS pour le sous-domaine

Vous créerez l’un des trois types d’enregistrements selon votre infrastructure.

Enregistrement A — Pointage vers une adresse IPv4

Utilisez un enregistrement A lorsque le sous-domaine se résout vers une adresse IP de serveur spécifique. C’est le scénario le plus courant pour les sous-domaines hébergés sur un VPS ou un serveur dédié.

Détail critique : Entrez uniquement l’étiquette du sous-domaine dans le champ Nom — blog, pas blog.example.com. La plupart des interfaces DNS ajoutent automatiquement le domaine racine. Saisir le FQDN complet créera un enregistrement pour blog.example.com.example.com.

Enregistrement AAAA — Pointage vers une adresse IPv6

Structure identique à l’enregistrement A, mais la valeur est une adresse IPv6 complète :

Enregistrement CNAME — Alias vers un autre nom d’hôte

Utilisez un enregistrement CNAME lorsque le sous-domaine doit se résoudre vers un autre nom d’hôte plutôt que vers une IP directe. Les scénarios courants incluent le pointage vers un CDN, une plateforme tierce (Shopify, HubSpot, Netlify) ou un autre nom d’hôte interne.

Contrainte architecturale : Un enregistrement CNAME ne peut pas coexister avec un autre type d’enregistrement au même label. Vous ne pouvez pas créer un CNAME pour example.com lui-même (l’apex de zone) — uniquement pour les sous-domaines. À l’apex, utilisez un enregistrement A ou, si votre fournisseur DNS le prend en charge, un enregistrement propriétaire ALIAS ou ANAME.

Enregistrement de sous-domaine wildcard

Un enregistrement A wildcard résout tout sous-domaine non défini vers une seule IP :

Ceci est utile pour les applications SaaS multi-locataires où chaque client obtient un sous-domaine (par exemple, customer1.example.com). Sachez qu’un enregistrement wildcard ne provisionne pas automatiquement SSL pour chaque sous-domaine — vous avez besoin d’un certificat SSL wildcard ou d’un client ACME prenant en charge les défis DNS-01.

Étape 3 : Configurer le serveur web ou le panneau d’hébergement

La création d’un enregistrement DNS rend le sous-domaine résolvable, mais ne sert pas automatiquement du contenu. Vous devez configurer le serveur web ou le panneau d’hébergement pour accepter et router les requêtes vers le nouveau nom d’hôte.

Configuration d’un sous-domaine dans cPanel

Si votre hébergement utilise cPanel — disponible sur les offres VPS avec cPanel — le processus est le suivant :

1. Connectez-vous à cPanel.
2. Naviguez vers Domaines > Sous-domaines.
3. Dans le champ Sous-domaine, entrez l’étiquette (par exemple, blog).
4. Sélectionnez le domaine racine dans le menu déroulant.
5. Définissez la Racine du document — cPanel utilise par défaut public_html/blog, mais vous pouvez spécifier n’importe quel chemin.
6. Cliquez sur Créer.

cPanel crée automatiquement l’enregistrement DNS A dans la zone BIND de WHM si le DNS du domaine est géré localement. Si le DNS est géré en externe (par exemple, Cloudflare), vous devez ajouter l’enregistrement manuellement comme décrit à l’étape 2.

Configuration d’un sous-domaine dans Nginx

Pour un VPS exécutant Nginx, créez un nouveau bloc serveur :

server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;

    root /var/www/blog;
    index index.html index.php;

    access_log /var/log/nginx/blog.access.log;
    error_log  /var/log/nginx/blog.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Enregistrez le fichier dans /etc/nginx/sites-available/blog.example.com, puis activez-le :

sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Configuration d’un sous-domaine dans Apache

Créez un nouveau fichier d’hôte virtuel dans /etc/apache2/sites-available/blog.example.com.conf :

<VirtualHost *:80>
    ServerName blog.example.com
    DocumentRoot /var/www/blog

    <Directory /var/www/blog>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/blog.error.log
    CustomLog ${APACHE_LOG_DIR}/blog.access.log combined
</VirtualHost>

Activez et rechargez :

sudo a2ensite blog.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Étape 4 : Provisionner un certificat SSL pour le sous-domaine

Chaque sous-domaine qui sert du trafic web doit être sécurisé avec TLS. Un sous-domaine est un nom d’hôte distinct et n’est pas couvert par le certificat à domaine unique du domaine racine, sauf si vous utilisez un certificat wildcard.

Option 1 — Let’s Encrypt avec Certbot (sous-domaine unique)

sudo certbot --nginx -d blog.example.com

Ou pour Apache :

sudo certbot --apache -d blog.example.com

Certbot modifie automatiquement la configuration de l’hôte virtuel et configure une tâche cron pour le renouvellement.

Option 2 — Certificat wildcard Let’s Encrypt (défi DNS-01)

Un certificat wildcard couvre *.example.com, sécurisant tous les sous-domaines actuels et futurs avec un seul certificat. Cela nécessite une vérification par défi DNS-01 :

sudo certbot certonly 
  --manual 
  --preferred-challenges dns 
  -d "*.example.com" 
  -d "example.com"

Certbot vous invitera à créer un enregistrement TXT (_acme-challenge.example.com) dans votre zone DNS. Après avoir ajouté l’enregistrement et vérifié la propagation, Certbot émet le certificat. Les certificats wildcard doivent être renouvelés tous les 90 jours ; automatisez le renouvellement avec un plugin DNS pour votre fournisseur (par exemple, certbot-dns-cloudflare).

Option 3 — Certificat SSL commercial

Pour les organisations nécessitant une validation étendue (EV) ou une période de validité plus longue, un certificat commercial d’une autorité de certification de confiance est approprié. AlexHost propose des certificats SSL incluant des options à validation de domaine, à validation d’organisation et wildcard. Après l’achat, installez le certificat en plaçant les fichiers .crt et .key sur le serveur et en les référençant dans la configuration de l’hôte virtuel.

Étape 5 : Vérifier la propagation DNS

Les modifications DNS ne prennent pas effet globalement à l’instant où vous les enregistrez. Chaque résolveur met en cache les enregistrements pendant la durée de la valeur TTL. Avec un TTL de 3600, les résolveurs peuvent servir l’ancien enregistrement pendant jusqu’à une heure après votre modification.

Vérifiez la propagation depuis plusieurs points d’observation mondiaux :

# Check from a specific DNS resolver
dig A blog.example.com @8.8.8.8 +short
dig A blog.example.com @1.1.1.1 +short

# Check authoritative answer directly
dig A blog.example.com +trace

Pour une vérification visuelle multi-régions, utilisez whatsmydns.net ou dnschecker.org. La propagation mondiale complète se termine généralement en 15 minutes à 2 heures pour des TTL de 3600 ou inférieurs. Les « jusqu’à 48 heures » souvent citées s’appliquent principalement aux valeurs TTL de 86400 (24 heures) définies sur l’enregistrement précédent — une valeur par défaut courante chez de nombreux registraires.

Conseil pro : Avant d’effectuer des modifications DNS, abaissez le TTL de l’enregistrement existant à 300 (5 minutes) au moins un cycle TTL à l’avance. Cela réduit considérablement le temps d’attente de propagation lors du changement effectif.

Étape 6 : Tester la fonctionnalité de bout en bout

Après la propagation, effectuez un test fonctionnel complet :

# Confirm DNS resolution
dig A blog.example.com +short

# Confirm HTTP response
curl -I http://blog.example.com

# Confirm HTTPS and certificate validity
curl -I https://blog.example.com

# Inspect the TLS certificate
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -dates

Vérifiez que :

• La réponse curl -I retourne 200 OK ou le code de redirection attendu.
• Le sujet du certificat TLS correspond à blog.example.com ou *.example.com.
• La date d’expiration du certificat est correcte.
• Aucun avertissement de contenu mixte n’apparaît dans la console de développement du navigateur.

Pièges courants et comment les éviter

CNAME à l’apex de zone : Tenter de créer un enregistrement CNAME pour example.com lui-même cassera la livraison de courrier et d’autres enregistrements DNS. Utilisez un enregistrement A ou un enregistrement ALIAS/ANAME à l’apex.

Sous-domaine non servi par le serveur web : Le DNS se résout correctement, mais le navigateur retourne une erreur 404 ou une connexion refusée. Cause : le serveur web n’a pas d’hôte virtuel correspondant au nom d’hôte du sous-domaine. Solution : ajoutez le bloc serveur ou l’hôte virtuel comme décrit à l’étape 3.

Incompatibilité de certificat SSL : Le navigateur affiche une erreur de certificat. Cause : le certificat existant ne couvre que example.com, pas blog.example.com. Solution : émettez un nouveau certificat spécifiquement pour le sous-domaine ou remplacez-le par un certificat wildcard.

cPanel crée un enregistrement DNS local mais le DNS est géré en externe : Lors de l’utilisation de Cloudflare ou d’un autre fournisseur DNS externe avec l’hébergement cPanel, l’assistant de sous-domaine de cPanel crée un enregistrement dans la zone BIND locale de WHM, qui n’est jamais consultée. Vous devez ajouter l’enregistrement A manuellement dans Cloudflare (ou votre fournisseur DNS externe). C’est l’une des sources de confusion les plus courantes pour les utilisateurs d’hébergement mutualisé.

DNS wildcard sans SSL wildcard : Un enregistrement DNS *.example.com résout tous les sous-domaines vers votre serveur, mais chaque nouveau sous-domaine déclenchera un avertissement de certificat à moins que vous n’ayez un certificat SSL wildcard installé. Ne vous fiez pas uniquement au DNS wildcard pour les sous-domaines en production.

Fuite de portée des cookies : Si votre application définit des cookies sur .example.com (notez le point initial), ces cookies sont envoyés à tous les sous-domaines. Cela peut exposer des jetons de session d’un sous-domaine hautement sécurisé à un moins sécurisé. Définissez explicitement la portée des cookies sur le nom d’hôte prévu.

Gestion des sous-domaines dans différents environnements d’hébergement

Pour les applications à fort trafic nécessitant un accès root complet et des configurations serveur personnalisées, un serveur dédié vous donne un contrôle total sur le DNS, les logiciels de serveur web et la gestion des certificats sans les contraintes d’un environnement mutualisé.

Liste de contrôle des décisions techniques

Avant de créer un sous-domaine, parcourez les points suivants :

• Où se trouvent les serveurs de noms faisant autorité ? Exécutez dig NS example.com +short pour confirmer avant de vous connecter à un panneau quelconque.
• Enregistrement A ou CNAME ? Utilisez A/AAAA pour une IP de serveur. Utilisez CNAME pour un nom d’hôte de plateforme tierce. N’utilisez jamais CNAME à l’apex de zone.
• Le serveur web est-il configuré pour accepter le nouveau nom d’hôte ? Un enregistrement DNS seul ne sert pas de contenu.
• Le sous-domaine a-t-il besoin de son propre certificat SSL ? Oui, sauf si un certificat wildcard est déjà installé.
• Le TTL est-il défini bas avant le changement ? Abaissez-le à 300 au moins un cycle TTL avant d’effectuer des modifications pour minimiser le délai de propagation.
• cPanel gère-t-il le DNS localement alors qu’un fournisseur externe fait autorité ? Si c’est le cas, ajoutez l’enregistrement chez le fournisseur externe, pas dans cPanel.
• Le sous-domaine doit-il être bloqué de l’indexation par les moteurs de recherche ? S’il s’agit d’un environnement de staging ou interne, ajoutez X-Robots-Tag: noindex au niveau du serveur ou utilisez HTTP Basic Auth.
• Les portées des cookies sont-elles définies correctement ? Définissez explicitement l’attribut Domain sur les cookies pour éviter le partage involontaire entre sous-domaines.

FAQ

Puis-je créer un sous-domaine sans accès au DNS du domaine racine ?

Non. Un sous-domaine nécessite un enregistrement DNS (A, AAAA, ou CNAME) dans la zone du domaine racine. Sans accès en écriture à la zone DNS faisant autorité, vous ne pouvez pas créer un sous-domaine résolvable publiquement.

Un sous-domaine affecte-t-il le référencement du domaine racine ?

Cela dépend de la relation entre les contenus et des liens internes. Google peut associer un sous-domaine au domaine racine, mais l’équité des liens ne circule pas aussi librement qu’entre les URL de sous-répertoires. Pour un contenu étroitement intégré au site principal, un sous-répertoire est généralement préférable du point de vue du référencement. Pour des applications distinctes ou des environnements de staging, un sous-domaine est le bon choix et devrait être noindex s’il n’est pas destiné à la recherche publique.

Combien de sous-domaines puis-je créer sous un domaine ?

La spécification DNS n’impose aucune limite pratique au nombre de sous-domaines. Les registraires et les panneaux d’hébergement peuvent imposer des limites souples, mais celles-ci sont administratives, pas techniques. Un seul domaine peut avoir des centaines de sous-domaines.

Quelle est la différence entre un enregistrement DNS wildcard et un certificat SSL wildcard ?

Un enregistrement DNS wildcard (*.example.com) route tous les sous-domaines non définis vers une seule adresse IP au niveau DNS. Un certificat SSL wildcard (*.example.com) sécurise tous les sous-domaines de premier niveau au niveau TLS. Ils sont indépendants : vous pouvez avoir l’un sans l’autre, mais les deux sont nécessaires pour servir tous les sous-domaines via HTTPS sans provisionnement de certificat individuel.

Pourquoi mon sous-domaine se résout-il correctement dans dig mais retourne-t-il une erreur dans le navigateur ?

La résolution DNS et le service HTTP sont des couches distinctes. Si dig retourne l’IP correcte mais que le navigateur affiche une erreur, le serveur web sur cette IP n’est pas configuré pour gérer les requêtes pour ce nom d’hôte (server_name dans Nginx ou ServerName dans Apache). Ajoutez le bloc d’hôte virtuel approprié et rechargez le serveur web.