Migration M365 : on ne migre pas que des données

La première question à se poser

Quand une organisation lance une migration vers Microsoft 365, la première question qui revient presque systématiquement est celle du délai : combien de temps le projet va-t-il prendre ? La réponse honnête est le plus souvent la même : plus que prévu initialement.

Pas parce que le projet est mal piloté. Mais parce qu’une migration Microsoft 365 fait presque toujours remonter des sujets qui n’avaient pas été complètement identifiés au départ. Des identités à nettoyer. Des droits d’accès historiques dont plus personne ne connaît l’origine. Des archives dispersées sur plusieurs serveurs. Des usages métiers jamais vraiment documentés. Et parfois, des choix de sécurité ou de gouvernance qui n’ont tout simplement jamais été posés clairement.

Ce qu’on migre vraiment

Une migration M365 commence presque toujours par la messagerie. C’est le point d’entrée le plus naturel : Exchange, les boîtes aux lettres, les calendriers, les archives associées. Mais très vite, le périmètre du projet s’élargit.

On en vient à parler de serveurs de fichiers, de SharePoint, de Teams, de OneDrive, de gestion documentaire, d’accès externes, de sécurité, de conformité. Et c’est à ce moment précis qu’une réalité s’impose : on ne migre pas seulement des données.

On migre aussi une organisation. Ses habitudes de travail. Ses règles implicites, jamais écrites nulle part. Ses dossiers jamais triés depuis des années. Ses groupes de sécurité créés à une époque que plus personne ne se rappelle vraiment. Ses droits d’accès dont la logique d’origine s’est perdue en cours de route.

Si l’on se contente de déplacer cet ensemble tel quel dans Microsoft 365, on ne modernise pas l’environnement. On déplace simplement le désordre existant, avec une interface plus moderne autour.

Les sujets à anticiper avant la bascule

Sur les projets accompagnés par les équipes de BSD, quelques sujets reviennent presque à chaque fois, quel que soit le secteur ou la taille de l’organisation.

Les identités. Avant toute migration, il faut savoir précisément comment les utilisateurs vont se connecter à Microsoft 365, et corriger les incohérences accumulées dans l’annuaire au fil des années : comptes doublons, comptes orphelins, attributs mal renseignés.

Les droits et les permissions. Accès anciens jamais révoqués, groupes imbriqués les uns dans les autres, partages oubliés depuis longtemps : au moment de migrer, une décision s’impose pour chacun. Qu’est-ce qu’on reprend tel quel ? Qu’est-ce qu’on nettoie avant de basculer ? Et qu’est-ce qu’on reconstruit proprement, plutôt que de reproduire une architecture devenue illisible ?

Les archives et les données historiques. Sur la messagerie comme sur les fichiers, migrer l’intégralité de l’existant n’est pas toujours la bonne décision. Une partie de ces données n’a plus d’usage réel et mérite d’être archivée différemment, voire supprimée, plutôt que transportée telle quelle dans le nouvel environnement.

La sécurité et la conformité. Ce sujet est souvent celui qui pâtit le plus d’un traitement tardif. Traité après le Go Live, il oblige presque toujours à corriger dans l’urgence ce qui aurait dû être cadré dès le départ du projet.

La bonne approche projet

Une migration réussie suit rarement une logique de bascule directe, où l’on déplacerait tout d’un seul tenant un week-end donné.

Le projet démarre par un audit et une conception cible. On inventorie l’existant, on regarde les volumes réels de données, on cartographie les accès en place, on identifie les zones à risque. Et surtout, on décide collectivement ce qui mérite réellement d’être migré, plutôt que de partir du principe que tout doit suivre.

Vient ensuite la construction du socle Microsoft 365 : tenant, identités, sécurité, partage, gouvernance. Cette étape pose les fondations sur lesquelles reposera l’ensemble de l’environnement cible.

Le projet passe alors par un pilote : un périmètre limité, mais représentatif de la diversité des usages, pour valider les choix techniques avant d’étendre la démarche à l’ensemble de l’organisation. C’est à ce stade que remontent les points de friction qu’aucun audit théorique n’aurait pu anticiper.

Le déploiement progressif n’intervient qu’ensuite, vague après vague. Une migration se déroule rarement bien quand les problèmes sont découverts au moment même de la bascule, plutôt qu’en amont sur un périmètre restreint.

Un exemple révélateur

Un cas revient régulièrement sur ce type de projet : une entreprise découvre, en cartographiant ses accès avant migration, qu’un ancien prestataire dispose encore de droits sur un espace de partage utilisé quotidiennement par les équipes commerciales. Personne n’avait pensé à révoquer cet accès à la fin de la mission, plusieurs années auparavant. Sans l’exercice de cartographie imposé par le projet de migration, cette situation serait probablement restée invisible encore longtemps.

C’est tout l’intérêt d’une phase d’audit menée sérieusement : elle transforme un projet technique en occasion de remettre à plat des sujets qui, sans cela, ne trouvent jamais vraiment de moment dédié dans l’agenda d’une organisation.

L’accompagnement au changement, souvent sous-estimé

Un sujet n’apparaît pas toujours dans le besoin initial exprimé par les organisations, mais fait souvent toute la différence à l’arrivée : l’accompagnement au changement.

Un environnement Microsoft 365 techniquement bien configuré, mais mal adopté par les équipes, ne produit pas la valeur attendue. Les utilisateurs recréent leurs anciennes habitudes de travail, contournent les nouveaux outils mis à leur disposition, ou se contentent d’utiliser Teams, SharePoint et OneDrive comme de simples espaces de stockage, sans exploiter les usages collaboratifs qu’ils permettent.

C’est la raison pour laquelle l’accompagnement doit démarrer avant le Go Live, et non après. Il se prolonge ensuite dans les semaines qui suivent la bascule, pour ancrer durablement les nouveaux usages plutôt que de les laisser s’éroder au fil du temps.

Après le Go Live : la vraie mesure de réussite

Le Go Live constitue une étape du projet. Ce n’est pas la fin du projet, contrairement à ce que son nom peut laisser penser.

La vraie question se pose souvent après : les équipes utilisent-elles réellement le nouvel environnement, ou reproduisent-elles leurs anciens réflexes sous une interface différente ? À J+30, J+60, J+90, plusieurs indicateurs permettent de le vérifier : les usages prennent-ils vraiment ? Les anciens réflexes disparaissent-ils progressivement ? Les accès configurés au moment de la bascule restent-ils maîtrisés dans le temps ? L’environnement tient-il la charge une fois la nouveauté passée ?

C’est souvent à ce moment, plusieurs semaines après la bascule technique, que se mesure la réussite réelle d’une migration.

Questions fréquentes sur la migration M365

Combien de temps dure une migration Microsoft 365 ? La durée varie fortement selon le volume de données, le nombre d’utilisateurs et l’état des accès existants. Un projet mené sérieusement, avec une phase d’audit préalable, prend généralement plus de temps qu’une simple bascule technique, mais réduit fortement les correctifs à réaliser après le Go Live.

Faut-il migrer toutes les données historiques ? Pas nécessairement. Une partie des archives n’a plus d’usage réel pour les équipes et peut être traitée différemment plutôt que transportée telle quelle dans le nouvel environnement. La phase d’audit permet justement de faire ce tri en amont.

Quand traiter la sécurité et la conformité dans un projet de migration ? Le plus tôt possible, dès la phase de conception cible. Traités après le Go Live, ces sujets obligent presque toujours à corriger dans l’urgence ce qui aurait dû être cadré dès le départ.

Qu’est-ce qu’un pilote de migration, concrètement ? Il s’agit d’un périmètre restreint, mais représentatif des usages réels de l’organisation, migré en premier pour valider les choix techniques avant le déploiement à l’ensemble des équipes.

Un moment pour remettre à plat l’organisation de l’information

Une migration Microsoft 365 bien menée n’est pas qu’un projet technique parmi d’autres. C’est un moment privilégié pour remettre à plat l’organisation de l’information d’une entreprise : clarifier les accès, nettoyer l’existant accumulé au fil des années, sécuriser le tenant, et préparer sereinement ce qui vient ensuite.

Pour une organisation qui a un projet de migration M365 en réflexion, le premier réflexe ne devrait donc pas être de parler planning. Le premier réflexe consiste à cadrer les sujets à risque avant la bascule : identités, droits d’accès, archives, sécurité et conformité.

Vous envisagez une migration vers Microsoft 365 ou vous vous interrogez sur la meilleure façon de la préparer ? Contactez nos équipes pour évoquer un audit de cadrage adapté à votre environnement.