Agendas et contacts :
les pièges d'une migration email

Dans un projet de migration, l'attention se concentre naturellement sur les emails. C'est le volume, c'est l'historique, c'est ce que tout le monde regarde le lendemain de la bascule. Résultat : les agendas et les contacts sont découverts tard, souvent une fois la messagerie déjà passée. Or, selon la source dont vous partez, ils ne sont tout simplement pas repris. Voici ce que la documentation officielle de Google dit exactement, et ce qu'il faut préparer.

1. Le malentendu de départ

« On migre la messagerie » et « on migre l'agenda » sont deux opérations distinctes, avec des outils et des limites différentes. Ce n'est pas un détail contractuel : c'est écrit noir sur blanc dans la documentation Google (Migrer depuis des serveurs IMAP) :

« Si vous effectuez une migration depuis IMAP, Gmail ou Google Workspace, GWMME et l'outil d'importation de données importent uniquement les e-mails et les libellés. Les contacts, les événements et ressources d'agenda, les fichiers Google Drive, le contenu Google Sites et l'ensemble du contenu autre que les e-mails ne sont pas inclus dans le transfert. »

Autrement dit : si votre messagerie est chez un hébergeur mutualisé, sur Zimbra, o2switch, OVH, Gandi ou IONOS — donc en IMAP — les outils de migration Google ne transporteront que les emails et leurs libellés. Les agendas et les contacts sont un chantier à part entière.

2. Ce qui est repris dépend entièrement de la source

C'est le point que les comparatifs oublient. Le périmètre repris n'est pas une propriété de Google Workspace, c'est une propriété de ce que vous quittez :

• Source IMAP (Zimbra, o2switch, mutualisé…)Emails et libellés uniquement. Agendas, ressources et contacts : non repris par l'outil.
• Source Exchange / Microsoft 365L'outil GWMME reprend les emails, les agendas et les contacts — sous réserve des exclusions détaillées plus bas.
• Fichiers PSTLes agendas arrivent en « Autres agendas », pas dans l'agenda principal de l'utilisateur.

La première question à poser dans un audit de migration n'est donc pas « combien de boîtes ? » mais « quelle est exactement la source, et qu'est-ce qu'elle expose ? ».

3. Depuis Exchange : ce qui suit, et ce qui ne suit pas

Même dans le cas le plus favorable — une source Exchange — la reprise n'est pas intégrale. La documentation de GWMME liste ce qui est migré pour l'agenda : l'agenda par défaut avec ses événements, descriptions, participants, rappels et lieux, le statut libre/occupé, et les ressources d'agenda via un fichier CSV.

Et surtout, ce qui n'est pas migré :

• les descriptions en texte enrichi (mise en forme perdue) ;
• les statuts « À confirmer » et absent du bureau ;
• les pièces jointes d'agenda ;
• les définitions de catégories ;
• les liens de visioconférence — un point sensible sur les réunions récurrentes.

Côté contacts, les contacts personnels sont repris avec leurs champs, et les notes arrivent en texte brut. En revanche, les groupes de contacts et listes de diffusion, ainsi que les contacts globaux du domaine, ne sont pas migrés (Ce qui est migré avec GWMME).

Le conseil de l'ingénieur :

« Les liens de visioconférence qui ne suivent pas, ce n'est pas un détail technique : ce sont les réunions récurrentes de direction qui pointent dans le vide le lundi suivant. On les identifie avant, on les recrée après. C'est une ligne de checklist, pas une surprise. »

4. Piège n°1 : les agendas partagés et les délégations

C'est le piège le plus coûteux, parce qu'il est invisible dans les rapports de migration. La documentation indique que les agendas autres que l'agenda principal sont migrés pour leur propriétaire uniquement. Traduction concrète : l'agenda « Direction », l'agenda « Interventions » ou l'agenda « Congés » arrivent bien — mais sans les personnes qui y avaient accès.

Les autorisations de partage et les délégations (l'assistant·e qui gère l'agenda d'un dirigeant, par exemple) ne sont pas transportées. Elles doivent être recensées avant la bascule, puis recréées côté Google Agenda. Un tableau de correspondance « agenda → qui y accède → avec quel niveau de droit » suffit, mais il faut l'avoir fait pendant que l'ancien système est encore consultable.

5. Piège n°2 : les salles et les ressources

Les salles de réunion, véhicules et équipements réservables ne sont pas des agendas comme les autres. Bonne nouvelle : ils sont traitables. Les ressources d'agenda Exchange Online peuvent être migrées vers les ressources Google Agenda à l'aide d'un fichier CSV. Mauvaise nouvelle : c'est une opération explicite et séparée. Si personne ne la déclenche, les invitations arrivent chez Workspace sans aucune salle réservable, et les collaborateurs recréent des ressources sauvages dans leur coin.

6. Piège n°3 : l'annuaire et les listes de diffusion

Les carnets d'adresses personnels sont repris ; l'annuaire global de l'entreprise, non. C'est logique — sous Workspace, l'annuaire est alimenté par les comptes utilisateurs et les groupes — mais cela veut dire que les listes de diffusion (contact@, compta@, direction@) doivent être reconstruites en Groupes Google, avec leurs membres et leurs règles d'accès.

C'est aussi l'occasion de faire le ménage : une messagerie ancienne accumule des listes devenues inutiles. Migrer à l'identique une structure obsolète, c'est reporter le problème.

7. L'outil dépend du couple source × taille

Il n'existe pas « un » outil de migration Google, mais plusieurs — et la matrice officielle les recommande en croisant la source et le nombre d'utilisateurs, jamais la taille seule (matrice des produits de migration).

Pour une source de messagerie, la lecture est stable : IMAP, Gmail, fichiers PST et Exchange 2007 relèvent de GWMME à toutes les tailles — l'outil d'importation de données restant une option jusqu'à 100 utilisateurs. Google Workspace Migrate, souvent présenté comme « l'outil des grandes organisations », n'entre en jeu que pour des sources Exchange 2010 à 2019 ou Exchange Online à partir de 1 001 utilisateurs, et pour les fichiers (SharePoint, OneDrive, partages réseau, Box).

La conséquence est contre-intuitive mais nette : grossir ne règle rien. Un projet IMAP à 1 500 comptes ne récupère pas davantage d'agendas qu'un projet à 15 comptes — c'est la source qui commande le périmètre. D'où des migrations qui s'annoncent en vagues, avec un périmètre annoncé pour chaque vague, et jamais en « un week-end ».

8. La checklist avant bascule

Ce que nous recensons systématiquement avant de toucher quoi que ce soit :

• la nature exacte de la source (IMAP ou Exchange) — elle détermine tout le reste ;
• la liste des agendas secondaires, avec leur propriétaire et leurs partages ;
• les délégations d'agenda en place ;
• les salles et ressources réservables ;
• les listes de diffusion et les alias réellement utilisés ;
• les réunions récurrentes critiques comportant un lien de visioconférence.

Cette liste est courte. C'est précisément parce qu'elle est courte qu'elle est faisable — et qu'il n'y a aucune excuse à la découvrir après la bascule.

Cette étape s'inscrit dans notre approche migration multi-fournisseurs. Pour la méthode générale et la bascule des enregistrements MX, voir migrer OVH, Gandi ou IONOS sans coupure ; pour les sources IMAP, Zimbra et o2switch ; pour une source Exchange, migrer depuis Microsoft 365 ; et pour le volet documentaire, Drive vers Shared Drives.

9. Sources officielles

• Google Workspace Admin Help — Migrer depuis des serveurs IMAP
• Google Workspace Admin Help — Ce qui est migré avec GWMME
• Google Workspace Admin Help — Matrice des produits de migration