Gmail vs Outlook : ce que MailBoss fait pareil, ce qui change

Quand on a commencé MailBoss, on pensait naïvement : « l'email c'est l'email, une fois qu'on a fait Gmail on fera Outlook en deux semaines ». Six mois plus tard, on a livré le connecteur Outlook. Il y a des choses très différentes entre ces deux mondes, et d'autres étonnamment similaires. Cet article te dit lesquelles, pour que tu ne sois pas surpris en arrivant sur MailBoss depuis l'un ou l'autre.

Ce qui est strictement identique

Côté utilisateur final, 95 % de l'expérience est la même. Tu connectes ta boîte en OAuth (pas de mot de passe à partager), tu choisis tes 9 catégories, tu valides les brouillons, tu reçois ton digest du soir. Le moteur IA est rigoureusement le même code, indépendant du provider.

Identique, premier jour :

• Écran de connexion OAuth, ergonomie du consentement.
• Les 9 catégories natives (urgent, client, fournisseur, newsletter, notification, RH, juridique, interne, spam) — on ne change rien.
• Le système de labels. Sur Gmail on utilise les labelsnatifs ; sur Outlook on utilise les catégories. Nom différent, comportement visible identique.
• Le digest du soir, la newsletter du dimanche, les règles d'auto-réponse : tout est géré côté MailBoss, pas côté provider.

Ce qui change en back-office

Côté technique, c'est deux mondes. Voici les cinq différences qui nous ont coûté du temps et qu'on partage ici.

1. Le push vs le pull

Gmail propose Google Pub/Sub : tu t'abonnes à un topic, et Google te pousse un événement léger (« il y a du neuf dans la boîte X@y.com »). Tu fais alors un history.list pour récupérer uniquement les deltas. C'est élégant, c'est rapide, c'est relativement peu coûteux.

Outlook propose Microsoft Graph change notifications. Sur le principe c'est pareil, mais la souscription expire toutes les 70 heures maximum. Il faut donc un cron qui renouvelle. Si tu le rates, tu manques des événements. Le SLA de Graph est moins bon que celui de Pub/Sub dans notre monitoring : on a mesuré 99,6 % côté Microsoft vs 99,95 % côté Google sur 90 jours.

2. Le threading

Gmail a inventé le threading moderne (2004) et garde une rigueur de fer : un thread = un threadId stable, visible dans l'API. Outlook utilise des conversationId qui, dans la pratique, se fragmentent parfois quand un utilisateur transfère le thread à un autre Outlook puis revient. On a vu 3 à 4 % des threads Outlook se couper en deux de manière inexplicable. On a dû écrire une logique de re-threading côté MailBoss.

3. Le quota d'API

• Gmail : 1 milliard d'unités/jour par projet, coût réel de nos opérations : 5-15 unités/mail traité. On tient des utilisateurs actifs à foison sur un seul projet GCP.
• Microsoft Graph : limites par app + par tenant beaucoup plus sévères. Il faut mettre en place un app-based throttling avec backoff exponentiel pour ne pas se faire couper pendant une heure.

4. Les labels et catégories

Les labels Gmail sont illimités, case-sensitive, et se créent à la volée. Les catégories Outlook sont limitées à 25 couleurs, stockées au niveau du compte, et l'API expose un objet séparé (un masterCategory) qui doit exister avant d'être appliqué à un message. On a dû écrire un sync bidirectionnel :

1. Créer les 9 catégories MailBoss dans le compte Outlook au premier login.
2. Vérifier qu'elles existent avant chaque application.
3. Les recréer si un utilisateur les supprime manuellement.

5. La recherche

Gmail propose une search API puissante ( q=from:xyz has:attachment newer_than:7d). Graph propose une search API moins expressive et beaucoup plus lente. Pour la recherche sémantique dans l'app MailBoss, on construit notre propre index vectoriel côté MailBoss — ce qui règle le problème des deux côtés.

Choix de design qu'on a assumés

Face à ces différences, on a fait trois choix explicites qu'on tient à documenter.

1. Ne pas exposer les différences à l'utilisateur. Qu'il soit sur Gmail ou Outlook, il voit la même interface, les mêmes boutons, les mêmes compteurs. Les bizarreries de Graph restent dans notre backend.
2. Avoir un provider abstrait côté code. Notre worker classeur reçoit un objet NormalizedMessage. Il ne sait pas d'où ça vient. Les adaptateurs Gmail/Outlook font le boulot de normalisation avant.
3. Refuser les features provider-specific. Gmail propose les smart compose, Outlook propose les focused inbox. On pourrait s'y appuyer, on ne le fait pas : c'est asymétrique, donc ça crée des utilisateurs de première et de seconde classe. MailBoss fait tout côté nous, identiquement.

Ce qui reste à faire côté Outlook

À la date de publication, on a deux limitations documentées côté Outlook :

• La signature riche (HTML complexe) n'est pas encore préservée à 100 % dans les brouillons générés. Les signatures simples passent bien.
• Les comptes Exchange on-premise (sans Microsoft 365) ne sont pas supportés. On ne prévoit pas de les supporter : c'est 2 % du marché et l'auth est radicalement différente.

Tu veux essayer ?

Que tu sois sur Gmail ou Outlook, la connexion prend 90 secondes et tu commences à voir des résultats le soir même. Les 14 jours d'essai, c'est pour toi l'occasion de valider que l'expérience est équivalente sur ton vrai flux — on se donne ce rendez-vous ici.