Pourquoi la migration technique n'est pas le sujet
Déplacer des boîtes mail de Gmail vers Exchange Online est un problème résolu. Les outils du marché savent lire une boîte Google, la recopier dans Microsoft 365, gérer les délais, reprendre les nouveaux messages arrivés pendant la copie. Sur un projet de 80 boîtes, cette partie occupe une poignée de nuits et se passe généralement bien.
Le problème est ailleurs. Google Workspace et Microsoft 365 ne rangent pas les fichiers de la même façon, ne partagent pas de la même façon, et ne donnent pas les mêmes réflexes aux utilisateurs. Une entreprise qui a passé six ans sur Google a construit des habitudes qui n'ont pas d'équivalent direct en face. C'est là que le projet prend du retard.
Le transfert des données se planifie, se chiffre et se vérifie ; la reprise des habitudes ne se laisse faire aucun des trois. C'est exactement pour cette raison qu'elle est le poste le plus systématiquement sous-estimé par les directions : elle n'apparaît sur aucune ligne du devis technique.
Quelles équivalences Google-Microsoft sont trompeuses ?
La plupart des tableaux d'équivalence que l'on trouve en ligne alignent les logos deux par deux et s'arrêtent là. En pratique, chaque ligne cache une différence de comportement qui se paie en incidents la semaine du basculement.
| Outil Google | Équivalent Microsoft annoncé | Le piège concret |
|---|---|---|
| Gmail | Exchange Online / Outlook | Les libellés ne sont pas des dossiers. Un message portant trois libellés devient trois copies ou un seul dossier, selon l'outil de migration. Les règles de tri sont à refaire. |
| Mon Drive | OneDrive Entreprise | Comparable, mais les chemins longs et les caractères interdits (*, :, <, >) bloquent une partie des fichiers. Il faut nettoyer avant de copier. |
| Drive partagés | Bibliothèque SharePoint ou équipe Teams | Le modèle de droits est différent : chez Google le fichier appartient au Drive, chez Microsoft il hérite du site. Voir la section suivante. |
| Docs, Sheets, Slides | Word, Excel, PowerPoint | La conversion casse les formules propres à Google (QUERY, IMPORTRANGE, ARRAYFORMULA), les scripts liés et une partie de la mise en forme des présentations. |
| Google Forms | Microsoft Forms | Forms couvre le questionnaire simple. Les logiques conditionnelles avancées et les workflows de validation demandent Power Automate, voire Power Apps. |
| Google Sites | Pages SharePoint | Pas de reprise automatique. Chaque site est à reconstruire, ce qui est l'occasion d'en supprimer la moitié. |
| Google Groups | Groupes Microsoft 365, listes de distribution, boîtes partagées | Un Google Group fait office de liste de diffusion, de forum et de groupe de droits. Côté Microsoft, ce sont trois objets différents à choisir un par un. |
| Google Chat et Meet | Teams | Aucune reprise d'historique de conversation en pratique. Prévoyez un export si la conservation a une valeur juridique. |
| Google Vault | Purview (rétention, eDiscovery) | Les fonctions avancées dépendent du niveau de licence. Vérifiez ce que couvre votre plan avant de promettre l'équivalent (à vérifier à date). |
| Apps Script | Power Automate, Power Apps, Office Scripts | Aucune conversion possible. Chaque script maison est à réécrire ou à abandonner. C'est le poste de coût le plus souvent oublié. |
| Lien « toute personne disposant du lien » | Lien de partage SharePoint | Beaucoup d'entreprises désactivent le partage anonyme à l'arrivée. Les liens Google diffusés à l'extérieur cesseront de fonctionner. |
| Google Keep | OneNote ou Microsoft To Do | Deux outils pour un seul, et un export peu confortable. |
Que deviennent les Drive partagés ?
C'est le sujet numéro un. Un Drive partagé Google est un espace autonome : les fichiers appartiennent au Drive, pas à une personne, et les droits se posent au niveau du Drive entier ou de dossiers isolés. Beaucoup d'organisations en ont créé des dizaines, parfois un par projet, parfois un par client.
Côté Microsoft, la question devient : est-ce que ce Drive doit devenir une bibliothèque SharePoint, une équipe Teams, ou disparaître ? Les trois réponses sont valables selon les cas, et le choix ne peut pas être automatisé. Nous traitons cette règle de décision en détail dans notre article Teams, SharePoint ou OneDrive : où doit-on ranger quoi.
Trois écueils reviennent à chaque projet :
- Les Drive orphelins. Un Drive créé pour un projet terminé en 2023, que personne n'ouvre plus, mais que personne n'ose supprimer. Migrer 400 Go de fichiers morts coûte du temps de copie et pollue l'index de recherche à l'arrivée.
- Les droits par dossier. Google autorise des exceptions de droits à l'intérieur d'un Drive. SharePoint le permet aussi, mais chaque exception devient une dette : elle échappe à l'héritage et complique tout audit ultérieur.
- Les fichiers partagés à l'extérieur. Clients, experts-comptables, prestataires. Chaque lien externe actif doit être recensé et recréé, sinon il tombe le jour du basculement.
Nous recommandons de traiter le rangement avant la copie, pas après. Une bibliothèque SharePoint mal construite au départ reste mal construite trois ans plus tard : c'est exactement le problème que nous détaillons dans la page mettre de l'ordre dans mes fichiers SharePoint.
Et les formulaires, les scripts et les petites applications maison ?
Toute entreprise sur Google Workspace depuis plusieurs années a fabriqué des choses. Un formulaire de demande de congés qui alimente une feuille de calcul. Un script qui envoie un récapitulatif tous les lundis. Un tableau partagé qui sert de suivi commercial et que trois personnes remplissent en même temps.
Ces objets n'apparaissent dans aucun inventaire technique. Ils apparaissent le lendemain du basculement, quand quelqu'un signale que « le formulaire ne marche plus ». Il faut donc les chercher activement, avant, en interrogeant les équipes métier.
Le tri se fait en trois catégories : ce qui disparaît — souvent une part notable de l'inventaire, personne ne s'en servant plus —, ce qui est remplacé par un équivalent natif Microsoft Forms ou une liste SharePoint, et ce qui justifie un développement Power Automate ou Power Apps. Cette dernière catégorie doit être chiffrée séparément du projet de migration. Sinon elle le fait déraper.
Pourquoi les utilisateurs résistent-ils autant ?
Parce que la migration leur retire un outil qu'ils maîtrisent pour leur en donner un qu'ils devront réapprendre, sans qu'ils aient demandé quoi que ce soit. La décision vient de la direction, souvent pour des raisons de coût, de sécurité ou d'harmonisation ; le coût du changement, lui, est payé par les équipes.
Trois points de friction reviennent presque toujours :
- La co-édition. Les utilisateurs Google ont l'habitude d'un document collaboratif en temps réel dans le navigateur. La co-édition Microsoft fonctionne, mais les réflexes ne sont pas les mêmes, et l'usage du client lourd Word ou Excel réintroduit des versions locales.
- Le partage. Chez Google, on partage un fichier. Chez Microsoft, on range un fichier au bon endroit et le droit suit. C'est une inversion mentale complète, et c'est la principale cause de sur-partage post-migration.
- La recherche. L'index Google est excellent et les utilisateurs s'en servent en remplacement de tout classement. Un SharePoint mal rangé donne une expérience de recherche décevante, ce qui confirme aux équipes que « c'était mieux avant ».
La réponse n'est pas une session de formation générale de deux heures la veille du basculement. Elle est faite de formats courts, par métier, répétés, avec des référents identifiés dans chaque service. C'est l'objet de notre accompagnement adoption et formation, et c'est la ligne budgétaire qu'il ne faut pas raboter.
Combien de temps prévoir, et pour quel effort interne ?
Une migration Google vers Microsoft 365 est plus longue qu'une migration depuis un serveur Exchange local, à volumétrie égale, parce que le travail de reprise des usages est plus lourd. Les ordres de grandeur par taille d'entreprise sont détaillés dans notre article combien de temps prend une migration Microsoft 365.
Retenez surtout la charge côté client : arbitrer la structure des espaces de fichiers, décider du sort de chaque Drive partagé, identifier les formulaires et scripts en service, désigner les référents métier. Aucun prestataire ne peut faire ce travail à votre place, parce qu'il suppose de connaître qui fait quoi dans l'entreprise.
Par où commencer
Nous démarrons toujours ces projets par un inventaire, pas par un devis de copie de données. Le déroulé type :
- Audit de départ (30 minutes). Volumétrie, nombre de comptes, nombre de Drive partagés, présence de scripts, contraintes réglementaires.
- Cartographie (1 à 2 semaines). Liste complète des Drive, des groupes, des formulaires et des partages externes. Classement en garder / transformer / abandonner.
- Conception de la cible. Structure SharePoint et Teams, modèle de droits, règles de nommage, politique de partage externe. Validée par écrit avant toute copie.
- Pilote. Un service volontaire, de préférence exposé, migré en conditions réelles. Les surprises apparaissent ici, pas en production générale.
- Vagues de bascule. Par service ou par site, avec un accompagnement présent les deux premiers jours de chaque vague.
- Reprise et clôture. Traitement des points restants, décommissionnement de Google Workspace après une période de conservation définie à l'avance.
La méthode complète et les livrables associés sont décrits sur notre page migration Microsoft 365. Sur un projet Google, la durée totale se joue surtout aux étapes 2 et 3 : une cartographie écourtée ou une cible validée trop vite se paie ensuite en incidents à chaque vague de bascule.
