Temps de lecture estimé : 4 min · Publié le
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.
| Contrôle | Repère technique | Interprétation utile |
|---|---|---|
| Réponse en cache à 09:00 | TTL = 3 600 s | Expiration ordinaire à 10:00 dans cet exemple |
| Nouveau TTL publié à 09:10 | TTL = 300 s | Ne raccourcit pas rétroactivement la copie déjà en cache |
| Destination web | A / AAAA | Tester les versions IPv4 et IPv6 réellement publiées |
| Réception et authentification des emails | MX / 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
- Afnic : Gestion des domaines relevant de son registre
- IETF : RFC 1035, DNS TTL · Source consultée
- Cloudflare : Time to Live · Source consultée
- Cloudflare : DNS MX record · Source consultée
Contenu mis à jour le
Repères documentaires pour ce sujet
| Référence | Valeur ou syntaxe | Portée du repère |
|---|---|---|
| GitHub Docs · Repository backup | git clone --mirror | Le 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é.
