Conseils TI pour PME

Migration DNS PME : reprendre le contrôle avant de fermer l’ancien fournisseur

Une PME décide de changer d’hébergement ou de fournisseur web. Le nouveau site est prêt, le serveur répond, les courriels de test passent. Tout le monde veut fermer l’ancien compte pour arrêter de payer. C’est tentant. C’est aussi le moment où une migration DNS PME peut créer des problèmes si personne n’a vérifié les domaines, les enregistrements et les accès.

Panneau de brassage réseau numéroté avec câbles Ethernet bleus et gris

Changer de fournisseur web ne commence pas par déplacer le site

Le domaine n’est pas seulement l’adresse du site. Il touche souvent les sous-domaines, les certificats SSL, les formulaires, les courriels transactionnels, des redirections, parfois même des alertes de sécurité. Fermer l’ancien fournisseur trop vite peut laisser des morceaux actifs au mauvais endroit.

Registrar, DNS et hébergement : trois rôles à ne pas mélanger

Dans plusieurs dossiers, la confusion vient du vocabulaire. Le registrar est l’endroit où le nom de domaine est enregistré. Le DNS autoritaire est le service qui répond aux questions du type « où pointe ce nom? ». L’hébergement est le serveur ou la plateforme qui sert le site. Ces rôles peuvent être chez le même fournisseur, mais ce n’est pas obligatoire.

Quand une entreprise dit « notre domaine est chez l’agence », elle parle parfois du registrar, parfois du DNS, parfois seulement du site. Avant une migration, il faut savoir exactement qui contrôle quoi. Sinon, la PME peut se retrouver avec un site déplacé, mais un DNS encore lié à l’ancien fournisseur.

Les vieux sous-domaines sont des angles morts

Un domaine peut accumuler des traces. Un ancien formulaire, un sous-domaine de test, un accès FTP, une redirection temporaire, une entrée de courriel oubliée. Des années plus tard, ces enregistrements peuvent encore pointer vers une plateforme qui ne devrait plus être dans l’histoire. Ce n’est pas seulement du ménage esthétique. Cela peut générer des alertes, exposer une vieille surface ou compliquer le support.

Une migration bien gérée devrait inclure un inventaire des enregistrements. Les entrées utiles sont conservées et validées. Les entrées historiques sont supprimées ou redirigées proprement. Les courriels, formulaires et certificats sont testés. C’est moins visible qu’une page d’accueil neuve, mais c’est souvent ce qui évite les incidents après le lancement.

Il faut aussi vérifier les comptes qui recevront les alertes. Un domaine peut envoyer des avis de renouvellement, des codes de validation ou des notifications SSL à une adresse qui n’est plus surveillée. Ce détail banal peut retarder une migration ou forcer une course inutile le jour de la coupure.

Ne pas annuler l’ancien service avant la validation

Le chevauchement coûte parfois quelques jours de plus. Il vaut mieux payer ce court délai que découvrir trop tard qu’un formulaire envoyait encore par l’ancien serveur ou qu’un sous-domaine important n’a pas été reproduit. La bonne séquence est simple : transférer ou confirmer les accès, copier les enregistrements, valider le nouveau chemin, tester les formulaires et les courriels, puis seulement ensuite fermer l’ancien service.

Cette logique s’applique aussi à l’hébergement web. Un site peut répondre en HTTP 200 et quand même avoir des détails manquants : certificat mal renouvelé, redirection absente, courriel de formulaire non livré, cache qui montre une vieille version ou ancien sous-domaine encore vivant.

Une checklist simple avant la coupure

  • Accès : qui contrôle le registrar, le DNS, l’hébergement et les boîtes courriel?
  • Inventaire : tous les sous-domaines ont-ils été expliqués ou nettoyés?
  • SSL : les certificats sont-ils valides sur le nouveau chemin?
  • Formulaires : les messages partent-ils du bon serveur et arrivent-ils au bon courriel?
  • Propagation : avez-vous prévu une période où l’ancien et le nouveau chemin coexistent?
  • Validation client : quelqu’un a-t-il testé les pages et fonctions importantes avant la fermeture?

Ce n’est pas un travail spectaculaire. Personne ne voit un enregistrement DNS bien supprimé. Mais tout le monde remarque quand un site, un formulaire ou un certificat casse après une migration.

Reprendre le contrôle, puis simplifier

Une migration DNS bien gérée est une bonne occasion de réduire la dépendance à un ancien fournisseur. Centraliser le DNS dans un compte contrôlé par l’entreprise, documenter les accès et nettoyer les restes évite de répéter les mêmes recherches à chaque changement.

Si vous préparez un changement de site, d’hébergement ou de fournisseur, Infotech Canada peut revoir les domaines, les DNS, les certificats et les formulaires avant la coupure. On peut aussi noter les comptes responsables pour éviter qu’un accès critique reste dans une boîte personnelle. Vous pouvez planifier une rencontre pour valider la séquence. Le but est simple : couper l’ancien service seulement quand le nouveau chemin est réellement prêt.

Séparer les rôles

Registrar, DNS, hébergement et courriel sont quatre sujets différents.

Nettoyer les traces

Les vieux sous-domaines peuvent continuer à pointer vers un ancien fournisseur.

Valider avant de couper

Un chevauchement contrôlé évite les surprises de propagation et de courriel.

Vous changez de fournisseur web ou d’hébergement?

On peut vérifier les domaines, DNS, certificats et courriels avant de couper l’ancien service.

Planifier une rencontre

Une question précise sur votre situation? Écrivez-nous.