Tous les outils de suivi finissent par avoir des champs personnalisés, et toutes les équipes qui les obtiennent suivent la même courbe : une poussée d'enthousiasme, onze nouveaux champs, et six semaines plus tard un formulaire où neuf d'entre eux sont vides sur chaque ticket.
Le problème, ce ne sont pas les champs personnalisés. C'est que « est-ce que ce serait utile à savoir ? » est la mauvaise question à se poser avant d'en créer un. Presque tout serait utile à savoir.
Le test à appliquer
Avant d'ajouter un champ, demandez-vous : quelle décision change grâce à lui ?
Pas « qu'est-ce que ça nous apprendrait », mais qu'est-ce que vous feriez différemment. Si la réponse honnête est « on pourrait le voir », c'est un champ qui sera vide dans un mois, parce que personne ne remplit une case qui ne change rien.
Deux exemples où la même information réussit puis rate le test :
Version concernée, dans une équipe qui livre chaque semaine et maintient deux versions : réussi. Le champ décide si un bug a besoin d'un backport.
Version concernée, sur une app web en déploiement continu : raté. Tout le monde est sur la même version. C'est une case qui enregistre la date dans un format moins pratique.
Le champ est identique. La décision, non.
Le second test : qui le remplit ?
Un champ rempli par la personne qui fait le tri, c'est réaliste. En revanche, un champ qui exige une information que seul le rapporteur possède, ou qu'un ingénieur n'aura qu'après enquête, est sauté pendant le tri et jamais repris.
Si un champ ne peut recevoir de réponse que tard, ce n'est pas un champ de tri, et le placer à côté de la priorité revient à ralentir chaque passe de tri alors qu'il reste vide.
Les champs qui se rentabilisent à coup sûr
Niveau client (liste de choix). Si l'urgence d'un bug dépend vraiment de qui l'a rencontré, c'est le champ qui change le plus l'ordre de tri. Il passe le test de la décision sans discussion.
Régression ? (case à cocher). Un seul bit, rempli pendant le tri, et il coupe le backlog en « on a cassé ça » et « ça n'a jamais marché ». Ce sont deux files différentes, avec deux urgences différentes.
PR liée (URL). Pas pour le suivi, mais pour la personne qui rouvrira le bug dans quatre mois et voudra savoir ce qui a déjà été essayé.
Relecteur ou Responsable QA (membre). Seulement si une deuxième personne doit vraiment valider. Si « assigné » est le seul rôle qui existe dans votre équipe, ce champ sera toujours égal à l'assigné.
Les champs auxquels résister
Tout ce qui se déduit. Jours depuis l'ouverture, nombre de rapports, a des pièces jointes : le tracker le sait déjà, et une copie tenue à la main sera périmée dès la première fois que quelqu'un oubliera.
Un second statut. Bloqué, Infos requises, En attente du client sous forme de champ à côté de la colonne du tableau, cela veut dire que l'état réel de la tâche vit à deux endroits qui finiront par se contredire. Si c'est un état, c'est une colonne, et si vous ne voulez pas de colonne pour lui, vous ne voulez probablement pas de cet état non plus.
Du texte libre là où il faut une liste. Un champ texte appelé Composant accumulera checkout, Checkout, check-out et chkout, et ne pourra alors plus être filtré ni compté. Si vous voulez regrouper par ce champ, il doit être une liste fixe.
Tout ce que vous ajoutez parce qu'une personne l'a demandé une fois. Les champs sont faciles à créer et socialement coûteux à supprimer. Placez la barre plus haut que « quelqu'un en a parlé ».
Bien typer le champ
Les types ne sont pas de la décoration. Ils décident de ce que vous pourrez demander au tableau plus tard.
Type | À utiliser quand | Permet de |
|---|---|---|
Liste de choix | Un ensemble fixe de choix | Filtrer et regrouper proprement |
Sélection multiple | Plusieurs valeurs d'un ensemble fixe | Filtrer sur iOS ou Android |
Nombre | Une vraie quantité | Filtrer par plage |
Date | Un moment précis | Filtrer par plage |
Case à cocher | Un seul bit | Couper le tableau en deux |
Texte / URL | Tout le reste | Chercher une sous-chaîne, rien de plus |
L'erreur principale, c'est de choisir le texte parce que c'est le plus rapide à configurer. Le texte, c'est le type qu'on choisit quand on a accepté de ne jamais filtrer sur ce champ.
Dans BugDump, le type d'une propriété ne peut plus être changé après sa création, parce que les valeurs déjà enregistrées ont la forme de ce type. Les trente secondes passées à choisir valent donc la peine.
Moins de champs, mais remplis
Ce qui rend un tableau utile, ce n'est pas la quantité de choses qu'il peut enregistrer. C'est que ce qu'il enregistre soit fiable.
Trois champs renseignés sur chaque tâche valent mieux que onze renseignés chacun sur un tiers des tâches. Un champ clairsemé est pire que pas de champ : il ressemble à des données, donc les gens filtrent dessus, et le filtre exclut en silence chaque tâche où quelqu'un était pressé.
Une habitude pratique : au bout d'un mois, regardez à quelle fréquence chaque champ personnalisé est rempli. Tout ce qui est sous la moitié environ est soit mal nommé, soit mal placé, soit la réponse à une question que personne ne se pose. Supprimez-le. Dans BugDump, supprimer une propriété la retire avec ses valeurs mais ne touche pas aux tâches, donc faire le ménage ne coûte que la décision.
Comment ça marche dans BugDump
Les propriétés personnalisées se trouvent sur la page Propriétés du projet, à côté des cinq propriétés intégrées (statut, assigné, priorité, étiquettes et échéance), qui reposent sur le même mécanisme et se modifient de la même façon.
Il existe huit types (texte, nombre, date, case à cocher, URL, liste de choix, sélection multiple et membre), et chacun reçoit sur le tableau le contrôle de filtre qui lui convient : des cases à cocher pour les listes, une plage pour les nombres et les dates, un champ « contient » pour le texte. Les filtres se combinent en ET et vivent dans l'URL, donc un tableau filtré est un lien.
Ils parviennent aussi jusqu'à votre agent IA. Le serveur MCP renvoie chaque propriété avec ses options, et list_tasks accepte des filtres de propriétés, donc « tâches ouvertes où Niveau client vaut Enterprise » tient en un seul appel au lieu de tout récupérer pour tout parcourir.
Les propriétés personnalisées font partie des forfaits Pro et Ultra ; les cinq propriétés intégrées, y compris la liste de priorités modifiable, sont disponibles sur tous les forfaits.
Pour aller plus loin
Niveaux de priorité des bugs : pourquoi quatre choix figés ne collent jamais — pourquoi une échelle de priorités imposée finit toujours contournée, et ce qu'il faut à la place.
Les métriques de suivi des bugs qui comptent vraiment — les quelques chiffres qui disent si votre suivi de bugs fonctionne.
Notifications dans un bug tracker : qui prévenir d'un changement ? — comment un champ de type membre décide aussi de qui est prévenu quand une tâche change.