Migration de Google Workspace ou Microsoft 365 vers Infomaniak

Le guide pour les organisations suisses

Introduction

Pendant des années, Google Workspace et Microsoft 365 se sont imposés comme les références incontournables pour gérer les emails, les documents et la collaboration au sein des organisations. Des outils efficaces, bien intégrés, simples à déployer — et adoptés parfois sans vraiment se poser la question de ce qu’ils impliquent côté données.

Cette question, de plus en plus d’organisations suisses commencent à se la poser. Où sont réellement hébergées les données traitées au quotidien — emails, fichiers, calendriers, contacts ? Sous quelle législation ? Avec quelles garanties en cas de litige ou de contrôle ?

Depuis l’entrée en vigueur de la LPD révisée en septembre 2023, les organisations qui traitent des données personnelles — que ce soit celles de collaborateurs, de clients ou d’usagers — ont des obligations renforcées en matière de protection et de localisation de ces données. Or, Google et Microsoft sont des entreprises américaines. Leurs infrastructures, même lorsqu’elles sont physiquement situées en Europe, restent potentiellement soumises au Cloud Act américain, une loi qui permet aux autorités américaines d’accéder à des données hébergées par des entreprises américaines, où qu’elles se trouvent dans le monde.

C’est dans ce contexte que des solutions comme kSuite d’Infomaniak — hébergée intégralement en Suisse, soumise au seul droit suisse — attirent une attention croissante.

Cet article explique pourquoi certaines organisations choisissent de migrer, comment évaluer si une migration est pertinente, et comment bien la préparer pour éviter toute interruption de service.

1. Pourquoi la localisation des données est devenue un enjeu concret

1.1 Ce que le Cloud Act implique pour les organisations suisses

En 2018, les États-Unis ont adopté le Clarifying Lawful Overseas Use of Data Act, plus connu sous le nom de Cloud Act. Cette loi autorise les autorités américaines à exiger d’une entreprise américaine qu’elle leur transmette des données stockées sur ses serveurs — y compris lorsque ces serveurs sont situés en dehors des États-Unis.

Concrètement, cela signifie que des données hébergées chez Google ou Microsoft peuvent être soumises à cette obligation, même si les datacenters utilisés sont physiquement en Irlande, en Allemagne ou aux Pays-Bas. Le critère déterminant n’est pas la localisation des serveurs, mais la nationalité de l’entreprise qui les exploite.

Pour une organisation qui traite des données sensibles — données de santé, données administratives, données d’élèves ou d’usagers — cette réalité juridique mérite d’être prise en compte dans les choix d’infrastructure.

1.2 La LPD révisée et ses implications

La nouvelle loi fédérale sur la protection des données (LPD), entrée en vigueur le 1er septembre 2023, renforce les obligations des organisations suisses en matière de traitement des données personnelles. Parmi les points les plus structurants :

• La responsabilité reste avec l’organisation, même lorsque le traitement est délégué à un prestataire externe. Confier ses données à Google ou Microsoft ne décharge pas l’organisation de sa responsabilité légale.
• Les transferts de données à l’étranger sont encadrés : ils ne sont autorisés que si le pays destinataire offre un niveau de protection adéquat, ou si des garanties contractuelles suffisantes sont en place.
• La documentation et la traçabilité des traitements deviennent obligatoires pour de nombreuses organisations.

Dans ce cadre, le choix de l’hébergement n’est plus seulement une question technique — c’est aussi une question de conformité.

1.3 Pourquoi « serveurs en Europe » ne suffit pas

Un argument souvent avancé par Google et Microsoft est que les données des clients européens sont hébergées dans des datacenters situés en Europe. C’est en partie vrai. Mais cette garantie géographique ne résout pas la question juridique posée par le Cloud Act.

Une entreprise suisse ou européenne qui héberge ses données chez un opérateur américain reste exposée à ce cadre légal, indépendamment de la localisation physique des serveurs. Ce point est régulièrement soulevé par des juristes spécialisés en droit du numérique et par le Préposé fédéral à la protection des données (PFPDT).

Choisir un hébergeur soumis exclusivement au droit suisse — comme Infomaniak, dont l’infrastructure est entièrement basée en Suisse et dont le capital est détenu par des actionnaires suisses — élimine cette ambiguïté juridique.

2. Faut-il vraiment migrer ?

Migrer vers une nouvelle plateforme n’est pas une décision anodine. Avant de se lancer, il vaut la peine d’évaluer honnêtement la situation.

2.1 Quand rester sur l’infrastructure actuelle est raisonnable

Certaines situations justifient de ne pas migrer, du moins pas immédiatement :

• Les équipes sont fortement dépendantes d’outils spécifiques difficiles à remplacer (macros Excel complexes, intégrations Power BI, Google AppScript, etc.)
• De nombreux outils tiers sont déjà connectés à l’infrastructure en place.
• Aucune échéance réglementaire ou contractuelle ne pousse à bouger.

Dans ces cas, une migration forcée crée plus de perturbations qu’elle n’en résout.

2.2 Les signaux qui indiquent qu’il est temps d’agir

À l’inverse, certains contextes rendent la migration particulièrement pertinente :

• Un audit de conformité LPD est prévu ou en cours.
• Le contrat Google ou Microsoft arrive à renouvellement — c’est souvent le meilleur moment pour réévaluer.
• Une directive interne ou externe pousse à rapatrier les données en Suisse.
• L’organisation souhaite réduire sa dépendance à des acteurs dont les conditions peuvent changer unilatéralement.

3. Ce que kSuite d’Infomaniak inclut concrètement

Avant de migrer, il est utile de savoir ce que la plateforme de destination propose réellement. kSuite d’Infomaniak regroupe les services essentiels dans une seule interface :

• Mail — messagerie professionnelle avec gestion des domaines, alias et groupes
• kDrive — stockage et partage de fichiers
• kCalendar / kContacts — calendriers et contacts synchronisables avec les clients standard (Outlook, Apple Mail, Thunderbird)
• kChat — messagerie interne et collaboration en équipe
• kMeet — visioconférence intégrée

Fonctionnalité	kSuite	Google Workspace	Microsoft 365
Email professionnel	✅	✅	✅
Stockage fichiers	✅	✅	✅
Calendrier / Contacts	✅	✅	✅
Visioconférence	✅	✅	✅
Édition collaborative docs	Basique	Avancée	Avancée
Hébergement Suisse	✅	❌	❌
Soumis au Cloud Act	❌	✅	✅

À noter : les outils d’édition collaborative de kSuite (traitement de texte, tableur en ligne) restent moins aboutis que Google Docs ou Microsoft Office. Pour des organisations qui travaillent intensément sur des documents complexes en temps réel, c’est un point à prendre en compte.

4. Préparer la migration

Une migration réussie repose avant tout sur une bonne préparation. L’objectif est d’éviter les surprises le jour de la bascule.

4.1 Faire l’inventaire de ce qui existe

Avant toute chose, il faut cartographier ce qui sera migré :

• Emails : nombre de boîtes, volume, historique à conserver
• Fichiers : contenu Google Drive ou OneDrive, structure des dossiers, droits de partage
• Comptes utilisateurs : liste complète, groupes, alias email
• Outils connectés : CRM, formulaires, signatures électroniques, SSO — tout ce qui dépend de l’infrastructure actuelle

C’est souvent à cette étape qu’on découvre des dépendances oubliées.

4.2 Évaluer la complexité

Quelques questions simples permettent d’estimer l’ampleur du chantier :

• Combien d’utilisateurs sont concernés ?
• Quel est le volume total des boîtes mail et des fichiers stockés ?
• Faut-il tout migrer, ou seulement les données récentes ?

4.3 Préparer les équipes

La dimension humaine est souvent sous-estimée. Il est utile de :

• Informer les collaborateurs en amont de la date de bascule
• Désigner un référent interne qui centralise les questions
• Prévoir une courte prise en main des nouveaux outils

5. Les étapes techniques de la migration

Une migration se déroule généralement en plusieurs étapes distinctes, dans un ordre précis pour éviter toute interruption de service.

5.1 Configurer l’environnement Infomaniak

La première étape est de préparer la nouvelle infrastructure avant de toucher à l’ancienne :

• Créer l’organisation dans kSuite
• Ajouter le domaine de l’organisation
• Configurer les enregistrements DNS nécessaires (MX, SPF, DKIM)
• Créer les comptes utilisateurs, groupes et alias

5.2 Migrer les emails

Infomaniak propose un assistant de migration qui permet de copier les boîtes mail existantes via IMAP. L’historique, les dossiers et les archives sont conservés. Cette étape peut tourner en arrière-plan sans interrompre le service actuel.

5.3 Migrer les fichiers

Les fichiers stockés sur Google Drive ou OneDrive sont exportés puis importés dans kDrive. Il est important de vérifier la structure des dossiers et les droits de partage après l’import — ils ne sont pas toujours recréés automatiquement.

5.4 Migrer calendriers et contacts

Les calendriers s’exportent au format ICS, les contacts au format vCard. Ces formats sont standards et compatibles avec kCalendar et kContacts sans manipulation complexe.

5.5 Tester avant de basculer

Avant de modifier les DNS pour faire pointer le domaine vers Infomaniak, il est recommandé de :

• Tester les flux emails entrants et sortants
• Vérifier les accès de quelques utilisateurs pilotes
• Contrôler les partages de fichiers et les calendriers

La bascule DNS est la dernière étape — c’est elle qui rend le changement effectif pour l’ensemble des utilisateurs.

6. Combien de temps faut-il prévoir ?

La durée d’une migration dépend principalement du nombre d’utilisateurs et du volume de données à transférer.

Structure	Préparation	Migration	Total estimé
1–10 utilisateurs	Quelques heures	Quelques heures	1 jour max
10–50 utilisateurs	1 jour	1–2 jours	2 à 3 jours
50+ utilisateurs	Plusieurs jours	Plusieurs jours	1 à 3 semaines

Deux approches sont possibles selon le contexte :

• Migration progressive : les utilisateurs basculent par groupes, ce qui permet de détecter les problèmes au fur et à mesure. Recommandée pour les structures sensibles ou de taille importante.
• Bascule complète : tout le monde migre en une fois à une date précise. Plus simple à coordonner, mais moins de marge en cas d’imprévu.

Dans les deux cas, prévoir une période de double-run courte — quelques jours pendant lesquels les deux systèmes fonctionnent en parallèle — réduit considérablement le risque d’interruption.

Conclusion

Migrer de Google Workspace ou Microsoft 365 vers Infomaniak n’est pas simplement un changement d’outil. C’est avant tout un choix sur la gouvernance des données de l’organisation — où elles sont hébergées, sous quelle législation, avec quelles garanties.

Dans un contexte où la LPD renforce les obligations des organisations suisses et où le Cloud Act crée une ambiguïté juridique persistante pour les hébergeurs américains, ce choix devient de plus en plus structurant.

Une migration bien préparée — avec un inventaire clair, une communication interne en amont et une bascule progressive — peut se faire sans perturber le travail des équipes. La complexité est souvent surestimée, surtout pour les structures de taille moyenne.