Rechercher
Saisissez au moins deux caractères, sans donnée personnelle.

    BibliothèqueArticles et FAQ Votre projetDemander un devis
    LangueFR
    Guides pratiques

    Choisir un hébergement et garder la maîtrise de son domaine

    Le domaine, le DNS, la messagerie, l’hébergement et le site peuvent dépendre de fournisseurs différents. Une décision durable commence par la liste de ces dépendances et des personnes capables d’agir.

    Voir la méthode

    Illustration de la préparation d’un projet web : Choisir un hébergement et garder la maîtrise de son domaine

    Dessiner la chaîne de fonctionnement

    Relevez le titulaire et le bureau d’enregistrement du domaine, les serveurs DNS, le fournisseur de messagerie, l’hébergeur et la plateforme du site. Pour chacun, notez le responsable opérationnel, la date de renouvellement et le moyen de contacter l’assistance. Une facture d’hébergement ne prouve pas à elle seule la propriété du domaine.

    Identifiez les liens entre ces éléments avant toute migration : un changement DNS peut affecter le site et les courriels ; un certificat ou un service de cache peut dépendre d’un autre compte. Gardez un schéma simple avec les noms des services et leurs responsabilités, sans y inscrire de mots de passe ni de secrets.

    Scénario DNS fictif, en cache ordinaire sans prolongation de réponse expirée : une réponse est reçue à 09:00 avec un TTL de 3 600 secondes. À 09:10, le serveur faisant autorité publie un TTL de 300 secondes. L’ancienne copie déjà conservée peut rester utilisable jusqu’à 10:00 ; le nouveau réglage ne lui impose pas rétroactivement une expiration à 09:15. Le TTL décrit une durée de cache en secondes, comme l’explique la RFC 1035. Préparez sa réduction avant la bascule et tenez compte de la durée précédemment publiée.

    Ce calcul sur un cache ne garantit pas une bascule mondiale à une heure donnée : d’autres caches, politiques de résolution et dépendances peuvent intervenir. Séparez les enregistrements web A et AAAA, la réception des courriels MX et les enregistrements d’authentification, notamment les TXT de SPF et DKIM selon la configuration. Si les serveurs DNS changent, inventoriez toute la zone avant de la reproduire chez le nouvel opérateur. Vérifiez le site et la messagerie séparément ; la résolution du site ou l’expiration d’un TTL ne prouvent pas le fonctionnement des courriels.

    • Titulaire du domaine et échéance de renouvellement.
    • DNS, courriel, hébergement et application identifiés séparément.
    • Responsable et canal d’assistance pour chaque composant.

    Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

    Migration DNS : distinguer cache, web et messagerie
    ContrôleRepère techniqueInterprétation utile
    Réponse en cache à 09:00TTL = 3 600 sExpiration ordinaire à 10:00 dans cet exemple
    Nouveau TTL publié à 09:10TTL = 300 sNe raccourcit pas rétroactivement la copie déjà en cache
    Destination webA / AAAATester les versions IPv4 et IPv6 réellement publiées
    Réception et authentification des emailsMX / TXT (SPF, DKIM)Inventorier et vérifier séparément de la migration web

    Comparer les offres sur un scénario réel

    Décrivez le site, les médias, le trafic, le stockage et les responsabilités avant de comparer les offres. Exemple fictif : le site et les courriels utilisent le même domaine mais deux prestataires ; une migration web doit préciser ce qui reste inchangé pour la messagerie. Faites détailler sauvegardes, restauration, certificats et assistance. Le prix d’appel ne dit pas qui reprend une panne ni quelles données seront récupérables.

    Faites chiffrer la durée pertinente, les options indispensables, le renouvellement et le travail d’exploitation qui reste à votre charge. Si des données doivent être localisées dans une zone donnée, vérifiez l’emplacement du service et les documents contractuels de l’offre choisie. Une marque peut proposer plusieurs architectures et régions.

    • Offre comparée au même périmètre et sur la même durée.
    • Sauvegarde, restauration et support décrits par écrit.
    • Coûts récurrents et de sortie visibles.

    Tester la récupération et la sortie

    Avant de confier un site, demandez comment récupérer fichiers, base de données, médias et paramètres nécessaires à une reprise. Vérifiez que les sauvegardes sont accessibles à une personne autorisée et qu’une restauration de test peut être effectuée sans écraser la production. Un simple bouton « sauvegarde » n’établit pas que le site redémarrera.

    Prévoyez un transfert de domaine distinct de la migration du site. Documentez les délais, les accès administratifs à transmettre et la personne qui valide la bascule. Le guide de transmission complète cette liste pour la fin d’un projet.

    • Export du contenu et des données essayé.
    • Restauration testée dans un environnement approprié.
    • Plan de transfert du domaine et du site distinct.

    Tenir un registre exploitable

    Tenez un registre des titulaires, fournisseurs, échéances et dépendances, avec un responsable de secours. Exemple fictif : l’adresse de récupération du domaine appartient à une personne qui quitte l’équipe ; corrigez le relais avant la prochaine échéance et vérifiez le canal d’alerte. Conservez les secrets dans un gestionnaire d’accès adapté, pas dans ce registre partagé. Réexaminez-le après chaque transfert ou changement de responsabilité.

    Le choix est satisfaisant si une autre personne autorisée peut comprendre où agir en cas de panne ou de départ du prestataire. Revoir ce document une fois par an et lors des renouvellements permet de détecter les services oubliés.

    • Registre sans secret et avec date de révision.
    • Personnes autorisées clairement désignées.
    • Procédure de remplacement du prestataire connue.

    Documents de référence

    Contenu mis à jour le

    Repères documentaires pour ce sujet

    Repères documentaires pour ce sujet
    RéférenceValeur ou syntaxePortée du repère
    GitHub Docs · Repository backup
    git clone --mirrorLe clone miroir sauvegarde le dépôt Git et son historique. Les objets Git LFS nécessitent une récupération supplémentaire et un wiki possède son propre dépôt. Pour préparer une reprise, inventorier également les données et services qui ne résident pas dans Git.

    Les dates indiquent la consultation des références. Ces repères ne constituent ni un audit du site ni une déclaration globale de conformité.

    Matrice de recette à adapter au projet

    Ces contrôles proposés utilisent des cas fictifs. Décidez du comportement attendu avec l’équipe, notez le résultat et attribuez les écarts non résolus avant publication.

    Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

    Cas de test, résultats attendus et preuves utiles
    CasRésultat attenduPreuve à conserver
    La bascule du site modifie une zone DNS qui contient la messagerie.Conserver les enregistrements nécessaires et vérifier la continuité du courriel.Valeurs DNS utiles à la messagerie et essais d’envoi et de réception après la bascule.

    Questions fréquentes

    Que vérifier quand l’adresse de récupération appartient à un ancien collaborateur ?

    Identifiez le titulaire, les personnes autorisées et la procédure du prestataire. Faites actualiser les contacts par le circuit prévu, puis vérifiez réception des alertes et capacité du relais à agir. Ne confondez pas contact opérationnel, titulaire du domaine et personne qui règle les factures.