Migrer des comptes email : plusieurs boîtes et bascule MX

Migrer des comptes email d'entreprise ne revient pas à copier une boîte personnelle. Les messages arrivent, les utilisateurs répondent et les alias distribuent du courrier; un enregistrement DNS oublié peut répartir la réception entre deux systèmes. Inventoriez d'abord, préparez la copie ensuite et basculez à la fin. Pour le contexte opérationnel, consultez ce guide de messagerie professionnelle avant de modifier DNS.

Le scénario est connu : export PST, dossiers glissés dans Outlook, toutes les adresses considérées comme des boîtes. Le lundi, sales@ ne reçoit plus, une grande boîte copie encore et personne ne sait quel serveur contient les données complètes. Traitez la migration comme une infrastructure active, pas comme une copie de fichiers.

Ce guide explique comment migrer des comptes email avec un processus contrôlé : voie manuelle IMAP, ordre de bascule, points de panne importants et option intégrée TrekMail pour équipes, agences et prestataires souhaitant réduire la maintenance de scripts.

Que signifie migrer des comptes email ?

Vous copiez le contenu entre serveurs IMAP, reconstruisez alias et transferts et, si vous déplacez la réception d'un domaine propre, modifiez DNS lorsque la destination est prête. La copie ne transfère pas automatiquement l'adresse d'un compte personnel et ne garantit pas l'absence de perte.

Cette distinction importe : IMAP copie dossiers et états compatibles, pas tout ce qui entoure la boîte. La RFC 3501 décrit accès et manipulation des messages, pas l'export complet d'une identité d'entreprise.

Il s'agit donc de trois tâches :

1. Copier messages et structure des dossiers.
2. Reconstruire alias, listes de diffusion et transferts avec leurs autorisations.
3. Modifier DNS au moment approprié si la réception d'un domaine contrôlé change.

Oublier une tâche nécessaire laisse la migration incomplète et peut provoquer des demandes d'assistance.

Ce qu'IMAP copie et ce qui reste à reconstruire

IMAP permet de copier messages, dossiers et généralement état de lecture selon la source et l'outil. Il ne copie pas calendriers, contacts, tâches, signatures locales ni règles des clients ou serveurs; prévoyez un processus séparé avant que les utilisateurs ne s'attendent à les retrouver.

Définissez le périmètre par écrit. La migration TrekMail utilise IMAP; elle ne clone pas une plateforme collaborative. Les instructions portent sur serveur, port, utilisateur, mot de passe et boîte cible, pas sur calendriers ou planification partagée.

Utilisez cette référence :

La dernière ligne est souvent oubliée. Consultez ce guide des alias et boîtes mail pour distinguer adresses de distribution et véritables boîtes et limiter les corrections ultérieures.

Inventorier avant la migration

Avant de synchroniser, inventoriez boîtes, alias, groupes, règles de transfert, quotas et grandes boîtes. Associez chaque objet à sa destination et à sa vague de migration.

Un export des utilisateurs ne suffit pas : recherchez aussi les objets moins visibles.

Au minimum, contrôlez :

1. Boîtes principales : comptes actifs, partagés et fonctionnels.
2. Alias : adresses supplémentaires livrant dans une autre boîte.
3. Listes et groupes : objets de distribution sans boîte IMAP ordinaire.
4. Transferts : règles serveur comme info@ vers owner@, avec autorisations et restrictions.
5. Adresse fourre-tout : décider de la conserver, limiter ou supprimer.
6. Grandes boîtes : prévoir une préparation anticipée et une marge suffisante.

Les grandes boîtes influencent le calendrier. Le fournisseur peut limiter IMAP et la copie durer des jours plutôt que des heures. Ne promettez pas un week-end pour des années de pièces jointes sans politique d'archivage.

Exemple illustratif : une bascule est prévue vendredi pour 60 utilisateurs. Une boîte de direction contient 48 Go. Dimanche, 59 utilisateurs ont terminé et cette boîte synchronise encore. Taille et limites doivent figurer dans le plan, pas devenir un délai garanti.

Si vous standardisez aussi la création des comptes, utilisez une liste de provisionnement telle que ce guide de création groupée de comptes email. Les erreurs peuvent commencer dans cette préparation, pas seulement dans DNS.

Plan par vagues pour plusieurs boîtes

Préférez des vagues à une bascule unique. Le pilote valide identifiants, dossiers et accès; la préparation copie l'historique; la dernière vague coordonne changements et transition de réception.

Voici la séquence pratique :

Vague 1 : pilote

Commencez par un petit échantillon : personnel technique, comptes de test et un utilisateur représentatif. Vérifiez TLS, chaîne de certificats et nom du serveur sur 993, identifiants et correspondance des dossiers de messages envoyés, brouillons, archives et dossiers personnalisés.

Vague 2 : préparation

Commencez avant le week-end prévu. Copier l'historique à l'avance évite d'attendre des années de courrier alors que le nouveau MX est déjà actif.

Vague 3 : changements et bascule

Validez copie préalable et destination avant de modifier MX pour votre domaine propre. Synchronisez les changements et répétez les passes après : incluez arrivées tardives datées auparavant, déplacements et indicateurs. Gardez réception et accès administratif sur la source tant que caches et nouvelles tentatives SMTP peuvent y apporter du courrier.

Vous réduisez ainsi la dépendance aux limites du fournisseur, au travail précipité et aux surprises, sans garantir une transition sans incident.

La voie manuelle avec imapsync

Pour un contrôle direct, utilisez un outil IMAP vers IMAP tel qu'imapsync. Ses options de reprise, dossiers et indicateurs permettent un processus reproductible, mais dépendent de la version et d'une configuration testée.

Glisser des messages, exporter PST ou improviser des commandes peut compliquer l'audit. Avec un client, copiez sans supprimer la source et vérifiez le résultat.

Des lots reproductibles, un journal par boîte et des passes définies facilitent le suivi. TrekMail propose un flux intégré selon ses fonctions actuelles. Pour l'exploitation manuelle, consultez le guide opérateur imapsync.

Ce modèle est illustratif, pas prêt à exécuter : l'en-tête ne permet pas une exécution directe valide. Vérifiez et corrigez une copie locale pour la version choisie, notamment options de journal et serveur IMAP réel de destination. L'option de journal est booléenne, elle ne définit pas le nom du fichier. La lecture par virgules ne traite pas le CSV entre guillemets; des mots de passe avec virgules ou retours à la ligne la cassent. Protégez fichiers, processus et journaux contenant des identifiants et activez la vérification des certificats :

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

Quelques notes pratiques :

Cache selon la méthode. Il peut réduire les lectures répétées de métadonnées, mais ne prouve ni intégrité ni absence de doublons. Les UID ne sont pas globaux entre serveurs; conservez et validez l'état de comparaison.

Dossier de préparation si utile. Séparer les imports facilite les contrôles mais change leur emplacement, sans les intégrer automatiquement aux dossiers de production. Cela ne résout pas les écritures simultanées sur les deux systèmes : organisez le passage vers un seul environnement actif et traitez déplacements, indicateurs et suppressions sans synchronisation destructive aveugle.

Journal par boîte. Identifiez l'échec et sa cause. Le message final s'affiche même si la commande échoue : contrôlez code de sortie et journal, puis nombres, contenu et indicateurs. Limitez les permissions au propriétaire et masquez les secrets dans les journaux partagés.

Bascule DNS contrôlée

Pour transférer la réception de votre domaine, réduisez TTL à l'avance, attendez l'expiration des anciens caches et préparez le remplacement MX. Publiez la destination après validation des boîtes, alias et copie préalable; conservez réception ancienne, synchronisations et retour arrière pour les arrivées tardives.

Finir la copie ne change pas la réception. DNS indique la destination des nouveaux messages lorsque les réponses actualisées parviennent à chaque émetteur; un compte personnel ne permet pas de modifier MX du domaine du fournisseur.

Les caches et nouvelles tentatives peuvent répartir les messages entre systèmes pendant la transition. Surveillez et réconciliez ces flux plutôt que d'arrêter la source prématurément.

Vérifiez les valeurs réelles dans le tableau de bord et la documentation TrekMail. Cet exemple est schématique : conservez tous les émetteurs légitimes dans SPF, utilisez la clé DKIM du compte et n'appliquez pas la quarantaine sans inventaire, tests et retour arrière :

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

Pendant la bascule, vérifiez :

1. Anciens MX retirés de la publication au moment approprié, avec réception ancienne temporaire.
2. Nouveau MX publié et vérifié sur les résolveurs pertinents.
3. Une politique SPF par nom, conservant les services qui envoient encore.
4. DKIM configuré et signature valide vérifiée sur de vrais messages.
5. DMARC adapté : SPF valide et aligné ou une signature DKIM valide et alignée, sans exiger les deux pour le résultat du protocole.
6. Test reçu à destination et surveillance des arrivées tardives sur la source.

Ensuite, utilisez Google Postmaster Tools si le trafic Gmail et les données disponibles le permettent. Vérifiez l'authentification dans les en-têtes d'un serveur récepteur de confiance; les rapports sont partiels et la copie finale ne remplace pas les tests d'envoi et de réception.

L'option intégrée TrekMail

Le texte décrit l'import IMAP côté serveur depuis le tableau de bord TrekMail. Il peut réduire le besoin d'une machine et de scripts selon plan et compatibilité, mais exige surveillance et validation.

La différence opérationnelle peut se résumer ainsi :

Préparez le flux actuel en vérifiant ces étapes :

1. Ajoutez le domaine et préparez DNS sans basculer la réception prématurément.
2. Créez boîtes, alias et autres objets nécessaires à destination.
3. Ouvrez Migration dans le tableau de bord.
4. Saisissez serveur IMAP, port et identifiants autorisés de la source.
5. Sélectionnez la boîte TrekMail cible.
6. Importez, vérifiez état et données, puis coordonnez bascule et passes complémentaires.

Confirmez les procédures dans la présentation de la migration IMAP, démarrer une migration dans le tableau de bord, créer une boîte et les enregistrements DNS requis. L'importateur utilise des identifiants IMAP directs; les mots de passe d'application Gmail dépendent de la validation en deux étapes et des politiques. Si OAuth est obligatoire, choisissez un autre accès autorisé compatible, sans présumer un support interactif de l'importateur. Sauvegardez le courrier local non synchronisé avant de retirer les profils des clients.

Le texte présente Starter dès $3.50 par mois, Nano à $0 et les plans Starter, Pro, Agency et Enterprise. Il décrit Nano gratuit sans carte et une période d'essai gratuite de 14 jours pour les plans payants avec carte bancaire. Vérifiez les conditions actuelles. Le stockage mutualisé peut aider les boîtes de tailles différentes, sans supprimer quotas ni garantir qu'une extension sera inutile.

Comparez directement les tarifs TrekMail.

Dernières vérifications pour les équipes actives

Avant de changer MX d'un domaine propre, vérifiez alias, DNS, identifiants et synchronisation des grandes boîtes. Une courte liste détecte certains risques de réception et de données sans garantir l'absence de toute erreur.

Contrôlez avant de modifier :

1. Toutes les boîtes cibles existent et sont accessibles.
2. Alias, transferts et groupes reconstruits avec autorisations et tests.
3. Accès IMAP source avec TLS et certificats vérifiés sur 993.
4. Grandes boîtes copiées tôt et vérifiées.
5. TTL réduit et anciens caches pris en compte.
6. Anciens MX documentés pour vérifier changement et retour arrière.
7. Passes de changements après bascule programmées.
8. Utilisateurs informés du moment où cesser de modifier règles et données sur la source.
9. Une boîte de test prête pour réception et envoi.
10. Responsable de surveillance désigné, réception ancienne et accès administratif conservés tant que nécessaires.

Ce travail n'a rien de spectaculaire : réduire les surprises avant le changement améliore le contrôle de la migration.

Conclusion : un processus plutôt qu'un pari

Pour migrer des comptes email d'un domaine ou cinquante, inventoriez les identités, préparez les données, changez DNS si nécessaire et vérifiez les flux ensuite. IMAP copie les boîtes; il ne corrige pas seul une conception incomplète.

La voie manuelle offre le contrôle si vous entretenez outils et tests. Pour des migrations fréquentes, comparez TrekMail par son modèle multidomaine, stockage mutualisé, import et tableau de bord opérationnel selon fonctions et limites actuelles. Évaluez Nano ou consultez les tarifs si l'import nécessite un plan payant.