Sortir de Microsoft 365 : trois chemins vers la souveraineté, un seul qui tient ses promesses

# Sortir de Microsoft 365 : trois chemins vers la souveraineté, un seul qui tient ses promesses

**2026. Les DSI européens ne peuvent plus prétendre ignorer le problème.** Le Cloud Act américain est toujours en vigueur. Le RGPD continue d'exiger une localisation réelle des données. NIS2 impose des obligations de résilience que l'extraterritorialité américaine rend structurellement impossibles à tenir. Et DORA, pour les acteurs du secteur financier, exige désormais une cartographie précise des dépendances critiques — dont Microsoft 365 fait partie, massivement.

Pourtant, quitter l'écosystème Microsoft n'est pas un geste politique. C'est un projet d'architecture, de gouvernance, et de gestion du risque. La vraie question n'est plus *pourquoi* migrer, mais *comment* — et avec quels outils.

Cet article compare trois approches concrètes pour une migration hors Microsoft 365 vers un cloud souverain européen : la migration assistée par un outil spécialisé comme Cloudiway, la migration manuelle via scripts et APIs internes, et le replatforming natif vers une suite collaborative souveraine. Quatre critères techniques : architecture de migration, intégration dans le SI cible, gouvernance des données pendant le transfert, et conformité réglementaire.

Je vais être direct : certaines de ces approches sont des illusions de souveraineté.

Comprendre le point de départ : ce que vous laissez derrière vous

Microsoft 365, ce n'est pas un logiciel. C'est une dépendance systémique : messagerie, agenda, visioconférence, stockage, IAM, gestion des identités, collaboration documentaire — tout est imbriqué dans un écosystème conçu pour être difficile à quitter. Les formats propriétaires (.msg, .pst, les métadonnées Exchange), les droits d'accès conditionnels Azure AD, les flux SharePoint et Teams : chaque brique crée une adhérence.

Migrer, c'est d'abord cartographier l'emprise. C'est ensuite choisir un chemin qui ne reproduit pas les mêmes vulnérabilités dans un autre silo.

Approche 1 — Migration assistée via Cloudiway

Architecture

Cloudiway est un outil de migration SaaS spécialisé dans les transferts entre plateformes de messagerie et de collaboration : il orchestre la migration des boîtes mails, calendriers, contacts, fichiers et permissions depuis Exchange/Microsoft 365 vers une cible choisie (Zimbra, Open-Xchange, Nextcloud, etc.). Son architecture repose sur des connecteurs bidirectionnels qui lisent les données dans la source et les écrivent dans la destination, avec gestion des batches, des conflits et des reprises sur erreur.

L'avantage technique est réel : la migration peut être progressive et parallèle, permettant une coexistence temporaire des deux environnements. Les utilisateurs ne migrent pas tous le même jour — ce qui réduit drastiquement le risque opérationnel.

Intégration dans le SI cible

Cloudiway n'est pas une suite collaborative. C'est un outil de transition. Il ne décide pas de votre cible souveraine — il vous aide à y arriver. L'intégration dans le SI cible dépend donc entièrement de votre choix de plateforme de destination. Si vous optez pour une suite souveraine hébergée chez un acteur certifié SecNumCloud, Cloudiway se charge du transfert ; la recomposition des workflows, des droits et des automatisations reste votre responsabilité.

C'est une nuance importante : Cloudiway résout le problème du transport des données, pas celui de la cohérence fonctionnelle post-migration.

Gouvernance des données pendant le transfert

C'est ici que la vigilance s'impose. Cloudiway étant lui-même un service cloud, il faut impérativement vérifier où transitent les données pendant la migration. Est-ce que les emails, les pièces jointes, les fichiers passent par des infrastructures localisées en Europe ? Sous quelle juridiction opère l'outil lui-même ?

Pour une migration vers un cloud souverain, le chemin compte autant que la destination. Une fuite de données sensibles pendant le transfert peut constituer une violation RGPD, même si la cible finale est parfaitement conforme. C'est un angle mort que beaucoup de DSI négligent.

Conformité réglementaire

L'approche Cloudiway est compatible avec une démarche de conformité si — et seulement si — elle est encadrée par un DPA (Data Processing Agreement) solide, une analyse d'impact (DPIA) préalable, et une vérification de la localisation effective des infrastructures utilisées pendant la migration. Pour NIS2 et DORA, la migration elle-même doit être documentée comme un événement de risque géré.

Approche 2 — Migration manuelle via scripts et APIs internes

Architecture

Certaines DSI choisissent de tout faire en interne : extraction via Microsoft Graph API, transformation des formats, injection dans la cible via les APIs natives. Cette approche donne un contrôle total sur le flux de données — rien ne transite par un tiers.

En théorie, c'est l'approche la plus souveraine pendant la migration. En pratique, elle est chronophage, fragile et rarement exhaustive. Les métadonnées Exchange sont complexes, les permissions SharePoint imbriquées sont difficiles à reconstituer, et les calendriers récurrents se comportent mal à l'export. Les équipes internes sous-estiment systématiquement le volume de cas particuliers.

Intégration dans le SI cible

L'intégration dépend là aussi de la cible. Mais l'absence d'outil spécialisé signifie que chaque connecteur, chaque règle de transformation, chaque gestion d'erreur doit être développée sur mesure. Le coût humain est élevé. Et le risque de régression fonctionnelle est important.

Gouvernance des données pendant le transfert

C'est le point fort de cette approche : si tout est fait en interne, sur des machines maîtrisées, dans un périmètre réseau contrôlé, les données ne quittent jamais votre emprise. C'est un argument fort pour les organisations traitant des données particulièrement sensibles (santé, défense, finance).

Conformité réglementaire

Bonne maîtrise théorique du flux. Mais attention : une migration manuelle mal documentée est aussi un risque NIS2. Si un incident survient pendant le transfert, pouvez-vous prouver que le processus était maîtrisé ? La conformité ne se limite pas à la localisation des données — elle inclut la traçabilité du processus.

Approche 3 — Replatforming natif vers une suite souveraine

Architecture

La troisième voie consiste à ne pas se concentrer sur la migration des données existantes, mais sur la reconstruction de l'environnement de travail sur une base souveraine dès le départ — en acceptant une rupture partielle avec l'historique. Les données critiques sont migrées (souvent via un outil comme Cloudiway ou une prestation intégrateur), et le reste est archivé ou abandonné.

C'est l'approche la plus radicale. Elle suppose un changement de paradigme : on ne cherche pas à reproduire Microsoft 365 sur une autre plateforme — on construit un environnement de travail souverain avec ses propres logiques.

Intégration dans le SI cible

C'est ici que le choix de la plateforme cible devient décisif. Des suites comme Nextcloud (en déploiement on-premise ou chez un hébergeur certifié) permettent une intégration profonde avec des outils de gestion d'identités européens, des systèmes de signature électronique conformes eIDAS, des outils de visioconférence souverains. L'intégration est plus complexe à construire, mais elle est architecturalement propre — sans dépendance cachée à Azure AD ou à un tenant Microsoft.

Gouvernance des données pendant le transfert

Elle peut être hybride : replatforming natif pour les nouveaux flux, migration assistée pour l'historique. C'est souvent le scénario le plus pragmatique pour les ETI qui ne peuvent pas se permettre un arrêt complet.

Conformité réglementaire

C'est l'approche qui offre la meilleure garantie à long terme au regard du Cloud Act. En éliminant toute dépendance à une infrastructure américaine, vous supprimez le vecteur d'extraterritorialité. Pour DORA et NIS2, la cartographie des dépendances devient enfin lisible. C'est aussi la seule approche qui résiste à une évolution réglementaire future — car elle ne dépend pas de la bonne volonté d'un acteur américain pour rester conforme.

Tableau comparatif

| Critère | Migration Cloudiway | Migration manuelle | Replatforming natif |

|---|---|---|---|

| Architecture de migration | Orchestrée, progressive, robuste | Artisanale, contrôlée, fragile | Rupture assumée, reconstruction propre |

| Intégration SI cible | Dépend de la cible choisie | Dépend des ressources internes | Intégration native, plus longue à construire |

| Gouvernance pendant le transfert | À vérifier (localisation du service) | Maximale (flux interne) | Hybride selon la part migrée |

| Conformité RGPD/NIS2/DORA/Cloud Act | Conditionnelle (DPIA obligatoire) | Bonne si documentée | Structurellement la plus solide |

Ce que je pense, clairement

Il n'y a pas de migration parfaite. Mais il y a des migrations qui construisent une souveraineté réelle — et des migrations qui déplacent simplement le problème d'un silo américain vers un autre point de fragilité.

Cloudiway est un outil utile, potentiellement précieux pour les ETI qui n'ont pas les ressources d'une DSI étendue. Mais il faut l'encadrer sérieusement : DPIA, vérification de la localisation des infrastructures, DPA contractualisé. Utilisé sans ce cadre, il ne garantit pas la souveraineté du chemin — seulement, peut-être, celle de la destination.

La migration manuelle est une illusion de maîtrise pour beaucoup d'organisations. Elle convient aux structures qui ont les compétences internes et le temps — et qui traitent des données si sensibles que le transit chez un tiers est exclu.

Le replatforming natif est la seule approche qui traite le problème à la racine. Il faut l'assumer comme un projet de transformation, pas comme une migration technique. Ce n'est pas plus cher au sens total du coût — c'est différemment coûteux. Et c'est la seule voie qui, dans cinq ans, ne vous exposera pas à la prochaine variation d'une politique commerciale américaine ou à la prochaine injonction d'un tribunal américain.

La souveraineté numérique n'est pas un label. C'est une architecture. Il faut choisir en conséquence.