Nom de domaine et hébergement : choisir un socle web que l’on peut maîtriser

1. Clarifier la titularité et la gestion du domaine

Le nom de domaine doit pouvoir être administré au nom de l’organisation qui l’utilise. Relevez le titulaire, le bureau d’enregistrement, la date d’échéance, les contacts de notification et les règles de renouvellement. L’ICANN rappelle que le titulaire dispose de droits et de responsabilités dans sa relation avec le registrar. Le prestataire qui construit le site peut gérer des opérations techniques sans devenir le seul point de contrôle du nom.

Préparez une documentation d’exploitation qui indique où demander un changement DNS, qui peut l’approuver et quelles personnes doivent être informées. Ne recopiez jamais de mots de passe ou de codes de transfert dans un document public. L’objectif est de rendre la responsabilité visible et la continuité possible lors d’un changement d’équipe ou de prestataire.

• Vérifier le titulaire et les contacts auprès du registrar.
• Confirmer l’état du renouvellement et l’accès aux notifications.
• Documenter les responsabilités de décision, distinctes de l’exécution technique.
• Prévoir le transfert du domaine dans le cadre contractuel approprié.

2. Cartographier ce qui dépend des DNS

Changer un enregistrement DNS peut affecter le site, mais aussi le courrier, les sous-domaines, les outils de vérification ou des services tiers. Avant toute modification, faites un inventaire des enregistrements et de leur usage avec les personnes qui exploitent ces services. Une migration web qui fonctionne dans le navigateur peut tout de même interrompre un autre flux si cette étape est oubliée.

Le plan de changement précise ce qui doit être conservé, ce qui doit être remplacé et comment revenir à l’état précédent. Les délais de propagation et de cache varient selon les configurations ; il faut donc prévoir une période de contrôle et éviter de promettre une bascule instantanée. La vérification porte sur les services réellement utilisés, pas seulement sur la page d’accueil.

• Repérer site, messagerie, sous-domaines et vérifications de propriété.
• Conserver une copie contrôlée de la configuration avant changement.
• Tester les réponses DNS et les services dépendants après bascule.
• Définir une fenêtre d’intervention et un scénario de retour arrière.

3. Comparer l’hébergement sur les besoins du site

Le prix et l’espace disque ne suffisent pas à choisir. Décrivez le langage et la version d’exécution nécessaires, la base de données, le volume de médias, les tâches programmées, les pics de fréquentation et les besoins d’assistance. Vérifiez les limites du service proposé, les possibilités d’observation et la manière de demander une intervention lorsque le site est indisponible.

Un site de présentation stable n’exige pas la même exploitation qu’une application transactionnelle. Le bon niveau de service est celui que l’équipe peut comprendre et maintenir. Les promesses générales de rapidité ou de sécurité doivent être reliées à une configuration, à des responsabilités et à des tests concrets.

• Vérifier compatibilité applicative, stockage et ressources utiles.
• Clarifier les sauvegardes proposées et ce qui reste à la charge du site.
• Examiner les journaux, alertes et modalités de support.
• Tester la performance sur les pages importantes plutôt que se fier à une seule caractéristique commerciale.

4. Préparer disponibilité et reprise

Le service dépend de plusieurs éléments : domaine, DNS, certificats, hébergement, application, base de données et médias. Une sauvegarde des fichiers ne suffit pas si les données ou la configuration nécessaires à la remise en ligne manquent. Définissez ce qu’il faut restaurer et le temps d’interruption acceptable pour les parcours prioritaires.

Une restauration doit être essayée sur un environnement isolé, avec contrôle des fonctions essentielles et des liens. La procédure doit pouvoir être suivie par une autre personne que son auteur. Les recommandations de l’ANSSI sur les sauvegardes soulignent l’intérêt d’une stratégie adaptée et vérifiée, plutôt que la simple existence d’une copie.

• Inventorier fichiers, données, certificats et configuration nécessaires.
• Conserver des copies adaptées au risque et séparées de la production.
• Tester la restauration puis noter durée et points de blocage.
• Définir qui reçoit l’alerte et décide du retour au service.

5. Distinguer les deux types de migration

Changer d’hébergeur en gardant les mêmes URL demande principalement de contrôler la copie du site, les réponses du nouveau serveur, l’accessibilité aux robots et la bascule de l’infrastructure. Si le domaine ou les chemins changent, il faut en plus établir une correspondance d’URL, mettre en place des redirections adaptées, actualiser les canoniques et suivre l’indexation.

Les guides de Google traitent séparément le changement d’hébergement sans changement d’URL et le déplacement avec nouvelles URL. Dans les deux cas, testez le nouveau site avant la bascule et surveillez les erreurs après. Évitez d’ajouter simultanément une refonte éditoriale, un changement de CMS et un nouveau domaine si ces changements peuvent être séquencés.

• Écrire explicitement ce qui change : serveur, domaine, chemins ou contenu.
• Tester les pages prioritaires, médias, formulaires et statuts HTTP.
• Préparer une table de redirections seulement si des URL changent.
• Contrôler les versions canoniques, robots et sitemap après ouverture.

6. Organiser la transmission du socle

Un site maîtrisable peut être repris sans dépendre d’une personne unique. Conservez un inventaire des services, des échéances, des contrats, des versions d’application et des procédures de publication. Les informations sensibles restent dans les outils protégés prévus à cet effet ; la documentation éditoriale peut décrire leur emplacement et leur propriétaire sans contenir les secrets.

Avant de signer ou de migrer, demandez comment récupérer contenus, données et médias, quelles étapes dépendent du prestataire et quel support est prévu lors d’un départ. Cette vérification évite de découvrir la réversibilité au moment où une panne ou un changement de stratégie impose d’agir vite.

• Identifier les titulaires et responsables des services.
• Prévoir l’export des contenus, médias et données utiles.
• Documenter la publication, le retour arrière et les contacts de support.
• Tester périodiquement la capacité de reprise et de transmission.

Quel contrôle selon le changement envisagé ?

Avant d’avancer

La check-list opérationnelle

1. ✓Le titulaire du domaine et le registrar sont connus de l’organisation.
2. ✓Les notifications et renouvellements du domaine ont un responsable.
3. ✓Les services dépendant des DNS sont inventoriés.
4. ✓L’hébergement est compatible avec l’application et ses tâches réelles.
5. ✓Les limites du support et de la supervision sont comprises.
6. ✓La sauvegarde couvre fichiers, données et configuration utiles.
7. ✓Une restauration a été testée hors production.
8. ✓Le scénario de migration distingue les URL conservées des URL modifiées.
9. ✓Les parcours, canoniques, robots et statuts HTTP seront contrôlés après bascule.
10. ✓La récupération des données et la réversibilité sont documentées.