Mes mails, mon serveur... et Microsoft au milieu

Je travaillais tranquillement sur l'amélioration des mécanismes d'autoconfiguration des boîtes mail hébergées sur mes serveurs : Outlook, Thunderbird, Apple... l'occasion de vérifier que tout ce petit monde retrouvait correctement ses paramètres.

Par curiosité, j'ai voulu voir comment se comportait le client désormais proposé avec Windows 11 : New Outlook.

Je pensais faire un test de cinq minutes.

Il aura surtout ravivé quelques réflexions sur nos données, les choix que l'on fait à notre place et ce que signifie encore utiliser un service « indépendant » en 2026.

Première surprise : Microsoft veut se mettre au milieu

J'ajoute donc une adresse hébergée sur mon propre serveur.

New Outlook détecte qu'il s'agit d'un compte IMAP et m'affiche ceci :

Pour ajouter votre compte IMAP à Outlook, vous devez synchroniser vos e-mails avec Microsoft Cloud.

Pardon ?

IMAP est un protocole standard permettant à un client mail d'accéder aux messages stockés sur un serveur. Il n'a absolument pas besoin du cloud de Microsoft pour fonctionner.

Mon Outlook classique le fait depuis des années.

Thunderbird le fait.

Un téléphone le fait.

À peu près n'importe quel client IMAP normalement constitué peut le faire.

Le modèle traditionnel est plutôt simple :

Avec New Outlook, Microsoft introduit un nouvel acteur dans cette relation :

Microsoft a ses raisons pour avoir conçu New Outlook de cette manière. La synchronisation dans son cloud lui permet notamment d'offrir aux comptes tiers certaines fonctionnalités intégrées à l'écosystème Outlook.

Je peux comprendre cette logique.

Ce qui me dérange beaucoup plus, c'est la manière dont elle est présentée.

L'écran dit :

Vous devez synchroniser vos e-mails avec Microsoft Cloud.

Vous devez.

Pour quelqu'un qui veut simplement consulter ses mails, le message semble assez clair : c'est une obligation.

Pourtant, cet écran n’explique pratiquement rien.

Pourquoi cette synchronisation est-elle nécessaire à New Outlook ?

Quelles fonctionnalités en dépendent ?

Quelles données seront synchronisées ?

Qu'est-ce que cela implique ?

Et quelles sont mes alternatives si je ne le souhaite pas ?

Ce sont pourtant des informations qui me semblent essentielles avant de demander à quelqu'un de faire entrer un nouvel acteur dans le traitement de sa messagerie.

Microsoft indique qu’une copie des données de la boîte est synchronisée entre le fournisseur de messagerie et ses propres centres de données.¹

Et je suis manifestement loin d'être le premier à me poser ce genre de questions. La manière dont New Outlook traite les comptes IMAP tiers intrigue et fait débat depuis son arrivée, notamment chez des administrateurs et des utilisateurs qui ont précisément choisi d'héberger leur messagerie en dehors de l'écosystème Microsoft.

Les interrogations reviennent régulièrement : quelles données transitent réellement par Microsoft Cloud, comment sont gérés les moyens d’accès au serveur d’origine et pourquoi ne peut-on pas simplement conserver une connexion IMAP directe ?

Je n’ai pas l’intention de refaire ici plusieurs années de débats autour de New Outlook. Mais si même des utilisateurs avertis s’interrogent sur les implications de cette architecture, comment considérer qu’un simple « Vous devez synchroniser vos e-mails avec Microsoft Cloud » constitue une explication suffisante pour le grand public ?

J'aurais beaucoup moins de choses à redire à un écran disant quelque chose comme :

Certaines fonctionnalités de New Outlook nécessitent la synchronisation de votre boîte avec Microsoft Cloud.

Voici pourquoi, voici ce que cela implique et voici vos alternatives.

Là, nous aurions un choix éclairé.

Le problème n'est donc pas que Microsoft propose son cloud.

Le problème est qu'une décision qui peut avoir des implications sur le traitement de nos données est présentée comme une simple étape nécessaire à la configuration d'une boîte mail, sans réellement expliquer pourquoi ni ce que nous sommes en train d'accepter.

Deuxième surprise : Outlook connaît mon login mieux que moi

Je continue tout de même le test.

Et je tombe sur quelque chose d'encore plus étonnant.

Sur mes serveurs, une adresse e-mail n'est pas nécessairement l'identifiant utilisé pour s'authentifier.

C'est volontaire.

Une adresse comme :

john.doe@example.com

peut très bien utiliser un identifiant tel que :

jdoe42

Ce sont deux informations différentes. Leur distinction ajoute une modeste couche de protection supplémentaire.

Une adresse e-mail est, par nature, une information que l'on diffuse. Elle se retrouve dans des carnets d'adresses, sur des sites web, dans des bases de données et malheureusement parfois dans des fuites.

Si cette adresse est automatiquement l'identifiant du compte, quelqu'un qui la connaît possède déjà une des informations nécessaires pour tenter de s'authentifier.

Chez moi, ce n'est volontairement pas toujours le cas.

Ce n'est évidemment pas une alternative à un mot de passe solide, à la limitation des tentatives ou aux autres mécanismes de sécurité.

C'est simplement une information supplémentaire que je ne vois aucune raison d'offrir gratuitement à un attaquant.

New Outlook, lui, a une autre opinion.

Dans sa configuration IMAP avancée, je peux choisir le serveur.

Je peux choisir le port.

Je peux choisir le type de chiffrement.

Je peux entrer mon mot de passe.

Mais je ne peux pas choisir mon nom d’utilisateur.³

New Outlook a décidé que mon adresse e-mail était mon identifiant IMAP.

Et si mon serveur n'est pas d'accord ?

Tant pis pour mon serveur.

Et puis arrive le SMTP...

C'est ici que l'histoire devient franchement comique.

Quelques lignes plus bas, New Outlook me demande les paramètres du serveur chargé d'envoyer mes messages.

Et que trouve-t-on dans cette partie ?

Nom d'utilisateur SMTP.

Un champ parfaitement modifiable.

Donc New Outlook comprend parfaitement ceci :

adresse e-mail ≠ identifiant SMTP

mais son interface ne me permet pas de faire ceci :

adresse e-mail ≠ identifiant IMAP

Je cherche encore la logique.

Ce n'est en tout cas pas une limitation intrinsèque des protocoles utilisés.

Et surtout, l'ancien Outlook savait parfaitement gérer ce type de configuration.

Nous avons donc perdu, avec son successeur, une possibilité parfaitement valide qui existait auparavant.

Ce n'est malheureusement pas qu'un test de geek

Le plus embêtant est que je connaissais déjà cette limitation.

Je l'avais rencontrée chez une cliente.

À la suite d'une évolution de son environnement Windows, le client mail qu'elle utilisait jusque-là était devenu inutilisable. La solution qui se présentait naturellement à elle était New Outlook.

Sa boîte mail fonctionnait.

Le serveur fonctionnait.

Ses identifiants fonctionnaient.

Mais son adresse e-mail et son identifiant IMAP étaient différents.

Et New Outlook ne permettait tout simplement pas de renseigner cet identifiant.

Elle a finalement dû migrer vers un autre client mail.

Ce qui, rétrospectivement, n'était peut-être pas une mauvaise chose.

Mais cette expérience illustre surtout le problème qui me dérange ici.

Moi, lorsque New Outlook me parle de synchronisation avec Microsoft Cloud, je comprends immédiatement qu'il se passe quelque chose d'un peu différent d'une simple connexion à mon serveur.

Je sais ce qu'est IMAP.

Je sais ce qu'est SMTP.

Je sais qu'un intermédiaire cloud n'est pas intrinsèquement nécessaire à leur fonctionnement.

Je sais également qu'il existe d'autres clients mail.

L’utilisateur ordinaire, lui, veut simplement lire ses mails.

Il achète un ordinateur Windows.

Il ouvre le logiciel de messagerie qui lui est proposé.

Il saisit son adresse.

Le logiciel lui explique qu'il doit synchroniser ses e-mails avec Microsoft Cloud.

Il clique sur Continuer.

Combien d'utilisateurs disposent réellement des connaissances nécessaires pour comprendre le choix technique qu'ils viennent d'accepter ?

Et peut-on vraiment leur reprocher de ne pas les avoir ?

Rendre la technologie invisible

Nous passons notre temps à essayer de rendre la technologie plus simple.

Et c'est une excellente chose.

Personne ne devrait avoir besoin de connaître la différence entre IMAP et SMTP, de savoir ce qu'est STARTTLS ou de mémoriser le numéro du port 993 simplement pour consulter ses mails.

L'autoconfiguration existe précisément pour cela.

On donne son adresse et son mot de passe, et le logiciel se charge du reste.

Parfait.

Mais cette simplification donne également beaucoup de pouvoir à celui qui conçoit l'interface.

L'utilisateur ne voit plus les décisions techniques.

Il ne voit plus nécessairement quels serveurs sont contactés.

Il ne sait pas forcément où transitent ses données.

Il fait confiance au logiciel pour prendre les décisions raisonnables à sa place.

Et c'est précisément pour cette raison que certaines décisions ne devraient pas devenir invisibles.

Plus une technologie devient invisible pour l'utilisateur, plus ceux qui la conçoivent ont la responsabilité de rendre visibles les choix qui comptent.

La simplification de la technique ne devrait pas entraîner la simplification du consentement.

Et la souveraineté numérique dans tout ça ?

Le sujet prend une saveur particulière à une époque où l'on parle de plus en plus de souveraineté numérique, de localisation des données et de dépendance envers quelques acteurs technologiques gigantesques.

On imagine souvent ces questions à l'échelle des États ou des grandes entreprises.

Mais elles existent également à une échelle beaucoup plus banale.

Quelqu'un peut choisir de confier ses e-mails à une petite société locale.

À son entreprise.

À une association.

À un fournisseur européen.

Ou même de les héberger lui-même.

Il peut faire ce choix précisément parce qu'il ne souhaite pas confier son courrier à Microsoft, Google ou un autre géant du Web.

Et pourtant, le simple choix du logiciel utilisé pour consulter cette boîte peut réintroduire l'un de ces acteurs dans l'équation.

C'est assez paradoxal.

Héberger soi-même son courrier électronique en 2026 est d'ailleurs presque un acte de masochisme.

Il faut gérer les serveurs, le DNS, les certificats, SPF, DKIM, DMARC, l'antispam, la réputation des adresses IP, les sauvegardes, la sécurité et quelques autres joyeusetés.

Si quelqu'un accepte volontairement tout cela plutôt que de créer gratuitement une boîte chez un géant du Web, il y a de bonnes chances que la maîtrise de son infrastructure et de ses données fasse partie de ses motivations.

Et voilà qu'un simple client mail peut décider qu'un intermédiaire supplémentaire doit malgré tout faire partie de l'histoire.

Le problème n'est toujours pas le cloud

Je n’ai rien contre le principe même d’un service cloud. Et je ne prétends pas qu’un logiciel open source serait automatiquement vertueux là où un logiciel Microsoft serait mauvais. Ce serait beaucoup trop simple.

Si Microsoft peut proposer de meilleures fonctionnalités Outlook en synchronisant une boîte tierce avec son infrastructure, très bien.

Que cette possibilité existe.

Qu'elle soit même proposée par défaut.

Mais expliquez-moi clairement ce qu'elle apporte.

Expliquez-moi ce qu'elle implique.

Et laissez-moi décider si je la veux.

La bonne interface pourrait très bien dire :

Synchroniser avec Microsoft Cloud

Permet de bénéficier de toutes les fonctionnalités de New Outlook.

et proposer également :

Utiliser directement mon serveur

Certaines fonctionnalités nécessitant Microsoft Cloud seront indisponibles.

La plupart des utilisateurs pourraient choisir la première option sans jamais avoir à connaître IMAP.

L'utilisateur qui souhaite conserver une connexion directe pourrait choisir la seconde.

Tout le monde y gagnerait.

Simplifier n'est pas décider à notre place

C'est finalement ce qui me gêne le plus dans cette expérience.

Microsoft cherche probablement à rendre la configuration du courrier électronique plus simple pour des millions de personnes.

L'intention est parfaitement compréhensible.

Mais il existe une différence fondamentale entre :

cacher une complexité inutile

et

supprimer un choix parce que la majorité des utilisateurs ne sauraient pas qu'il existe.

C'est d'autant plus difficile à accepter ici que l'ancien Outlook permettait des configurations plus traditionnelles.

La possibilité technique n'a donc pas disparu du courrier électronique.

C'est le produit qui a changé de philosophie.

Et lorsqu'un logiciel occupe une place aussi naturelle dans l'environnement informatique du grand public, je pense justement qu'il devrait être particulièrement attentif à ce genre de choix.

Pas parce que tous les utilisateurs vont vouloir les modifier.

Mais parce que la plupart ne sauront même pas qu'on les a faits pour eux.

Alors, quel client utiliser ?

Heureusement, New Outlook n'est pas la seule manière de consulter ses mails sous Windows.

Parmi les alternatives grand public, Thunderbird est probablement la plus connue : libre, open source et multiplateforme. eM Client propose de son côté une approche commerciale assez soignée et accessible. Tous deux permettent de travailler avec des comptes IMAP traditionnels et d'en conserver la maîtrise des paramètres.

Aucun n'est parfait, et il existe évidemment d'autres solutions. Le but n'est pas d'élire ici le meilleur client mail.

C'est justement tout le contraire : le but est de rappeler qu'on a le choix.

Thunderbird ne conviendra pas à tout le monde. Certaines alternatives sont commerciales. D'autres privilégient davantage l'intégration de services en ligne. Et les besoins de quelqu'un qui utilise simplement une boîte IMAP ne sont pas nécessairement ceux d'un utilisateur professionnel travaillant avec Microsoft 365 toute la journée.

Et il reste d'ailleurs un acteur assez amusant dans cette histoire : Outlook lui-même.

Pas New Outlook.

L'Outlook classique de Microsoft 365, que j'utilise toujours professionnellement.

Lui continue à me laisser configurer mes comptes de manière traditionnelle. Je peux choisir mes serveurs, utiliser un identifiant différent de mon adresse e-mail et conserver une relation directe avec mon infrastructure lorsque je le souhaite.

Autrement dit, Microsoft continue aujourd'hui à proposer à ses clients professionnels des possibilités que son nouveau client destiné au grand public a choisi de simplifier ou de faire disparaître.

Pour le moment, du moins. Microsoft annonce maintenir le support des installations existantes d’Outlook classique au moins jusqu’en 2029, sans pour autant garantir que toutes les possibilités actuelles resteront inchangées.⁴

Et cette différence pose elle aussi une question intéressante.

Pourquoi un utilisateur professionnel aurait-il besoin de conserver cette maîtrise alors qu'un particulier pourrait s'en passer ?

Peut-être simplement parce que les contraintes et les attentes ne sont pas les mêmes. Peut-être aussi parce qu'il est beaucoup plus difficile d'imposer certains changements à des entreprises qui disposent d'infrastructures existantes, de politiques de sécurité et d'administrateurs capables d'en mesurer les conséquences.

Je n'ai pas la réponse.

Mais le contraste mérite d'être relevé.

Je continuerai donc à utiliser Outlook classique professionnel tant qu'il répond à mes besoins. Et pour quelqu'un qui cherche simplement un client mail indépendant, je conseillerais de regarder Thunderbird et les autres alternatives disponibles plutôt que d'accepter automatiquement ce que Windows lui propose.

Parce que le choix de l’endroit où résident nos données et de la manière dont nous y accédons devrait rester le nôtre.

Microsoft peut parfaitement me proposer son cloud.

Il peut m'expliquer pourquoi il considère que mon expérience sera meilleure avec lui.

Il peut me prévenir que certaines fonctionnalités seront indisponibles si je décide de m'en passer.

Mais il devrait rester un mot particulièrement important dans cette conversation :

Non.

Mes mails.

Mon serveur.

Et si je le souhaite,

personne au milieu.

---

Mise à jour

2026-10-13 : révision du texte, vérification des informations techniques et ajout de références documentaires.

---

Footnotes

1. Microsoft Support, « Synchroniser votre compte dans Outlook avec le Microsoft Cloud ». Microsoft précise qu’une copie des données du compte est synchronisée avec ses centres de données. La liste des fournisseurs pris en charge dans cette page n’est toutefois pas exhaustive ou cohérente avec toutes ses autres pages consacrées à New Outlook. ↩

2. Dirk Knop, Ronald Eikenberg et Stefan Wischner, Heise/c’t, 10 novembre 2023, « Microsoft lays hands on login data: Beware of the new Outlook ». L’analyse a observé la transmission de paramètres et d’identifiants de connexion aux serveurs Microsoft à travers une connexion TLS. Elle ne documente pas leur mode de conservation interne. ↩

3. Microsoft Q&A, 22 juillet 2025, « How to setup IMAP account with separate username and email address for receiving email with new Outlook? ». Une réponse d’une modératrice confirme l’absence de champ permettant de définir un identifiant IMAP différent de l’adresse e-mail dans New Outlook. ↩

4. Microsoft Learn, « Stages of migration to new Outlook for Windows ». Microsoft prévoit le support des installations existantes d’Outlook classique, avec les licences concernées, au moins jusqu’en 2029. ↩