Changer d'hébergeur au Maroc : la méthode sans coupure

Un changement d'hébergeur met en jeu deux hébergements qui peuvent parfaitement tourner en même temps. Rien ne vous oblige à éteindre l'un pour allumer l'autre : la source continue de servir le site pendant que la destination est montée, remplie et testée. Le seul commutateur, c'est le DNS — et il ne bascule pas d'un coup.

C'est de là que vient le risque réel, et ce n'est pas la page blanche. Pendant la fenêtre où les résolveurs n'ont pas tous la même réponse, une partie de vos visiteurs atteint encore l'ancien serveur et une autre le nouveau. Les deux affichent le site. Mais une commande passée, un formulaire envoyé, un article publié ou un e-mail reçu du mauvais côté n'existe que de ce côté-là — et disparaît le jour où vous coupez l'ancien hébergement. La coupure qu'on redoute est visible ; celle qui coûte cher ne l'est pas.

Chaque enregistrement DNS porte une durée de vie — son TTL. Les résolveurs gardent la réponse en cache pendant cette durée et ne reviennent pas la chercher avant. Tant que le TTL courant n'a pas expiré, votre nouvelle adresse n'existe pas pour eux, quoi que dise votre zone.

D'où la seule règle qui compte, et l'erreur la plus fréquente : le TTL se baisse avant, et il faut le baisser au moins une durée égale à l'ancien TTL avant la bascule. C'est ce qu'il faut pour que tous les caches aient eu l'occasion de relire l'enregistrement et d'apprendre la nouvelle valeur, courte. Baisser le TTL au moment de basculer ne sert à rien : à cet instant, les résolveurs servent encore la réponse mise en cache sous l'ancienne durée.

Un cas particulier mérite d'être repéré tôt : si votre zone DNS est hébergée chez l'hébergeur que vous quittez, changer de serveurs de noms est lui-même soumis au même mécanisme, et il emporte tout le reste avec lui. Déplacer la zone d'abord, séparément, évite d'empiler deux propagations sur la même journée.

Une fois la bascule faite et tout vérifié, on remonte le TTL : en régime permanent, un TTL court multiplie les requêtes pour rien.

Un site est un objet figé qu'on recopie ; une boîte e-mail est un objet vivant qui continue de recevoir pendant qu'on la recopie. C'est toute la différence, et c'est là que la plupart des migrations perdent des données.

La séquence qui tient : on synchronise une première fois les boîtes vers la destination, on bascule les MX, on laisse l'ancien serveur continuer à recevoir ce qui lui arrive encore, puis on refait une synchronisation avant de couper. Un compte e-mail source ne se supprime jamais tant qu'il reçoit quelque chose — et il en reçoit encore bien après que le site, lui, a basculé.

Deux détails ressemblent à des pannes sans en être. D'abord, les logiciels de messagerie de vos postes gardent en configuration les serveurs entrant et sortant de l'ancien hébergement : tant qu'ils ne sont pas reconfigurés, ils relèvent l'ancienne boîte, pas la nouvelle. Ensuite, l'authentification du courrier — SPF, DKIM, DMARC — vit dans la zone DNS, pas dans la boîte : changer de serveur d'envoi sans reprendre ces enregistrements fait partir du courrier parfaitement légitime dans les indésirables. Ils se recréent avec les valeurs du nouveau serveur, et se vérifient avant de couper l'ancien.

Deux opérations se confondent souvent : déplacer l'hébergement (fichiers, base, e-mails) et transférer le nom de domaine vers un autre bureau d'enregistrement. Elles sont indépendantes. On peut changer d'hébergeur en laissant le domaine où il est et ne le transférer qu'ensuite — c'est même l'ordre le plus prudent, puisqu'il évite de faire bouger deux choses le même jour.

Pour un .ma, le transfert obéit aux règles du registre national, tenu par l'ANRT, l'Agence Nationale de Réglementation des Télécommunications. Seuls les prestataires qu'elle accrédite peuvent opérer directement sur ce registre ; les autres passent par un intermédiaire. MEGALOGI, éditeur de la plateforme, figure parmi ces prestataires accrédités.

Trois conditions techniques doivent être réunies avant de déposer la demande : le domaine doit être actif depuis 60 jours au moins, son verrou de transfert doit avoir été levé chez le prestataire actuel, et le code d'autorisation (EPP) doit vous avoir été communiqué. S'y ajoute une pièce que les extensions génériques n'exigent pas systématiquement : le registre demande une copie de la pièce du titulaire — CIN, passeport ou carte de séjour pour un particulier, justificatif d'entreprise (ICE ou RC) pour une société.

Deux vérifications valent d'être faites avant, pas après. Qui est le titulaire déclaré : si c'est votre prestataire actuel et non vous, le transfert dépend de son accord, et ce n'est plus une question technique. Et où la zone DNS est réellement servie : un changement de bureau d'enregistrement ne recopie pas le contenu d'une zone hébergée chez celui que vous quittez.

Changer d'hébergeur ne déplace pas que des fichiers : ça change aussi la pièce comptable que vous recevez à chaque échéance. Une facture émise hors du Maroc, dans une devise étrangère, sans TVA marocaine ni identifiants légaux marocains, n'est pas la même pièce qu'une facture marocaine — et la différence se voit en comptabilité, pas à l'écran.

Trois lignes changent concrètement. La devise dans laquelle votre compte est débité : facturé en dirhams, il n'y a ni taux de change appliqué par votre banque, ni frais associés. La TVA, qui apparaît sur la facture au taux de 20% — les montants du site étant affichés hors taxes (HT). Et l'émetteur : une facture marocaine porte l'IF, l'ICE et le RC de la société qui l'émet, ce que votre comptabilité attend. Le règlement se fait par Carte bancaire — CMI, PayPal et Virement bancaire.

Un point d'organisation évite une mauvaise surprise : la double période a un coût. Tant que les deux hébergements tournent, les deux sont facturés. Ce n'est pas un risque, c'est une ligne à prévoir — et c'est le prix réel de la méthode. Autant faire coïncider la coupure de l'ancien contrat avec une échéance plutôt qu'avec le milieu d'un cycle.

Dernier point, dit en clair plutôt que deviné : nos centres de données sont en Europe. Changer de fournisseur déplace une facture, une relation contractuelle et un panneau d'administration — pas la position géographique de vos serveurs.