Reprendre le contrôle : sortir de Microsoft 365 en trois semaines

Depuis le 13 octobre, il ne reste plus grand-chose de Microsoft 365 chez Vecteur IT : mes mails, mes fichiers et ceux d’un de mes clients tournent sur des logiciels libres que j’héberge, sur mes clusters Kubernetes.

Je fais un rapide REX, parce que la migration s’est faite d’une façon un peu particulière : du début à la fin avec de l’IA agentique comme copilote (non pas Copilot). Environ 120 Go de mails et 560 Go de fichiers en trois semaines, sans perte de données.

Pourquoi quitter Microsoft 365 ?

Le déclencheur n’a rien de technique : Microsoft a coupé l’accès à sa messagerie à la Cour pénale internationale. Il était facile de le dénoncer, moins de continuer à payer l’abonnement.

Deux raisons de fond ont fait le reste, dans cet ordre.

1. Souveraineté de la donnée : les mails sont sur des serveurs que j’exploite. Altaro est passé chez l’allemand Hornetsecurity, puis chez l’américain Proofpoint ; Vade, français, racheté par le même Hornetsecurity, a suivi. Un éditeur change de drapeau, les données suivent. Chez moi, je décide où elles sont, qui y accède, comment elles sont sauvegardées et quand elles sortent.
2. Prix : la migration libère cinq licences Business Premium. Ce n’est pas l’argument principal, mais pour une petite structure, chaque abonnement compte. Dans ce cadre-là, pouvoir donner à des stagiaires tous les outils d’entreprise sans coût supplémentaire est un plus.

Les hausses s’enchaînent : +12 à +25 % en mars 2022, +10 % en juillet 2025 sur les serveurs sur site, puis +15 et +20 % le mois suivant sur les licences d’accès, et +5 à +33 % en juillet 2026 sur les abonnements. La justification ne change pas : des fonctions ajoutées à la licence, ou la « maintenance et les mises à jour ». On ne choisit ni le périmètre ni le prix, seulement la date du renouvellement.

Puis le 1er octobre 2026, Microsoft réduit la marge partenaire sur Office M365 toutes gammes pour inciter les partenaires à vendre du Copilot. Les prix publics ne changent pas, donc ce que le revendeur perd, l’éditeur le gagne. On croit rêver.

Sur la qualité, rien à redire : Microsoft 365 est performant, fiable et bien pensé. Le désaccord porte sur ce qui se décide au-dessus de l’outil.

Ce n’était pas ma première tentative

J’avais déjà essayé de sortir ma messagerie de Microsoft 365 vers Stalwart, et j’avais renoncé. Le blocage n’était pas technique. Il était du côté de l’utilisateur.

Dans Outlook, une règle de tri se fait en trois clics, et le gestionnaire d’absence tient dans une fenêtre. Dans Stalwart, les règles passent par Sieve : un protocole normalisé, solide, propre, mais qui s’écrit comme du code. Un utilisateur non geek n’est pas en mesure de faire ça, et ce n’est pas une question de bonne volonté : c’est un langage qui ne s’apprend pas en passant. Côté absence, il n’y avait même pas d’interface, il fallait aller configurer le serveur à la main.

Autrement dit, l’infrastructure était prête, mais elle n’était pas utilisable par ceux à qui elle était destinée. Et je n’allais pas reprendre le rôle du service informatique qui écrit les filtres de chacun à la main, à chaque demande.

Ce qui a changé depuis, c’est l’IA agentique. On décrit la règle qu’on veut en français, l’agent écrit le Sieve, on relit, on corrige si besoin. Et le gestionnaire d’absence est désormais disponible officiellement dans Bulwark. Les deux freins ont disparu, sans changer ni de serveur ni de protocole : c’est le même Stalwart, simplement devenu accessible.

Qu’est-ce que j’ai mis à la place ?

Chaque brique Microsoft a trouvé son équivalent open source, hébergé sur mes clusters Kubernetes.

• Stalwart remplace Exchange. Un seul serveur pour le mail et la collaboration : SMTP, IMAP et POP3, JMAP pour les clients récents, CalDAV et CardDAV pour les calendriers et les contacts, ManageSieve pour les règles. Écrit en Rust, il tourne chez moi dans un simple pod Kubernetes. L’antispam est intégré, sans démon à côté : classifieur statistique, listes de blocage, réputation de l’expéditeur, et un classificateur IA dont le modèle tourne sur mon Mac mini.
• Bulwark remplace Outlook sur le web. Un client JMAP complet, et pas seulement une boîte de réception : messagerie, agenda, contacts et fichiers dans une seule fenêtre, conversations groupées, filtres Sieve, gestionnaire d’absence, boîtes partagées, interface en français. Il ne stocke pas les mails de son côté : tout est lu et écrit en JMAP sur Stalwart, seuls ses réglages restent chez lui. C’est un projet indépendant, sous AGPL.
• OpenCloud remplace SharePoint et OneDrive, avec des espaces projet, un client de bureau qui garde une copie locale des fichiers, et l’authentification gérée par Keycloak.
• PowerDNS héberge les zones DNS. Stalwart s’y connecte par API et publie lui-même ses enregistrements : MX, SPF, clés DKIM, SRV, autoconfig, TLS-RPT, et le DMARC quand je l’autorise. C’est coché domaine par domaine, et c’est volontaire : un DMARC en rejet mal placé coupe une messagerie légitime du jour au lendemain.

Sur le choix d’OpenCloud : j’avais d’abord essayé Nextcloud, que j’ai trouvé lourd à maintenir et pas franchement performant sur le gestionnaire de fichiers. OpenCloud a moins de fonctionnalités, mais il se concentre sur l’essentiel : un drive personnel qui fait le OneDrive, et des espaces projet avec droits et permissions qui font le site d’équipe SharePoint. Le reste, je n’en ai pas l’usage, et dans la plupart des entreprises que je vois, SharePoint sert de toute façon surtout de serveur de fichiers.

Côté poste de travail, OpenCloud Desktop synchronise dans le Finder ou l’Explorateur les dossiers qu’on choisit : les fichiers existent aussi en local, et on continue de travailler avec ses outils habituels.

Tout repose sur des protocoles standards : un iPhone, un Mac ou un Thunderbird se configurent sans application propriétaire.

La sécurité, côté compte

Chaque compte a un mot de passe, et l’on peut y ajouter un second facteur (TOTP, avec une application d’authentification sur le téléphone). C’est le MFA, et c’est Stalwart qui le vérifie. Pour les clients qui ne savent pas faire de MFA (un iPhone, un Thunderbird, une imprimante qui scanne vers le mail, un script de sauvegarde), je génère un mot de passe d’application, un par usage, révocable seul sans toucher aux autres. La limite par compte est passée de cinq à dix, on en a vite besoin dès qu’un utilisateur a un téléphone, un portable et deux ou trois outils. Même logique côté fichiers : OpenCloud s’appuie sur Keycloak pour la double authentification, et sur des jetons d’application pour les scripts qui déposent des documents.

Un mot sur JMAP, puisqu’il revient tout le temps

JMAP (pour « JSON Meta Application Protocol ») est la norme qui relie tout ça. Il est pensé pour remplacer, côté client moderne, IMAP et la soumission SMTP : le client demande en une seule requête tout ce dont il a besoin, le serveur lui pousse les changements au fur et à mesure, et il n’y a plus besoin d’interroger la boîte toutes les cinq minutes pour savoir si du courrier est arrivé. C’est ce qui rend une boîte de 78 000 messages utilisable dans un navigateur ou sur un téléphone.

C’est un standard de l’IETF (RFC 8620 pour le socle, 8621 pour le mail), poussé à l’origine par Fastmail, et implémenté par plusieurs serveurs. C’est l’inverse d’EWS ou de MAPI, les protocoles propriétaires de Microsoft, qui n’existaient que pour faire dialoguer Outlook avec Exchange. Et IMAP n’a pas disparu : Stalwart continue de le parler, c’est même ce qui permet à un iPhone ou à Thunderbird de se connecter sans rien installer.

La méthode

Pour une migration de messagerie, je me suis imposé la même règle à chaque étape : inventorier, simuler, sauvegarder, et seulement ensuite basculer.

1. Inventaire : avant de toucher à quoi que ce soit, un script PowerShell relevait l’état du tenant en lecture seule (domaines, boîtes, volumes, règles, connecteurs, DKIM). C’est d’ailleurs là que le périmètre s’est clarifié.
2. Simulation : par défaut, chaque script de modification tourne à blanc. Il faut une option explicite pour qu’il agisse.
3. Sauvegarde : zone DNS, réglages Stalwart, objets Microsoft… chaque état « avant » est sauvegardé, avec le retour arrière noté.
4. Copie en plusieurs passes : imapsync copie les mails pendant que la boîte Microsoft reste active, puis rattrape les nouveautés toutes les six heures. Le jour J, il ne reste presque plus rien à copier.
5. Bascule : le MX change dans le DNS, et je vérifie tout de suite la réponse sur des résolveurs publics.

Pour le client, j’ai ajouté une contrainte : on ne touche pas la source. Aucune boîte, aucun compte, aucune adresse n’a été modifié côté Microsoft pendant la migration. En cas de souci, il suffisait de remettre l’ancien MX.

Comment ça s’est passé ?

Ma boîte d’abord, en une journée

Un point à connaître avant de couper le domaine : une archive en ligne n’est pas accessible en IMAP. La rétention de Microsoft y déplace ce qui dépasse deux ans, et imapsync ne la voit pas : 26 Go sur 35 chez moi. La méthode tient en deux étapes, export PST depuis Purview (eDiscovery, un fichier par boîte), puis réimport en JMAP dans Stalwart.

La copie prend une heure pour environ 23 000 messages, soit 5 Go, sans erreur. Le MX bascule dans la soirée, puis suivent quelques centaines de contacts et près de 200 rendez-vous de calendrier.

J’ai ensuite rangé ma boîte dans Bulwark : près de 20 000 mails en dix étiquettes de couleur, et un filtre Sieve qui continue d’étiqueter chaque mail à son arrivée. À retenir : les noms et les couleurs des étiquettes vivent dans Bulwark, les mails ne portent qu’un mot-clé JMAP. Depuis, tout arrive en Réception et ne rejoint son dossier qu’au bout de trente jours, étiquettes tout de suite, dossiers plus tard : on ne rate plus un mail d’une catégorie qu’on consulte peu.

Le client ensuite, en une semaine

Le client, une marque de création, c’est quatre utilisateurs et cinq boîtes partagées, soit environ 80 Go de mails, dont deux boîtes qui dépassent 60 000 messages chacune. Et le site SharePoint pèse plus d’un demi-téraoctet, près de 58 000 fichiers, surtout des photos, des vidéos.

Je lance alors trois chantiers en parallèle : rclone copie SharePoint vers OpenCloud, bridé à 5 Mo/s, pour une trentaine d’heures ; je recrée la zone DNS du client dans PowerDNS et je change la délégation chez le registrar ; et une copie imapsync démarre pour chaque boîte. Les boîtes partagées deviennent des comptes de groupe dans Stalwart.

Deux jours plus tard, la copie se termine sans une seule différence. Entre-temps, le MX a basculé et le DMARC du domaine est passé en rejet.

Les sites d’équipe, un sujet à part

J’ai créé un espace projet OpenCloud par site d’équipe, avec un quota calculé sur le volume inventorié et une correspondance de droits volontairement simple : propriétaires du site → gestionnaires de l’espace, membres → éditeurs, visiteurs → lecteurs. Chaque personne a deux comptes, un dans OpenCloud et un dans Keycloak, avec le même identifiant ; et ce sont les propriétaires du site qui accordent les accès ensuite, pas moi.

La copie s’est faite avec rclone dans un pod, en WebDAV vers OpenCloud, bridée à 5 Mo/s, avec un rclone check fichier par fichier avant d’annoncer quoi que ce soit aux utilisateurs. Ce qui ne suit pas, et qu’il faut dire dès le départ : l’historique des versions, les colonnes de métadonnées, les liens de partage et les blocs-notes OneNote. Les fichiers, oui ; les conventions SharePoint qui vont avec, non.

Il n’y a pas de synchronisation permanente entre SharePoint et OpenCloud. J’ai fait la copie, puis demandé aux utilisateurs de déposer les nouveaux documents directement sur OpenCloud, dans le navigateur ou depuis le dossier synchronisé, et le site SharePoint est passé en lecture seule. Une seule source vivante vaut mieux que deux : on sait toujours quel fichier fait foi.

Le ménage, une semaine plus tard

Plus aucun mail n’arrivait chez Microsoft. Les domaines sont sortis du tenant, 27 comptes ont été supprimés et les copies arrêtées. Il ne reste que le compte administrateur, sur un seul domaine.

Trois semaines plus tard, Stalwart passe en 1.0

Ce n’était pas prévu dans le calendrier, mais c’est une bonne mesure de ce que vaut le choix des protocoles. Le serveur est passé de la 0.16.27 à la 1.0.1 : 18 comptes, quatre domaines, l’outil de migration fourni avec la 1.0 et un retour arrière prévu. Un seul ordre à respecter : d’abord Bulwark 1.18, la première version qui parle à Stalwart 1.0, ensuite le serveur. C’est le seul endroit où les deux projets doivent avancer ensemble. Aucun client de messagerie à reconfigurer, aucun utilisateur à prévenir, aucune donnée à recopier. C’est exactement ce que je cherchais en quittant Microsoft.

Un outil de migration officiel : Vandelay

Stalwart Labs publie aussi Vandelay, son outil de migration officiel. Il importe une boîte depuis JMAP, IMAP, CalDAV, CardDAV, WebDAV, ManageSieve, Maildir, un export Google Takeout, un Exchange on-premise (EWS) ou un Microsoft 365 (Graph) dans une archive SQLite, puis pousse cette archive vers Stalwart en JMAP. Mails, calendriers, contacts et règles Sieve dans le même passage, avec reprise après interruption, dédoublonnage et mode simulation. Ce que j’ai dû assembler avec imapsync et des scripts Graph tient désormais en deux commandes, import et export. L’archive sert d’ailleurs aussi de sauvegarde par compte. Pour la prochaine migration, je partirai de là.

Et l’IA agentique dans tout ça ?

L’IA a exécuté et vérifié, et c’est moi qui ai décidé : ce partage m’a permis de mener la migration en trois semaines, à côté de mon activité habituelle.

Elle s’est occupée des inventaires, de l’analyse d’une boucle de routage entre Microsoft et Stalwart (jusque dans le code source de Stalwart), de l’écriture des scripts PowerShell, Python et des manifestes Kubernetes, du lancement et du suivi des copies, et des contrôles après chaque étape. Elle rédige aussi chaque nuit une page de journal de bord dans OpenCloud.

De mon côté, j’ai gardé les choix d’architecture, les mots de passe, les consentements Microsoft, le changement de délégation DNS et les suppressions de comptes. Chaque bascule a attendu mon « go ». Et quand une action était trop sensible, les garde-fous de l’agent la bloquaient : il préparait alors un script, et c’est moi qui le lançais.

Sur la cohabitation de Microsoft et de Stalwart sur le même domaine, elle m’a proposé deux méthodes que j’ai refusées, au profit d’une bascule complète, plus simple.

Je n’ai pas tout fait faire au même modèle : Claude et DeepSeek ont tourné en parallèle, chacun sur ce qu’il faisait le mieux. Le point commun, c’est la méthode, pas le fournisseur. C’est aussi ce qui rend l’approche reproductible : on peut changer de modèle sans changer de procédure.

Pendant que les copies tournaient pendant des heures, je continuais à travailler en parallèle. Et comme les décisions prises et les points à surveiller ont été notés au fur et à mesure, puis transformés en procédure réutilisable, celle du client est partie de cette base huit jours plus tard.

Alors, ça vaut le coup ?

Trois semaines, deux migrations, aucune perte : mes données et celles de mon client sont sur des serveurs que j’exploite. Les utilisateurs du client ont suivi sans formation, avec leur iPhone, leur Mac et leur navigateur. Un utilisateur règle sa boîte sans appeler quelqu’un : c’est exactement ce que l’IA agentique a débloqué.

Côté confort, Bulwark s’installe en PWA sur le Mac comme sur le téléphone, avec les notifications du système. Il manque encore un client natif JMAP : Apple Mail et Thunderbird font le travail en IMAP, et Flectar Mail, écrit en Rust sous AGPL, est encore en développement.

Si ça vous inspire, je peux vous accompagner pour faire cette démarche.

Les chiffres

La boîte à outils

• imapsync pour les mails, un pod Kubernetes par boîte ; depuis, Vandelay couvre aussi les calendriers, les contacts et les règles
• Microsoft Graph et des scripts Python pour les calendriers et les contacts, importés en CalDAV et CardDAV
• rclone pour SharePoint et OneDrive, dans plusieurs pods Kubernetes
• PowerShell (Exchange Online, Graph) pour l’inventaire et le ménage du tenant
• PowerDNS pour les zones, Stalwart, Bulwark et OpenCloud pour les services
• Claude et DeepSeek avec OpenCode via LiteLLM en backend

Références

• Stalwart, avec la liste des protocoles, de l’antispam et de Sieve : https://stalw.art
• Vandelay, l’outil de migration de Stalwart Labs : https://github.com/stalwartlabs/vandelay
• Bulwark, le webmail JMAP : https://bulwarkmail.org
• OpenCloud : https://opencloud.eu
• imapsync : https://imapsync.lamiral.info
• Flectar Mail, le client natif en Rust qui parle JMAP : https://flectar.com/mail