Un client du secteur du tourisme avait acté, avant même de me contacter, la décision de séparer chacune de ses quatre versions linguistiques sur un nom de domaine dédié : exemple.fr, exemple.com pour l’anglais, exemple.de et exemple.es. Cette structure présente des avantages marketing réels, notamment une meilleure perception locale par les visiteurs et parfois un signal de pertinence géographique pour les moteurs de recherche. Mais elle a un coût technique que le client n’avait pas anticipé : chaque domaine doit être configuré indépendamment au niveau DNS, certificat et serveur web, avec une rigueur de suivi supérieure à une structure en sous-dossiers.
Cet article ne revient pas sur le choix de la structure elle-même, question déjà tranchée avec le client sur des critères business ; il détaille uniquement la mise en œuvre technique concrète une fois cette décision prise.
Configurer les enregistrements DNS pour chaque domaine
Pour chaque nom de domaine acquis, deux enregistrements minimum doivent pointer vers l’infrastructure d’hébergement : un enregistrement A (ou AAAA pour IPv6) pointant vers l’adresse IP du serveur, et généralement un enregistrement CNAME pour le sous-domaine www redirigeant vers le domaine racine ou vers l’adresse du serveur directement. Sur l’infrastructure de ce projet, les quatre domaines pointaient vers la même adresse IP du serveur mutualisé, le serveur web se chargeant ensuite de distinguer les requêtes par nom de domaine grâce à l’en-tête HTTP Host.
exemple.fr. IN A 203.0.113.10
www.exemple.fr. IN CNAME exemple.fr.
exemple.com. IN A 203.0.113.10
www.exemple.com. IN CNAME exemple.com.
exemple.de. IN A 203.0.113.10
exemple.es. IN A 203.0.113.10Un délai de propagation DNS, généralement entre quelques minutes et 48 heures selon le registrar et le TTL configuré, s’applique à chaque nouveau domaine ou chaque modification. Je programme systématiquement ces changements plusieurs jours avant la date de mise en ligne prévue, pour ne jamais dépendre d’une propagation instantanée.
Générer un certificat pour chaque domaine
Deux approches existent pour le TLS : un certificat distinct par domaine, ou un certificat unique couvrant plusieurs noms alternatifs (SAN, Subject Alternative Name). Avec Let’s Encrypt et Certbot, la seconde option se configure en une seule commande couvrant l’ensemble des domaines du projet :
certbot certonly --nginx \
-d exemple.fr -d www.exemple.fr \
-d exemple.com -d www.exemple.com \
-d exemple.de -d exemple.esCette approche simplifie le renouvellement, puisqu’une seule commande certbot renew couvre l’ensemble des domaines. L’inconvénient apparaît si un seul domaine change de propriétaire DNS ou rencontre un problème de validation : le renouvellement de l’ensemble du certificat peut alors échouer, bloquant aussi les domaines qui fonctionnaient correctement. Sur ce projet, après discussion avec le client, j’ai préféré générer un certificat séparé par domaine, un choix plus verbeux mais qui isole totalement les incidents.
Configurer un bloc serveur distinct pour chaque nom
Sur Nginx, chaque domaine mérite son propre bloc server, même si tous pointent finalement vers la même installation WordPress. Cela permet d’associer précisément chaque nom de domaine à son certificat et d’ajouter, si besoin, des règles spécifiques à un domaine (redirection, en-tête personnalisé) sans affecter les autres.
- Un bloc
serverpar domaine, même en cas d’installation WordPress partagée, garde la configuration lisible et isolée. - La redirection HTTP vers HTTPS doit être répétée pour chaque domaine, elle ne se propage pas automatiquement entre blocs.
- Un test avec l’outil de vérification TLS de votre choix après chaque déploiement confirme que chaque domaine sert bien le bon certificat.
Le cas d’une architecture WordPress multisite
Quand les quatre domaines pointent vers une même installation WordPress en mode multisite avec domaines mappés, WordPress doit être configuré en mode « sous-domaines » ou avec une table de correspondance de domaines explicite dans wp-config.php ou via une extension de mapping de domaines. Cette configuration doit être cohérente avec les enregistrements DNS créés plus haut : un mauvais mapping affichera le contenu d’un site sur le nom de domaine d’un autre, une erreur que j’ai déjà vue en production suite à une inversion de deux lignes dans un fichier de configuration.
Sur une architecture à domaines multiples, je documente systématiquement, dans un tableau partagé avec le client, la correspondance exacte entre chaque domaine, son certificat et le site WordPress associé : cette table sert de référence en cas d’incident, plutôt que de reconstituer l’information dans l’urgence.
Prévenir les incidents de renouvellement
Un certificat expiré sur un seul des quatre domaines suffit à afficher un avertissement de sécurité aux visiteurs de cette seule version linguistique, pendant que les trois autres continuent de fonctionner normalement. Ce type d’incident partiel est plus difficile à détecter qu’une panne totale, car les alertes de monitoring globales du site peuvent rester silencieuses si elles ne surveillent qu’un seul domaine. Je recommande de configurer une surveillance de certificat indépendante pour chacun des domaines de langue, avec une alerte au moins quinze jours avant l’expiration.
En résumé
Un choix de domaines séparés par langue implique de traiter chaque domaine comme un projet d’infrastructure à part entière : ses propres enregistrements DNS, son propre certificat TLS et son propre bloc de configuration serveur, même lorsque le contenu final provient d’une seule installation WordPress. Cette rigueur, une fois documentée dans un tableau de référence partagé, évite la plupart des incidents liés à cette architecture plus exigeante qu’une simple structure en sous-dossiers.
