Passer de Google Workspace à un autre hébergeur de boîtes mail prend environ une semaine et demande 3-4 heures de travail actif lorsque la migration est préparée avec soin. La clé est la réception en parallèle : configurez le nouvel hébergeur pendant que Workspace accepte encore les messages, lancez l’outil de migration IMAP pour copier l’historique en arrière-plan, puis modifiez les enregistrements MX avec un TTL DNS faible afin que la bascule prenne quelques minutes et non plusieurs heures.
De nombreux guides consacrés au départ de Google Workspace décrivent une bascule à froid qui perd des messages pendant la propagation DNS. Cette méthode perd généralement 10-50 messages selon le volume entrant. La procédure en six étapes ci-dessous évite cette perte lorsqu’elle est correctement exécutée. Les 30 minutes de préparation supplémentaires évitent de devoir rechercher plus tard ce qui est arrivé à l’e-mail d’un client pendant la première année.
Ce guide détaille la migration en six étapes avec des blocs d’enregistrements DNS concrets. Pour une vue plus large, consultez le guide pour migrer ses e-mails depuis Google Workspace.
Pourquoi quitter Google Workspace est plus simple qu’il n’y paraît
Quitter Google Workspace peut sembler intimidant, car Workspace regroupe la messagerie, l’agenda, Drive et Meet sous une même identité. Cette impression vient surtout de l’offre groupée. La messagerie seule repose sur IMAP et des enregistrements DNS, et peut être transférée proprement vers tout hébergeur compatible avec IMAP.
Le travail se divise clairement. Messagerie : 1-2 jours avec la procédure en six étapes ci-dessous. Agenda : export depuis Workspace, puis import chez le nouvel hébergeur, par exemple Fastmail Calendar, Apple Calendar ou un serveur CalDAV autohébergé. Drive : copie de type rsync vers le nouveau stockage. Meet : remplacement par Zoom ou un service similaire lors de l’inscription. Chaque composant se migre séparément, ce qui rend le projet moins impressionnant que ne le suggère l’expression « quitter Google Workspace ».
La migration en six étapes en bref
Six étapes permettent de quitter la messagerie Google Workspace sans perdre de messages entrants pendant la bascule. Leur ordre est important : le résultat de chaque étape prépare la suivante. En omettre une peut créer des lacunes en aval et faire perdre des messages en transit pendant la propagation DNS.
- Réduire le TTL DNS 48 heures à l’avance. La propagation des MX passe de plusieurs heures à quelques minutes pendant la bascule.
- Préparer le nouvel hébergeur. Ajoutez le domaine et créez les boîtes correspondantes.
- Lancer la migration IMAP en arrière-plan. Copiez l’historique depuis Workspace pendant qu’il continue à recevoir.
- Modifier les enregistrements MX. Pointez le DNS vers le nouvel hébergeur et recevez sur les deux services pendant la propagation.
- Vérifier et tester l’aller-retour. Confirmez l’authentification auprès de trois destinataires.
- Désactiver Workspace. Attendez 48-72 heures après la modification des MX, puis désactivez les boîtes Workspace.
La séquence complète prend environ une semaine. Le travail actif représente 3-4 heures réparties sur cette période. La rigueur de cette procédure évite les pertes de courrier que produisent régulièrement les migrations improvisées depuis Google Workspace.
Étape 1 : réduire le TTL DNS 48 heures à l’avance
La première étape consiste à réduire le TTL DNS des enregistrements MX 48 heures avant la bascule prévue. Le TTL par défaut des MX de Workspace est généralement de 3600, soit une heure. Réduisez-le à 300, soit cinq minutes, pour que la modification des MX à l’étape 4 se propage rapidement.
; before - default TTL
yourcompany.com. 3600 IN MX 1 aspmx.l.google.com.
; after - low TTL for cutover window
yourcompany.com. 300 IN MX 1 aspmx.l.google.com.
Modifiez le TTL de chaque enregistrement MX chez l’hébergeur DNS. Le changement se propage pendant les 1-2 heures suivantes, au rythme de l’expiration des caches. Attendez 48 heures pour que le TTL faible soit pris en compte partout. Une fois la migration terminée à l’étape 6, remontez le TTL à 3600 pour le fonctionnement habituel.
Étape 2 : préparer le nouvel hébergeur
La deuxième étape prépare le nouvel hébergeur de boîtes mail. Inscrivez-vous chez TrekMail ou auprès de l’alternative choisie. Ajoutez le domaine dans le tableau de bord, prouvez sa propriété avec l’enregistrement TXT de vérification et créez des boîtes portant les mêmes noms que dans Workspace, comme sarah.smith@ et mike.davis@. Générez les valeurs SPF, DKIM et DMARC, mais ne les publiez pas encore. Cette publication intervient à l’étape 4.
À ce stade, les nouvelles boîtes sont prêtes, mais les MX pointent toujours vers Workspace. Aucun vrai message n’arrive donc encore chez le nouvel hébergeur. Cette préparation permet à la réception en parallèle de l’étape 4 de fonctionner proprement. Pour comparer les fournisseurs, consultez les solutions de remplacement de Google Workspace.
Étape 3 : lancer la migration IMAP en arrière-plan
La troisième étape lance la migration IMAP en arrière-plan. L’outil de migration IMAP côté serveur de TrekMail prend en charge cette opération. Fournissez les identifiants IMAP de Workspace pour chaque boîte ; l’outil copie les dossiers pendant quelques heures tandis que Workspace continue de recevoir les nouveaux messages.
La plupart des migrations se terminent en 24 heures pour des boîtes de taille courante, soit 1-10GB par utilisateur. Les boîtes volumineuses, de 50GB ou plus, demandent davantage de temps. Lancez la migration avant la bascule afin que tout l’historique soit présent chez le nouvel hébergeur avant l’étape 4. Suivez l’opération dans le tableau de bord ; l’outil indique séparément les erreurs IMAP qui nécessitent une intervention sur une boîte précise.
Étape 4 : modifier les enregistrements MX
La quatrième étape modifie les enregistrements MX pour les faire pointer vers le nouvel hébergeur. Publiez les nouvelles valeurs MX ainsi que les enregistrements SPF, DKIM et DMARC générés à l’étape 2. La propagation DNS prend environ 5 minutes grâce au TTL faible défini à l’étape 1.
; new MX pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; authentication records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
Pendant la propagation, certains expéditeurs envoient encore vers Workspace tandis que d’autres utilisent le nouvel hébergeur. Les deux reçoivent en parallèle, ce qui évite les rejets liés à la bascule si les services restent correctement configurés. Gardez les boîtes Workspace actives et accessibles pendant au moins 48-72 heures après la modification des MX afin de récupérer les messages encore en transit depuis des serveurs dotés de caches DNS plus longs.
Étape 5 : vérifier et tester l’aller-retour
La cinquième étape vérifie l’authentification des messages sortants depuis le nouvel hébergeur. Envoyez un message de test depuis chaque boîte vers des comptes Gmail, Outlook.com et Yahoo. Vérifiez que les en-têtes indiquent SPF=PASS, DKIM=PASS et DMARC=PASS chez les trois destinataires. Tout résultat FAIL signifie que les enregistrements publiés à l’étape 4 doivent être corrigés avant la mise en production.
Vérifiez également la réception : envoyez un message depuis une adresse externe vers l’une des nouvelles boîtes et confirmez son arrivée chez le nouvel hébergeur en quelques minutes. S’il arrive dans Workspace, la propagation DNS n’est pas terminée. Attendez encore 10-15 minutes et recommencez. Cette vérification est indispensable ; sans elle, les problèmes de délivrabilité apparaissent à grande échelle au lieu d’être détectés pendant la bascule contrôlée.
Étape 6 : désactiver Workspace
La sixième étape désactive les boîtes Workspace 48-72 heures après le changement de MX, une fois la propagation mondiale terminée. Désactivez les boîtes depuis la console d’administration, résiliez l’abonnement à la fin de la période de facturation en cours et remontez le TTL DNS à 3600.
Avant la résiliation définitive, conservez un export des données Workspace, notamment Mail, Calendar et Drive, au cas où vous auriez besoin d’un ancien élément. Google Takeout se charge de l’export ; téléchargez-le dans un stockage local avant la fin de l’abonnement. Vous disposerez ainsi d’une sauvegarde de l’ancien environnement indépendante du nouvel hébergeur. La procédure structurée figure dans la liste de contrôle de migration des e-mails.
Étapes suivantes
La procédure en six étapes pour quitter la messagerie Google Workspace prend environ une semaine et 3-4 heures de travail actif. Lorsque la réception parallèle est correctement configurée, le nouvel hébergeur recueille les messages pendant la propagation et Workspace traite ceux qui arrivent encore sur les anciens MX, ce qui évite la perte de courrier liée à la bascule.
Essayez gratuitement TrekMail Nano sur trekmail.net/pricing, sans carte bancaire. Selon les fonctionnalités publiées, Starter à $4/month inclut l’outil de migration IMAP côté serveur nécessaire à l’étape 3. Pour les équipes centrées sur l’e-mail qui n’utilisent pas Docs et Sheets chaque jour sur la majorité des comptes, le tarif fixe de $42/year peut réduire la facture Workspace d’environ 90%+. Le contexte complet figure dans le guide de migration IMAP.
Exemple concret : une entreprise SaaS de 24 personnes à Helsinki quitte Google Workspace après plusieurs années. Dépense avant migration : $1,728/year pour Workspace Business Starter. Migration : 5 jours, comprenant la période de TTL faible, la réception parallèle et la copie IMAP de 180GB d’historique dans 24 boîtes. Dépense après migration : $96/year pour TrekMail Pro avec la même charge. Économie annuelle : $1,632, ce qui a permis dans ce cas de financer l’abonnement Notion de l’équipe tout en conservant une marge.
Deuxième exemple : une entreprise intermédiaire de 40 personnes à Tel-Aviv quitte Google Workspace Business Standard. Dépense avant migration : $5,520/year. L’audit montre que Docs et Sheets sont surtout utilisés sur 8 comptes précis, ceux de la direction et de la comptabilité. Le plan retient TrekMail Pro pour les 40 boîtes à $96/year et 8 comptes Workspace Business Starter à $576/year pour les utilisateurs travaillant beaucoup dans les documents. Dépense totale après migration : $672/year. Économie annuelle : $4,848.
Ces deux exemples montrent qu’il n’est pas nécessaire de quitter Google Workspace intégralement. Après avoir identifié les comptes qui utilisent vraiment la suite de productivité, la plupart peuvent migrer vers un hébergeur de messagerie à tarif fixe, tandis que les utilisateurs dépendant des documents restent sur Workspace. Cette répartition réduit généralement la facture de 70-90% tout en conservant la suite pour les personnes qui en ont réellement besoin.
