Monaco Cloud : préparer DNS et domaine (octobre 2026)

Préparer les DNS et le domaine avant une migration vers Monaco Cloud consiste à identifier les services qui utilisent chaque nom, à confirmer leurs nouvelles destinations et à organiser une bascule réversible. Commencez par un inventaire validé, des accès maîtrisés et une recette de la future installation. Le déplacement du site, le changement de prestataire DNS et le transfert du domaine sont des décisions à examiner séparément.

IPWhoisIP.fr

1. 1. InventorierNoms, usages, accès et responsables de chaque service.
2. 2. Préparer la cibleDestinations confirmées et installation de recette.
3. 3. ValiderParcours métier, messagerie et décision de départ.
4. 4. BasculerActions approuvées, contrôles et journal commun.
5. 5. Reprendre si nécessaireRetour préparé, données traitées et dossier archivé.

Ce guide s’adresse au responsable du projet, à l’agence web et à la personne qui administre les noms de domaine. Il propose un dossier de préparation pour une infrastructure envisagée à Monaco. Les exemples sont hypothétiques : ils servent à définir les questions, les preuves et les responsabilités de votre opération. Les paramètres exacts doivent venir des intervenants qui connaissent les installations concernées.

Séparer le domaine, le service DNS et l’application

Dans votre dossier, distinguez le prestataire auprès duquel le domaine est enregistré, l’équipe qui peut modifier sa zone DNS et l’équipe qui exploite le site. Ces responsabilités peuvent appartenir à une même société ou à plusieurs acteurs. Ne le déduisez pas du nom inscrit sur une facture : demandez qui possède effectivement les accès et qui peut autoriser les changements. Une agence capable de publier une page peut ne pas disposer des droits nécessaires sur le domaine.

La FAQ officielle de l’ICANN distingue le transfert entre registrars du changement d’hébergement ou d’adresse IP. Elle décrit aussi des restrictions de transfert. Un déplacement du site ne nécessite donc pas systématiquement de transférer le domaine. Vérifiez les règles de votre extension ; les informations relatives aux domaines génériques ne constituent pas automatiquement la procédure d’un domaine en .mc.

Demandez un choix explicite pour chacun de ces trois périmètres : conserver, modifier maintenant ou traiter dans un projet ultérieur. Si seule l’application change d’installation, exigez la justification d’un éventuel transfert du domaine ajouté au devis. Cette séparation réduit le nombre de décisions à prendre pendant la même fenêtre. Pour examiner le rôle du prestataire d’enregistrement, notre guide de choix d’un registrar fournit un complément à la préparation du dossier.

Construire un inventaire utilisable par chaque intervenant

Récupérez un export lisible de la zone actuelle et demandez à son responsable de confirmer sa date. Ajoutez les noms réellement utilisés par les équipes : site principal, espace client, outil de réservation, application métier, messagerie et services de test. Pour chaque nom, renseignez un propriétaire, un usage, un prestataire et une conséquence possible en cas d’erreur. Un enregistrement dont personne ne connaît la fonction doit être étudié avant la bascule, pas supprimé pour simplifier le tableau.

La RFC 1035 décrit notamment A pour une adresse IPv4, CNAME pour un nom canonique et MX pour un échangeur de messagerie. Elle définit le TTL comme une durée de conservation en cache, exprimée en secondes. Dans l’inventaire, relevez également les enregistrements AAAA et TXT présents, puis faites confirmer leur usage par le responsable du service correspondant.

Ajoutez une colonne « action prévue » et une colonne « preuve de validation ». Écrire simplement « conserver » ne suffit pas si l’ancien prestataire doit fermer son compte après le projet. Faites préciser ce qui restera actif et à quelles conditions. Conservez l’export original séparément de la version de travail, avec une personne responsable de la dernière version approuvée. Le support de réunion doit permettre de distinguer une observation, une proposition de changement et une décision déjà validée.

Vérifier les droits avant de fixer une date

Organisez une vérification des accès en présence des responsables concernés. Il faut savoir qui peut consulter la configuration, qui peut la modifier et qui approuve une intervention. Le compte principal doit être récupérable par l’organisation propriétaire du projet. Prévoyez le remplacement d’un intervenant absent et confirmez que les moyens de récupération ne dépendent pas uniquement d’une ancienne adresse professionnelle. Un accès testé plusieurs semaines auparavant peut ne plus correspondre aux personnes disponibles le jour choisi.

Le dossier ne doit pas devenir un fichier de mots de passe partagé. Référencez l’emplacement sécurisé des secrets, leur propriétaire et la procédure d’accès autorisée. Séparez le droit de valider le projet du droit technique de modifier une zone. Une personne métier peut autoriser la fenêtre d’intervention sans avoir à manipuler la configuration. Cette répartition protège aussi la traçabilité : la décision, l’exécution et la vérification doivent pouvoir être attribuées à leurs responsables.

Vérifiez l’extension du domaine et demandez la procédure applicable au prestataire concerné. Un projet situé dans la Principauté peut utiliser différentes extensions ; sa localisation ne suffit pas à déterminer les règles de gestion du nom. Si un changement de titulaire ou de registrar est envisagé, faites-le apparaître comme une opération distincte avec ses prérequis. Évitez de le découvrir pendant la migration technique, lorsque l’équipe attend déjà la possibilité de modifier la destination du site.

Obtenir les destinations réellement prévues pour le projet

Monaco Cloud présente une offre cloud hébergée en Principauté. Cette présentation ne suffit pas à choisir les valeurs à inscrire dans votre zone. Demandez à l’équipe chargée de la future installation une fiche de raccordement : noms concernés, destinations attendues, responsable de leur validation et date à partir de laquelle la recette peut commencer. Une destination copiée depuis un échange préparatoire ne doit pas être considérée comme définitive sans confirmation.

La documentation de gestion des IP publiques prévoit une demande auprès du support avant allocation. Faites intégrer cette dépendance au planning lorsque le projet en a besoin. Demandez qui effectue la demande, qui en suit le résultat et qui vérifie que la destination communiquée correspond bien à l’environnement prévu. Ce contrôle doit intervenir avant que le responsable DNS prépare une modification sur la zone utilisée par les visiteurs.

Faites également préciser qui hébergera et administrera la zone après le projet. Ne présumez pas qu’un service DNS managé est inclus dans une proposition d’infrastructure. Dans un exemple hypothétique, le domaine et les DNS restent chez leurs prestataires actuels tandis que seul le site change de destination. Dans un autre, la gestion DNS est confiée à une nouvelle équipe. Les deux dossiers demandent des vérifications différentes ; le devis et le calendrier doivent refléter le scénario effectivement retenu.

Recetter la future installation avant d’exposer les visiteurs

Demandez un environnement de vérification qui permette à l’équipe autorisée d’exécuter les parcours utiles avant la bascule publique. Le moyen d’accès doit être choisi par le responsable technique en fonction de l’application et de ses dépendances. Décrivez le résultat attendu : consulter une page, se connecter avec un compte de test, télécharger un document et utiliser un formulaire sans conséquence réelle. La personne qui valide doit disposer d’une liste de résultats observables, et pas seulement d’une adresse à ouvrir.

Préparez des données de recette et identifiez les échanges extérieurs à neutraliser ou à simuler. Un test de formulaire ne doit pas créer involontairement une demande commerciale réelle ; un test marchand ne doit pas déclencher une opération financière. Demandez comment les traitements automatiques seront contrôlés dans cette copie. L’équipe doit pouvoir vérifier le fonctionnement de l’application sans perturber les clients, les outils commerciaux ou les équipes qui continuent à travailler sur l’installation actuelle.

Consignez les anomalies dans un registre unique, avec leur gravité et leur responsable. Une page secondaire mal affichée peut recevoir une décision différente d’un accès client impossible ; ce choix appartient au commanditaire, informé par l’équipe technique. La recette doit se terminer par un accord explicite sur les anomalies acceptées et celles qui interdisent la bascule. Conservez les preuves sur les parcours prioritaires afin de les comparer aux vérifications effectuées après le changement DNS.

Construire le calendrier à partir de la configuration observée

Le planning doit intégrer les valeurs relevées dans la zone actuelle et les contraintes des équipes. Faites examiner les TTL avant de réserver la fenêtre d’intervention. Réduire une valeur ne modifie pas immédiatement les copies déjà conservées avec une ancienne durée. Demandez donc un calendrier argumenté à l’administrateur DNS, fondé sur l’état constaté, plutôt qu’une promesse générale de propagation instantanée. Notez quand chaque préparation doit être réalisée et comment son résultat sera vérifié.

Réservez une période pendant laquelle les interlocuteurs indispensables sont joignables : responsable DNS, exploitant de l’application et représentant métier capable de tester. Identifiez également les prestataires externes dont l’action pourrait être nécessaire. Une fenêtre techniquement commode peut être inadaptée si personne ne peut valider les parcours à ce moment. L’arbitrage doit porter sur le risque de perturbation et sur la capacité à réagir, pas uniquement sur le volume habituel de visiteurs.

Définissez ce qui se passe si un prérequis manque à l’heure prévue. Un report doit rester possible lorsque les destinations ne sont pas confirmées, que la recette échoue ou qu’un responsable est absent. Préparez un message interne indiquant que la fenêtre est conditionnelle jusqu’à la décision de départ. Cette règle évite que l’équipe exécute un changement incomplet pour respecter une date annoncée alors que les preuves nécessaires ne sont pas réunies.

Traiter la messagerie comme un périmètre de validation distinct

Demandez expressément si les courriels restent sur leur infrastructure actuelle. Relevez les services qui envoient des messages au nom de l’organisation : messagerie des collaborateurs, formulaires, outil commercial, facturation et notifications applicatives. Leurs propriétaires doivent confirmer ce qui demeure inchangé et ce qui nécessite une adaptation. Ne laissez pas le terme général « migration du site » masquer des changements de messagerie que le devis, la recette et l’assistance n’ont pas prévus.

Pour les enregistrements de vérification ou d’authentification présents dans la zone, faites identifier le service associé avant toute modification. Demandez au responsable de ce service quelles valeurs doivent être conservées et quelle preuve permettra de vérifier le résultat. Une chaîne TXT peu compréhensible pour l’équipe web peut encore avoir une fonction importante. La bonne question n’est pas de savoir si elle semble ancienne, mais si son propriétaire confirme son usage et autorise sa suppression éventuelle.

Construisez une recette spécifique avec des comptes de test autorisés. Vérifiez les parcours nécessaires à l’organisation : envoi depuis l’application, réception d’une notification attendue, traitement d’une réponse et fonctionnement des formulaires. Conservez le résultat et l’heure du contrôle. Si la messagerie reste hors du périmètre de migration, cette recette confirme que l’opération web n’a pas perturbé un service maintenu. Si elle change aussi, exigez un plan dédié avant d’approuver la fenêtre commune.

Coordonner une délégation ou DNSSEC sans improviser

Si la proposition comprend un changement de serveurs DNS, ouvrez un chantier de validation distinct. Demandez l’inventaire de la zone d’arrivée, l’identité de l’équipe qui l’administrera et la méthode de comparaison avec la zone actuelle. La préparation doit vérifier que tous les usages nécessaires sont représentés. Une copie limitée aux noms du site peut oublier des services moins visibles ; chacun doit avoir un propriétaire capable d’attester que son périmètre est couvert.

Faites relever l’état de DNSSEC et transmettez-le aux intervenants qui gèrent l’enregistrement du domaine et le service DNS. Demandez une procédure écrite adaptée à cette situation, avec les étapes, les dépendances, les preuves et le retour arrière. Ce guide ne remplace pas cette procédure technique. Il serait imprudent d’appliquer une suite universelle de modifications sans connaître la configuration, les responsabilités contractuelles et les mécanismes disponibles chez les prestataires concernés.

Le commanditaire doit pouvoir comprendre la décision sans exécuter lui-même les manipulations. Demandez une réponse simple : quels changements sont nécessaires, qui les effectue et quel contrôle autorise l’étape suivante ? Si les acteurs ne s’accordent pas sur cette séquence, reportez cette partie de l’opération. Étudier le maintien temporaire du service DNS actuel peut alors réduire le périmètre de la bascule applicative, à condition que cette option soit techniquement validée.

Exécuter la bascule avec un journal de décision

Avant l’intervention, réunissez la version approuvée de l’inventaire, les résultats de recette, les destinations confirmées et la liste des personnes présentes. Le responsable de la bascule vérifie les prérequis puis annonce la décision de départ. Chaque intervenant doit savoir quelle action lui appartient et quelle preuve il doit transmettre. Évitez les instructions dispersées entre plusieurs conversations : le journal commun doit indiquer l’état du projet et la prochaine décision attendue.

Après chaque changement prévu, enregistrez l’heure, l’auteur et le résultat du contrôle associé. Faites vérifier le service par une personne différente de celle qui a réalisé la modification lorsque l’organisation le permet. Pour un exemple hypothétique d’espace client, cette vérification comprendrait l’accès au compte de test, la consultation d’un dossier et le téléchargement d’une pièce. Les contrôles doivent correspondre au parcours réel, sans se limiter à constater que la page d’accueil s’affiche.

Décidez à l’avance comment traiter un résultat incohérent entre plusieurs observations. L’équipe doit pouvoir distinguer un point à surveiller d’une anomalie qui impose l’arrêt ou le retour arrière. Gardez les personnes métier informées des services disponibles et des restrictions temporaires. Une communication factuelle, fondée sur les parcours testés, est plus utile qu’un statut global « migration terminée » alors que certaines dépendances restent à vérifier.

Préparer un retour arrière compatible avec les données

Conserver les anciennes valeurs DNS est nécessaire au dossier, mais ne décrit pas toute la reprise du service. Demandez ce qui arrive aux données créées après la bascule : messages de formulaire, comptes, commandes ou documents. Une décision de retour peut nécessiter un traitement applicatif pour éviter que ces informations restent isolées dans la nouvelle installation. L’équipe qui exploite les données doit définir cette méthode avant d’autoriser des écritures réelles.

Le plan doit nommer la personne habilitée à déclencher le retour, les symptômes qui justifient cette décision et les contrôles à réaliser ensuite. Confirmez que l’ancienne installation restera utilisable pendant la période retenue et que ses accès seront disponibles. Une copie sauvegardée dont personne n’a vérifié la restauration n’est pas équivalente à un service prêt à reprendre. Le coût de cette préparation doit apparaître dans le périmètre du projet.

Répétez une version limitée du scénario dans l’environnement de recette. Notez les étapes manuelles, les dépendances oubliées et les décisions nécessitant l’accord du métier. Ajustez ensuite la procédure de bascule pour rendre le retour praticable. Notre guide sur l’historique d’un domaine peut compléter les recherches de contexte ; il ne remplace ni votre export de zone ni les preuves recueillies pendant l’intervention.

Demander un devis qui attribue les tâches et les preuves

Faites distinguer la préparation, la recette, l’intervention et le suivi après bascule. Pour chaque lot, demandez le livrable, l’interlocuteur responsable, les hypothèses et les dépendances à la charge du commanditaire. Un devis intitulé uniquement « migration DNS » ne permet pas de savoir si l’inventaire, la coordination de messagerie ou l’exercice de retour arrière sont compris. Comparez les propositions sur ces tâches avant de comparer leurs montants.

Demandez aussi comment seront traitées les demandes qui apparaissent pendant l’opération. Une modification de messagerie découverte tardivement doit recevoir une estimation de périmètre et une décision, plutôt qu’être ajoutée sans responsable. Faites préciser les conditions d’assistance après la fenêtre et les informations nécessaires pour ouvrir un incident. Vous pourrez ainsi comparer une proposition limitée à l’exécution technique avec une prestation qui comprend réellement la coordination et les vérifications.

Le livrable final est un dossier de bascule approuvé : inventaire daté, destinations confirmées, résultats de recette, responsabilités, journal et procédure de retour. Autorisez l’intervention lorsque ces éléments sont complets et les responsables disponibles. Sinon, reportez-la en indiquant précisément les pièces manquantes. Après validation des parcours en production, archivez le dossier dans un espace contrôlé par votre organisation et attribuez la maintenance du domaine et des DNS à un interlocuteur identifié.

Questions fréquentes

Faut-il transférer le domaine pour déplacer le site vers Monaco Cloud ?

Pas systématiquement. Faites examiner séparément le domaine, le service DNS et l’hébergement. Le dossier doit expliquer quels contrats et quels accès changent réellement. Si un transfert est proposé, demandez sa justification et la procédure applicable à votre extension.

Peut-on conserver le prestataire de messagerie actuel ?

Cette option doit être étudiée et confirmée dans le périmètre. Faites inventorier les services de messagerie, attribuer leurs enregistrements à un propriétaire et valider les parcours de courriel après la bascule. Ne considérez pas leur fonctionnement comme acquis au seul motif que le site répond.

Que faire si personne ne connaît un enregistrement de la zone ?

Identifiez son propriétaire avant de le modifier. Croisez l’inventaire avec les équipes métier, les anciens dossiers et les prestataires concernés. Une suppression doit être explicitement autorisée après examen de l’usage, avec un moyen de vérifier son absence d’effet sur les services conservés.

Qui doit décider du retour arrière ?

Le dossier doit nommer un décideur disposant des informations techniques et métier nécessaires. Définissez les critères avant l’intervention, ainsi que la méthode de traitement des données créées depuis la bascule. L’exploitant exécute ensuite la procédure approuvée et documente ses résultats.

À quel moment peut-on fermer l’ancienne installation ?

Après une décision explicite fondée sur la recette, les dépendances conservées et les besoins de retour arrière. Vérifiez également les exports, les accès et les obligations contractuelles applicables. La fermeture ne doit pas découler automatiquement du premier affichage réussi du nouveau site.