Définir la frontière de synchronisation
Une petite équipe dispose d’une attention limitée. Le temps consacré à coordonner les échanges réseau manque pour expliquer un import échoué ou rendre les messages lisibles. JMAP propose une frontière plus cohérente entre le modèle local du client et le service qui héberge la boîte. Son intérêt est architectural, sans promettre de rendre le courrier électronique facile.
La base est RFC 8620, publié en 2019. RFC 8621, également publié en 2019, définit JMAP pour le courrier : messages, boîtes, fils et soumission. C’est un standard ouvert avec un modèle de données défini, plutôt qu’une API propriétaire à reconstituer.
Décrire le travail plutôt qu’orchestrer les requêtes
JMAP échange du JSON via HTTPS. Une requête peut contenir plusieurs appels de méthodes, et un appel ultérieur peut référencer le résultat d’un précédent. Une vue de boîte peut donc décrire ensemble sa recherche et les données à récupérer pour les identifiants obtenus, dans les limites annoncées par le serveur. Réduire les échanges dépendants peut aider sur un réseau à forte latence ; les résultats dépendent du travail et de l’implémentation.
Les dépendances deviennent explicites : quelles propriétés faut-il à l’écran, quel résultat nourrit l’opération suivante ? Pagination, gestion des erreurs et limites restent nécessaires. Grouper les appels organise les requêtes ; cela ne justifie pas de télécharger tout le compte à chaque ouverture de fenêtre.
Traiter l’état comme un point de reprise durable
Les jetons d’état permettent de demander ce qui a changé depuis un point connu. Les méthodes /changes signalent les identifiants créés, modifiés et détruits ; le client récupère les données nécessaires et met à jour son stockage. Les notifications push signalent un changement d’état pour déclencher la synchronisation, sans remplacer celle-ci.
Un point de reprise n’est utile que s’il correspond à des données durablement enregistrées. Il faut prévoir un arrêt entre réception et sauvegarde. Le serveur peut aussi répondre cannotCalculateChanges s’il ne conserve plus l’historique demandé ; une resynchronisation plus complète s’impose alors. La reprise après une longue absence fait partie du fonctionnement normal.
Garder visibles les responsabilités restantes
JMAP ne remplace pas SMTP entre serveurs. La soumission depuis le client et l’acheminement sur le réseau restent des tâches distinctes. Le protocole n’élimine pas automatiquement le spam, ne garantit pas la confidentialité de bout en bout et ne crée pas un mode hors ligne. Celui-ci nécessite stockage local, règles pour les actions en attente et gestion des conflits.
La prise en charge n’est pas universelle. Il faut découvrir les capacités, choisir les fournisseurs pris en charge et conserver les chemins de compatibilité nécessaires. Les performances dépendent du serveur, du client et du travail demandé. IMAP moderne dispose lui aussi de fonctions de synchronisation.
Pour un studio, il faut choisir un contrat qui rend la reprise compréhensible. Pourquoi construire une app mail reste difficile : cinquante ans de compatibilité expose les contraintes héritées ; Comment JMAP modernise le courrier électronique présente le point de vue utilisateur. Une communication plus claire laisse de la place à une meilleure application, que l’équipe doit encore construire.