Un client artisan avait souscrit Google Workspace pour ses emails professionnels au lancement de son activité, quand une douzaine d’euros par mois et par boîte semblait un détail. Cinq ans plus tard, avec douze collaborateurs et autant de licences, la facture mensuelle avait pris une tout autre ampleur, alors même que son serveur WordPress, chez un hébergeur infogéré, disposait déjà d’une capacité de messagerie largement suffisante pour couvrir ce besoin sans coût supplémentaire.
La demande était claire : rapatrier les douze boîtes email vers le serveur existant, sans perdre un seul message ni interrompre la réception pendant la bascule. L’opération se décompose en deux temps bien distincts, qu’il ne faut jamais inverser : migrer le contenu des boîtes avant de basculer les enregistrements MX qui déterminent où arrivent les nouveaux messages.
Étape 1 : créer les boîtes cibles sur le nouveau serveur
Avant tout transfert de contenu, chaque boîte email doit exister côté serveur cible, avec son mot de passe et son quota définis. Sur ce serveur, la messagerie reposait sur Dovecot pour IMAP et Postfix pour l’envoi, une pile classique et bien documentée sur Debian.
doveadm user -u marie@exemple.fr
doveadm mailbox create -u marie@exemple.fr INBOX
Étape 2 : transférer le contenu via IMAP, boîte par boîte
Plutôt que d’exporter puis réimporter des archives, l’outil imapsync synchronise directement une boîte source (Google Workspace) vers une boîte destination (le nouveau serveur), en conservant les dossiers, les dates de réception et le statut lu/non lu de chaque message.
imapsync --host1 imap.gmail.com --ssl1 --user1 marie@exemple.fr --password1 'xxxx' \
--host2 mail.nouveau-serveur.fr --ssl2 --user2 marie@exemple.fr --password2 'yyyy' \
--automap --skipcrossduplicates
Le mot de passe Google Workspace utilisé ici est un mot de passe d’application dédié, généré depuis les paramètres de sécurité du compte, jamais le mot de passe principal du compte Google. Cette première synchronisation transfère l’historique complet ; une seconde exécution, juste avant la bascule finale des MX, ne rapatrie que les messages arrivés entre-temps, grâce à l’option --skipcrossduplicates qui évite les doublons.
Étape 3 : configurer les clients de messagerie en double, temporairement
Pendant la période de transition, chaque collaborateur a conservé un accès de secours à son ancienne boîte Google Workspace (en lecture seule, sans nouvel envoi), le temps de vérifier que rien ne manquait dans la boîte migrée. Cette précaution demande un peu de discipline collective, mais évite les situations de panique si un message semble manquant juste après la bascule.
Étape 4 : basculer les MX, seulement une fois le contenu vérifié
Une fois les douze boîtes synchronisées et vérifiées, les enregistrements MX du domaine ont été modifiés pour pointer vers le nouveau serveur de messagerie, avec un TTL abaissé à 300 secondes une semaine avant la bascule pour limiter la durée de propagation.
exemple.fr. 300 IN MX 10 mail.nouveau-serveur.fr.
Les anciens MX Google (aspmx.l.google.com et ses variantes régionales) ont été supprimés intégralement au même moment, jamais laissés en parallèle : deux jeux de MX simultanés répartiraient les nouveaux messages entrants de façon imprévisible entre les deux systèmes, un risque de perte de courrier à éviter absolument.
Étape 5 : la dernière synchronisation, filet de sécurité
Certains messages continuent d’arriver sur l’ancien système pendant les heures suivant la bascule, tant que la propagation DNS n’est pas complète chez tous les résolveurs. Une dernière exécution d’imapsync, 48 heures après la bascule, a rapatrié ces derniers messages égarés avant la résiliation définitive des licences Google Workspace.
- Synchroniser une première fois plusieurs jours avant la bascule pour absorber le gros du volume
- Basculer les MX un jour de faible activité, jamais un lundi matin
- Conserver l’accès Google en lecture seule au moins 72 heures après la bascule
Une migration d’emails réussie se mesure à ce qui ne se voit pas : aucun message perdu, aucune coupure de réception, aucun collaborateur qui s’en aperçoit.
En résumé
Rapatrier des emails professionnels vers un serveur propre est une opération accessible sans prestataire spécialisé, à condition de respecter l’ordre des étapes : migrer le contenu avant de toucher au DNS, jamais l’inverse. Pour ce client, l’économie annuelle a largement couvert le temps passé sur la migration, dès la première année.
