CNAME vs redirection : ce que chacun fait et quand l’utiliser

Un CNAME et une redirection résolvent des problèmes différents. Un CNAME est un alias DNS : il indique à Internet qu’un nom d’hôte est un autre nom pour un second nom d’hôte, de sorte que les deux pointent vers le même serveur. Une redirection est une réponse du serveur web qui indique à un navigateur d’aller vers une URL différente, et le visiteur voit l’adresse changer. Si vous voulez qu’un visiteur qui saisit old-domain.com arrive sur new-domain.com/page, vous avez besoin d’une redirection. Si vous voulez que go.yourbrand.com soit servi par une plateforme que vous n’hébergez pas vous-même, vous avez besoin d’un CNAME. La plupart des configurations réelles utilisent les deux, dans cet ordre.

Ce que fait réellement un enregistrement CNAME#

CNAME signifie nom canonique. Un enregistrement CNAME mappe un nom d’hôte vers un autre nom de domaine, puis le DNS résout ce second nom en une adresse IP. La documentation DNS de Hetzner^[1] le décrit ainsi et précise que les enregistrements CNAME sont souvent appelés enregistrements alias.

Supposons que vous créiez cet enregistrement dans votre zone DNS :

go.yourbrand.com.   CNAME   edge.provider-example.net.

Quand l’appareil de quelqu’un recherche go.yourbrand.com, le résolveur voit l’alias, recherche edge.provider-example.net et récupère une adresse IP. Le navigateur se connecte ensuite à cette IP et demande go.yourbrand.com. Rien dans cet échange n’indique au navigateur d’aller ailleurs. La barre d’adresse affiche toujours go.yourbrand.com.

Pourquoi les gens utilisent un CNAME#

Un CNAME est la méthode standard pour fournir à un service votre propre nom d’hôte sans l’héberger vous-même. Cas typiques :

• Pointer www ou shop vers une plateforme de commerce électronique
• Connexion de help.yourbrand.com à un outil de service d'assistance
• Pointer go.yourbrand.com vers une plateforme de liens de marque
• Vérifier la propriété d'un domaine ou déléguer un sous-domaine à un tiers

L'avantage est que le fournisseur peut changer ses serveurs et ses adresses IP sans vous demander de modifier quoi que ce soit. Votre enregistrement pointe vers un nom, et c'est lui qui maintient ce vers quoi ce nom se résout.

Les chaînes CNAME ralentissent les choses#

Un CNAME peut pointer vers un autre CNAME, mais c'est déconseillé. TechTarget note^[2] que les CNAME chaînés impliquent plusieurs recherches DNS avant de trouver l'adresse finale, et que le délai s'accumule à chaque étape. Gardez vos alias à un seul niveau du nom qui contient la véritable adresse.

Les points finaux comptent#

Lorsque vous saisissez un nom d'hôte complet comme cible, écrivez-le comme un nom pleinement qualifié. Hetzner avertit^[1] que l'omission du point final peut entraîner l'ajout du nom de votre propre zone à la cible, ce qui envoie l'alias au mauvais endroit. De nombreux tableaux de bord ajoutent le point pour vous, alors vérifiez comment le vôtre affiche l'enregistrement enregistré.

Ce que fait réellement une redirection#

Une redirection est une instruction d’un serveur web. Le navigateur demande une URL, le serveur répond avec un code d’état et un en-tête Location, puis le navigateur effectue une deuxième requête vers cette nouvelle adresse. Le visiteur voit l’URL changer.

Cela signifie qu’une redirection a besoin de trois choses qu’un CNAME ne fournit pas :

1. Un serveur qui reçoit la requête pour le nom d’hôte d’origine
2. Un certificat HTTPS valide pour ce nom d’hôte, si le visiteur a saisi https://
3. Une règle qui indique où envoyer la requête

La règle peut être aussi simple que « tout ce qui se trouve sur old.com va vers new.com » ou aussi détaillée que « old.com/pricing va vers new.com/plans ». Comme les redirections fonctionnent au niveau de l’URL, elles peuvent conserver les chemins et les chaînes de requête, envoyer différents visiteurs vers différents endroits et indiquer aux moteurs de recherche si un déplacement est permanent. Si vous hésitez entre des codes d’état permanents et temporaires, notre guide sur les redirections 301 vs 302 explique les conséquences SEO de chacun.

CNAME vs redirection, côte à côte#

La ligne à retenir est « a besoin d'un serveur pour répondre ». TechTarget explique^[2] qu'un CNAME ne génère pas de redirection à lui seul : le serveur qui reçoit la requête HTTP doit être configuré pour en renvoyer une. C'est pourquoi les personnes qui mettent en place un CNAME en s'attendant à un transfert se retrouvent avec une erreur de certificat ou une page par défaut.

Un CNAME peut-il rediriger un domaine ?#

Non. Un CNAME pointe vers un autre domaine ou sous-domaine, et il ne peut pas être utilisé pour créer une redirection HTTP^[1]. La confusion vient du mot « alias ». Cela semble vouloir dire « envoyer les visiteurs là-bas », mais cela signifie seulement « traiter ce nom comme ce nom-là à des fins de résolution ».

Voici ce qui se passe si vous pointez old-domain.com vers new-domain.com avec un CNAME et rien d’autre :

• Le navigateur du visiteur résout old-domain.com vers l’adresse IP du serveur de new-domain.com.
• Il se connecte et demande une page pour l’hôte old-domain.com.
• Le serveur ne reconnaît pas ce nom d’hôte, renvoie le mauvais site, ou échoue à la vérification du certificat, car le certificat ne couvre pas old-domain.com.

Le visiteur n’est jamais envoyé vers new-domain.com. Pour que le transfert fonctionne, le serveur qui répond pour old-domain.com doit connaître ce nom d’hôte, disposer d’un certificat valide pour celui-ci et renvoyer une réponse de redirection.

Le problème du domaine racine#

Il existe une deuxième raison pour laquelle un CNAME fonctionne rarement pour une redirection d’un domaine entier : l’apex. L’apex, aussi appelé domaine racine ou domaine nu, est yourbrand.com sans aucun préfixe. Il porte déjà des enregistrements requis tels que les enregistrements SOA et NS, et un CNAME ne peut pas partager un nom avec d’autres enregistrements. Hetzner indique^[1] que les enregistrements CNAME appartiennent généralement aux sous-domaines, ne peuvent pas coexister avec d’autres enregistrements au même nom, et ne devraient pas être utilisés à l’apex de la zone dans un DNS standard.

Certains fournisseurs DNS proposent leur propre contournement sous des noms comme ALIAS ou ANAME. Ce sont des mécanismes propres au fournisseur qui résolvent la cible pour vous et renvoient une adresse, ce qui est différent d’un CNAME standard. Ils résolvent le problème de résolution, mais ne redirigent toujours pas : vous avez besoin d’un serveur répondant à ce nom pour envoyer les visiteurs ailleurs.

Le schéma habituel pour le transfert du domaine racine est :

• Pointez l’apex vers le service de transfert avec un enregistrement A (ou un ALIAS/ANAME si votre hébergeur DNS en prend un en charge).
• Pointez www vers le même service avec un CNAME si nécessaire.
• Laissez le service renvoyer la redirection via HTTPS.

Ce qui arrive aux e-mails#

Si vous transférez un domaine, vos e-mails doivent continuer à fonctionner. La règle est simple : un nom d’hôte avec un CNAME ne peut pas non plus contenir d’autres enregistrements, comme MX^[2], et un domaine qui reçoit des e-mails ne devrait pas avoir de CNAME à ce nom. C’est une raison de plus pour ne pas essayer de forcer un CNAME sur la racine d’un domaine qui gère le courrier.

Une redirection n’affecte pas du tout les e-mails. Elle agit uniquement sur les requêtes web. Vos enregistrements MX, SPF, DKIM et DMARC restent dans le DNS tels quels, et les e-mails continuent d’arriver sur les mêmes serveurs. Si vous ajoutez un service de transfert à un domaine qui envoie ou reçoit des e-mails, modifiez uniquement les enregistrements web (A, AAAA ou le CNAME www) et laissez les enregistrements de messagerie intacts. Notre guide pratique des enregistrements DNS pour les e-mails indique le rôle de chacun afin que vous puissiez voir lesquels laisser inchangés.

Comment rediriger un domaine vers un autre#

C’est la question à laquelle la plupart des personnes qui recherchent « CNAME vs redirection » veulent réellement une réponse. La procédure est la même quel que soit le fournisseur que vous utilisez.

Étape 1 : Choisir le type de redirection#

Utilisez une redirection permanente lorsque le changement est définitif, par exemple lors d’un changement de marque ou de la mise hors service d’un domaine. Utilisez une redirection temporaire lorsque l’adresse d’origine reviendra, par exemple pour une campagne ou une page de maintenance. Les redirections permanentes indiquent aux moteurs de recherche de transférer la valeur de l’ancienne URL vers la nouvelle.

Étape 2 : Décidez ce qu’il advient des chemins#

Souhaitez-vous que old.com/anything mène à la nouvelle page d’accueil, ou à new.com/anything ? Conserver les chemins est presque toujours préférable pour les visiteurs et pour le référencement, car chaque ancienne page aboutit à son équivalent. Si vous avez besoin d’une règle générique pour de nombreux sous-domaines, une redirection générique gère cela en une seule règle.

Étape 3 : Pointez le DNS vers le service qui effectuera la redirection#

• Pour le domaine racine : un enregistrement A (ou ALIAS/ANAME) vers le service de redirection.
• Pour les sous-domaines tels que www ou go : un CNAME vers le nom d’hôte fourni par le service.

Ici, les deux concepts fonctionnent ensemble. Le DNS dirige la requête vers le bon serveur, et le serveur effectue la redirection.

Étape 4 : Assurez-vous que HTTPS fonctionne pour l’ancien domaine#

Les visiteurs qui saisissent ou cliquent sur https://old.com ont besoin d’un certificat valide pour old.com, sinon ils verront un avertissement du navigateur avant que la redirection puisse se produire. C’est l’étape que la plupart des configurations maison sautent ; servir des redirections via HTTPS explique comment obtenir d’abord le certificat.

Étape 5 : Testez-le#

Ouvrez l’ancienne URL dans une fenêtre privée, vérifiez qu’elle mène à la bonne page et contrôlez que la barre d’adresse affiche la destination. Testez un lien profond, pas seulement la page d’accueil. Testez aussi à la fois http:// et https://, ainsi que www et le non-www. Un vérificateur de redirection répertorie chaque étape avec son code de statut, afin que vous puissiez confirmer que l’ancienne URL répond avec une seule redirection permanente plutôt qu’avec une chaîne.

Redirection DNS ou redirection serveur ?#

De nombreux bureaux d’enregistrement vendent le « transfert de domaine » ou le « transfert web » comme fonctionnalité. Cela fonctionne en pointant votre domaine vers les serveurs de transfert du bureau d’enregistrement, qui renvoient ensuite une redirection. Il s’agit d’un service de redirection, pas d’une astuce CNAME. Son utilité dépend du niveau de contrôle dont vous avez besoin sur les codes de statut, HTTPS, les chemins et les rapports. Nous comparons les deux approches plus en détail dans redirection DNS vs redirection serveur.

La vitesse compte aussi. Chaque redirection ajoute une requête avant que le visiteur ne voie le contenu, donc un serveur de redirection lent vous coûte directement. Voir pourquoi la vitesse de redirection compte pour savoir comment réduire au minimum cette étape.

À quelle vitesse le serveur de redirection répond#

Quel que soit le serveur vers lequel vous pointez le DNS, son temps de réponse s’ajoute à chaque visite effectuée via l’ancienne URL. Notre benchmark de vitesse des redirections^[3] mesure cette étape pour 27 fournisseurs depuis Washington, D.C., Francfort et Tokyo. Du 27 octobre au 3 novembre 2026, le temps médian jusqu’au premier octet d’une redirection allait de 9 ms (Amazon CloudFront) à 586 ms (Apache). Les redirections servies par RedirHub répondaient en médiane en 15 ms, les redirections servies par nginx en 143 ms et les redirections depuis Amazon S3 en 293 ms.

Laquelle devriez-vous utiliser ?#

Un test simple : si le visiteur doit voir une URL différente ensuite, vous avez besoin d’une redirection. Si le visiteur doit continuer à voir votre nom d’hôte pendant qu’un autre fournisseur sert le contenu, vous avez besoin d’un CNAME.

Il existe une troisième option lorsque le DNS du domaine ne peut pas être modifié du tout : avec le mode d’intégration, la plateforme qui sert déjà le site (Cloudflare Workers, Next.js sur Vercel ou Caddy) récupère ses règles de redirection depuis RedirHub, donc aucun CNAME ni enregistrement A n’est impliqué.

Erreurs courantes#

• Utiliser un CNAME en s’attendant à un renvoi. L’alias se résout, mais personne ne redirige le visiteur nulle part.
• Placer un CNAME sur le domaine racine. Il entre en conflit avec les enregistrements qui doivent s’y trouver, y compris les enregistrements de courrier.
• Oublier le HTTPS sur l’ancien domaine. La redirection n’a jamais l’occasion de se déclencher si le navigateur bloque d’abord la connexion.
• Rediriger tout vers la page d’accueil. Les liens profonds perdent leur pertinence et les visiteurs perdent leur destination.
• Enchaîner les redirections et les alias. Chaque saut supplémentaire ajoute du délai. Pointez directement vers la cible finale.
• Utiliser une redirection temporaire pour un déplacement permanent. Les moteurs de recherche peuvent continuer à traiter l’ancienne URL comme la principale.

Notre perspective#

Gérer les redirections sans exploiter de serveurs#

Si vous gérez plusieurs domaines, ou si vous souhaitez des liens de marque et des codes QR que vous pourrez rediriger plus tard, exploiter vos propres serveurs de redirection et certificats demande beaucoup d’entretien. RedirHub vous permet d’utiliser votre propre domaine pour les liens de marque et les redirections de domaine, avec une gestion du SSL pour vous et des analyses sur le trafic qui transite.

Les forfaits commencent à 49 $ par mois pour Core et 119 $ par mois pour Pro, et Enterprise est défini par contrat ; consultez la page des tarifs pour voir ce que chacun comprend. Si vous migrez un site, notre service de migration de site web couvre le mappage des anciennes URL vers les nouvelles. Pour les supports imprimés, les codes QR dynamiques vous permettent de modifier la destination après impression.