Il existe plusieurs méthodes de travail qui s’intéressent à la relation que nous avons avec nos boîtes aux lettres électroniques. Pour n’en citer que deux, je dirais GTD et Zero Inbox, dont le but est d’améliorer le traitement des messages que nous recevons, pour être certain de traiter convenablement les informations reçues. Ce sont des approches très intéressantes, dont je vous parlerai dans de futurs posts.

Pour le moment, je vais vous parler de quelque chose d’autre, qui concerne aussi la manière dont nous utilisons les emails en entreprise. Plus particulièrement, je vais vous expliquer pourquoi il ne faudrait jamais – jamais – échanger de documents de travail par email.

Très souvent, les gens ont tendance à s’échanger les documents (spécifications fonctionnelles, spécifications techniques, listes de choses à faire, relevés de bugs, …) par email. Ça commence par un petit document rédigé par quelqu’un sur son traitement de texte ou son tableur. Voulant que ce document soit lu et utilisé par les autres intervenants du projet, cette personne va donc le leur envoyer par email. Les destinataires vont recevoir le document, le lire, et éventuellement le modifier. Les modifications seront elles-mêmes envoyées par email à toutes les personnes impliquées. Jusque-là, c’est assez clair.

Pourtant, malgré cette clarté apparente, le vers est déjà dans la pomme. Plusieurs pièges classiques peuvent apparaître :

• Plusieurs personnes modifient le même document, puis le renvoient. Vous vous retrouvez avec autant de versions différentes du même document. Tant que personne n’aura fait le travail de « réconciliation » pour fusionner ces versions, vous allez devoir jongler tel un acrobate.
• Le premier document aura certainement été nommé en respectant une norme, incluant le numéro de version du document et/ou sa date de création. Mais il y a de fortes chances pour que ceux qui l’éditeront ne pensent pas à modifier le nom du fichier avant de le renvoyer.

• Aussi fin que soit votre système de classement des messages de votre boîte aux lettres, vous allez commencer à vous arracher les cheveux lorsque vous allez chercher la dernière version du document. Les fichiers ayant tous le même nom (cf. point précédent), il faut se baser sur la date de réception des messages. Mais êtes-vous certain de ne pas avoir oublié de chercher dans un sous-dossier de votre Inbox ? Est-ce que quelqu’un n’a pas dit que la version de lundi était finalement meilleure que celle de mardi ?
• Enfin, lorsqu’une nouvelle personne s’insère dans un projet, comment être certain de lui transmettre tous les documents nécessaires ? N’en avez-vous pas oublié un ? Avez-vous bien retrouvé les bonnes versions ?

Bref, tout ça devient très rapidement un gros sac de nœuds. La solution est pourtant évidente : Tous les aspects d’un projet doivent être accessibles de manière centralisée. À vous de mettre en place la solution qui vous convient. Mais cela peut être :

• Au minimum, un wiki pour la documentation textuelle qui est amenée à être fréquemment modifiée, un outil de buglist (par exemple Flyspray) pour tracer les bugs et possiblement les choses à faire, et un partage de fichiers (Samba, NFS ou WebDAV) pour stocker les données plus complexes.
• En fonction des besoins, vous pouvez utiliser un outil de collaboration en ligne, comme Action Method, Backpack ou Basecamp. Ils reprendront ces fonctionnalités au sein d’une interface unique.

L’intérêt de procéder de la sorte est double. Non seulement vous vous épargnez les problèmes de version générés par les fichiers qui se « baladent dans la nature », mais vous simplifiez et accélérez la recherche d’informations : Lorsque vous cherchez un élément qui concerne un projet donné, vous savez automatiquement où le trouver.

Si cela semble simple dans le principe, il faut parfois se battre contre les habitudes et la méconnaissance des nouveaux outils. Vous continuerez à entendre des gens dire « Ah, tu peux m’envoyer ta nouvelle version du document XYZ par email ? Je le retrouverai plus vite ». Oui mais non. Parce que cela fonctionnera uniquement pour cette personne-là, à ce moment donné, pour ce document particulier. Quand il s’agira de retrouver un autre document, ou passer en revue la liste des priorités, comment allez-vous faire ? Cette personne reviendra vous demander de lui renvoyer les documents ? Ce qui voudrait dire que vous prenez le risque de voir à nouveau des versions différentes s’échanger sans contrôle.

En fait, il faut aider les gens à se créer de nouvelles habitudes. Il est très facile d’ajouter dans son navigateur un marque-page vers la liste des projets, voire un marque-page pour chaque projet. C’est souvent juste ça qui manque.
Dans le pire des cas, ajoutez dans vos emails un lien vers la page du projet, là où sont accessibles les fichiers demandés ; ainsi les gens prendront l’habitude de retrouver ces fichiers dans le référentiel unique où ils sont disponibles. Mais cela reste une béquille ; le jour où des échanges d’emails de contiendront pas le lien magique, il faudra bien que ces personnes soient capables de retrouver les données dont elles ont besoin.