Migrer sa messagerie de cPanel vers Microsoft 365 : le guide pas à pas d'une PME

Une messagerie hébergée chez un hébergeur mutualisé sous cPanel rend service pendant des années, puis un jour elle bloque : un client mail qui ne se connecte plus, une protection anti-bruteforce qui verrouille le compte, des mails vers Gmail qui n’arrivent pas. La réponse courte : on peut passer sur Microsoft 365 sans perdre un seul message, à condition de respecter un ordre strict. Créer le tenant, créer toutes les boîtes, copier l’historique par IMAP, et ne basculer le DNS qu’une fois la copie synchronisée. Voici le déroulé exact que nous appliquons, avec les pièges rencontrés sur le terrain.

Pourquoi quitter cPanel pour la messagerie

Un hébergement mutualisé fait cohabiter de nombreuses entreprises sur le même serveur. Les listes noires anti-bruteforce sont communes : il suffit qu’un autre client ait généré des échecs de connexion pour que vos propres outils se retrouvent bloqués. L’authentification reste par mot de passe, sans double facteur natif, et les boîtes partagées n’existent pas.

Critère	Messagerie cPanel mutualisée	Microsoft 365
Authentification	Mot de passe seul	Authentification moderne avec MFA
Boîtes partagées	Non, comptes à mot de passe partagé	Oui, gratuites, avec droits délégués
Réputation d’envoi	Liée au serveur partagé	Infrastructure Microsoft, DKIM par domaine
Calendriers et contacts	Selon le client mail	Synchronisés sur tous les appareils
Administration	Par boîte, dans cPanel	Centralisée, avec journaux d’audit

Pour la seule messagerie, la licence Business Basic suffit ; elle donne une boîte de 50 Go par utilisateur. Nous détaillons les différences entre plans dans notre comparatif Business Basic, Standard et Premium, et si vous hésitez encore avec Google, dans Microsoft 365 ou Google Workspace.

Étape 0. Inventorier avant de toucher à quoi que ce soit

La plupart des incidents de migration viennent d’un inventaire incomplet. Avant de commencer, listez :

• Toutes les adresses : boîtes nominatives, adresses de service, alias, redirections et listes de diffusion configurées dans cPanel.
• Les usages non humains : imprimantes multifonctions qui envoient des scans, site web ou formulaire de contact qui expédie des mails, logiciel métier qui envoie des factures. Chacun devra être reconfiguré.
• La zone DNS actuelle : qui la gère (hébergeur, registrar, Cloudflare), et une copie de tous les enregistrements existants.
• Les clients mail utilisés : Outlook, Thunderbird, Apple Mail, téléphones. Leur reconfiguration diffère.

Pensez aussi à réduire la durée de vie (TTL) des enregistrements MX et autodiscover quelques jours avant la bascule, pour que le changement se propage plus vite le moment venu.

Étape 1. Créer le tenant et rattacher le domaine

Le nom du tenant, en onmicrosoft.com, est définitif : choisissez-le court et propre. Ajoutez ensuite votre domaine avec un simple enregistrement TXT de vérification, et refusez la connexion automatique des services. À ce stade, le courrier doit continuer d’arriver chez l’ancien hébergeur.

Un détail qui surprend : changer son propre identifiant depuis le centre d’administration Microsoft 365 déconnecte la session avant l’enregistrement. Passez par le centre Entra, qui applique la modification sans couper la session. Activez dès maintenant le MFA sur les comptes administrateurs.

Étape 2. Préparer les boîtes de destination

Chaque adresse doit exister chez Microsoft avant la bascule, sinon les mails rebondissent. Les adresses de service, contact, support, sales, deviennent des boîtes partagées gratuites, avec un accès complet et un droit d’envoi délégués aux personnes concernées. Recréez aussi les alias et les groupes de distribution relevés à l’inventaire. Sur un tenant créé le jour même, la création peut échouer temporairement avec un message « domaine non accepté » : c’est un délai de provisionnement, pas une erreur de configuration.

Étape 3. Migrer l’historique par IMAP

Le centre d’administration Exchange propose un lot de migration IMAP : un point de terminaison vers le serveur cPanel, port 993 en SSL, et un fichier CSV avec trois colonnes, adresse cible, identifiant source, mot de passe. Microsoft copie ensuite les boîtes serveur à serveur, puis les resynchronise régulièrement jusqu’à la finalisation.

Trois pièges rencontrés :

• Le CSV doit être en virgules, sans guillemets englobants. Excel et Numbers en français produisent des points-virgules.
• Le serveur cPanel peut refuser les connexions de Microsoft, avec un « Authentication failed » trompeur alors que le mot de passe est bon. C’est la protection cPHulk qui bloque les adresses IP de Microsoft. Réduire les connexions simultanées à une, ou demander à l’hébergeur une mise en liste blanche, débloque la situation.
• La migration IMAP ne transfère que les mails et les dossiers : ni contacts, ni calendriers, ni règles de tri. Exportez-les depuis l’ancien client mail pour les réimporter dans Outlook.

Le CSV contient des mots de passe en clair : supprimez-le dès la migration terminée, et faites changer les mots de passe cPanel ensuite.

Étape 4. Basculer le DNS

Quand tous les lots affichent « Synced », cinq enregistrements suffisent pour la messagerie, tous sans proxy si vous êtes sur Cloudflare :

Enregistrement	Valeur
MX	votredomaine-com.mail.protection.outlook.com, priorité 0
TXT SPF	v=spf1 include:spf.protection.outlook.com -all
CNAME autodiscover	autodiscover.outlook.com
CNAME selector1._domainkey	fourni par Microsoft
CNAME selector2._domainkey	fourni par Microsoft

Supprimez les anciens enregistrements autodiscover de cPanel, A et SRV, sinon le CNAME ne peut pas être créé. Attention aussi au format des cibles DKIM : les tenants récents utilisent des cibles en dkim.mail.microsoft, différentes de l’ancien format en onmicrosoft.com. Copiez celles que le centre Defender affiche, puis activez la signature.

Si le site web, un logiciel ou une imprimante envoie des mails au nom du domaine depuis un autre service, ajoutez-le au SPF : un SPF en -all trop strict rejettera ces envois. Terminez par un enregistrement DMARC, d’abord en mode observation (p=none) avec une adresse de rapport, puis durci une fois les rapports propres. C’est l’une des meilleures protections contre l’usurpation de votre domaine, décrite dans notre article sur les arnaques par mail.

Étape 5. Finaliser et reconnecter les clients

Après un test de réception depuis une adresse externe, finalisez les lots de migration : une dernière synchronisation récupère les mails arrivés entre-temps. Les clients mail se reconnectent ensuite en OAuth, sans serveur ni port à saisir. Sur les téléphones, supprimez l’ancien compte IMAP avant d’ajouter le compte Microsoft 365, pour éviter les doublons.

Deux limites à connaître pour les clients tiers. Les boîtes partagées Exchange ne sont pas prises en charge par la plupart des clients autres qu’Outlook : la solution est un transfert avec copie vers la boîte principale, plus un alias pour répondre au nom de l’adresse partagée. Et un tenant neuf peut voir ses envois externes refusés avec le code 5.7.708 pendant une période transitoire, le temps que Microsoft lui accorde une réputation.

Le planning type

Moment	Actions
Avant la bascule	Inventaire, TTL réduit, tenant créé, domaine vérifié, boîtes et alias créés, MFA administrateurs
Pendant la copie	Lots IMAP lancés et suivis, export des contacts et calendriers
Soir de bascule	Lots synchronisés, DNS basculé, test de réception externe
Lendemain	Lots finalisés, postes et téléphones reconnectés, DKIM activé, imprimantes et site reconfigurés
Semaine suivante	DMARC en observation, vérification des rapports, ancien hébergement conservé puis résilié

Les erreurs les plus fréquentes

1. Basculer le MX avant que toutes les boîtes existent chez Microsoft : les mails rebondissent.
2. Oublier une adresse de service ou un alias, découvert quand un client se plaint d’un retour en erreur.
3. Oublier l’imprimante, le formulaire du site ou le logiciel de facturation, qui cessent d’envoyer.
4. Résilier l’ancien hébergement le jour même, sans pouvoir revenir en arrière ni récupérer un dossier oublié.
5. Laisser le CSV de migration, avec ses mots de passe, dans un dossier partagé.
6. S’arrêter au MX sans configurer DKIM et DMARC, et découvrir ensuite que les mails arrivent en indésirables.

Checklist de migration

• Toutes les adresses, alias, redirections et listes inventoriés.
• Usages non humains identifiés : imprimantes, site, logiciels métier.
• Copie de la zone DNS existante et TTL réduit.
• Tenant créé, domaine vérifié, MFA sur les administrateurs.
• Boîtes, boîtes partagées et alias créés chez Microsoft.
• Lots IMAP synchronisés, contacts et calendriers exportés.
• MX, SPF, autodiscover et DKIM en place, DMARC en observation.
• Test de réception et d’envoi externe réussi, délivrabilité vérifiée avec un outil comme mail-tester.
• CSV supprimé, ancien hébergement conservé quelques jours.

Comment nous procédons

Nous commençons par l’inventaire complet et un plan de bascule validé avec vous, puis nous menons la migration hors des heures de travail pour que l’activité ne soit pas interrompue. Nous gérons le DNS, reconnectons les postes et les téléphones, configurons SPF, DKIM et DMARC, et restons joignables le lendemain pour les derniers réglages. Nous proposons aussi de mettre en place dès le départ la sauvegarde de Microsoft 365, car Microsoft ne la fait pas pour vous, et le MFA pour tous les utilisateurs. En tant que partenaire Microsoft, c’est l’un des chantiers les plus courants de notre offre cloud managé Microsoft 365 ; nos réalisations en présentent d’autres.

La même méthode s’applique à une migration vers Google : voir Google Workspace au Maroc : licences et migration.

Vous voulez déléguer cette migration, avec un objectif simple : aucun mail perdu, aucune coupure visible pour vos clients ? L’audit initial est offert : contactez-nous, nous répondons sous 24 h ouvrées.