Un site statique devient réellement public lorsqu'il quitte son lien de prévisualisation et arrive sur un nom de domaine que vous contrôlez. C'est aussi le moment où un petit projet peut devenir fragile si les étapes sont faites dans le mauvais ordre.
DNS, www, domaine racine, certificat HTTPS, anciens liens, cache navigateur et retour arrière arrivent souvent en même temps. Le sujet n'est pas seulement technique. Il s'agit de faire une bascule propre, compréhensible et réversible.
Publier avant de changer le DNS
Le réflexe le plus sûr consiste à publier le site sous un lien de prévisualisation avant de toucher au domaine de production.
Cela permet de vérifier :
- le contenu visible ;
- le mobile ;
- les chemins d'images et de scripts ;
- les formulaires ;
- les pages légales ;
- les performances perçues ;
- la version à restaurer si une mise à jour casse le site.
Une fois ces points validés, le domaine peut être connecté avec moins d'incertitude. La page domaines personnalisés couvre ce passage du lien temporaire à l'adresse publique.
Distinguer domaine racine et www
En France comme ailleurs, beaucoup de sites utilisent deux variantes :
example.frwww.example.fr
Il faut décider laquelle sera l'adresse principale et comment l'autre redirige. Les deux doivent être cohérentes pour éviter les doublons, les erreurs de certificat ou les liens qui semblent fonctionner seulement dans certains cas.
Pour un site statique, cette décision doit être prise avant la communication publique. Une campagne, une carte de visite, un QR code ou une signature e-mail devient difficile à corriger une fois diffusé.
Vérifier les enregistrements DNS
La configuration exacte dépend du domaine et du fournisseur, mais l'objectif reste le même : faire pointer le bon nom d'hôte vers la bonne destination.
Avant la bascule, vérifiez :
| Élément | Pourquoi le vérifier |
|---|---|
| Propriété du domaine | Le projet ne doit pas accepter une adresse que vous ne contrôlez pas. |
| CNAME ou cible fournie | Une faute de copie suffit à bloquer la mise en ligne. |
| TTL | Un TTL élevé peut ralentir la propagation d'un changement. |
Variante www | Elle doit être prévue, pas découverte après le lancement. |
| Ancienne configuration | Un vieil enregistrement peut continuer à orienter une partie du trafic. |
La recherche DNS aide à inspecter les enregistrements visibles depuis l'extérieur. Ce contrôle est plus utile qu'une capture d'écran du panneau DNS.
HTTPS ne doit pas être une étape séparée
Un domaine public sans HTTPS inspire moins confiance et peut casser des fonctionnalités modernes. Le certificat doit couvrir exactement le nom utilisé par les visiteurs.
Vérifiez notamment :
- que le certificat existe pour le domaine choisi ;
- que
wwwet le domaine racine sont traités correctement ; - que les anciens liens HTTP redirigent proprement ;
- que les images, scripts et polices ne créent pas de contenu mixte ;
- que le site reste accessible après renouvellement.
L'outil de vérification SSL peut servir de contrôle externe, surtout après une migration ou une nouvelle configuration DNS.
Garder un retour arrière pendant la bascule
Le risque d'un domaine personnalisé n'est pas seulement de mal configurer le DNS. Il peut aussi révéler un bug de contenu au mauvais moment : formulaire cassé, page manquante, fichier oublié, mauvaise version publiée.
Un flux de lancement plus robuste garde :
- une prévisualisation testée ;
- une version précédente restaurable ;
- un domaine prêt mais pas communiqué trop tôt ;
- une vérification HTTPS ;
- des statistiques après mise en ligne.
La fonctionnalité retour arrière instantané sert précisément à éviter qu'une mauvaise mise à jour devienne l'état durable du site public.
À retenir
Connecter un nom de domaine n'est pas la première étape d'un site statique. Publiez d'abord, testez le lien, préparez DNS et HTTPS, puis basculez le domaine quand le projet est stable.
Ce chemin laisse le lancement rapide, mais évite de traiter une adresse publique comme une expérience improvisée.