Mon nouvel indicateur de danger n’est pas rouge. Il ressemble à ceci :

RE: RE: RE: problème urgent

Le courriel est rendu tellement pratique qu’on lui confie les questions, les décisions, les documents, les demandes de changement et les bugs. Pourtant, son mécanisme a été conçu d’abord pour transporter un message, pas pour gérer le cycle de vie du travail qu’il déclenche.

Quand j’envoie un message, mon client le remet à un serveur avec SMTP. Ce serveur consulte le DNS pour trouver le serveur du domaine destinataire et tente la livraison. Si l’autre côté ne répond pas, il place le message dans une file et réessaie plus tard. Le serveur destinataire dépose ensuite le message dans une boîte que le client lit avec POP, IMAP ou un protocole d’entreprise comme celui d’Exchange.

Outlook → SMTP sortant → file de transfert → SMTP destinataire
        → boîte aux lettres → POP/IMAP/Exchange → lecteur

Cette architecture store-and-forward tolère bien une panne temporaire. Elle ne garantit pas une livraison instantanée ni une seule copie visible. Un retry, une règle de transfert ou une liste peut dupliquer un message. Un accusé de lecture n’est pas une preuve fiable qu’une tâche a été comprise ou terminée.

Les pièces jointes voyagent avec MIME. Un fichier binaire est souvent encodé en base64 pour passer dans le corps texte, ce qui ajoute environ un tiers à sa taille. Trois réponses qui renvoient chacune le document complet fabriquent rapidement plusieurs copies divergentes. Le serveur peut limiter la taille, l’antivirus peut bloquer un type de fichier, et une boîte pleine peut refuser le message.

Même le fil RE: n’est pas une vraie structure de travail. Les clients peuvent utiliser des en-têtes comme Message-ID, In-Reply-To et References pour rattacher les réponses. Changer l’objet, repartir d’un vieux message ou utiliser un client qui les gère autrement casse la conversation. Surtout, aucun de ces champs ne dit « assigné à Julie, reproduit, corrigé dans la version 1.4, à tester ».

Pour un bug, le courriel utile contient au moins :

• ce que la personne essayait de faire;
• ce qu’elle pensait voir;
• ce qui s’est réellement produit;
• le texte exact du message et l’heure;
• la version du logiciel et les étapes pour reproduire;
• une capture ou un fichier d’exemple nettoyé si nécessaire.

Je transfère ensuite ces faits dans un enregistrement possédant un identifiant et des transitions explicites :

BUG-184
État: Nouveau → Reproduit → Corrigé → Testé → Fermé
Responsable: ST
Version visée: 1.4
Étapes: ...
Décision: ...

Le courriel peut notifier les personnes et pointer vers BUG-184; il ne devient pas la seule copie de son état. Une pièce jointe corrigée va dans le dépôt ou l’espace documentaire, pas dans le quatrième fil. La décision importante est résumée dans le ticket pour qu’un nouveau membre n’ait pas à reconstruire vingt réponses.

Il y a aussi une question de sécurité. Un journal ou une base complète jointe pour « aider » peut contenir des mots de passe, des renseignements clients ou des adresses internes. Je demande l’extrait minimal, je retire les secrets et je limite l’accès au ticket. Le transfert du message à quelqu’un d’autre ne devrait pas répandre toutes les données originales.

Une panne du système de suivi ne doit pas bloquer la réception d’un incident urgent. On peut créer le ticket après coup à partir du message, mais son identifiant devient ensuite la référence commune. De même, une réponse automatique du suivi doit éviter une boucle avec une autre réponse automatique.

Je ne vais pas arrêter d’utiliser le courriel : ses files et son caractère asynchrone en font un excellent transport. Ma pratique sera de déplacer le travail dès qu’il a un état, un responsable ou un artefact à versionner. Au quatrième RE:, j’envoie le lien vers l’endroit qui sait réellement ce que « terminé » veut dire.