Chaque équipe a sa version de cette histoire. Quelqu'un signale que le PDF de facture s'affiche avec le mauvais logo. Le designer dépose le bon fichier dans Slack. La QA enregistre une vidéo de l'écran et la met sur le drive partagé. Le client envoie la charte graphique par e-mail. Trois semaines plus tard, le ticket revient sur la table, et les quatre fichiers qui l'expliquent sont à quatre endroits différents, dont deux ont expiré entre-temps.
Le rapport de bug est dans le tracker. Les preuves sont partout ailleurs.
Pourquoi les pièces jointes s'éparpillent
Les fichiers atterrissent hors du bug pour des raisons qui, chacune, se tiennent sur le moment.
Le fichier arrive avant le bug. Un designer envoie la spec alors que le problème n'est encore qu'une conversation dans un canal. Il n'y a pas encore de ticket auquel le joindre, alors il reste là où il a atterri.
L'outil complique les choses. Si joindre un fichier oblige à le télécharger depuis une application pour l'envoyer dans une autre, les gens collent un lien à la place. Les liens vers des fils de discussion meurent plus vite que tout le reste dans un workflow.
Le chat semble être le plus rapide. C'est vrai, pour l'expéditeur. Le coût retombe sur celui qui reprend le bug le mois suivant.
Personne n'a jamais décidé où vont les fichiers. Sans règle, chacun applique la sienne, et chacune est raisonnable prise isolément.
Ce que coûte l'éparpillement
Le coût évident, c'est le temps. Quelqu'un redemande un fichier qui existe déjà, et attend.
Le deuxième coût est pire : un correctif est construit sur la mauvaise référence, parce que la bonne était dans un fil que personne n'a retrouvé. Le code est juste, et le résultat est quand même faux.
Le troisième coût est silencieux. Un bug difficile à reconstituer est repoussé plutôt que corrigé, puis rouvert plus tard avec encore moins de contexte que la première fois.
Ce qui a sa place sur un bug
Pas tout. Une tâche avec vingt pièces jointes est à peu près aussi utile qu'une tâche sans. Le critère : le fichier répond-il à une question que la prochaine personne se posera vraiment ?
La référence. Le design, la maquette, le paragraphe de la spec qui dit quel comportement est le bon. La plupart des désaccords sur un bug s'avèrent être des désaccords sur l'intention.
Les preuves hors de portée de la capture automatique. Une photo d'écran de téléphone, une vidéo d'une interaction avec un appareil physique, le PDF généré par votre application.
Les données qui le reproduisent. Le CSV qui casse l'import, la config qui déclenche le crash, nettoyés au préalable.
Le contexte côté serveur. Le log applicatif de la même minute que le rapport, quand le côté navigateur seul n'explique pas ce qui s'est passé.
Ce qui n'a pas sa place
Les secrets. Jetons d'accès, identifiants, vraies données clients. Une pièce jointe est exactement aussi visible que la tâche qui la porte, et les tâches se partagent.
Tout ce qui se régénère en un instant. La capture d'une page que n'importe qui peut ouvrir en cinq secondes n'est que du bruit dans la liste.
Les archives entières. Un dossier de 200 Mo joint « au cas où » est un fichier que personne n'ouvrira jamais. Extrayez la partie qui compte et joignez-la.
Quatre habitudes qui font tenir le système
Joindre au moment de demander. Quand vous demandez la spec à un collègue, demandez-lui de la mettre sur la tâche plutôt que de vous l'envoyer. Une phrase de plus, et le fichier est là où la prochaine personne cherchera.
Nommer les fichiers pour que la liste se lise comme des réponses. correct-invoice-logo.svg vaut mieux que Screenshot 2026-03-04 at 14.22.11.png. On devrait pouvoir parcourir la liste des pièces jointes sans rien ouvrir.
Dire pourquoi le fichier est là. Une ligne dans la description qui renvoie à la pièce jointe transforme un tas de fichiers en argument. « L'en-tête doit correspondre au deuxième écran de la maquette » vaut bien plus que la maquette seule.
Retirer les fichiers qui ne sont plus à jour. Une maquette dépassée laissée en pièce jointe finira par servir à quelqu'un. La supprimer fait partie du travail de correction.
Comment ça marche dans BugDump
Les rapports arrivent avec leurs preuves déjà jointes : logs de console, requêtes réseau, relecture de session, capture d'écran, environnement de l'utilisateur. Cela couvre ce qui s'est passé dans le navigateur. Cela ne couvre pas ce qui aurait dû se passer, et c'est cette moitié que vos propres fichiers apportent.
Chaque tâche a une section Pièces jointes sous sa description. Vous joignez des fichiers en créant la tâche, en ajoutez d'autres plus tard depuis la page de la tâche ou le panneau latéral du tableau, ou glissez un fichier depuis votre bureau pour le déposer n'importe où sur l'écran de la tâche.
Les fichiers qui vivent dans la description (une image collée, un document inséré dans le texte) y sont aussi listés, regroupés à part, parce qu'on les supprime en modifiant le texte auquel ils appartiennent, pas depuis la liste.
Un avantage plus modeste s'est révélé plus important que je ne le pensais. Quand un agent IA lit un bug via le serveur MCP, il voit désormais les pièces jointes de la tâche en plus de ses rapports. Un agent qui peut lire la spec que vous avez jointe raisonne à partir des mêmes preuves que vous.
La règle derrière tout ça
Mettez le fichier là où la question sera posée.
La question « À quoi c'était censé ressembler ? » se pose sur le bug, des mois après l'envoi de la maquette, par quelqu'un qui n'était pas dans la conversation d'origine, au moment où il décide quoi construire. C'est le seul endroit où la réponse sert à quelque chose.
Pour aller plus loin
Comment rédiger un bon rapport de bug (avec checklist) — ce qu'un rapport doit contenir pour qu'on puisse reproduire le bug, avec une checklist à reprendre telle quelle.
Anatomie d'un rapport de bug – ce que BugDump capture et pourquoi — ce que le widget joint automatiquement à chaque rapport, de la console aux requêtes réseau.
Un modèle de rapport de bug qui marche vraiment (et comment l'automatiser) — les champs d'un modèle qui sert vraiment, et comment les remplir sans effort.