A quoi pourrait ressembler le futur du mail ? (2/2)

Cet article est constitué de deux parties :

1/2 : La banqueroute du mail (le précédent)

2/2 : A quoi pourrait ressembler le futur du mail ? (celui-ci)

 

Aujourd'hui, les deux outils représentatifs de l'évolution du mail, précédemment cités, se positionnent comme des "surcouches" d'une messagerie existante :

• Xobni procure une nouvelle vision, orientée historique et réseau social, des contacts des messages sur Microsoft Outlook et bientôt Yahoo! Mail (selon Techcrunch) mais aucune fonction de traitement autres que celles de la messagerie sous-jacente.
• ClearContext offre un "réhabillage" de la messagerie avec des fonctions enrichies de visualisation, priorisation et traitement du flux de message qui se superposent aux fonctions de la messagerie sous-jacente (mais sans réelle fonction d'analyse "sociale" de ses contacts et messages).

 

Quelles conclusions tirer de ces réalisations par rapport à nos réflexions sur le futur du mail ?

• Il est inutile de refaire ou de réinventer le mail. Ce n'est pas le sujet. La messagerie, tant coté client que serveur, est une application complexe, riche en fonctionnalités, largement déployée et adoptée auprès des utilisateurs. La valeur des innovations sur le mail ne se trouve pas dans la réécriture des fonctions de messagerie. Il vaut mieux se focaliser sur des nouvelles fonctions. La messagerie doit être considérée comme un "legacy" et un projet ayant pour ambition de se déployer et remplacer les outils de messagerie existants se trompe de cible. Xobni et ClearContext l'ont bien compris. Ils s'appuient sur les fonctions de la messagerie sous-jacente qu'ils enrichissent.
• Il faut "reconstruire" une base analytique de mails à coté de la base de messagerie classique. Les messageries existantes ne sont pas basées sur des bases de données structurées. Cela limite leur capacité de croisement et d'extensibilité des données. I l est donc nécessaire, à coté de la base de mails opérationnelle, de construire une base de données structurées pour collecter et structurer l'ensemble des échanges, leur historique et les données sur les éléments liés afin de les rendre exploitables pour du data-mining. Une base structurée est d'autant plus intéressante qu'une grande part des éléments des messages sont structurés (de type sujet/sous-sujet, entreprise / département / équipe / contact, adresse, etc…). L'équivalent coté mail du "web sémantique". Les données des mails portent énormément d'informations. Elles représentent notre activité relationnelle et notre réseau social. Par exemple :
  • Destinataires en contact via des messages associés directs ou indirects (en copie)
  • Participants communs à des événements
  • Sujets, organisation, dates, pièces jointes
• Leur analyse et leur catégorisation conduisent naturellement à constituer une base du réseau social.
• Les utilisateurs ont besoin de nouvelles vues pour appréhender en globalité le traitement des mails...
  • Par activités : projets, tâches, sujets (ClearContext)
  • Par conversation (ClearContext, Xobni)
  • Par niveaux de priorité (ClearContext)
• ….ainsi que de pouvoir croiser ces différentes dimensions pour naviguer dans l'information tout en conservant la faculté de revenir au message élémentaire
• Ils ont aussi besoin d'accéder directement à partir d'un message :
  • À l'information associée (contacts et réseau social, historique, éléments liés,…)
  • Aux actions associées du processus de traitement du message (actions de traitement, priorités, catégorisation, étape d'un processus de traitement (workflow),…)
• Indexation intégrale et recherche directe. Cette fonction est maintenant standard dans les outils récents (notamment Outlook 2007). L'augmentation du volume des mails reçus conduit nécessairement à partir d'un certain seuil à l'abandon du traitement par rangement manuel dans des dossiers des mails. L'indexation intégrale et la recherche directe s'imposent d'elles-mêmes d'autant plus que la fonction est devenue très efficace.

 

Quelles sont les fonctionnalités supplémentaires que l'on pourrait attendre ?

• Tags. Les possibilités de catégorisations offertes, même si elles sont multiples (catégories, priorités), ne permettent néanmoins pas réellement de tagguer les messages. Il devrait être possible d'associer un ou plusieurs tags à un message, tag libre ou provenant d'une liste structurée mais extensible (folksonomie).Ainsi définis, les tags permettraient de mettre en œuvre des notions de groupes multiples très puissantes (de type professionnels / personnels, collègues proches / reste de l'entreprise / externe entreprise, etc…). Les tags devraient pouvoir être associés au message ou à certains de ses éléments (contacts, conversation, sujets, pièces jointes,…) et il devrait être possible de définir des règles d'affectation automatique de ces tags (par exemple, tous les éléments d'un message provenant d'un destinataire dont l'adresse est une entreprise ont le tag de cette entreprise). Une fonction similaire serait d'associer une note libre ou une adresse internet au message ou à ses éléments liés. Cette fonction de tag prend tout son sens lorsqu'elle est propageable à l'ensemble des éléments liés car elle multiplie la pertinence de la recherche directe sur indexation intégrale. L'information apportée par les tags est aussi exploitable pour des processus de traitement automatique qui seront évoqués à la suite.
• Workflow et tableau de bord d'activité. ClearContext a montré la voie dans ce domaine. Les messages devraient pouvoir se déposer dans des "containeurs" d'activité. Ceux-ci pourraient consolider l'ensemble des éléments liés à ces activités (messages, mais aussi événements du calendrier, voire tâches, notes, contacts ou autres si pertinents). L'étape suivante serait d'associer à ces "containeurs" des étapes d'un workflow correspondant à l'activité en cours et de pouvoir partager ces containeurs avec l'ensemble des personnes impliquées dans l'activité (avec des restrictions éventuelles aux étapes correspondantes du workflow si nécessaire). Le tableau de bord d'activité en résulterait facilement et là encore pourrait être partagé, en fonction de chacun de ses éléments, au sein d'une équipe.
• Gestion relationnelle. Cela regroupe les fonctionnalités pour "Gérer son capital relationnel" comme décrit dans mon précédent billet (partie 1/2). Xobni est le plus avancé dans cette direction pour la partie analyse. Il lui manque, par contre, la partie "planification" et réalisation de "campagne d'actions" relationnelles. Par là j'entends la possibilité, à partir de la visualisation de son réseau social sur différents groupes ou caractéristiques de regroupement, de définir des axes de développement (sur un sujet, dans une organisation, sur une dimension) et d'y rattacher des actions de contact (contacter des personnes, organiser des événements, communiquer sur certains sujets) qui sont ensuite déroulées dans le cadre de "campagnes d'actions ".
• Gestion en masse, enrichissement, rapprochement et déduplication des données. Derrière l'inflation des mails, se profile un autre problème lié : l'inflation des contacts. Problème aggravé par le manque de qualité des informations saisies et la duplication des contacts. Sans compter la tendance à la dispersion de ces informations entre plusieurs messageries (une professionnelle et une personnelle mais souvent les contours en sont plus flous), des smartphones à la synchronisation imparfaite et des services de réseaux sociaux sur internet (Linkedin, Facebook,…) riches en informations. Il n'existe aucune réponse à ce besoin dans les messageries traditionnelles. Les contacts sont stockés sous forme d'information non ou peu structurée. Il n'est pas possible d'éditer ses contacts en masse, de les tagguer ou de les affecter à un groupe en masse ou en utilisant une règle. Il n'existe pas de fonction de rapprochement et de fusion des contacts en double (mêmes noms, adresses mail ou numéros de téléphone). Rien n'est, non plus, prévu pour importer ou lier ces contacts avec des profils en ligne (des services tels que Linkedin ou Plaxo proposent néanmoins des pluggin pour Outlook) et la synchronisation des contacts avec l'ensemble de ses devices ne couvre jamais tout les cas de figure. Et je ne parle pas de la possibilité d'abonner des contacts à des flux RSS de mise à jour ou à des "Lifestreams" (de type Twitter) ainsi que la possibilité de les exporter/modifier/réimporter dans une feuille Excel.
• Filtrage amont : un moteur de règle comme assistant(e). Que font ClearContext et Xobni ? Ils prennent les mails entrants, analysent leurs caractéristiques qu'ils utilisent à la suite pour en organiser l'affichage et le traitement. Il est possible d'étendre ce principe en faisant reposer l'analyse des mails entrants sur des règles de proximité dans le réseau social précédemment constitué (notamment à partir de l'analyse des mails mais aussi des contacts saisis manuellement ou importés). Par exemple :
  • Afficher en priorité les mails provenant de la hiérarchie ou de personnes proches ou de personnes avec une fréquence de relation élevée
  • Séparer les mails de nature professionnelle et les mails personnels
  • Faire ressortir des mails "signaux faibles" (personnes avec des fréquences de relation faible, provenant d'organisations spécifiques, de personnes inconnues en direct mais liées à des contacts directs
  • A partir de là, une très grande variété de règles peuvent être envisagées pour filtrer, voire traiter de manière automatique , les mails entrants. L'équivalent du (conséquent) travail de filtrage réalisée par un(e) assistant(e).
• Syndication relationnelle. On part ici de l'idée que dans la vie réelle, on ne fait pas que gérer ses contacts individuellement et qu'il peut être intéressant de les mettre à disposition, de les partager ou de "connecter" le réseau social de ses contacts avec celui d'autres contacts proches (typiquement entre les personnes de la même organisation).

La syndication se décline donc en deux axes :

• Syndication de contacts : Mettre à disposition ses contacts ou une partie de ses contacts (un extract de son fichier de contact) pour une utilisation partagée (par exemple au sein d'une équipe commerciale) ou pour une destination particulière (typiquement pour l'organisation d'un événement). Les contacts ainsi "syndiqués" sont enrichis des retours de leur utilisation (par exemple : a été invité et a participé à tel événement) et ces "enrichissements" sont récupérés par le possesseur initial du contact.
• Syndication du réseau social : Rapprocher et connecter les réseaux sociaux des différents participants impliqués. Cela peut nécessiter une opération de rapprochement / déduplication des fichiers de chacun au niveau du groupe de partage.

"Permission marketing". La contrepartie de cette "syndication" doit nécessairement être de pouvoir contrôler cette mise à disposition (par exemple ne partager que certains contacts rattachés à une organisation ou professionnels, exclure certains contacts du partage, imposer des règles d'autorisation de la mise en relation ou de l'utilisation du contact - du type de celles présentes dans Linkedin-, etc…). Ce partage et cette valorisation des contacts sont déjà censés être réalisés dans les outils de gestion de la relation client (CRM) mais, dans la pratique, on s'aperçoit que, hors contacts commerciaux directs avec une contrainte de renseignement forte, ces outils ne sont absolument pas adaptés pour collecter des contacts "non structurés" et ne gèrent absolument pas, ni les relations entre les contacts (ni même leur rattachement à une structure organisationnelle), ni les règles de contrôle de leur utilisation ("permission marketing").

 

Tout cela fait, au final une belle application ! Une usine à gaz me diront certains...

Il y a néanmoins une autre manière de considérer le sujet. Lorsque l'on prend globalement l'ensemble des fonctionnalités décrites, ce qui m'apparait c'est qu'il s'agit de la juxtaposition d'une messagerie et d'une application de gestion de campagnes. Une application un peu détournée puisqu'il s'agit de faire dans ce cas de la gestion de campagne sur une base individuelle.

Dans cette perspective, tout est dans la boite :

• Une base de données structurées historisant l'ensemble des messages envoyés avec les contacts correspondants et les éléments liés
• Des fonctions de gestion de listes et de traitement en masse pour l'édition des contacts
• Des fonctions d'enrichissement, de déduplication et d'analyse des données (exploitables par la suite pour le traitement des messages)
• Un moteur de règles s'exécutant sur l'ensemble des transactions et gérant des aspects aussi différents que :
  • La pression commerciale (ne pas envoyer trop de messages toujours au même prospects "haut potentiel")
  • Le "permission marketing" (vous pouvez m'envoyer des informations mais pas des propositions commerciales ou pas de propositions de partenaires)
  • La confidentialité des données (ces données ne doivent pas être communiquées à l'extérieur, les données de contact peuvent être utilisée pour prendre contact en cas de problème individuel mais pas pour réaliser des études marketing)
  • Des scénarios de retour sur des messages envoyés (du type : si le prospect n'a pas appelé au bout de 5 jours; lui envoyer un message, si le prospect est venu sur le site web; le faire appeler par le call center, etc…)

De plus, les nouveaux besoins décrits correspondent bien à ce que sait faire un outil de gestion de campagne :

• Planifier et exécuter des "campagnes d'actions relationnelles" pour gérer son capital relationnel
• Gérer des règles de filtrage et de routage sur des messages entrants
• Mettre à disposition des fichiers de contacts pour des opérations réalisées en externe et récupérer les données enrichies du résultat de ces opérations.

 

Quelle serait l'architecture globale envisagée d'une telle solution ?

• L'outil client et le serveur de mail restent inchangés
• Une interface en surcouche est ajoutée à l'interface client du mail avec :
  • La possibilité de tagguer les messages, les contacts ou les éléments liés du message
  • Des interfaces de visualisation du flux des mails et de gestion relationnelle
  • Des interfaces permettant d'étendre les actions de traitement du flux des mails et de gestion relationnelle (workflow d'activité, tableau de bord, planification et réalisation d'actions relationnelles) complétées par les processus de traitement correspondants.
  • Des interfaces d'accès et de gestion aux données et aux règles sur l'outil de gestion de campagne
• Un outil de gestion de campagne avec :
  • Une base structurée des messages, contacts et éléments liés supportant la représentation des réseaux sociaux, des groupes et des folksonomies (tags) provenant des interfaces clients
  • Une gestion des fichiers de données pour gérer des alimentations, traitements, mise à disposition, reprise et déduplication multiples des données
  • Un moteur de règle pour filtrer et gérer les flux de mails en mettant à jour les fichiers de données

L'ensemble de ces éléments pourraient être embarqué sur le poste client (comme le font Xobni et ClearContext) ou réparti entre une interface client sur le poste client et un serveur de traitement (dans une architecture massivement multi-instances pour faire tourner autant d'instances individuelles que de clients).

A terme, je pense que l'architecture cible d'une telle solution comprendra une partie client avec les interfaces et un moteur de règles et que ce moteur de règle client discutera et se partagera les traitements avec le moteur de règles sur le serveur. Une architecture "Software + Service" comme la développe Microsoft.

L'architecture "interface client + traitement serveur" me semble néanmoins la plus simple à mettre en œuvre à court terme. Elle se positionne comme les "Services attachés" que met à disposition Microsoft pour les serveurs de mails (Microsoft Exchange Hosted Filtering (spam, antivirus et queuing), MEH Archive, MEH Continuity, MEH Encryption) ou encore comme une "Gateway" rajoutée sur le tuyau de la messagerie.

 

Si vous êtes intéressé pour discuter du sujet ou même pour développer un prototype, n'hésitez pas à me contacter ("écrivez moi" en haut à droite du blog).