Migrer les e-mails de Google Workspace sans perte

Si vous tentez de migrer les e-mails de Google Workspace sans méthode, vous risquez une distribution fragmentée, des alias manquants et des utilisateurs mécontents dès le lundi matin. Il s'agit d'un basculement, pas d'un simple export par glisser-déposer. Pour commencer par une vue d'ensemble avant de choisir, consultez la messagerie professionnelle. Si le projet est déjà lancé, ce guide explique comment migrer les e-mails de Google Workspace vers un hébergeur IMAP comme TrekMail sans perturber les messages entrants.

Le piège est simple : les administrateurs se concentrent sur la copie des anciens messages et oublient la couche de routage. La messagerie ne se soucie pas que votre migration soit terminée à 92%. Dès que les enregistrements MX changent, les nouveaux messages doivent arriver quelque part. Si les alias, les groupes, le DNS et les clients ne sont pas prêts au même moment, deux réalités coexistent dans les boîtes de réception. Les utilisateurs continuent d'envoyer des messages, les clients continuent de répondre et une partie des e-mails arrive au mauvais endroit.

La solution réside dans l'ordre des opérations. Commencez par l'inventaire, puis préparez les données. Modifiez le DNS une seule fois. Reconfigurez proprement les clients. Enfin, vérifiez le nombre d'éléments plutôt que de vous fier à une impression. TrekMail convient à ce modèle grâce au stockage mutualisé, à l'hébergement multidomaine à tarif fixe, à la migration IMAP intégrée et à la prise en charge des clients IMAP/SMTP standard, sans facturation par utilisateur.

Que signifie migrer les e-mails de Google Workspace ?

Pour migrer les e-mails de Google Workspace, il faut transférer les messages stockés via IMAP, puis faire passer le routage des nouveaux e-mails de Google au nouveau fournisseur. La copie compte, mais le basculement est encore plus important. Si le routage change avant que les identités, le DNS et les clients soient prêts, les messages commencent à arriver dans les mauvaises boîtes.

Cette distinction est essentielle, car Google Workspace regroupe plusieurs types d'identités dans une seule interface d'administration. Un compte de connexion ne correspond pas à toutes les adresses qui reçoivent des messages pour une personne. Les alias partagés, les adresses de groupe, les chemins de transfert et les règles catch-all peuvent tous influer sur le basculement.

Avant de modifier le DNS, préparez correctement la destination. Dans TrekMail, cela consiste généralement à ajouter le domaine, confirmer les enregistrements DNS, créer chaque boîte aux lettres et décider quelles adresses doivent rester des alias ou devenir de véritables boîtes. Ces ressources facilitent la préparation : ajoutez un domaine, vérifiez les enregistrements DNS requis et découvrez comment TrekMail gère les migrations depuis Gmail.

Phase 1 : dresser un inventaire complet avant toute copie

Lorsque vous migrez les e-mails de Google Workspace, la première véritable tâche consiste à identifier chaque adresse capable de recevoir des messages. Les utilisateurs principaux sont évidents. Les alias, les groupes et les anciennes règles de routage sont à l'origine des échecs. Si vous oubliez ces adresses, le basculement DNS les transforme en rejets définitifs ou en voies sans issue silencieuses.

Commencez par quatre listes :

1. Les utilisateurs principaux et la taille de leur boîte aux lettres.
2. Tous les alias associés à chaque utilisateur.
3. Les groupes Google qui reçoivent encore de vrais messages entrants.
4. Les transferts, les catch-all et les anciennes adresses qui figurent encore sur des factures, formulaires de contact ou signatures.

C'est pourquoi un simple export depuis l'interface d'administration ne suffit pas. Une commerciale peut se connecter avec jane@company.com tout en recevant encore des messages à sales@company.com, quotes@company.com et sur le domaine d'une ancienne acquisition que personne n'a documenté. Oubliez une seule de ces adresses et le basculement semblera défaillant même si le DNS est correct. Pour migrer proprement les e-mails de Google Workspace, chaque adresse routable doit avoir une destination.

Pour extraire les données de Google, les équipes utilisent souvent GAM ou le SDK d'administration afin d'établir une carte complète du routage. L'outil précis importe moins que le résultat : chaque adresse routable doit disposer d'un emplacement explicite dans le système de destination avant la migration des e-mails de Google Workspace.

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

Pendant que vous organisez ces adresses, déterminez ce que chaque identité doit devenir chez le nouvel hébergeur :

Pour choisir rapidement entre ces formes d'identité, consultez alias de domaine ou boîte aux lettres. De nombreuses erreurs de migration commencent à ce stade.

Phase 2 : préparer les données, car Google limite le débit IMAP

Pour migrer les e-mails de Google Workspace à une échelle significative, une phase de préchargement est indispensable. Google documente des limites de bande passante IMAP qui plafonnent le volume téléchargé et envoyé par compte et par jour. Les grandes boîtes ne seront pas transférées en un seul week-end, même avec le calendrier le plus optimiste.

Google publie les limites de bande passante Gmail pour les comptes Workspace : le téléchargement IMAP est limité à 2,500 MB par jour et l'envoi IMAP à 500 MB par jour. C'est une contrainte concrète de la migration, pas une simple recommandation. Le transfert de tout l'historique d'une boîte de 50 GB via IMAP peut prendre plusieurs semaines.

La bonne méthode est donc la suivante :

1. Précharger les anciens e-mails pendant que les utilisateurs travaillent encore dans Google.
2. Effectuer des synchronisations différentielles les jours précédant le basculement.
3. Transférer les messages les plus récents après le changement DNS ou pendant la dernière fenêtre de synchronisation.

Pour les utilisateurs ayant beaucoup de données, divisez le travail par période si votre outil le permet. Le processus de migration TrekMail prend en charge les imports échelonnés grâce à son flux de migration IMAP. Il devient ainsi beaucoup plus pratique de migrer les e-mails de Google Workspace par lots plutôt que de lancer une copie intégrale à l'aveugle.

Exemple : si le service comptable possède une boîte de 36 GB, mais n'a besoin immédiatement que des derniers 90 jours, importez d'abord les dossiers récents, basculez le flux de messagerie, puis transférez les archives une fois la production stabilisée.

Les consignes actuelles de Google sur la connexion ont également leur importance. L'ancienne authentification basique a disparu dans la plupart des cas, les mots de passe d'application restant la principale exception pour les configurations compatibles. Pour une migration dont Gmail est la source, la documentation actuelle de TrekMail recommande d'utiliser un mot de passe d'application Gmail plutôt que le mot de passe normal du compte lorsque la politique Google l'exige. Consultez l'aide de Google sur les mots de passe d'application.

Phase 3 : modifier le DNS une seule fois, dans le bon ordre

Lors de la migration des e-mails de Google Workspace, le DNS constitue le point de bascule qui détermine où arrivent les nouveaux messages. Réduisez le TTL à l'avance, publiez les nouveaux enregistrements d'authentification et ne modifiez les MX qu'une fois les boîtes et alias de destination créés. En inversant cet ordre, vous provoquez une distribution fragmentée.

La bonne séquence est volontairement prévisible. Deux jours avant le basculement, réduisez à 300 secondes le TTL des enregistrements MX, SPF et DMARC. La veille, publiez le DKIM du fournisseur de destination. Au moment du basculement, remplacez les MX de Google par ceux de TrekMail. Vérifiez ensuite la propagation depuis un résolveur public au lieu de faire confiance au cache de votre ordinateur.

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

Pendant la période de chevauchement, conservez Google et TrekMail dans le SPF si des messages peuvent encore partir des deux systèmes. Cette approche respecte la RFC 7208. Surveillez la limite de 10 recherches DNS. Si votre enregistrement contient déjà trop de fournisseurs, simplifiez-le avant de migrer les e-mails de Google Workspace.

Si vous prévoyez de répéter l'opération pour de nombreux domaines clients, TrekMail commence ici à rentabiliser son coût. L'ancienne méthode consiste à modifier le DNS et les paramètres de boîte domaine par domaine tout en payant par utilisateur. La nouvelle repose sur une plateforme à tarif fixe avec gestion multidomaine, stockage mutualisé, assistant DNS et migration intégrée.

Phase 4 : reconfigurer les clients, pas seulement le mot de passe

Après la migration des e-mails de Google Workspace, de nombreuses demandes d'assistance ressemblent à des erreurs de mot de passe, mais ont une autre cause. Les clients configurés pour Google conservent souvent des attentes liées à OAuth, des données de détection automatique en cache ou les préréglages de l'ancien fournisseur. Les utilisateurs ont besoin d'une configuration IMAP propre pointant vers le nouvel hébergeur, et non d'une succession de tentatives de mot de passe.

Les appareils mobiles et Outlook sont les plus touchés. Sur leur téléphone, les utilisateurs choisissent volontiers le logo Google pendant la configuration parce qu'il leur est familier. Ce choix est incorrect après le basculement. Dans Outlook, les anciens profils peuvent continuer à essayer de joindre Google alors que les MX pointent déjà ailleurs.

Utilisez les paramètres IMAP directs de TrekMail :

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

Sur iPhone et Android, demandez aux utilisateurs de supprimer l'ancien compte Google et d'ajouter à nouveau la boîte sous Autre ou IMAP. Dans Outlook pour ordinateur, créez un nouveau profil de messagerie plutôt que de réparer l'ancien. Pour suivre les étapes exactes, les guides clients de TrekMail présentent les paramètres IMAP/SMTP. Vous pouvez les compléter par le guide publié sur imapsync si vous avez besoin d'une procédure de migration plus manuelle.

Autre précision : TrekMail est un hébergement IMAP fondé sur les standards. Il ne propose pas POP3 et ne prétend pas être Exchange. Si un appareil ou un utilisateur s'obstine à suivre les processus propriétaires de Google ou Microsoft, vous perdrez du temps sur le mauvais protocole.

Phase 5 : vérifier avec des décomptes et simplifier le retour arrière

Pour migrer les e-mails de Google Workspace en toute sécurité, contrôlez l'état des boîtes à partir du nombre de messages par dossier et du flux réel, pas du total en gigaoctets. La vue de stockage de Google tient compte de la compression et d'éléments autres que les e-mails, qui ne correspondent pas directement aux destinations IMAP. Comptez les messages. Confirmez la réception et l'envoi de nouveaux e-mails. Vous pourrez alors valider le basculement.

Votre liste de contrôle minimale doit inclure les points suivants :

1. Les nombres de messages par dossier sont suffisamment proches dans chaque boîte essentielle.
2. Après propagation des MX, les messages de test entrants arrivent uniquement dans TrekMail.
3. Les messages sortants passent les contrôles SPF, DKIM et DMARC.
4. Les alias et les adresses partagées distribuent les messages exactement à la destination prévue.
5. Les utilisateurs peuvent se connecter sur ordinateur et appareil mobile avec les nouveaux paramètres.

De petits écarts de décompte peuvent être normaux. Les messages corrompus, les invitations endommagées et certains éléments vides atypiques ne survivent pas toujours au transfert IMAP. En revanche, les nouveaux messages entrants ne doivent pas continuer à arriver dans Google une fois la migration supposée terminée. Si c'est le cas, la migration des e-mails de Google Workspace n'est pas encore complète.

Le retour arrière doit être direct et rapide. Si la réception échoue largement, redirigez les MX vers Google pendant que le TTL reste faible. Exportez ensuite les messages arrivés sur le nouvel hébergeur pendant la période problématique et réinjectez-les si nécessaire. Un plan de retour arrière impossible à exécuter en cinq minutes n'en est pas un.

Ancienne méthode et nouvelle méthode : pourquoi les équipes choisissent TrekMail

Si vous migrez régulièrement des e-mails de Google Workspace, le coût réel ne se limite pas au prix des licences. Il comprend aussi les tâches administratives répétées autour des domaines, de la création des boîtes, de la reconfiguration des clients et des nouvelles tentatives de migration. TrekMail réduit ce travail grâce à un modèle multidomaine à tarif fixe, conçu pour les équipes d'exploitation plutôt que pour des feuilles de calcul par utilisateur.

TrekMail propose les domaines personnalisés, les boîtes IMAP, le catch-all, le transfert de boîte, votre propre SMTP ou un SMTP inclus selon l'offre, ainsi que la migration côté serveur. L'offre Nano reste gratuite et ne nécessite pas de carte. Les offres payantes incluent un essai gratuit de 14-day, qui requiert une carte bancaire. Si vous gérez une marque aujourd'hui et vingt domaines clients le trimestre prochain, ce modèle tarifaire peut faire la différence entre une activité rentable et un fonctionnement chaotique.

Pour les équipes qui gèrent de nombreuses boîtes simultanément, l'avantage opérationnel ressemble beaucoup à celui de l'hébergement de messagerie multidomaine : un seul tableau de bord, moins d'éléments à coordonner et aucun piège de facturation par utilisateur chaque fois qu'un client ajoute une boîte.

Pour migrer les e-mails de Google Workspace sans transformer le basculement en urgence de fin de semaine, commencez par consulter les tarifs de TrekMail. Préparez d'abord la destination. Préchargez les messages. Modifiez le DNS une fois. Puis vérifiez le résultat avec rigueur.