Migration Google Workspace à Paris et en petite couronne : devis gratuit en 2 minutes

Une migration Google Workspace consiste à transférer l’organisation numérique complète d’une entreprise vers la suite de Google : comptes utilisateurs, courriels, contacts, agendas, fichiers et partages. Le mouvement peut aussi être inverse, lorsqu’une entreprise quitte Google Workspace pour une autre plateforme. Dans les deux cas, la méthode reste la même : inventaire, préparation du domaine, copie, bascule et accompagnement.

Ce qui se transfère, et ce qui se reconstruit

Les courriels, contacts, agendas et fichiers se copient à l’aide d’outils de transfert adaptés à la plateforme de départ. Les éléments de configuration, eux, se reconstruisent à la main : alias, groupes de diffusion, règles de routage, droits sur les Drive partagés et intégrations avec les applications métier. Ce sont ces éléments qui demandent le plus de vérifications.

Le domaine, pivot de la bascule

Le nom de domaine reste le point d’entrée de la messagerie. Ses enregistrements DNS, en particulier MX, indiquent où arrivent les courriels. Les enregistrements SPF, DKIM et DMARC précisent en plus quels serveurs ont le droit d’envoyer au nom de l’entreprise. Une migration soignée prépare ces enregistrements avant la bascule, réduit à l’avance la durée de mise en cache (TTL) de l’enregistrement MX pour que le changement se propage vite, génère la clé DKIM dans la console d’administration et ajoute Google à l’enregistrement SPF existant plutôt que d’en créer un second, ce qui invaliderait les deux.

Le sujet arrive rarement par hasard. Quelques situations reviennent souvent :

• Une messagerie d’hébergeur qui ne suit plus : la boîte atteint ses limites, les envois deviennent difficiles et l’entreprise cherche une solution adaptée à sa croissance.
• Des comptes issus de deux univers : après un rachat ou une fusion, des collaborateurs utilisent encore Microsoft 365 et Google sans règle commune.
• Des fichiers dispersés : documents sur des disques locaux, clés USB ou comptes personnels, sans qu’aucun espace partagé ne fasse référence.
• La crainte d’une perte de courriels : une bascule sans préparation inquiète à juste titre, surtout lorsque des clients attendent une réponse.
• Des droits que personne ne maîtrise : des dossiers partagés restent accessibles à d’anciens salariés, ou au contraire fermés à ceux qui en ont besoin.
• Des enregistrements DNS modifiés sans trace : un ancien prestataire a changé la configuration, et l’équipe ignore quel service dépend de chaque entrée.
• Des courriels classés en indésirables : les messages de l’entreprise n’arrivent plus chez les destinataires, faute d’authentification correcte du domaine.
• Des applications qui envoient par l’ancien serveur : un logiciel de facturation ou un outil de supervision continue d’utiliser une messagerie appelée à disparaître.

Avant la bascule : inventaire et préparation

Le projet commence par un inventaire précis : boîtes, alias, groupes, agendas partagés, Drive partagés, applications reliées à la messagerie et volume de données à transférer. Le prestataire crée ensuite le domaine dans la console d’administration, définit les unités organisationnelles, les règles de sécurité et la double authentification. Les comptes sont préparés sans être encore utilisés par les équipes.

Pendant la migration : copie et bascule

La copie des courriels, contacts et agendas s’effectue en amont, souvent en plusieurs passes, pour limiter ce qui reste à transférer le jour de la bascule. Celle-ci consiste à modifier l’enregistrement MX au moment convenu, de préférence en dehors des heures de forte activité. Pendant la propagation, les messages peuvent arriver sur l’une ou l’autre messagerie ; une passe de rattrapage récupère ensuite ceux qui sont restés sur l’ancienne boîte.

Après la bascule : droits, accompagnement et contrôle

Une fois les courriels acheminés, les droits de partage sont recartographiés vers les Drive partagés et les groupes. Les utilisateurs reçoivent des notices courtes, des sessions de prise en main et une assistance renforcée les premiers jours. Le prestataire vérifie l’authentification du domaine avec SPF, DKIM et DMARC, contrôle les envois des applications, puis désactive l’ancienne messagerie à l’issue d’une période convenue.

Deux propositions peuvent sembler proches et couvrir des périmètres très différents. Pour les comparer, il faut regarder ce qui est réellement inclus, et non seulement l’intitulé de la prestation. Quelques points s’examinent en priorité :

• Le périmètre des comptes et des données : le devis indique si les boîtes, contacts, agendas et fichiers sont tous concernés, et si les archives font partie du projet.
• La méthode de bascule : une bascule en une fois et une bascule service par service n’ont ni le même coût ni les mêmes risques. L’offre doit préciser celle qui est proposée et pourquoi.
• La recartographie des droits : elle prend souvent plus de temps que la copie. Une offre sérieuse la mentionne explicitement, avec sa méthode de contrôle.
• La gestion du DNS : il faut savoir qui modifie les enregistrements, à quel moment, et qui conserve l’accès aux comptes du domaine une fois le projet terminé.
• L’accompagnement des utilisateurs : notices, sessions de prise en main, assistance les premiers jours, et interlocuteur identifié après la fin du chantier.

Pour une comparaison juste, alignez les propositions sur les mêmes éléments : mêmes comptes, mêmes données, même méthode de bascule et même répartition des responsabilités sur le domaine. Un devis muet sur l’un de ces points n’est pas comparable à un autre.

1. Copier sans inventorier. Les alias, groupes et règles de routage disparaissent dans la copie. Parade : un inventaire écrit, relu avant toute copie.
2. Modifier le DNS sans préparer les enregistrements. Des messages sont rejetés si une boîte de destination n’existe pas encore, ou classés en indésirables si SPF et DKIM ne couvrent pas le nouvel expéditeur. Parade : créer toutes les boîtes et tous les alias, préparer MX, SPF, DKIM et DMARC, puis tester l’envoi et la réception avant la bascule.
3. Oublier les applications qui envoient des courriels. Un logiciel de facturation ou un outil de supervision continue d’utiliser l’ancien serveur, et ses messages cessent d’arriver. Parade : lister chaque application et définir son mode d’envoi.
4. Laisser les droits de partage au hasard. Des fichiers se retrouvent ouverts à tous ou inaccessibles à leurs équipes. Parade : recartographier les droits vers les Drive partagés avant la bascule, puis les valider avec les responsables de service.
5. Négliger la conduite du changement. Les équipes, habituées à leur ancienne messagerie, perdent du temps pendant des semaines. Parade : prévoir des sessions de prise en main et un point d’assistance pendant les premiers jours.

Avant de confier le projet, posez des questions précises. La réponse doit décrire une méthode, et non une promesse vague.

Comment la passe de rattrapage est-elle organisée après la bascule, et qui la lance ? Les droits de partage sont-ils recartographiés vers les Drive partagés, et selon quelle méthode ? Qui modifie les enregistrements DNS, à quel moment, et qui garde la main sur le domaine à la fin du projet ? Quel accompagnement est prévu pour les utilisateurs les premiers jours, et qui répond aux questions ensuite ?

Si l’entreprise quitte Google Workspace plutôt que d’y entrer, demandez aussi quels outils assureront le transfert et comment seront traités les fichiers dont les droits ne se transposent pas. Des réponses écrites permettent de comparer les offres sur des bases identiques.