Futur du mail : les protocoles

Ce billet est le 1er d’une série sur le futur du mail qui prendra, selon mon opinion, la forme d’un “Personal Social CRM”.

J'ai discuté dans des billets précédents le sujet de l'évolution futur du mail. Sujet qui revient régulièrement à la une.

Qu'est-ce qui mérite de s'intéresser au sujet aujourd'hui ?

• Il devient "mass market" avec l'introduction de nouvelles fonctionnalités natives aux principaux fournisseurs de messagerie : Google avec le "Priority Inbox" et Microsoft avec "Outlook Social Connector"
• De nombreuses startups se sont  lancées dans le domaine : des nouvelles (Liaise, Raportive, OtherInbox, Dooster,...), des françaises (Kwaga, Silentale...), certaines ayant déjà de l'antériorité (Xobni, Gist,...) et certaines ayant même fermé (Etacts, Silentale), la dynamique du secteur en est intéressante à analyser. J'en ai établi une première liste sur Quora : http://www.quora.com/What-are-some-great-personal-CRM-apps.
• Le "Social CRM" est devenu un sujet clé et le "Personal Social CRM" en constitue un des aspects qui représente pour moi le futur du mail (futur convergent avec d'autres formes de communication).

Par ailleurs, un des Projets Web Innovants retenu dans l'appel à projet du Secrétariat d'Etat à l'Economie Numérique porte sur "Demain Le Mail" centré sur le mail sémantique http://blog.dlm30.com/.

Pour l'actualité, le PDG d'Atos, Thierry Breton, a annoncé son ambition de réussir à supprimer les mails d'ici trois ans en le substituant par des applications dédiées permettant une meilleure communication ainsi que les nouveaux outils de collaboration et les réseaux sociaux. Les problèmes du mail (surcharge informationnelle,…) sont bien connus et ce n'est pas la première fois que l'on annonce la mort du mail aussi il faudra voir quelles en sont les concrétisations.

Le mail n’est pas un sujet aussi simple qu’il y parait à première vue. Repartons donc à la base : qu'est-ce que le mail ?

La question n'est pas seulement rhétorique car le mail recouvre trois éléments clairement distincts :

• un protocole
• un service
• un client

Comme on me fait régulièrement la remarque de la longueur de mes billets, je ne traiterai, dans un soucis de lisibilité, dans celui-ci que le protocole (et dans les autres la suite).

Le protocole, c'est la norme de communication utilisée pour échanger des messages entre les serveurs de messagerie (POP, IMAP,…).

Le service, c'est le serveur de messagerie qui peut être d'entreprise (Exchange, Notes) ou grand public de type webmail (Hotmail, Gmail).

Le client, c'est le logiciel ou l'interface web qui est utilisée pour consulter et traiter ses mails et les éléments associés (Outlook ou Windows Live Mail sur PC , Apple Mail ou Entourage sur Mac, les interfaces webmail de Hotmail ou Gmail dans un navigateur).

 

Le protocole

La caractéristique clé du protocole de mail qui a fait son succès, c'est son universalité. Tout serveur de messagerie peut fonctionner avec tous les autres. Une adresse mail est totalement pervasive. C'est pour cela que toute inscription à n'importe quel service sur internet commence toujours par vous demander votre adresse mail (y compris Facebook - vous ne pouvez pas vous inscrire sur Facebook sans adresse mail).

SMTP (Simple Mail Transfer Protocol) est le protocole d'envoi de courrier entre serveurs partagés par toutes les messageries.

POP et IMAP sont les protocoles de relève de courrier. IMAP est le protocole de référence qui permet d'accéder à une boite mail à partir de différents clients (PC, mobile, webmail), de faire des relèves sélectives de mails ou de les déplacer dans des dossiers. Il est très puissant et a remplacé le protocole POP3 aux fonctionnalités dépassées. Il est généralisé à la plupart des serveurs de messagerie d'entreprise et des services de webmail (les services de mail les plus anciens étant resté à POP3 et Hotmail faisant aussi de la résistance d'arrière garde sur ce point - les webmails pouvant aussi communiquer de manière propriétaire avec leur interface web).

Il faut aussi citer XMPP Extensible Messaging and Presence Protocol qui est un protocole de présence et de messagerie instantanée pour la collaboration en quasi-temps-réel avec partage de fichiers et d'applications.

Les problèmes du mail viendraient-ils de son protocole et des principes de fonctionnement qui en sont sous-jacent ? Comment devrait-on alors le faire évoluer ?

Il y a trois écoles sur la question :

• Le protocole actuel du mail est trop compliqué. Il faut développer un protocole plus simple qui se rapproche de l'évolution des usages vers la messagerie instantanée et les échanges au sein des réseaux sociaux.
• Le protocole actuel a permis un développement extrêmement important du mail jusqu'à maintenant et il est très puissant mais sous-utilisé. Il ne faut rien changer et mieux en exploiter les possibilités.
• Le protocole actuel du mail est insuffisant pour gérer la diversité des éléments échangés, des modes d'interaction et des nouveaux modèles de collaboration. Ces nouveaux usages doivent être gérés nativement dans le protocole afin d'en faire un protocole de collaboration et non de communication.

La première position est celle de Facebook notamment à travers son nouveau webmail et de manière plus générale par les réseaux sociaux qui cherchent à préempter le territoire d'usage du mail à la suite de l'adhésion des populations jeunes comme outil principal de communication. Leur vision est de faire converger le mail vers les messageries internes en en supprimant les éléments “inutiles” (titre, personnes en copie, etc..) héritées de la lettre papier, en les agrégeant avec toutes les autres formes de communication en les centrant sur les personnes (et non plus les messages ou les conversations).

Gabor Csell (Xobni puis ReMail racheté par Google) a décrit les principales caractéristiques d'un tel protocole (je traduis son article en français) :

• Un protocole techniquement simple : REST, HTTP/HTTPS, Oauth, JSON
• En mode conversation natif : l'ordre de classement natif serait la conversation (et non la date de réception) comme sur Gmail, les SMS sur iPhone ou Facebook.
• Tag/Label et non répertoire : les messages peuvent porter un ou plusieurs tags/labels qui les caractérisent, qui sont toujours associés et affichés au message et qui remplacent les répertoires du protocole IMAP
• Identifiant unique de message stable pour les conversations / messages / pièces attachées : à la différence d'IMAP qui modifie les ID lorsqu'il manipule les répertoires.
• Suppression de MIME (Multipurpose Internet Mail Extensions) : manipuler le texte du message et les éléments attachés séparément dans des échanges techniques avec le serveur plus simples et plus spécialisés. Ce point rejoint un soucis majeur des DSI qui, face à l’envolée des volumes de stockage nécessaire au mail, voudraient gérer séparément (de manière non redondante surtout) les pièces jointes (fichiers attachés, photo). Cette spécialisation des extensions de gestion des éléments associés au mail est aussi développée par Hotmail pour l’envoi de photos ou de fichiers de grande taille. Xoopit, une startup rachetée par Yahoo, s’était aussi positionnée comme le “mail multimedia” qui “permet de visualiser facilement les photos, vidéos et autres fichiers média enterrés dans votre email”.
• Mode push natif : qui n'est pas natif dans IMAP (et souvent géré via le rajout de Microsoft ActiveSync)
• Indexation plein texte sur le serveur

L'objectif est de faire du mail un service aussi facilement accessible et manipulable que le sont les services web actuel comme Twitter ou Flickr et non une usine à gaz comme IMAP, MIME ou Outlook Object Model and MAPI.

A l'opposé, un protocole de collaboration sophistiqué existe aussi. Il s'agit de Wave qui été développé par Google.

Google Wave est constitué de deux parties :

• une application web de messagerie et de travail collaboratif, créée par Google, dont le concept mélange les notions de services de courriel, de messagerie instantanée, de wiki et de réseautage social,
• Un protocole de communication et collaboration, Wave Federation Protocol, qui constitue une extension de XMPP (c'est pour cela que je n'ai cité), mixant différentes formes de communication, un suivi de différentes formes d'interaction dans la communication (conversation ou thread), des notions de gestion des groupes associés à la communication / collaboration et le support d'un grand nombre d'éléments associés à la communication / collaboration (texte, image, video, application partagée, workflow,…).

L'application web Wave n'a pas connu l'adoption attendue par Google du fait de la trop grande complexité de son usage et Google a annoncé son arrêt. Le protocole a été publié en open source sous licence Apache.

Ce type de protocole et l'interopérabilité qu'il offre constitue ce qui manque aux logiciels actuels de collaborations de type Social Entreprise Management (Blue Kiwi, Socialtext, Jive, etc….).

Ceux-ci sont l'inverse du mail : très puissants en terme de collaboration mais très fermés sur leur communauté de déploiement et incapable d'intégrer des échanges avec des systèmes tiers externes. C'est à ceux-ci que Thierry Breton fait référence quand il parle de "applications dédiées permettant une meilleure communication ainsi que les nouveaux outils de collaboration et les réseaux sociaux". Un protocole commun, ouvert et supportant des modes de collaboration sophistiqués comme l'est Wave Federation Protocol permettrait de “mettre en réseau” ces “réseaux privés”.

Similairement, les réseaux sociaux professionnels de type Linkedin, Viadeo, Palaxo ou Xing ne peuvent pas devenir des "services externes outsourcés de collaboration d'entreprise" pour la même raison : on ne peut pas y collaborer avec des services tiers. Ils contribuent à ce que "les référentiels sortent de l'entreprise" mais un référentiel n'est pas une application.

Un autre point d’extension intéressant du mail qui vient à la suite du “mode conversation” serait d’intégrer des notions “d’étape” afin de pouvoir gérer nativement dans son mail des workflows. Cela couvrirait alors un autre grand sujet de discussion : quel est le meilleur outil pour supporter les processus d’entreprise, le mail répandu et adopté mais peu structuré ou un outil spécialisé de workflow, adapté mais difficile à faire adopter en dehors des processus métier cœur.