imapsync : guide opérationnel pour une migration sûre des e-mails (2026)

Vous êtes face à un projet de migration qui vous inquiète. Vous devez transférer les e-mails du serveur A au serveur B sans perdre un seul message, sans détruire l’arborescence des dossiers et sans payer une « licence de migration » à $15/utilisateur à un prestataire externe uniquement pour déplacer des données qui vous appartiennent déjà.

L’outil que vous cherchez est imapsync. Ce guide vous explique précisément comment l’utiliser sans mettre en péril les boîtes de vos utilisateurs.

Ce qu’est imapsync et ce qu’il n’est pas

imapsync est un utilitaire en ligne de commande qui synchronise des boîtes entre deux serveurs IMAP. Il sert d’intermédiaire : il se connecte simultanément aux deux serveurs, lit les messages sur la source et les ajoute à la destination. Il suit l’état du transfert, gère les interruptions et préserve l’arborescence des dossiers, les indicateurs et le contenu des messages.

Ce n’est ni un outil de sauvegarde ni un relais SMTP. Il ne touche pas à Google Calendar, aux contacts Outlook ni aux règles de transport Exchange. Il communique en IMAP, rien d’autre. Si votre serveur source est protégé par un pare-feu ou hors ligne, imapsync ne peut pas l’atteindre. Point final.

Sa couche de préservation de l’état en fait une référence pour les transferts de boîte à boîte. Une migration réussie ne consiste pas seulement à déplacer du texte, mais à préserver trois éléments :

• Contenu : le corps du message RFC 822, les pièces jointes, l’encodage MIME et tout ce qui se trouve dans l’enveloppe.
• Métadonnées : les indicateurs. \Seen (lu), \Answered (répondu), \Flagged (marqué). S’ils ne sont pas transférés, chaque utilisateur croira avoir 4,000 nouveaux e-mails non lus le premier jour.
• Structure : la hiérarchie des dossiers. INBOX/Clients/ProjectA doit être identique sur le nouveau serveur, et non aplatie dans un dossier littéralement nommé INBOX.Clients.ProjectA avec des points dans son nom.

imapsync prend en charge ces trois éléments, à condition d’être correctement configuré. C’est précisément la difficulté à laquelle répond ce guide.

Les limites strictes : l’outil ne connaît pas intrinsèquement les limites de débit de Gmail ni les restrictions des API Microsoft. Lancez-le à pleine puissance et votre adresse IP risque d’être bloquée. Il ne pousse pas non plus les données : pour les envoyer quelque part, vous devez les extraire. Enfin, il ne supprime rien par défaut sur la destination. Cette mesure de sécurité peut aussi vous piéger si vous manquez d’attention, comme expliqué à la Phase 6.

Pour une présentation plus générale du protocole, consultez notre guide sur la configuration des e-mails sur votre domaine.

Phase 1 : état des lieux approfondi. Ne l’ignorez pas

Les amateurs commencent à copier. Les professionnels auditent d’abord l’environnement. Si vous ignorez ce que vous transférez, vous échouerez, probablement à 2 h du matin un dimanche, lorsqu’il sera trop tard pour réparer.

1. Repérez les boîtes géantes

Un utilisateur possède une boîte de 45GB. C’est peut-être le PDG, ou la personne qui détient l’alias sales@ depuis 2011. Si vous tentez de la migrer dans le même lot que les utilisateurs à 500MB, le lot se bloque et vous restez devant un terminal figé sans savoir où en est le transfert.

Commencez par une analyse préalable :

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfoldersizes

Vous obtenez le détail par dossier sans toucher à un seul message. Toute boîte dépassant 10GB exige un traitement dédié : délais d’attente plus longs, créneau d’exécution réservé et attention complète.

2. Le problème des données dormantes

Toute entreprise possède des comptes zombies : anciens employés dont les e-mails sont toujours transférés ailleurs, ou « comptes de service » qui sont en réalité des boîtes partagées pour une imprimante ou une ancienne intégration CRM. Si vous les oubliez dans l’inventaire, leurs données resteront bloquées lors du basculement DNS.

Comparez la liste des utilisateurs source à celle des utilisateurs réellement actifs. Si bob@company.com est parti il y a trois ans, décidez maintenant de migrer sa boîte ou de l’archiver dans un export EML. Sinon, vous devrez trancher sous pression au pire moment. Notre guide de gestion des e-mails clients propose un modèle complet d’inventaire préalable.

3. Le nombre d’éléments dit la vérité

Ne vous fiez jamais au volume en gigaoctets. Le serveur source A peut annoncer une boîte de 10GB et le serveur de destination B mesurer exactement les mêmes données à 11GB. Ce n’est pas un bug : les serveurs calculent le stockage différemment. Exchange inclut le dossier Recoverable Items, le « Dumpster », tandis que Gmail déduplique les messages entre les libellés.

La métrique importante est le nombre d’éléments. Si la source contient 14,200 messages et la destination 14,200 messages, le transfert est terminé. Un écart inférieur à 10% en octets est normal et attendu. Au-delà de 10%, enquêtez avant de valider.

Phase 2 : le processus de migration sûr

La plus grosse erreur consiste à adopter l’approche « Big Bang » : tout déplacer le vendredi soir en espérant terminer avant lundi matin. Avec 50GB d’e-mails et une limite de 500KB/s, le calcul ne tient pas. Le service sera indisponible lundi et vous devrez expliquer au PDG pourquoi sa boîte est vide.

La méthode professionnelle est une migration par étapes. Effectuez le gros du travail pendant que les utilisateurs restent sur l’ancien système, puis exécutez un dernier delta minuscule au moment du basculement.

Étape 1 : la simulation

Avant de déplacer un seul octet, vérifiez que la connexion fonctionne. Associez --dry à --justfolders. Cette commande simule l’exécution et affiche l’arborescence sans rien copier.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfolders

Vérifiez deux points : l’authentification a-t-elle réussi et à quoi ressemblent les noms des dossiers ? Si la source contient [Gmail]/Sent Mail, vous devez l’associer à Sent Items sur la destination. Ne le découvrez pas pendant le basculement réel.

Étape 2 : la synchronisation en masse préalable

Exécutez-la 1 à 2 semaines avant le basculement, alors que les utilisateurs travaillent encore sur l’ancien système. L’objectif est de sortir 90 à 95% des données du chemin critique.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --usecache --skipsize --maxsize 25000000

--usecache est indispensable. Cette option enregistre localement l’état de la migration. Chaque exécution suivante consulte ce cache et ne traite que les changements, au lieu de réexaminer tous les messages. Sans elle, chaque passage constitue une analyse complète.

--maxsize 25000000 ignore au premier passage les messages de plus de 25MB. Les pièces jointes volumineuses provoquent le plus de délais d’attente dépassés et de coupures. Vous les récupérerez lors d’un passage dédié avec des délais étendus.

Étape 3 : la synchronisation delta

Quelques jours avant le basculement, relancez la commande. imapsync lit le cache, constate que 10,000 e-mails sont déjà présents, les ignore et copie uniquement les 50 à 100 nouveaux messages arrivés depuis la synchronisation en masse. Ce passage devrait durer quelques minutes, pas plusieurs heures.

Étape 4 : le basculement

Le moment est venu. Procédez dans cet ordre :

1. Réduisez le TTL DNS : 48 heures avant le basculement, réglez le TTL de l’enregistrement MX sur 300 secondes. Si vous attendez le dernier moment, certains résolveurs conserveront l’ancien MX jusqu’à 24 heures et des e-mails arriveront sur l’ancien serveur après le basculement.
2. Modifiez les enregistrements MX : faites-les pointer vers le nouvel hébergeur.
3. Attendez 60 minutes afin que la propagation se stabilise sur les principaux résolveurs.
4. Exécutez le delta final : un dernier passage imapsync récupère les messages arrivés sur l’ancien serveur pendant la propagation.

Pour une explication détaillée de la fenêtre DNS et des points à surveiller pendant la propagation, consultez notre guide sur la configuration des e-mails sur votre domaine.

Phase 3 : indicateurs, dossiers et piège des messages envoyés

Les serveurs IMAP parlent des dialectes différents. Sans traduction entre eux, vos utilisateurs retrouveront une boîte dont la structure est brisée et vous en tiendront responsable, à juste titre.

Le problème du délimiteur

C’est la panne technique la plus courante dont personne ne parle avant de la subir.

Les serveurs IMAP utilisent différents caractères pour séparer les niveaux de dossiers :

• Dovecot utilise généralement un point : INBOX.Clients.ProjectA
• Exchange/Outlook utilise une barre oblique : INBOX/Clients/ProjectA
• Certains serveurs n’emploient aucun séparateur et reposent sur la commande IMAP NAMESPACE

Si vous migrez sans vérifier, imapsync peut créer sur la destination un dossier littéralement nommé INBOX.Clients.ProjectA : un seul dossier plat avec des points dans son nom, et non une hiérarchie imbriquée sur trois niveaux. L’arborescence de chaque utilisateur semble avoir explosé.

La solution est --regextrans2, qui réécrit à la volée les chemins de dossiers avec des expressions régulières. Testez toujours la création avec --dry sur un seul compte avant de lancer un lot de 100 utilisateurs.

Le chaos des messages envoyés

Chaque serveur nomme différemment le dossier des messages envoyés. Ce n’est pas un désagrément mineur : l’ignorer dégrade fortement l’expérience utilisateur.

Sans correspondance explicite, l’utilisateur se retrouve avec deux dossiers d’envoi : son dossier actif Sent Items et un dossier fantôme Sent Mail contenant tout son historique. Il le remarquera et ne sera pas satisfait.

Définissez la correspondance explicitement :

--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'

La commande indique à imapsync : « Si le dossier source commence par [Gmail]/Sent Mail, renomme-le Sent Items sur la destination. » Testez d’abord toute la table de correspondance avec --dry pour vérifier que chaque règle s’applique correctement.

Le piège All Mail de Gmail

Gmail possède un dossier [Gmail]/All Mail. Il contient une copie de chaque e-mail, quel que soit son libellé. Il s’agit de la vue globale interne de Gmail exposée comme dossier IMAP.

Si vous migrez All Mail et Inbox et Sent Mail, chaque e-mail sera dupliqué deux ou trois fois sur la destination. Une boîte de 10GB devient une boîte de 30GB et chaque message apparaît plusieurs fois. C’est un désastre.

Excluez-le toujours :

--exclude "All Mail"

Excluez aussi [Gmail]/Spam et [Gmail]/Trash, sauf raison précise de les transférer. Personne ne souhaite migrer ses anciens spams.

Phase 4 : réglage des performances et limitation du débit

Vous ne pouvez pas envoyer des données à plein débit vers Google ou Microsoft. Leur infrastructure traite une connexion IMAP à grand volume comme une attaque par déni de service, car les deux se ressemblent de son point de vue.

La pénalité

Dépassez les limites, généralement autour de 1 message par seconde ou 500MB par heure pour Gmail, et le serveur commence à renvoyer HTTP 429, NO [OVERQUOTA] ou simplement des erreurs BAD. Si vous insistez, le compte est verrouillé pendant 24 heures. Voilà un appel au support que vous préférerez éviter.

Les options de réglage

--maxmessagespersecond 1     # Hard speed limit: 1 email per second
--maxbytespersecond 500000   # Bandwidth cap: 500KB/s
--timeout 120                # Network timeout in seconds (default is often too short for big attachments)
--reconnectretry1 3          # Retry on source connection drops
--reconnectretry2 3          # Retry on destination connection drops

1 message par seconde paraît terriblement lent. C’est vrai. Mais un rythme stable finit par aboutir. Une exécution agressive bloquée à l’heure 3 ne finit jamais.

Note pour les MSP : si vous migrez plusieurs clients en parallèle, ne lancez pas les tâches simultanément contre le même serveur source. Décalez les heures de début. Chaque flux parallèle a besoin de son propre quota de débit.

Si vous migrez vers TrekMail, notre ingestion IMAP gère bien les connexions très concurrentes. Vous pouvez solliciter davantage la destination que la source chez Google ou Microsoft.

Phase 5 : authentification. L’obstacle de l’authentification moderne

L’époque où l’on plaçait password123 dans un fichier en clair est révolue. Google et Microsoft ont tous deux abandonné l’authentification de base pour IMAP. Vos identifiants habituels provoqueront une erreur d’authentification et vous risquez de chercher pendant une heure ce que vous avez fait de travers.

Mots de passe d’application (option PME)

Pour la plupart des migrations d’un seul domaine, les mots de passe d’application sont la voie la plus rapide. Ces chaînes de 16 caractères contournent la 2FA et fonctionnent avec les anciens clients IMAP :

1. Connectez-vous au compte source (Gmail, Workspace, etc.)
2. Activez l’authentification à 2 facteurs si nécessaire, car elle est obligatoire pour générer des mots de passe d’application
3. Ouvrez les paramètres Sécurité → Mots de passe des applications
4. Générez un mot de passe pour « Mail » sur « Autre appareil »
5. Utilisez cette chaîne comme mot de passe dans le fichier indiqué par --passfile à imapsync

Conservez-la dans un fichier protégé par chmod 600, pas dans la ligne de commande. Des identifiants dans l’historique Bash sont un incident en attente.

OAuth2 (option MSP et entreprise)

Un MSP qui migre 500 utilisateurs ne peut pas générer manuellement 500 mots de passe d’application. Il lui faut OAuth2. Cette solution est plus complexe, mais c’est la seule réaliste à grande échelle :

1. Enregistrez une application dans le tenant source (Azure AD pour Microsoft, Google Cloud Console pour Google)
2. Accordez-lui l’accès complet aux boîtes de tout le tenant, avec l’approbation obligatoire d’un administrateur général
3. Générez un Refresh Token par utilisateur ou utilisez un compte de service pour agir au nom de l’utilisateur
4. Transmettez le jeton à imapsync avec --oauthaccesstoken1

Si vous configurez mal les autorisations de l’application dans Azure AD ou GCP, l’accès à toutes les boîtes sera refusé ou, pire, vous accorderez involontairement des droits plus larges que prévu. Lisez attentivement les étendues d’autorisation avant de cliquer sur « Accorder le consentement administrateur ».

Pour une approche pratique de la migration à grande échelle, consultez notre guide sur la gestion des e-mails clients.

Phase 6 : défaillances courantes et récupération

Même un plan parfait rencontre des problèmes. Voici comment comprendre la panne et la corriger sans repartir de zéro.

1. Le problème UIDVALIDITY (le scénario cauchemardesque)

Chaque dossier IMAP possède un identifiant unique appelé UIDVALIDITY. imapsync l’utilise pour savoir quels messages ont déjà été copiés. Si un dossier source est supprimé puis recréé, ou si l’index du serveur est corrompu puis reconstruit, cet identifiant change.

Symptôme : imapsync détecte un nouvel UIDVALIDITY, suppose qu’il s’agit d’un dossier entièrement nouveau et télécharge tout de nouveau. Chaque message de ce dossier est désormais en double. À grande échelle, cela représente des milliers de doublons dans des centaines de boîtes.

Solution : supprimez les fichiers de cache locaux de votre répertoire temporaire, puis relancez avec --useheader :

--useheader

Cette option force imapsync à comparer l’en-tête Message-ID de chaque e-mail, immuable et unique, au lieu de s’appuyer sur l’UID du dossier. C’est plus lent, mais cela évite les doublons. Utilisez-la dès que vous pensez que l’index du serveur source a été modifié.

2. Messages corrompus ou de zéro octet

Les anciens serveurs accumulent des messages « fantômes » : en-têtes sans corps ou fichiers de 0 octet exactement. Ils résultent généralement d’un import raté, d’une livraison interrompue ou d’un très vieux serveur dont la maintenance a été différée pendant des années.

Symptôme : imapsync tente de récupérer un message, le serveur reste bloqué pendant 120 secondes, puis coupe la connexion. Le cycle se répète indéfiniment sur le même message.

Solution :

--minbytes 10

imapsync ignore alors tout message de moins de 10 octets. Un véritable e-mail ne fait jamais moins de 10 octets. Ce filtre revient à ignorer les fichiers vides et peut être employé sans risque pour chaque migration.

3. Le problème des suppressions fantômes

Vous avez exécuté la synchronisation en masse lundi. Mardi, l’utilisateur a supprimé 50 e-mails de la source. Mercredi, vous lancez le delta.

Par défaut, imapsync ajoute uniquement des e-mails : il ne supprime pas de la destination ce qui a été effacé sur la source. Ce comportement est volontaire et adapté à la plupart des cas. Mais les 50 messages supprimés réapparaissent dans la nouvelle boîte. Les utilisateurs les signaleront comme des « e-mails fantômes » ou des « e-mails supprimés qui reviennent ».

La solution est --delete2, à utiliser avec une extrême prudence :

--delete2

Cette option indique à imapsync de supprimer de la destination tout message absent de la source.

Utilisez-la uniquement pendant la phase préalable, avant le basculement MX. Après celui-ci, les nouveaux e-mails arrivés sur la destination, puisque le MX pointe déjà vers elle, seront supprimés parce qu’ils n’existent pas sur l’ancienne source. Vous perdrez des messages. N’utilisez pas --delete2 après le basculement.

4. Coupures de connexion sur les pièces jointes volumineuses

Une pièce jointe PDF de 40MB peut parfois bloquer les connexions IMAP dont le délai d’attente est court. Le serveur envoie le message, le réseau connaît une interruption, la connexion tombe à 95% et imapsync consigne une erreur avant de poursuivre, laissant un message incomplet sur la destination.

Solution : portez --timeout à 300 secondes pour les passages consacrés aux pièces jointes volumineuses. Vous pouvez aussi utiliser --maxsize 25000000 afin de les ignorer dans la synchronisation en masse, puis lancer un passage dédié avec une limitation assouplie et des délais étendus.

Vérification : comment prouver que la migration a réussi

Le script s’est terminé. Le terminal indique que tout est fini. Comment savoir si les e-mails du PDG n’ont pas disparu dans une route nulle ?

1. Lisez le bloc récapitulatif

imapsync affiche un récapitulatif à la fin de chaque exécution. Trois nombres comptent :

• Transferred : doit valoir 0 lors du delta final. Si la valeur n’est pas nulle, certains messages n’ont pas encore été transférés.
• Skipped : doit correspondre au nombre total de messages source ou le dépasser. Il s’agit des messages déjà présents sur la destination.
• Errors : doit valoir 0. Tout nombre d’erreurs non nul exige une enquête avant de conclure.

2. Le contrôle ponctuel

Connectez-vous à la nouvelle boîte avec un client IMAP vierge, et non avec un client disposant d’un stockage local en cache qui fausserait le test. Vérifiez :

• Sent Items : les années de messages envoyés sont-elles présentes et correctement classées ?
• Un sous-dossier profondément imbriqué : la hiérarchie est-elle correcte ?
• Le message le plus récent : est-ce le même que sur la source ?
• Un message marqué ou suivi : l’attribut \Flagged a-t-il été conservé ?

3. La recherche dans les journaux

Un utilisateur signale un e-mail manquant. Avant d’affirmer qu’il a dû se perdre, consultez le journal :

grep -i "bob@sender.com" /var/log/imapsync/user@source.com.log

Le journal consigne le sort de chaque message : Transferred, Skipped (déjà présent sur la destination) ou Error avec son code précis. En cas d’erreur, vous connaissez exactement le message, le dossier et le code concernés. C’est le point de départ de la récupération, au lieu de simples suppositions.

4. L’audit du nombre d’éléments

Pour une dernière vérification de cohérence, interrogez directement les deux serveurs :

# On source (example for Dovecot)
doveadm mailbox status -u user@source.com messages '*'

# Or use imapsync's own count
imapsync ... --dry --justfoldersizes 2>&1 | grep "Messages"

Comparez le nombre d’éléments de la source à celui de la destination. L’écart devrait rester dans une plage de 1 à 2%, compte tenu des dossiers de spam exclus et de la déduplication Gmail All Mail. Au-delà, examinez le journal d’erreurs avant de valider.

L’alternative : se passer du terminal

Nous avons écrit ce guide parce que nous croyons à la transparence. imapsync est l’outil adapté aux opérateurs qui veulent un contrôle total et acceptent de travailler avec des dépendances Perl, des enregistrements d’applications OAuth2 et l’analyse forensique des journaux.

Mais pour beaucoup d’opérateurs, du fondateur qui déplace son premier domaine à l’agence qui migre 200 comptes clients, le temps de configuration coûte plus cher que l’économie réalisée sur le logiciel.

L’outil de migration intégré à TrekMail fonctionne côté serveur : pas besoin de déplacer des dossiers dans Outlook pendant trois heures ni de subir les dépendances Perl. Indiquez la source (Gmail, cPanel ou tout serveur IMAP standard), saisissez les identifiants et le serveur effectue le transfert. Vous pouvez suivre la progression dans le tableau de bord.

Le modèle tarifaire diffère aussi de ce que vous connaissez probablement. Aucun frais par utilisateur. Les forfaits commencent à $3.50/mois et couvrent jusqu’à 100 utilisateurs sur 50 domaines, avec un stockage mutualisé. Un dirigeant possédant 40GB de pièces jointes ne contraint donc pas tous les autres à changer d’offre, puisque le stockage est partagé à l’échelle du compte.

Consultez les tarifs TrekMail pour comparer le contenu des offres. Pour suivre précisément le processus de l’outil, consultez le guide Démarrer une migration dans notre documentation.

Que vous écriviez vos propres scripts imapsync ou utilisiez notre plateforme, l’objectif reste le même : déplacer les e-mails sans perte de données, sans incident et sans péage par compte.

Si vous souhaitez cesser de payer par utilisateur et nous confier la migration, essayez TrekMail gratuitement : essai de 14 jours, sans carte bancaire.