Construire Inboxer pour Gmail et pour Outlook a pris plus de temps que la version mono-fournisseur que nous avons livrée en premier. Pas parce qu'Outlook est moins bon - Microsoft Graph est une API tout à fait respectable - mais parce que les deux plateformes exposent des modèles mentaux fondamentalement différents. Quiconque évalue un assistant email IA en 2026 devrait savoir où ces différences se répercutent dans le produit, parce qu'elles affectent ce que votre IA peut faire ou non.

Labels contre catégories contre dossiers

La brique organisationnelle de Gmail, c'est le label : une chaîne de caractères attachée à un fil. Un même fil peut porter plusieurs labels. Retirer un label ne déplace le fil nulle part - ça retire simplement l'étiquette. L'archivage, c'est l'absence du label INBOX.

La brique d'Outlook, c'est le dossier : un fil vit dans exactement un dossier à la fois. L'archivage, c'est déplacer le fil vers le dossier Archive. Séparément, Outlook a aussi des Catégories, des étiquettes colorées qui se comportent davantage comme les labels Gmail - mais la plupart des utilisateurs ignorent qu'elles existent, et les vues filtrées fonctionnent différemment.

Pour la classification IA, ça compte : un outil construit sur les labels Gmail peut appliquer "1 - À répondre" comme label sans perturber la structure de dossiers de l'utilisateur. Le même outil sur Outlook doit choisir : utiliser les Catégories (que l'utilisateur doit découvrir) ou les Dossiers (qui sortent le fil de la vue) ? Nous avons opté pour les Catégories, avec exactement les mêmes noms que nos labels Gmail, pour que l'expérience utilisateur reste identique d'un fournisseur à l'autre.

Threading et regroupement des conversations

Gmail regroupe les messages en fils de façon agressive - parfois trop. Cinq emails avec le même objet venant de personnes différentes finissent dans un seul fil, même s'ils n'ont aucun rapport entre eux. Le regroupement des conversations d'Outlook est plus strict (il respecte plus fidèlement l'en-tête In-Reply-To), mais l'utilisateur peut le désactiver. Quand c'est désactivé, chaque message apparaît comme sa propre ligne.

L'implication pour l'IA : la précision de la classification dépend de l'accès au contexte complet du fil. Une réponse à "On confirme mardi 15h ?" ne veut rien dire sans le message d'origine. Le threading agressif de Gmail aide le modèle. Outlook avec la vue conversation désactivée oblige l'IA à reconstruire les fils à partir des en-têtes, ce qui est possible mais ajoute de la latence.

Snooze, report, relance

Gmail a une action native de report (Snooze) : retirer un message de la boîte jusqu'à X. Le modèle peut détecter un label SNOOZED et ignorer le fil jusqu'à son retour.

Outlook n'a pas d'équivalent. Ce qui s'en rapproche le plus est le marqueur "Assurer un suivi" avec une date de début et une date d'échéance. Nous utilisons flag.flagStatus === "flagged" avec une date future comme équivalent du report, et sautons la classification sur les fils marqués. Ça fonctionne pour le cas courant, mais ne couvre pas les utilisateurs qui utilisent la vraie action de menu "Reporter" d'Outlook - qui déplace le message vers un état caché que l'API Graph v1.0 n'expose pas proprement.

Webhooks et notifications push

Les notifications push de Gmail passent par Google Pub/Sub. Vous enregistrez une surveillance (watch), Gmail pousse vers votre sujet, votre service consomme. Les surveillances expirent au bout de 7 jours et doivent être renouvelées.

Microsoft Graph utilise un modèle d'abonnement : vous faites un POST sur /subscriptions avec un chemin de ressource et une URL de notification, Microsoft appelle votre URL. Les abonnements expirent au bout d'environ 3 jours pour le mail. La logique de renouvellement est symétrique.

Le coût caché côté Microsoft : les webhooks sont livrés via Svix, qui utilise un format de signature spécifique (svix-id.svix-timestamp.body, HMAC-SHA256 avec le secret décodé en base64, fenêtre de rejeu de ±5 minutes). Si vous implémentez la vérification des webhooks en supposant un signing façon Stripe ou façon Gmail, chaque webhook est rejeté avec un 401 et vous passez une session de débogage entière à comprendre pourquoi. (On sait de quoi on parle.)

Création et envoi de brouillons

Les deux fournisseurs exposent la création et l'envoi de brouillons. Les brouillons de Gmail ont leur propre ressource (/drafts) et nécessitent messages.modify pour les mises à jour de label, parce que threads.modify ne se propage pas aux brouillons. Les brouillons de Microsoft SONT des messages - ils vivent dans le dossier /Drafts et sont modifiables par PATCH comme n'importe quel message.

Net pour l'IA : rédiger une réponse est équivalent côté API entre les deux fournisseurs. Le code d'Inboxer abstrait les deux derrière une seule interface EmailConnector.createDraft() ; le consommateur n'a pas besoin de savoir quel fournisseur se trouve dessous.

Données du profil de style : les éléments envoyés

Pour apprendre comment un utilisateur écrit, l'IA a besoin d'accéder à son historique d'envoi. Les deux fournisseurs l'exposent :

Gmail : users.messages.list?q=in:sent
Microsoft Graph : /me/mailFolders/SentItems/messages

Même taille de payload, même parsing. La construction du profil de style tourne à l'identique sur les deux. Si vous connectez Inboxer à un Gmail et à l'Outlook de la même personne, vous obtiendriez le même profil de style.

Le problème de la déduplication des labels

En voici un particulier. Le réglage "Vue conversation" de Gmail change la façon dont les labels s'affichent dans les vues filtrées. Quand il est DÉSACTIVÉ (un choix d'environ 30 % des power users), filtrer par label affiche une ligne par message plutôt qu'une par conversation. Donc si un fil a 5 messages tous labellisés "5 - FYI", l'utilisateur voit la même conversation 5 fois. Inboxer déploie une tâche cron quotidienne qui retire les labels en double pour ne garder que le dernier message de chaque fil, spécifiquement pour corriger ça.

Le filtre par catégorie d'Outlook n'a pas ce comportement. Un fil = une ligne, toujours. La tâche de déduplication est donc spécifique à Gmail. Bon à savoir si vous migrez un jour.

Faut-il choisir sa messagerie en fonction du support IA ?

Honnêtement, non. Gmail et Outlook peuvent tous les deux héberger le même assistant IA en 2026 avec des fonctionnalités effectivement identiques, parce que les différences propres à chaque fournisseur sont abstraites par des outils comme Inboxer. Choisissez le client mail que vous préférez réellement utiliser. La couche IA se pose dessus dans les deux cas.

La seule exception : si vous êtes sur un tenant Microsoft 365 d'entreprise où l'IT a désactivé les abonnements Graph tiers, vous n'aurez pas de notifications push en temps réel et basculerez sur du polling. Ça rend l'IA environ 30 secondes plus lente par email entrant. C'est une vraie différence, mais rarement rédhibitoire.