J'ai voulu créer l'application mail parfaite

Temps de lecture: 36 min

1.Aujourd'hui, ma boîte mail était affreuse

L’été dernier, j’ai fait une grosse déprime à cause de mes e-mails.

J’ai commencé à écrire des mails à l’âge de 6 ans, pour rester en contact avec ma grand-mère, et je n’ai jamais arrêté depuis: pour organiser des projets sur lesquels je travaillais avec d’autres élèves au lycée, pour me tenir au courant des événements qui avaient lieu sur le campus et pour envoyer des candidatures après avoir eu mon diplôme. Je recevais beaucoup plus d’e-mails que je n'en envoyais, mais je suis toujours parvenu à rester à jour dans mon courrier.

Mais lorsque j’ai rejoint Slate.com en tant que chargé des contenus interactifs, les vannes se sont ouvertes. J’ai commencé à recevoir des e-mails de mon supérieur. Puis du supérieur de mon supérieur. Puis d’agences de relations publiques. Des chaînes interminables de «répondre à tous» cachant, bien enfouie au milieu des messages, une information intéressante.

Pour faire face aux centaines de messages que je recevais chaque jour, j’ai essayé tous les logiciels de messagerie que j’ai pu trouver: Gmail, Microsoft Outlook, Apple Mail, Mozilla Thunderbird et une kyrielle d’applications moins connues. J’ai mis en place un immense système de règles pour ma boîte de réception, j’ai inventé des méthodes d’organisation élaborées et mis en place des plans complexes.

Pourtant, dès que j’essayais de plonger dans mes mails, mes yeux partaient dans le vague et mon esprit s’embrumait.

J’étais devenu un déprimé du courriel. Vous l’êtes peut-être vous-même. Beaucoup de gens le sont. Mais les problèmes que l’on a avec sa boîte mail ne font pas partie des choses dont on peut se plaindre au quotidien, comme la météo, les allergies ou les transports en commun.

Personne ne demande jamais «Ça a été, tes mails, aujourd’hui?» et personne ne répond «M’en parle pas, c’était l’enfer. Les mails, dans cette ville, c’est n’importe quoi».

Mais si vous posez la question directement autour de vous, vous vous rendrez compte de l’épidémie de déprimes dues aux mails. L’année dernière, Slate.com a mené une enquête interne au sujet des e-mails en demandant aux journalistes et aux auteurs ce qu’ils ressentaient face à la quantité de mails dans leur boîte. Parmi les réponses, on pouvait lire: «Epuisé», «Débordé», «Inquiet» et «Dans la merde».

Je suis persuadé qu’un jour, nous communiquerons directement par l’intermédiaire d’une interface inter-cerveaux; les e-mails seront, pour notre grand esprit de ruche zombie, un peu ce que sont devenus les dessins rupestres préhistoriques à nos yeux, et la primitivité du passé ne nous inspirera que pitié et amusement. Mais, pour l’heure, les mails font partie des choses obligatoires, au même titre que la mort et les impôts. Comme la mort, ils sont inévitables, et ce en dépit des miracles de la technologie moderne. Et comme les impôts, ils sont critiqués par tous, mais n’en sont pas moins essentiels au fonctionnement de notre société.

Ils font tellement partie intégrante de nos vies du XXI^e siècle que se déconnecter est devenu une sorte de test d’endurance et de volonté, un peu comme un marathon, ou une quête de repos spirituel, un vœu de silence numérique.

Pourquoi les e-mails doivent-ils ressembler à un tel travail de Sisyphe pour les milliards de personnes qui les reçoivent? C’est cette question qui tournait dans ma tête un soir, alors que je regardais la quantité de plus en plus grande de mails qui s’entassaient dans ma boîte de réception. Un message du rédacteur en chef de Slate.com, qui me demandait si mon projet avançait bien, une confirmation de vol, un e-mail de candidature, un communiqué de presse d’une agence qui ne cesse de m’envoyer des mails sur les robes de soirée d’Olivia Munn… Ma boîte mail ressemblait à une bibliothèque après une tornade, avec des pages déchirées éparpillées dans toute la pièce.

J’ai passé autant de temps à faire le tri dans tout ce fatras qu’à lire les mails. Les organiser semblait un combat futile contre l’entropie, et le temps de finir ce travail de titan je n’avais déjà plus le courage d’y répondre... après tout, répondre engendrerait encore plus de messages. Ma boîte mail semblait cassée. Si seulement il existait un moyen de la réparer.

Et puis j’ai pensé que je pouvais peut-être le faire. Me serait-il possible de me servir des mêmes technologies que j’utilisais tous les jours pour faire des cartes et des widgets pour Slate.com afin de créer ma propre application mail? Un client de messagerie qui me permettrait d’organiser facilement mes mails, dont l’utilisation serait intuitive, un vrai bon logiciel, en somme…

Je me suis donc embarqué dans l’aventure la plus technique que j’ai jamais entreprise: créer une application mail qui soit parfaite pour moi. La tâche allait me prendre des mois, m’immerger dans un univers à la Rube Goldberg... et me rendre légèrement cinglé.

Il existe un antagonisme fondamental au cœur même de ce que sont les e-mails, entre ce pour quoi ils ont été inventés (il y a plusieurs décennies de cela) et la manière dont nous les utilisons aujourd’hui. C’est cet antagonisme qui fait que la quasi-totalité des logiciels de messagerie que nous utilisons aujourd’hui sont, par essence même, imparfaits. Le seul moyen de «régler» ce problème serait de changer entièrement notre approche des e-mails.

2.Dinosaures

Ma mission: concevoir, pour mon ordinateur portable, un client mail qui rendrait l’utilisation des e-mails aussi agréable que possible, en rassemblant et associant les caractéristiques que je préfère dans diverses autres applications, tout en ajoutant quelques spécificités de mon cru. Ce programme doit être la messagerie parfaite pour moi, mais pas forcément pour les utilisateurs, ni même pour mes collègues ou des gens que je ne connais pas. Je lui ai déjà trouvé un nom: SlateMail.

Je suis journaliste. Je n’ai aucun diplôme en informatique. Je conçois des widgets interactifs pour Slate.com en utilisant des connaissances en informatique glanées lors de cours facultatifs à la fac, dans quelques livres et sur Internet.

Le seul moyen pour que je puisse mener à bien un tel projet était de m’appuyer sur la communauté du logiciel libre, à savoir les millions de développeurs qui partagent gratuitement leurs codes en ligne dans l’espoir que d’autres l’amélioreront et favoriseront les innovations.

Je me suis servi tout particulièrement de quatre modules JavaScript d’e-mails en open source: un pour permettre à mon application de communiquer avec mon fournisseur de mail, un pour analyser les mails depuis mon fournisseur, un pour m’aider à concevoir un éditeur de texte afin d’écrire les mails et un pour envoyer les messages. Ensemble, ces modules m’ont permis de gagner un nombre d’heures incalculable et éviter d’écrire des milliers de lignes de code. J’ai donc décidé d’écrire mon propre code en open source pour une raison de karma (est-ce que quelqu’un en voudra? C’est une toute autre question).

Mais Internet ne pouvait pas concevoir l’intégralité de l’application à ma place. Il me fallait assembler tous ces composants ensemble afin de créer une solution utilisable. J’ai donc décidé de plonger directement dans le code. Il va sans dire que j’ai passé mes premiers jours à avancer dans la mauvaise direction. Je m’étais, en effet, attelé à la tâche en pensant que les e-mails, comme la plupart des produits technologiques, étaient des créatures sophistiquées, optimisées par des années d’évolution afin de surfer rapidement sur cet océan qu’est Internet.

Cruelle erreur.

Les mails sont des dinosaures.

Il est difficile de s’en souvenir, car l’e-mail n’est devenu monnaie courante qu’au début du siècle. Mais, à vrai dire, il est assez vieux pour que, à l’instar de l’agriculture ou du feu, ses origines ne soient pas précisément identifiables. L’identité de la personne à féliciter (ou à huer) pour avoir créé l’e-mail est un sujet de controverse qui prend racine dans une querelle sémantique sur les types de communications électroniques que l’on peut qualifier d’«e-mail». Si les mails ne sont qu’un moyen de communication entre deux ordinateurs, alors il serait plus approprié de dire qu’ils ont simplement commencé à exister dès le début des années 1960. Puis, les utilisateurs d’un ordinateur du MIT (Massachusetts Institute of Technology) qui communiquaient par l’intermédiaire de terminaux isolés laissaient régulièrement des fichiers dans des répertoires partagés avec des titres comme «pour Jack» ou «pour Steve». En 1965, un utilisateur a officialisé ce système avec la commande «e-mail», ce qui peut être la première association officielle des messages numériques avec les e-mails actuels.

Une revue universitaire sur l’histoire de l’informatique nous raconte le reste de l’histoire: un groupe d’informaticiens a proposé les premiers standards Internet en 1973, l’année du Watergate, ce qui fait que les standards des e-mails sont plus vieux que l’Américain moyen.

Ces premiers standards n’ont établi que peu de choses, hormis les en-têtes «From» («De»), «Subject» («Objet») et «Date» que l’on connaît aujourd’hui encore.

Les informaticiens ont passé le reste de la décennie à se disputer à propos de détails: les en-têtes des e-mails devraient-ils être lisibles par des machines ou par des humains? Les véritables noms devraient-ils apparaître dans le champ «To» («A»)? L’en-tête «Date» devrait-il utiliser un système horaire de 12 ou 24 heures? C’est également dans les années 1970 que la convention du «@» est entrée en fonction et que la fonction «Reply» («Répondre») a rendu plus facile l’envoi et la réception d’e-mails.

Un informaticien a rédigé un deuxième ensemble de standards en 1982, l’année même où un autre a publié les protocoles de base de l’Internet actuel. Ces standards ont défini les e-mails tels que nous les connaissons aujourd’hui dans le monde entier et n’ont été que légèrement revisités depuis.

Ces standards et protocoles Internet, que vous connaissez pour les avoir lus sur les messages d’erreur, quand votre e-mail ne marche pas (POP? IMAP? SMTP?), sont gérés par un groupe international de technologues appelé Internet Engineering Task Force. Ils s’assurent que les deux sous-systèmes des e-mails (fournisseurs et clients de messagerie) fonctionnent bien ensemble.

Les fournisseurs de mails sont des services qui s’occupent de l’échange de mails, comme, par exemple, les serveurs de Google, d’Apple iCloud et d’Exchange. Les clients de messagerie sont les logiciels et applications grâce auxquels on peut lire et écrire des e-mails. Apple Mail, Mozilla Thunderbird, Microsoft Outlook et n’importe quelle application e-mail sur votre téléphone sont des clients de messagerie. Les clients e-mail qui sont associés à un fournisseur de mails portent souvent le même nom –«Gmail» peut soit être le client de messagerie de Google, le service mail de Google ou les deux– mais ce sont deux choses bien distinctes. Vous pouvez, par exemple, utiliser le fournisseur d’e-mails Gmail sans vous servir du logiciel de messagerie Gmail (si vous avez un compte Gmail et que vous lisez votre courrier sur le programme de messagerie par défaut de votre iPhone, c’est ce que vous faites déjà).

Quand Twitter a voulu ajouter des images aux tweets, il n’a eu qu’à sortir sa baguette magique et bim! Tout à coup, tout le monde a pu tweeter des images.

Ce n’est pas comme ça que se font les changements pour les e-mails. Personne ne «possède» les e-mails. Il n’y a personne à la tête de la chaîne de commandement qui pourrait transformer les mails en une nuit… il n’y a pas de chaîne de commandement.

C’est important: cela signifie que tout dispositif pouvant se connecter à Internet peut également envoyer et recevoir des mails. Vous pourriez vous débarrasser de Google, d’Apple et de Microsoft et transformer votre ordinateur personnel en un serveur mail. Mais cette décentralisation signifie aussi qu’il y a trop de monde en cuisine: les fournisseurs, les clients et les informaticiens qui s’occupent des standards Internet. C’est pourquoi les changements se font moins rapidement que nous en avons l’habitude pour les autres technologies.

Un problème que posent les e-mails et qui m’est apparu cruellement lors de la conception de SlateMail, c'est qu’il existe une contradiction entre ce pour quoi les mails ont été conçus et la manière dont nous les utilisons aujourd’hui.

Le facteur ne déposerait pas des centaines de courriers dans votre boîte aux lettres tous les jours. Vous n’écririez pas une lettre à tous vos collègues pour leur demander si l’un d’entre eux pourrait aller chercher des burritos pour le déjeuner.

Toutefois, les e-mails ressemblent toujours, d’une certaine manière, au courrier papier lent, formel et encombrant (même s’il a remplacé de nombreuses autres formes de communication, comme le téléphone, le meeting, le fax, le pager et le passage rapide dans le bureau des collègues).

En raison de la décentralisation des e-mails, les fournisseurs, les clients et les informaticiens qui s’occupent des standards Internet ne peuvent que greffer de nouvelles fonctionnalités sur le modèle existant. Ainsi, bien que les e-mails bénéficient d’innovations, ces dernières se caractérisent par des options qui s’ajoutent parfois aussi astucieusement que maladroitement à un système archaïque (des options qui tentent soit de faire retrouver aux mails leur fonction d’origine, soit de les transformer en quelque chose de complètement différent).

3.Le joueur d'échecs trop bavard

Imaginez deux personnes en train de jouer aux échecs par téléphone. La première commence à jouer en annonçant «Pion en C4».

Le deuxième joueur, quand vient son tour, prend une grande inspiration et lance:

«A1: tour. B1: cavalier. C1: fou. D1: reine. E1: roi. F1: fou. G1: cavalier. H1: tour. A2: pion. B2: pion. C2: vide. D2: pion. E2: pion. F2: pion. G2: pion. H2: pion. A3: vide. B3: vide. C3: vide. D3: vide. E3: vide. F3: vide. G3: vide. H3: vide. A4: vide. B4: vide. C4: pion. D4: vide. E4: vide. F4: vide. G4: vide. H4: vide. A5: vide. B5: vide. C5: vide. D5: pion. E5: vide. F5: vide. G5: vide. H5: vide. A6: vide. B6: vide. C6: vide. D6: vide. E6: vide. F6: vide. G6: vide. H6: vide. A7: pion. B7: pion. C7: pion. D7: vide. E7: pion. F7: pion. G7: pion. H7: pion. A8: tour. B8: cavalier. C8: fou. D8: reine. E8: roi. F8: fou. G8: cavalier. H8: tour.»

Le deuxième joueur, pour avancer son pion, a indiqué l’état de toutes les cases de l’échiquier. En quoi est-ce que ça cloche? Cela implique beaucoup de communications inutiles. Les joueurs ont juste besoin d’indiquer ce qui change sur l’échiquier, pas de renseigner l’état de chaque case. Un simple «pion en D5» aurait suffi. Sans cela, la partie pourrait durer des jours.

Les e-mails fonctionnent comme le joueur d’échecs trop bavard.

La première chose que j’ai eue à faire pour créer mon propre logiciel de messagerie a été de synchroniser les e-mails de mon ordinateur avec ceux de mon serveur mail. Tous les clients de messagerie ou presque exécutant cette tâche à intervalles réguliers (une fois par minute ou quelque chose comme ça), je m’attendais à ce qu’il existe une sorte de méthode générale et efficace pour exécuter cette tâche. Je m’attendais à pouvoir demander simplement au serveur: «Salut, qu’est-ce qui a changé depuis la dernière fois qu’on s’est parlé?» et que le serveur me répondrait: «Eh bien, j’ai trois nouveaux e-mails pour toi. Tiens», avant que le logiciel n’indique au serveur: «Tiens, ces quatre e-mails sont désormais supprimés et ces deux autres ont été lus.» Mais ça ne marche pas comme ça.

Au lieu de ça, le serveur agit comme le joueur d’échecs bavard. Pour se synchroniser correctement via le protocole standard baptisé IMAP, le client mail doit demander au serveur la liste des e-mails et leur statut (lu ou non lu), les comparer avec les e-mails et statuts qu’il a déjà, demander les mails qui lui manquent, supprimer ceux qu’il a en trop et s’assurer que les statuts des mails correspondent.

La quantité de données inutilement transférées entre le logiciel et le serveur est aberrante. Le client mail doit télécharger les statuts de dizaines de milliers de mails potentiels pour détecter un seul changement (voire pas de changement du tout!). Cela fonctionne, certes, mais cela veut aussi dire que les logiciels de messagerie sont plus lents et plus gourmands en données et en bande passante qu’ils ne devraient l’être.

Maintenant, il est vrai que, la plupart du temps, l’utilisateur ne réalise pas à quel point le fonctionnement de son logiciel de messagerie est inefficace. Mais ce problème de la synchronisation montre bien pourquoi l’e-mail est une technologie qu’il est difficile de faire évoluer: le cadre à partir duquel il est possible de construire un nouveau programme d’e-mail tient souvent de l’usine à gaz, mais aucun changement n’est effectué tant que les utilisateurs et les fournisseurs s’en contentent.

Par exemple, en 2008, un membre de l’IETF a développé un protocole baptisé QRESYNC permettant au client de demander simplement au serveur ce qui avait changé au lieu de télécharger un ensemble de données superflues. Pourtant, nombre de gros fournisseurs, notamment Gmail et Outlook, ne supportent pas QRESYNC (prononcez «kiou-ri-sink»). Et ma boîte mail professionnelle ne le supporte pas non plus. Pourquoi le ferait-elle? Rares sont les clients qui le supportent (et pourquoi les logiciels devraient-ils le supporter si les fournisseurs ne le font pas?). Personne ne bougera tant que nous ne pédalerons pas tous ensemble.

SlateMail restera donc ridiculement inefficace.

4.L'appendice qui explose

Lorsque Gmail a lancé sa version beta en 2007, l’une de ses caractéristiques les plus remarquables était le mode «conversation». Cette fonction regroupe par défaut les messages qui sont liés entre eux, de manière à ce que l’utilisateur puisse voir chaque e-mail à la suite de ceux qui l’ont précédé, dans le contexte d’un seul fil de discussion.

Cela implique aussi que, dans Gmail et de nombreux autres clients de messagerie qui ont mis ce système en place, les messages d’un même fil de discussion apparaissent dans votre boîte de réception comme un seul e-mail commun, ce qui permet d’éviter de se retrouver avec 20 mails individuels traitant d’un même sujet dans sa boîte de réception.

C’est une innovation capitale dans le domaine du mail, qui le rapproche de sa fonction première: être une plateforme de discussions démocratiques auxquelles peuvent prendre part plusieurs participants, comme dans un grand brainstorming en ligne.

Je ne pourrais pas me passer de cette fonction pour SlateMail. Je suis donc allé fouiller dans le fonctionnement des e-mails pour trouver un moyen d’avoir ce type de regroupement.

Et euh… comment dire?

Il s’avère que les e-mails ne contiennent pas de métadonnées identifiant explicitement le fil auquel ils appartiennent.

Pour les protocoles de messagerie, les ingrédients universels qui constituent un mail sont l’adresse mail, le mot de passe et le statut, mais pas les conversations. Il n’existait aucun moyen pour que mon logiciel de messagerie demande à mon serveur mail d’identifier tous les messages d’une même conversation. Pourtant, Gmail et, aujourd’hui, d’autres clients mail parviennent à effectuer cette tâche. Comment font-ils?

En fait, Gmail n’a pas été le premier client de messagerie à regrouper les mails de cette manière. C’est une fonction qui remonte au moins à de vieux clients des années 1990, comme Netscape Mail, Grendel, Evolution et Balsa.

N’obtenant aucune information sur la conversation à partir du protocole IMAP, les logiciels doivent les trouver eux-mêmes dans le contenu du mail ou dans les métadonnées. Le fil de discussion peut apparaître au travers de quelque chose d’aussi simple que des e-mails partageant un même objet, ou des métadonnées identifiant le message auquel répond l’e-mail.

En prenant tous les messages contenus dans une boîte mail, un logiciel pourrait très bien les rassembler en remontant jusqu’aux messages d’origine. Le processus implique un algorithme élaboré pour prendre en compte la variété des manières dont les logiciels de messagerie gèrent ces titres cachés.

Ce n’est qu’en 2008 que cet algorithme a pu accéder à IMAP en tant qu’extension proposée au protocole. Cette extension, baptisée THREAD, donnerait au serveur la responsabilité de regrouper les mails en fils de discussion. Malheureusement, comme pour QRESYNC, ni Gmail ni Outlook ne supportent THREAD sur leurs serveurs IMAP, et il m’a donc fallu mettre en place l’algorithme dans mon propre logiciel.

Vient ensuite la question de la manière dont sont affichés les messages d’un même fil de discussion.

Une idée de jeu à faire en voiture pour passer le temps lors de votre prochain long trajet: essayez de tenir une conversation dans laquelle chaque participant, après avoir dit ce qu’il avait à dire, répète tout ce qu’a dit la personne avant lui. Essayez de tenir le plus longtemps possible. Entre deux personnes, cela donnerait quelque chose comme:

«On doit prendre quelle sortie, déjà?

— D’après la carte, c’est la sortie 45. Tu as dit “On doit prendre quelle sortie, déjà?”

— Je crois que c’est bientôt. Tu as dit “D’après la carte, c’est la sortie 45. Tu as dit ‘On doit prendre quelle sortie, déjà?’ ”»

Et voilà comment on loupe la sortie 45.

Imaginez maintenant une réalité alternative dans laquelle tout le monde serait obligé de parler comme cela, un monde infernal dans lequel chaque déclaration inclut une répétition de toutes celles qui l’ont précédée. Bienvenue dans le monde des e-mails!

Lorsque vous cliquez sur le bouton «répondre» dans votre logiciel de messagerie, votre mail cite automatiquement les messages auxquels vous répondez. Votre réponse contient donc deux messages: votre nouveau message et le texte complet du message auquel vous répondez. Et encore, si vous répondez à une réponse, votre propre réponse contient trois messages. Les messages individuels se font donc de plus en plus volumineux à mesure que le fil de discussion progresse.

Afin de ne pas polluer l’affichage des fils de discussions avec tous ces messages superflus, les applications modernes suppriment les messages cités. Cela devrait normalement faciliter la lecture des fils de discussion pour l’utilisateur, mais les cafouillages sont fréquents, avec des conversations devenant quasiment illisibles sous le poids des messages cités.

Inutile, mais dangereux, le message cité n’est qu’une annexe du mail, un accessoire que l’on néglige… jusqu’à ce qu’il vous explose au visage. Pourquoi certains fils de discussion dérapent-ils ainsi?

Réponse: parce que, s’agissant de la manière dont les messages cités sont affichés dans un e-mail, tous les clients ne suivent pas la même règle. Dans un e-mail envoyé depuis le client Gmail, par exemple, le message cité est introduit par une ligne comme celle-ci:

Le 18 février 2015 12h41, Chris Kirk <[email protected]> a écrit:

Dans les e-mails envoyés depuis le client Web d’Outlook, le message cité apparaît sous une ligne horizontale, précédé de quelque chose dans cet esprit:

De: Kirk, Chris
Date: Lundi 23 février 2015 10h30
À: Dan Kois
Objet: Re: Fresca

Et, bien entendu, les autres clients ont encore d’autres manières d’afficher le message cité. Par exemple:

-----Message d’origine-----
De: Chris Kirk
À: Dan Kois
Envoyé le: Lundi 23 février 2015 10h30
Objet: Re: Fresca

Cette variabilité fait qu’il est quasiment impossible d’indiquer à un client de messagerie comment reconnaître rapidement où le message s’arrête et où le mail cité commence. Google a même déposé sa méthode.

C’est un sujet délicat: si votre méthode est trop laxiste, les utilisateurs risquent d’être ennuyés par le capharnaüm des messages cités sous leurs mails, mais si elle est trop stricte, elle risque de supprimer des parties importantes des nouveaux messages.

Pour m’aider à mettre cela en place pour SlateMail, je suis allé voir (comme je le fais souvent) sur Stack Overflow, un site d’entraide entre programmeurs. Je n’y ai rien vu de vraiment rassurant.

Lorsqu’un utilisateur a demandé à la communauté quel était le meilleur moyen de supprimer proprement les citations, un autre utilisateur s’est empressé de l’avertir: «Bienvenue en enfer». Un ingénieur de Facebook a aussi expliqué sur Quora qu’il n’existait aucune solution vraiment propre de le faire.

Mouais... En même temps, ce n’était qu’un ingénieur avec des années d’expérience derrière lui... Après tout, qu’est-ce qu’il en savait?

J’ai tenté de trouver une solution propre. Je me suis planté. J’ai corrigé ma solution. Je me suis encore planté.

Quelle que soit la méthode adoptée, je me retrouvais soit avec de grosses portions de mes nouveaux messages qui disparaissaient, soit avec d’immenses parties de messages cités.

J’ai fini par abandonner et j’ai résolu la question en faisant en sorte que l’affichage de chaque message soit automatiquement limité à la première centaine de caractères, à l’exception du nouveau mail. L’utilisateur n’a qu’à cliquer sur un mail pour l’étendre ou le réduire. C’est loin d’être parfait (je déteste cliquer plus que cela est nécessaire), mais ça me permet de m’en sortir.

5.Moi-même et la chocolaterie

Après trois semaines passées à coder, j’avais un logiciel de messagerie déjà semi-fonctionnel. J’étais en mesure de recevoir, afficher et envoyer des e-mails. Les fonctionnalités que j’estimais primordiales, comme le mode conversation et la suppression des messages cités marchaient plus ou moins bien.

Je souhaitais ajouter à mon logiciel d’autres fonctions standard, que la plupart des utilisateurs jugeraient absolument indispensables, comme une fonction de recherche et la saisie automatique des adresses. Je savais néanmoins que ce type de fonctionnalités pouvait venir avec le temps.

Ce que je voulais avant tout, c’était aller de l’avant pour tenter de faire de SlateMail quelque chose de différent. Je ne voulais pas simplement une application qui me permette de recevoir, afficher et envoyer des e-mails, je voulais un logiciel qui m’aide à gérer mes e-mails.

Quand je pense à la gestion des e-mails, j’ai toujours en tête une scène célèbre de la série I Love Lucy, dans laquelle Lucy et Ethel sont embauchées pour emballer des chocolats qui défilent devant elles sur une chaîne. Au départ, elles sont confiantes. «Ça va, c’est facile», dit Lucy. «Oui, on s’en sort super bien», lui répond Ethel. Mais les chocolats arrivent de plus en plus vite et, rapidement, Lucy et Ethel finissent par se les fourrer frénétiquement en bouche, dans un effort désespéré pour tenir le rythme.

C’est exactement l’impression que me donnent les e-mails (en dehors du fait que l’on ne peut malheureusement pas les manger quand ils commencent à vous déborder).

Par exemple, il m’arrive souvent de ne plus retrouver un mail qui nécessite une réponse urgente. D’autres fois, je peux passer plusieurs minutes à rechercher un mail datant d’il y a quelques semaines.

Tout cela arrive parce que lorsque les mails ont été créés, personne n’avait pensé que nous en recevrions plusieurs centaines par jour. L’ordinateur ne fera pas la différence entre un e-mail envoyé directement par votre patron et votre facture d’eau. C’est à vous de dire où les classer. Le protocole IMAP offre seulement deux outils permettant de faire cela: les dossiers et les «flags». Il est attendu de l’utilisateur qu’il classe ses e-mails dans des dossiers, comme s’il triait du papier, et qu’il indique leur statut avec un jeu de couleurs plus ou moins limité.

Néanmoins, faites-le régulièrement et vous vous retrouverez, comme ce fut le cas pour moi, à vous débattre constamment avec un classement à la hiérarchie élaborée pour retrouver le bon dossier. Plus complexe est votre système d’organisation, plus il vous faudra de temps pour retrouver un mail et moins votre système sera efficace. Au final, le temps que vous passez à maintenir en place votre système d’organisation finit par dépasser le temps qu’il est censé vous faire gagner.

Pourquoi ne pas travailler différemment? Pourquoi ne pas penser d’abord à la quantité de travail et construire une application autour?

C’est exactement ce qu’ont fait Alex Obenauer et Josh Milas, deux étudiants de Virginia Tech, en 2011.

Dans le cadre de l’un de leurs cours, Alex Obenauer avait conçu un client mail en partant du principe que l’on devait traiter la boîte de réception non pas comme une boîte aux lettres, mais comme une liste de choses à faire.

Après tout, il n’est pas faux que tous les mails que vous recevez vous demandent quelque chose: votre attention plus ou moins brève, une réponse ou une action (comme payer la facture d’eau).

Après une campagne de financement réussie sur Kickstarter, ils ont conçu Mail Pilot, un logiciel de messagerie appliquant à la lettre cette idée de liste de choses à faire.

Dans Mail Pilot, pour marquer qu’un e-mail a été lu, il suffit d’appuyer sur la barre d’espace. L’e-mail est alors littéralement rayé à l’écran avant de disparaître dans le dossier des tâches «achevées».

Fonction encore plus impressionnante, le «report» (deferring) d’e-mail permet de sélectionner la date à laquelle on souhaite voir l’e-mail réapparaître au sommet de sa boîte de réception –une fonction impossible à reproduire sur les principaux clients de messagerie sans l’ajout d’une extension tiers (comme Boomerang pour Gmail ou MailTags pour Apple Mail).

Mail Pilot réussit tout cela en utilisant de façon créative l’architecture par ailleurs limitée des e-mails. Marquer qu’un mail a été «lu» ne fait que le déplacer vers un dossier spécial «tâches achevées» automatiquement créé par Mail Pilot. Lorsque l’utilisateur reporte l’e-mail à une date future, Mail Pilot crée un dossier correspondant à cette date et, lorsqu’elle arrive, il affiche automatiquement les messages dudit dossier aux côtés de ceux de la boîte de réception.

J’ai reproduit cette fonction dans SlateMail: en sélectionnant un fil de discussion et en tapant sur la touche D (pour «done», ou «fait») pour marquer les tâches achevées et la touche S (pour «schedule», ou «planning») pour le reporter à une date ultérieure spécifique.

Mais cela ne me suffisait pas encore.

J’ai découvert que, lorsque les gens ont lu leurs e-mails et les ont «traités», ils se répartissent ensuite en deux catégories: les chercheurs et les trieurs. Les trieurs rangent consciencieusement leurs mails dans différents dossiers afin de pouvoir les retrouver rapidement plus tard. Les chercheurs, quant à eux, considèrent leur boîte mail comme un dépôt infini et pensent avoir assez de mémoire pour retrouver un e-mail grâce à la fonction «recherche» de leur messagerie au cas où ils en auraient besoin à l’avenir.

Trier demande de la discipline et chercher nécessite une bonne mémoire. Je n’ai ni l’une ni l’autre.

Au fond de moi, j’aimerais être un trieur, parce que je trouve que je passe beaucoup trop de temps tous les jours à rechercher de vieux mails. Chercher un message est une entreprise fastidieuse faite de nombreux essais et d’erreurs. Parfois, je me souviens juste du nom de l’expéditeur.

Mais je ne suis pas certain que le tri soit plus avantageux: les dossiers laissent vite place à des sous-dossiers, puis à des sous-sous-dossiers. Plus mon système de tri est élaboré, plus je passe de temps à trier mes mails (et plus je devrais finalement passer de temps à retrouver mon mail quand même, lorsque je ne saurai plus dans quel sous-sous-dossier je l’ai placé). Je suis donc partagé entre tri et recherche, sans être vraiment convaincu par l’un ou l’autre.

SlateMail pourrait peut-être m’aider.

Presque toutes mes communications professionnelles importantes peuvent être divisées en projets indépendants.

Ce texte, par exemple, est un projet totalement indépendant des widgets interactifs que je crée pour le site. Mais j’ai souvent l’impression que les différents fils de discussion liés à un seul projet sont comme suspendus dans l’espace. Une fois le projet achevé, je me retrouve souvent un peu perdu, incapable de me rappeler quelles étaient mes dernières décisions et communications liées au projet.

J’ai donc développé un concept organisationnel baptisé «projets» (oui, je sais: je ne suis pas allé chercher bien loin): un mot ou une phrase que l’on peut assigner à un fil de discussion pour le relier à d’autres, qu’ils se trouvent dans les dossiers «fait», «ouvert» ou «pour plus tard».

Disons que mon patron m’envoie un mail pour me demander quand je pourrai lui envoyer la version finale de ce texte et que je souhaite associer cet e-mail aux autres que nous nous sommes envoyés pour parler de ce projet.

Sans cela, il me faudrait passer par tout un système de dossiers. Avec mes «projets» SlateMail, je n’ai qu’à taper P, puis «SlateMail», et le logiciel regroupe instantanément le mail de mon patron avec tous les autres que j’ai tagués «SlateMail». Plus besoin de passer par un système toujours plus compliqué pour trouver le bon dossier. Plus de glisser/déposer laborieux. On tape P, on écrit le mot à taguer, «Entrée» et c’est bon. Par la suite, il suffit de taper le nom d’un projet pour sortir tous les fils de discussion qui lui sont associés. «Projets» facilite le tri et accélère les recherches.

«La belle affaire! Me direz-vous. Il est possible de faire quasiment la même chose avec les libellés Gmail.» Certes, mais à l’inverse des libellés de Gmail, cependant, «projets» a été étroitement lié à la conception de mon application.

Lorsque je cliquerai sur un e-mail que j’aurai précédemment attribué à un projet, par exemple, je verrai non seulement les messages du fil de discussion, mais aussi un panneau affichant ce même fil dans le contexte des autres discussions du même projet, en affichant quelles autres discussions sont ouvertes, lesquelles sont reportées et lesquelles sont achevées. En outre, cela m’offrira un accès rapide à toutes les pièces jointes des messages du projet en question.

Comment ai-je réussi cela dans le cadre très limité offert par IMAP? Je n’ai pas réussi.

Les données de «projets» ne sont stockées que dans SlateMail, pas sur le serveur mail. Pour ce que je veux en faire, c’est OK pour l’instant. Plus tard, je m’inspirerai peut-être de MailTags, une extension d’Apple Mail qui permet de taguer les fils de discussion. MailTags sauvegarde les données relatives aux tags en créant un nouveau dossier pour chaque tag et en copiant les messages dedans. Cela vous permet de voir tous les messages rattachés à un tag depuis un client traditionnel. Autre avantage: si votre ordinateur crame, vous gardez une sauvegarde de tous ces tags sur le serveur IMAP. Un jour ou l’autre, je pourrai modifier SlateMail pour stocker les données de «projets» de la même manière.

Mon concept de «projets» m’aiderait à emballer les chocolats plus efficacement, mais pourquoi ne pas pouvoir également réduire la vitesse à laquelle ils arrivent?

Trop souvent, les cascades de «répondre à tous» finissent par ne plus rien apporter d’intéressant (ce ne sont plus que des blagues et des détails insignifiants). J’ai donc décidé d’emprunter la fonction «ignorer la conversation» à Gmail. Sélectionnez une conversation, tapez sur M («mute», silence) et la conversation ne rejaillit plus jamais dans votre boîte de réception.

Et puis, je me suis fait un petit plaisir: je sélectionne un mail, j’appuie sur B pour «bloquer» et je n’entends plus jamais parler de son expéditeur. Prends ça, Olivia Munn!

6.Beta testing

J’avais enfin conçu le client mail de mes rêves.

Il était atroce.

Les bugs sont inévitables. Plus vous codez, plus vous aurez de bugs. Quand j’ai commencé à vraiment utiliser SlateMail, il n’y avait donc rien d’étonnant à ce qu’il me fasse des choses bizarres: plantages en plein milieu de la synchronisation, impossibilité de sélectionner des e-mails après en avoir envoyé un, coupures aléatoires de la connexion IMAP, comme si le serveur jetait l’éponge et disait «Je ne veux plus travailler avec ce machin».

Faire fonctionner toutes les parties de SlateMail ensemble est devenue une véritable obsession.

Pendant une semaine, je n’ai quasiment rien fait à part dormir, manger et corriger les bugs. Parfois, je réussissais à corriger un bug en quelques instants. D’autres fois, SlateMail plantait sans même un message d’erreur et je devais vérifier mon code ligne par ligne pour isoler le problème, un exercice de tâtonnement qui durait des jours entiers.

Comme je m’appuyais sur une technologie que d’autres avaient construite, il y avait beaucoup de choses dans mon application que je ne comprenais pas vraiment. Je cherchais un bug dans une seule ligne cachée au fin fond d’un code écrit dans une langue de programmation que je ne connaissais même pas. Parfois, les bugs me semblaient si énigmatiques qu’au lieu de les corriger, j’ajoutais des routines afin que le programme continue à se comporter normalement en dépit des erreurs.

Capture d’écran du code de SlateMail

J’ai trouvé l’exercice frustrant, mais il m’a donné une leçon d’humilité et il a été aussi étonnamment amusant. J’imaginais que j’étais dans Les Experts, mais au lieu d’un corps, c’était mon application que je retrouvais morte sur le sol, et je devais découvrir qui l’avait tuée et comment.

En utilisant ma propre application, je me suis surtout rendu compte du nombre de choses que j’avais oublié d’y intégrer. Il y a une quantité de fonctionnalités et de règles que l’on s’attend à trouver même dans les logiciels de messagerie les plus basiques: créer de nouveaux dossiers, pouvoir déplacer ou sélectionner plusieurs messages à la fois, trouver le dossier «boîte de réception» en haut, dans l’arborescence des dossiers, même si cela ne respecte pas l’ordre alphabétique. De même, lorsque l’on sélectionne un e-mail et que l’on se rend dans un dossier différent avant de revenir dans le dossier de départ, on s’attend à ce que l’e-mail soit toujours sélectionné.

A ce moment-là, SlateMail occupait dans ma vie une part beaucoup plus importante que les e-mails n’en avaient jamais prise. Dès je trouvais le temps de penser, je codais en silence. J’ai improvisé un outil de synchronisation lors d’un aller-retour à l’épicerie. J’ai conçu l’arborescence des dossiers alors que j’attendais le métro.

Miraculeusement, les différents éléments ont commencé à s’assembler. Au bout de quelques jours, j’ai pu utiliser SlateMail pendant une minute entière sans que quelque chose ne plante lamentablement. Et puis deux minutes, trois minutes, quatre minutes!

Quand j’ai finalement réussi à faire fonctionner suffisamment d’éléments ensemble, j’ai pu effectuer un vrai test de la fonctionnalité de SlateMail. A l’instar de Mail Pilot, Mailbox de Dropbox et la nouvelle Inbox de Google, SlateMail est conçu autour de la gestion des nouveaux e-mails.

Quand un mail arrive, soit vous vous en occupez immédiatement et vous le marquez comme lu, soit vous le remettez à plus tard. L’objectif autrefois mythique de l’Inbox Zero est devenu une expérience quotidienne pour moi depuis que j’utilise SlateMail.

C’est un véritable soulagement de savoir que le statut de tous mes nouveaux e-mails est bien renseigné et que chaque e-mail est fixé à un statut définitif au lieu d’être suspendu dans l’espace. En théorie, je n’oublierai plus jamais de répondre à un e-mail, et c’est très rassurant à savoir. Chaque fois que j’appuie sur la touche D et que je regarde un e-mail disparaître de ma boîte de réception, je sens une agréable petite montée d’endorphine. J’ai fait quelque chose, aujourd’hui!

Mon concept «projets» a également été très utile. Au lieu de compulser la liste monstrueuse de dossiers pour trouver le dossier auquel se rapporte un e-mail en particulier, je tape P et inscris le nom du projet. C’est un outil de classement parfait pour un gros utilisateur comme moi.

Plus important, SlateMail fournit une vue d’ensemble d’un projet qu’aucun des clients mails les plus importants ne propose.

Avec la fenêtre «projets» de SlateMail, je peux voir tous les fils de discussion d’un projet, leur état d’avancement et les pièces jointes, le tout dans un seul et même endroit.

Imaginons que je remette cet article à plus tard et que j’y revienne dans deux ou trois semaines. Où me suis-je arrêté? A qui dois-je encore répondre? Où est le brouillon le plus récent? Avant SlateMail, j’aurais dû effectuer une recherche en suivant la méthode essais-erreurs. Rechercher les e-mails de mon patron. Rechercher les e-mails de mon patron avec pièces jointes. Rechercher les e-mails de mon patron avec pièces jointes qui me sont directement adressés et datent de plus de deux semaines.

Trop de travail! Aujourd’hui, il me suffit tout simplement de cliquer sur «projets» et de taper «SlateMail». Mon logiciel de messagerie reflète enfin la manière dont j’organise mon travail mentalement.

Mais la fonctionnalité que je préfère, et de loin, est la possibilité de bloquer des expéditeurs.

Bien sûr, la plupart des clients mails vous permettent d’ajouter des règles de dossier et des filtres afin de faire le tri dans les expéditeurs, mais SlateMail réduit cette commande à une seule frappe, et cela me donne un sentiment de puissance presque jouissif. Si une entreprise de marketing m’envoie des e-mails publicitaires sans avoir la courtoisie d’ajouter un lien de désinscription, je n’ai qu’à presser la touche B pour l’envoyer aux cachots et ne plus jamais en entendre parler.

7.La bête de somme

Rien ne vous fait plus prendre conscience de la complexité d’une technologie, qu’il s’agisse d’un grille-pain ou d’un logiciel de messagerie, que d’essayer de le concevoir par vous-même.

Dans ma quête pour concevoir un client mail qui me convienne parfaitement, j’ai découvert à quel point il est difficile de mettre en place la majorité des fonctionnalités auxquelles nous sommes aujourd’hui habitués, et qu’il est encore plus ardu d’en inventer de nouvelles.

Pour l’utilisateur final, l’infrastructure ancienne des e-mails implique l’utilisation de logiciels lourds et de processus peu fiables. Mais ce n’est pas le plus grave: les clients mails sont, à vrai dire, si difficiles à concevoir qu’ils ne sont souvent pas conçus du tout.

Cela fait plus d’un mois que je travaille dessus et SlateMail contient encore tellement de bugs que c’en est risible.

En outre, il lui manque encore certaines fonctionnalités que la majorité des utilisateurs considère essentielles, comme la fonction recherche. Je ne suis même pas certain que mon application fonctionne avec la plupart des fournisseurs d’e-mails. Dans les cas où elle fonctionne, il y a des centaines de possibilités de l’améliorer. Combien de temps cela me prendrait-il pour élaborer un logiciel qui soit un minimum viable pour la majorité des utilisateurs, qui puisse entrer en concurrence, ne serait-ce que symboliquement, dans le monde des logiciels de messagerie? Des années.

Mais, puisque j’ai promis de présenter SlateMail, qu’il soit prêt ou non, le voici dans toute sa monstruosité. Les courageux beta-testeurs peuvent le télécharger ici, et les développeurs peuvent découvrir mon abominable code ici. Je suis impatient d’entendre ce que pensent les gens de ce produit encore inabouti.

La barrière à l’entrée est très élevée et, plus les e-mails évoluent, plus elle sera haute. Les clients mail doivent éviter ce que les développeurs de logiciel appellent les «changements incompatibles», ces modifications qui ne sont pas rétrocompatibles, et qui pourraient, dans le cas des e-mails, faire disparaître de la circulation certains logiciels de messagerie et fournisseurs mail.

Tout doit fonctionner avec tout ce qui l’entoure, même les vieux clients et fournisseurs mail que les gens utilisent depuis plus de dix ans.

«C’est comme la plomberie dans les vieux quartiers, m’a dit Dave Baggett, fondateur de l’application e-mail Inky. Vous pouvez vous plaindre autant que vous voulez, mais elle ne sera pas supprimée. C’est tout simplement impossible. Trop de choses en dépendent.»

Mon client mail soignera ma déprime, mais je ne pense pas que je pourrais me considérer guéri un jour. Les e-mails ne seront jamais ce que nous voulons qu’ils soient. Et en compulsant tous ces protocoles, en écrivant ce code, j’ai compris pourquoi.

Le problème ne réside pas dans les difficiles procédés de synchronisation des e-mails, ni dans l’explosion des fils de discussion, ni dans les formalités rébarbatives de ce médium, ni même sur le volume d’e-mails que nous recevons.

Le problème, c'est que nous évoluons plus vite que les e-mails ne peuvent le faire. Aujourd’hui, nous nous attendons à ce que nos communications se déroulent sans aucun accroc –se faire comprendre en n’ayant quasiment rien à faire. Nous voulons que les applications que nous utilisons au quotidien soient améliorées, non pas une fois tous les dix ans, mais plutôt tous les mois. Le problème ne réside pas dans les e-mails. Le problème, c’est nous.

Les e-mails ne sont pas un dragon qui doit être terrassé. C’est une vieille bête de somme et nous avons exagéré en déposant tout l’éventail des communications humaines sur ses épaules fatiguées.

Et si sauvegarder cette créature loyale n’impliquait pas une transformation totale, mais plutôt un allègement de sa charge?

Peut-être que le rêve d’un avenir sans e-mail n’est pas mort; peut-être cela signifie-t-il seulement un avenir dans lequel les e-mails ne représenteront qu’une infime partie, et non la totalité, de nos communications. Déjà, Facebook, Snapchat et les textos ont allégé la charge des e-mails de la sphère sociale. Désormais, ce répit pourrait aussi s’imposer dans le monde des affaires, où les mails demeurent le premier outil de communication.

L’année dernière, Slate.com a commencé à utiliser Slack, l’un des tout nouveaux outils de collaboration. A l’instar d’autres applications similaires, telles que Hall, Twoodo et Hipchat, Slack est un logiciel de messagerie instantanée conçue pour les bureaux. Il permet à une entreprise de créer des chat rooms permanentes, réservées à des sujets spécifiques, baptisées channels. Le contenu n’est visible que par les employés de Slate.

Désormais, les membres du personnel de Slate n’envoient plus d’e-mails pour dire où ils se trouvent tous les matins, ils postent simplement quelques mots dans le channel #whereabouts. Si les employés de New York veulent aller déjeuner avec des collègues, ils laissent juste un mot dans le channel #slateny. Les membres du personnel peuvent aussi avoir des discussions instantanées entre eux et créer des chat rooms privées.

Le channel Slack #whereabouts de Slate.

Beaucoup à Slate se sont d’abord montrés sceptiques. Cela ne risquait-il pas de «fracturer» nos communications en nous forçant à consulter deux fenêtres au lieu d’une seule?

Je ne sais pas exactement dans quelles proportions le volume d’e-mails de Slate.com a baissé depuis que nous avons commencé à utiliser Slack, mais disons que l’adverbe radicalement vient à l’esprit.

Les mailing lists où les débats sur les pandas faisaient autrefois rage sont devenues silencieuses. Les petites réponses et les questions rapides (de même que les débats sur les pandas!) appartiennent désormais à Slack.

Les mails, de leur côté, ressemblent de nouveau à des mails, c'est-à-dire à des messages d’une certaine longueur et plus ou moins formels. J’ai toujours une foule de conversations en cours au sujet de mes projets, mais si j’ai juste besoin d’un oui ou d’un non de mon patron ou si je veux qu’un développeur m’envoie une URL, je n’ai pas besoin d’écrire une lettre avec salutations et signatures.

«Les e-mails ne disparaissent pas, a dit James Sherrett, directeur des comptes de Slack. Ils deviennent juste l’une des composantes de votre communication.»

Les outils comme Slack ne supplanteront pas plus les e-mails qu’ils ne guériront les dépressifs du courriel. Mais ils offrent un traitement et nous poussent à réfléchir: à l’heure où les services de messagerie, les logiciels et les nouveaux standards tentent de pousser l’e-mail vers l’avenir, ne devrions-nous, utilisateurs, pas tenter nous-mêmes de mieux adapter l’outil à la tâche?

Certes, cela implique d’expérimenter divers programmes et services afin de trouver la meilleure combinaison, voire, si vous êtes un peu fou, de développer votre propre client mail. Mais le plus important serait peut-être de s’appuyer un peu moins sur une technologie vieille de 50 ans alors que tant d’autres options sont disponibles: médias sociaux, outils de collaboration, interfaces auditives corporelles (enfin, la parole, quoi), etc.

La prochaine fois que vous serez sur le point d’envoyer un e-mail rapide, ravisez-vous. Au lieu de forcer votre contact à trouver un moyen de classer votre mail, réservez votre message à un média qui lui corresponde vraiment. Peut-être alors qu’un jour, ensemble, nous pourrons trouver la paix de l’e-mail.

Quelle belle boîte mail j’ai eue aujourd’hui!