Quelle est la réponse courte ?
Pour une PME de 20 à 50 personnes qui part d'un serveur de messagerie unique et d'un serveur de fichiers, comptez trois à six semaines entre le lancement et la fin du dernier basculement. Pour 100 utilisateurs, six à dix semaines. Au-delà de 300, on parle en mois, pas en semaines.
Ces chiffres surprennent souvent dans les deux sens. Certains dirigeants pensent qu'un week-end suffit, parce qu'un prestataire leur a annoncé « une bascule le samedi ». D'autres imaginent un projet d'un an. La vérité est au milieu, et surtout elle dépend beaucoup plus de votre situation de départ que du nombre d'utilisateurs.
Un point important : la copie des données elle-même représente rarement plus de 10 % du calendrier. Les outils de migration savent transférer plusieurs centaines de gigaoctets pendant la nuit. Ce qui prend du temps, c'est tout ce qui se décide avant, et tout ce qui s'accompagne après.
Combien de temps selon la volumétrie ?
Le tableau ci-dessous donne les ordres de grandeur que nous appliquons pour un chiffrage initial. Il suppose un point de départ classique : messagerie sur site ou chez un hébergeur, fichiers sur un serveur de fichiers, pas de contrainte réglementaire lourde.
| Volumétrie | Préparation et conception | Pilote | Vagues de bascule | Durée totale réaliste | Charge côté client |
|---|---|---|---|---|---|
| 10 à 20 utilisateurs | 1 à 2 semaines | 2 jours | 1 vague, 1 week-end | 3 à 5 semaines | 3 à 5 jours cumulés |
| 20 à 50 utilisateurs | 2 semaines | 3 à 5 jours | 1 à 2 vagues | 4 à 7 semaines | 5 à 10 jours cumulés |
| 50 à 100 utilisateurs | 3 semaines | 1 semaine | 2 à 3 vagues | 6 à 10 semaines | 10 à 15 jours cumulés |
| 100 à 250 utilisateurs | 4 à 6 semaines | 1 à 2 semaines | 3 à 5 vagues | 3 à 4 mois | 15 à 30 jours cumulés |
| 250 à 500 utilisateurs, mono-site | 6 à 8 semaines | 2 semaines | 5 à 8 vagues | 4 à 6 mois | 1 personne à mi-temps |
| Plus de 500, ou multi-sites, ou multi-pays | 2 à 3 mois | 3 semaines | 8 vagues et plus | 6 mois et plus | Équipe projet dédiée |
La colonne de droite est celle qu'il faut lire en premier. Elle exprime le temps que vos propres équipes devront consacrer au projet, et c'est presque toujours la ligne qui manque dans les devis concurrents.
Qu'est-ce qui allonge réellement les délais ?
Six facteurs expliquent l'essentiel des dérapages que nous observons. Aucun n'est technique au sens strict.
- Un annuaire en désordre. Comptes d'anciens salariés encore actifs, doublons, groupes dont personne ne connaît l'usage. Le nettoyage prend de une à trois semaines et ne peut pas être fait par le prestataire seul, puisqu'il faut décider du sort de chaque compte.
- Un serveur de fichiers jamais rangé. Vingt ans de dossiers, des chemins trop longs, des droits posés utilisateur par utilisateur. C'est le premier poste de retard sur les projets de plus de 50 personnes.
- Les applications métier qui envoient des mails. ERP, GPAO, logiciel de paie, photocopieurs. Chacun a une configuration SMTP à reprendre, et chacun se rappelle à vous le lendemain de la bascule s'il a été oublié.
- Les décisions non prises. Qui a droit au partage externe ? Garde-t-on les archives PST ? Quelle politique de rétention ? Tant que la direction n'a pas tranché, le projet attend.
- Les contraintes réglementaires. Santé, secteur public, données à caractère personnel sensibles : les arbitrages de localisation et de conservation ajoutent plusieurs semaines d'analyse en amont.
- Les périodes bloquées. Clôture comptable, inventaire, haute saison commerciale. Une PME du retail ne migre pas en novembre, un cabinet comptable ne migre pas entre mars et mai.
Ce dernier point mérite d'être posé dès le premier échange. Sur une année, il ne reste souvent que deux fenêtres praticables, et elles se réservent longtemps à l'avance.
À l'inverse, deux éléments raccourcissent le calendrier plus qu'on ne l'imagine. Un annuaire déjà synchronisé avec Entra ID fait gagner une à deux semaines, parce que les identités n'ont pas à être recréées. Et une direction capable de trancher en séance, plutôt qu'en comité mensuel, supprime les temps morts entre les phases. Sur les projets qui glissent, le délai perdu se situe presque toujours entre deux décisions, pas pendant une opération technique.
Quelle est la charge côté client, concrètement ?
C'est le sujet le plus mal traité de la profession. Un prestataire peut migrer des données ; il ne peut pas décider à votre place de la structure de vos dossiers ni identifier vos référents métier.
Voici ce que le client fournit obligatoirement, quel que soit le prestataire :
- Un interlocuteur unique disponible sur toute la durée, avec un pouvoir d'arbitrage réel.
- Les décisions de périmètre : quels comptes on garde, quelles données on reprend, quelles données on archive, quel niveau de partage externe on autorise.
- La cartographie métier : qui travaille avec qui, quels dossiers servent à quoi, quelles applications envoient des mails.
- La disponibilité des équipes pour les sessions de prise en main, y compris celles qui expliqueront qu'elles n'ont pas le temps.
Sur un projet de 100 personnes, cela représente couramment 10 à 15 jours cumulés répartis sur deux mois. Une entreprise qui refuse de dégager ce temps aura une migration techniquement réussie et un usage médiocre pendant deux ans. Notre page adoption et formation détaille comment nous répartissons cet effort pour qu'il reste supportable.
Peut-on aller plus vite ?
Oui, dans trois cas précis. Si vous partez déjà d'un environnement cloud propre, si votre volumétrie de fichiers est faible, ou si vous acceptez de repartir d'une page blanche sur les fichiers en archivant l'existant plutôt qu'en le reprenant.
Cette dernière option est plus fréquente qu'on ne le croit. Reprendre 3 To de serveur de fichiers dont 80 % n'a pas été ouvert depuis trois ans coûte du temps de copie, du stockage et de la confusion à l'arrivée. Une alternative honnête consiste à migrer les fichiers vivants et à conserver le reste en archive froide, consultable, pendant une durée définie.
En revanche, quatre raccourcis se paient toujours plus cher qu'ils ne rapportent : sauter le pilote, migrer tout le monde en une seule nuit, supprimer l'accompagnement utilisateur, et laisser les droits d'accès se recopier tels quels depuis l'ancien serveur. Ce dernier point crée un sur-partage qui bloquera plus tard votre projet Copilot, comme nous l'expliquons dans l'article pourquoi il faut ranger SharePoint avant de déployer Copilot.
Et après la bascule, ça s'arrête quand ?
Une migration ne se termine pas le jour du dernier basculement. Comptez deux à quatre semaines de stabilisation : mots de passe oubliés, signatures à refaire, imprimantes qui ne scannent plus vers les mails, dossiers introuvables parce qu'ils ont changé de place.
Cette période doit être prévue au contrat, avec un niveau de support renforcé et une décrue programmée. C'est aussi le moment de décider si vous gardez l'exploitation en interne ou si vous la confiez, sujet traité sur notre page infogérance Microsoft 365.
Le décommissionnement de l'ancien environnement intervient plus tard encore, généralement un à trois mois après, une fois la période de conservation écoulée. Le supprimer trop tôt est une erreur classique et irréversible.
Par où commencer
Le chiffrage sérieux d'une migration tient en cinq questions, auxquelles vous pouvez répondre avant même de consulter un prestataire.
- Combien de boîtes aux lettres actives, et quelle taille moyenne ?
- Quel volume de fichiers, et quelle part réellement ouverte dans les douze derniers mois ?
- D'où partez-vous : serveur local, hébergeur, Google Workspace, autre cloud ?
- Quelles applications métier envoient ou reçoivent des mails ?
- Quelles fenêtres calendaires sont interdites dans votre activité ?
Avec ces cinq réponses, un devis se construit en une demi-journée. Sans elles, tout chiffrage est une estimation optimiste qui glissera. Notre audit de 30 minutes sert exactement à ça : poser ces questions, sortir une fourchette de durée et de coût, et vous dire si le projet doit attendre une meilleure fenêtre. La méthode complète est décrite sur la page migration Microsoft 365.
Sur nos projets, les plannings qui glissent le font rarement pour des raisons techniques. Ils glissent quand une décision interne tarde, ou quand un serveur de fichiers se révèle plus désordonné que ce que l'inventaire laissait supposer.
