TerrainScénario type
Migrer la messagerie de 5 000 agents : méthode
Le serveur de messagerie arrive en fin de support, la nouvelle plateforme est choisie, cinq mille agents attendent. Ce scénario type suit une migration de messagerie dans une administration, de l'inventaire aux deux semaines qui suivent la bascule.
Le compte à rebours est connu depuis longtemps : le logiciel de messagerie installé dans les salles serveurs arrive en fin de support, comme Exchange Server 2016 et 2019, dont le support étendu s’est achevé le 14 octobre 2025. Après une consultation, l’administration a choisi une nouvelle plateforme hébergée, conforme à ses exigences de sécurité et de localisation des données. Il reste à y faire passer cinq mille agents, répartis sur plus d’une centaine de sites, sans interrompre le service public. Une migration de messagerie de cette taille est moins un projet technique qu’un déménagement : ce qui compte, c’est ce que contiennent les cartons.
Ce récit est un scénario type. L’administration imaginée est une collectivité régionale dont les agents travaillent au siège, dans des antennes territoriales et dans des établissements dispersés. La direction des systèmes d’information compte une soixantaine de personnes et s’appuie sur un intégrateur pour la migration.
Ce qu’il y a vraiment dans une messagerie
Le premier inventaire, réalisé à partir des outils d’administration, recense les boîtes aux lettres : un peu plus de cinq mille, plus quelques centaines de boîtes partagées. C’est la partie visible. Trois semaines d’enquête révèlent tout le reste.
| Élément | Pourquoi il compte | Comment il a été traité |
|---|---|---|
| Délégations et agendas partagés | Un assistant qui gère l’agenda d’un directeur doit migrer avec lui | Groupes de migration constitués par liens de délégation |
| Listes de diffusion et règles | Des circuits de travail entiers reposent dessus | Inventaire, nettoyage des listes inactives, recréation |
| Archives locales | Des fichiers d’archives sur les postes et les partages réseau, parfois très volumineux | Politique d’archivage décidée avec les archivistes avant toute copie |
| Applications qui envoient des courriels | Logiciels métiers, copieurs multifonctions, alertes techniques passent par le serveur à remplacer | Recensement à partir des journaux, nouveau relais d’envoi authentifié |
| Téléphones | Chaque appareil configuré sur l’ancien serveur devra être reconfiguré | Profil de configuration poussé par l’outil de gestion des mobiles |
| Adresses et domaines | Anciens noms de domaine, adresses fonctionnelles, alias historiques | Table de correspondance validée par chaque direction |
Les applications qui envoient des courriels sont la principale surprise. L’analyse des journaux du serveur fait apparaître plusieurs dizaines d’émetteurs automatiques, dont certains que personne ne savait rattacher à un service : un logiciel de gestion des marchés, un outil de réservation de salles, des copieurs qui numérisent vers la messagerie, un serveur de supervision. Chacun doit être reconfiguré avant la bascule, sous peine de silence le lundi matin.
Les archives posent une autre question, juridique celle-là : les courriels des agents publics peuvent constituer des archives publiques. Avant de décider ce qui est copié, conservé ou éliminé, la direction des systèmes d’information associe le service des archives. La règle retenue : une période récente migre dans les boîtes, l’historique rejoint un archivage consultable, et rien n’est supprimé sans visa.
Une vague pilote qui sert à casser
La première vague réunit environ cent cinquante personnes : l’équipe informatique, des volontaires de plusieurs directions, et quelques agents choisis précisément parce que leurs usages sont compliqués (un secrétariat de direction, un service qui partage une boîte entre vingt personnes, un agent en mobilité permanente).
Son objectif est de trouver les problèmes. Elle en trouve : des règles de tri qui ne se recréent pas, des signatures perdues, une délégation qui fonctionne dans le nouveau système mais pas pendant la coexistence, des téléphones anciens incompatibles avec la méthode d’authentification. Chaque problème donne lieu à une correction ou à une fiche d’aide. La vague pilote dure trois semaines au lieu d’une ; c’est le temps le mieux investi du projet.
Les vagues : par service, pas par ordre alphabétique
- Pilotevolontaires et cas complexes
- Vagues simplesservices aux usages standards
- Directions et élusdélégations nombreuses, accompagnement individuel
- Sites distantsétablissements, antennes
- Bascule finaleroutage, ancien serveur en lecture seule
Les vagues sont construites par service et par liens de travail, jamais par ordre alphabétique ou par numéro d’agent. Une équipe migre ensemble, avec ses boîtes partagées et ses délégations. Chaque vague suit le même rythme : annonce dix jours avant, rappel la veille, copie des données la nuit, accueil le matin par un relais de proximité, point d’étape en fin de journée.
Le calendrier tient compte de la vie de l’administration. Aucune vague pendant la préparation du budget pour les services financiers, ni pendant les sessions de l’assemblée pour le secrétariat des élus. Les élus et la direction générale bénéficient d’un accompagnement individuel, avec un rendez-vous de configuration de leurs appareils.
Pendant les vagues, deux systèmes cohabitent. Si l’affichage des disponibilités entre les agendas des deux systèmes n’est pas assuré, les réunions se planifient mal pendant des semaines et le projet perd sa crédibilité. La coexistence se teste dès la vague pilote.
Le week-end de bascule
Quand la dernière vague est passée, reste à faire basculer le routage : les enregistrements DNS qui désignent le serveur de réception des messages sont modifiés pour pointer vers la nouvelle plateforme. Leur durée de validité a été réduite une semaine plus tôt, pour que le changement se propage vite. Les enregistrements qui authentifient les envois du domaine, destinés à éviter l’usurpation et le classement en indésirables, sont mis à jour et vérifiés.
Le plan de retour arrière a été écrit et répété : qui décide, dans quel délai, et comment revenir à la situation antérieure si les messages ne circulent plus. Il ne sert pas. L’ancien serveur reste accessible en lecture seule pendant trois mois, puis est arrêté après une vérification que plus aucune application ne lui écrit.
Les deux semaines qui suivent
La bascule n’est pas la fin. Pendant deux semaines, une assistance renforcée est organisée : un numéro dédié, des relais dans chaque site, des créneaux de passage sans rendez-vous. Les demandes portent surtout sur des gestes simples : retrouver un dossier, recréer une règle, configurer un nouveau téléphone, comprendre la nouvelle interface de l’agenda. Elles sont classées chaque soir, et les plus fréquentes donnent lieu à un message à tous les agents dès le lendemain.
Ce que l’équipe referait autrement tient en deux points. Commencer l’inventaire des applications qui envoient des courriels trois mois plus tôt. Et former les relais de proximité avant la vague pilote, pas après. Pour le reste, la méthode a tenu : un inventaire honnête, un pilote fait pour casser, des vagues construites autour des équipes, et une assistance visible. C’est la façon de travailler de nos équipes déployées auprès des directions informatiques, et notre dossier sur la transformation numérique pour les dirigeants replace ce type de projet dans une trajectoire plus large.
Scénario type construit à partir de situations courantes ; il ne décrit pas une organisation réelle.
Pour approfondir : Gouvernance & traçabilité
Questions fréquentes
Combien de temps dure une migration de messagerie pour plusieurs milliers d'utilisateurs ?
La copie des boîtes elle-même se compte en semaines. L'ensemble du projet, inventaire, pilote, vagues et assistance comprises, prend généralement plusieurs mois. La durée dépend surtout de la qualité de l'inventaire et du nombre d'applications qui envoient des messages par le serveur à remplacer.
Faut-il migrer tout l'historique des messages ?
Pas forcément. Beaucoup d'organisations migrent une période récente dans la boîte et versent l'historique dans un archivage consultable. La décision doit tenir compte des obligations d'archivage : les courriels des agents publics peuvent constituer des archives publiques, dont la conservation et l'élimination obéissent à des règles précises.
Comment éviter une coupure de messagerie le jour de la bascule ?
En organisant une période de coexistence : pendant les vagues, les deux systèmes échangent les messages et les informations de disponibilité des agendas. La bascule finale du routage, par la modification des enregistrements DNS, se prépare en réduisant leur durée de validité quelques jours avant, et s'accompagne d'un plan de retour arrière testé.
Qui doit être migré en premier ?
Une vague pilote composée de volontaires et de l'équipe informatique, puis des services dont les usages sont simples. Les directions avec beaucoup de délégations, de boîtes partagées et d'élus ou de dirigeants passent plutôt au milieu du projet, quand les procédures sont rodées, mais jamais en dernier, quand la fatigue s'installe.