Gandi ou o2switch : nom de domaine, hébergement et migration

La comparaison « o2switch gandi » revient dès qu’un projet web quitte le stade du brouillon, et elle repose sur un malentendu fréquent : ces deux prestataires ne vendent pas exactement le même service. L’un s’est construit comme bureau d’enregistrement de noms de domaine avant d’ajouter de l’hébergement, l’autre comme hébergeur mutualisé qui enregistre aussi des domaines. La vraie question n’est donc pas de désigner un vainqueur, mais de décider si le nom de domaine et le serveur doivent vivre chez le même prestataire ou chez deux acteurs distincts. Ce choix engage la réversibilité du projet, la difficulté des migrations futures et la rapidité de réaction en cas d’incident. Les mécanismes qui suivent valent pour n’importe quel couple de prestataires.

Regrouper ou séparer : deux stratégies défendables

Tout regrouper chez un seul prestataire présente des avantages concrets. Une facture unique, un seul interlocuteur d’assistance, et surtout une configuration automatique : quand le domaine et le serveur appartiennent au même compte, les enregistrements techniques se posent tout seuls, le certificat de chiffrement s’émet sans intervention, la messagerie se branche sans manipulation de la zone. Pour une personne qui découvre le sujet, ce gain de simplicité est réel et légitime.

La séparation répond à une autre logique, celle de la réduction du risque. Le nom de domaine est le seul actif véritablement irremplaçable d’un projet web : les fichiers se restaurent, la base de données se sauvegarde, le nom, lui, ne se recrée pas. Le confier à un acteur dont ce n’est pas le métier principal, ou au même acteur que celui qui héberge, concentre le risque. Un litige commercial, une suspension de compte, une défaillance technique touchent alors les deux services au même instant, et le domaine devient l’otage de l’incident.

La séparation offre aussi une liberté de manœuvre. Changer d’hébergeur devient un simple changement d’adresse dans la zone du domaine, opération réversible en quelques minutes, alors qu’un déménagement complet impose de transférer aussi le nom, avec ses délais et ses codes. Cette souplesse compte dès qu’un projet est amené à évoluer.

Pour un site personnel ou une vitrine stable, le regroupement reste défendable. Pour un projet professionnel qui génère du chiffre d’affaires, la séparation est le choix le plus prudent, quitte à assumer une configuration manuelle au démarrage. Le duo o2switch gandi illustre bien cette répartition : un acteur qui excelle sur la gestion de noms et un autre sur l’hébergement mutualisé, chacun sur son terrain, sans dépendance croisée. Les critères de jugement d’une offre d’hébergement sont détaillés dans notre décryptage de l’offre unique en mutualisé.

Serveurs de noms et zone DNS : la mécanique réelle

Deux niveaux de réglage se confondent souvent dans l’esprit des débutants, et la confusion coûte cher lors des migrations.

Le premier niveau est celui des serveurs de noms, parfois appelés NS. Ils se déclarent chez le bureau d’enregistrement et répondent à une seule question : quelle machine fait autorité pour dire où pointe ce domaine. Changer de serveurs de noms revient à déménager tout le carnet d’adresses du domaine chez un autre gestionnaire. L’opération est globale et affecte simultanément le site, la messagerie, les sous domaines.

Le second niveau est celui de la zone DNS elle même, l’ensemble des enregistrements gérés par ces serveurs de noms. On y trouve les enregistrements de type A qui associent un nom à une adresse de serveur, les CNAME qui font pointer un nom vers un autre, les MX qui désignent le serveur de messagerie, et les enregistrements de texte utilisés pour l’authentification du courrier ou la validation de propriété auprès des moteurs de recherche.

La distinction devient opérationnelle au moment de migrer. Modifier un seul enregistrement A pour faire basculer le site vers un nouveau serveur, en laissant les MX intacts, permet de déplacer le site sans toucher aux courriels. Basculer les serveurs de noms, à l’inverse, emporte tout, et si la zone n’a pas été recopiée à l’identique chez le nouveau gestionnaire, la messagerie tombe le jour même. Cette erreur est la plus fréquente des migrations ratées.

Chaque enregistrement porte une durée de vie, exprimée en secondes, qui indique aux résolveurs combien de temps conserver la réponse en mémoire. Abaisser cette valeur quelques jours avant une bascule accélère considérablement la propagation, technique simple et systématiquement oubliée.

Un dernier réflexe évite bien des nuits blanches : documenter la zone avant d’y toucher. Un export complet des enregistrements, conservé hors du panneau d’administration, permet de revenir à l’état antérieur en quelques minutes si la bascule tourne mal. Beaucoup de gestionnaires proposent cet export en un clic, et beaucoup d’utilisateurs découvrent son existence le jour où ils en auraient eu besoin la veille.

Transférer un nom de domaine : les règles à connaître

Le transfert d’un domaine d’un bureau d’enregistrement à un autre obéit à des règles standardisées, avec quelques variantes selon l’extension.

Le domaine doit d’abord être déverrouillé. Un verrou de transfert, activé par défaut chez la plupart des acteurs sérieux, empêche toute sortie non autorisée : c’est une protection contre le détournement, à désactiver volontairement le temps de l’opération. Le titulaire récupère ensuite un code d’autorisation, chaîne unique fournie par le bureau d’enregistrement actuel, valable un temps limité et qui prouve la légitimité de la demande.

Deux délais bloquent les transferts. Un domaine fraîchement enregistré ne peut généralement pas être transféré avant une soixantaine de jours, et le même verrou s’applique souvent après un changement de titulaire. Un transfert réalisé dans la précipitation, juste avant une échéance de renouvellement, expose au pire scénario : une expiration pendant la procédure.

Le point rassurant est que le transfert ne coupe rien. Le domaine continue de pointer vers ses serveurs de noms pendant toute l’opération, le site et la messagerie restent en ligne. Ce sont les modifications de zone qui provoquent des interruptions, jamais le changement de bureau d’enregistrement en lui même. Le transfert ajoute d’ailleurs généralement une année de validité au domaine, ce qui en fait une opération neutre financièrement plutôt qu’un coût sec.

L’adresse électronique associée au contact administratif joue un rôle décisif : c’est elle qui reçoit les demandes de validation. Une adresse hébergée sur le domaine en cours de transfert, ou une ancienne adresse dont personne ne relève plus la boîte, suffit à faire échouer la procédure. Vérifier ce point avant d’engager quoi que ce soit prend deux minutes.

Reste la question de la propriété. Le titulaire déclaré dans les registres est le propriétaire légal du nom. Quand un prestataire enregistre un domaine pour le compte de son client, la vigilance s’impose : le titulaire doit être le client, jamais l’agence. Ce point figure parmi les livrables à contractualiser abordés dans notre article sur le métier de webdesigner intégrateur.

o2switch gandi : migrer un site entre hébergeurs sans coupure

Une migration réussie repose sur un principe unique : le site tourne à l’identique sur le nouveau serveur avant que le moindre visiteur n’y soit envoyé. Tout le reste découle de là.

La phase de recette mérite un mot. Tester un site sur son futur serveur sans y avoir encore dirigé le domaine se fait en forçant localement la correspondance entre le nom et la nouvelle adresse, ce qui permet de naviguer comme un visiteur réel pendant que le public reste sur l’ancien serveur. Cette précaution révèle les chemins codés en dur, les extensions bloquantes et les incompatibilités de version de PHP avant qu’elles ne deviennent visibles.

La période de propagation, souvent redoutée, dure de quelques minutes à quelques heures selon la durée de vie configurée. Pendant ce laps de temps, une partie des visiteurs atteint l’ancien serveur et une autre le nouveau. Garder les deux serveurs actifs et synchronisés en lecture évite toute erreur affichée. Un contrôle du temps de réponse serveur après bascule ferme la boucle, en comparant les mesures relevées avant l’opération sur les mêmes pages et aux mêmes heures.

Le sort de la messagerie, angle mort des migrations

Les courriels sont ce qui casse le plus souvent, et ce qui se remarque le plus tard. Un site inaccessible se voit en dix secondes, une messagerie qui n’arrive plus met parfois deux jours à se signaler, et les messages perdus pendant l’intervalle ne se rattrapent pas.

Trois précautions couvrent l’essentiel. Récupérer d’abord l’intégralité des messages existants en local avant toute manipulation, par un protocole qui télécharge réellement les contenus. Recopier ensuite à l’identique les enregistrements MX et les enregistrements de texte d’authentification chez le nouveau gestionnaire, avant de basculer quoi que ce soit. Envoyer enfin un message de test depuis et vers une adresse extérieure une fois la bascule effectuée, dans les deux sens.

Une migration de messagerie peut d’ailleurs être découplée de celle du site. Rien n’oblige à déplacer les deux le même jour, et beaucoup de projets gagnent à confier les courriels à un service dédié, indépendant de l’hébergeur du site, ce qui simplifie durablement toutes les migrations suivantes.

La sécurisation des accès mérite la même attention pendant l’opération : identifiants temporaires, comptes de service, clés d’échange créés pour la migration doivent être révoqués une fois celle ci terminée, principe développé dans notre checklist de sécurisation WordPress.

Choisir entre deux prestataires compte finalement moins que la manière dont le projet est câblé. Un domaine dont le titulaire est correct, une zone documentée, des sauvegardes restaurables et une messagerie autonome rendent n’importe quel changement d’hébergeur presque anodin.