Une instance Jira ne s'effondre jamais d'un coup. Elle se dégrade lentement : les recherches ralentissent, les tableaux mettent dix secondes à charger, créer un ticket devient pénible. Quand on diagnostique, la cause est presque toujours la même — une accumulation de configuration que personne n'a gouvernée.
Sur Jira, chaque champ personnalisé a un coût. Lors d'une recherche ou de l'affichage d'un tableau, Jira doit évaluer les champs présents dans le contexte. Au-delà de plusieurs centaines de champs, les performances chutent — particulièrement les champs visibles dans tous les projets (« contexte global »).
Le scénario typique : chaque équipe demande « juste un petit champ » pour son besoin. Trois ans plus tard, l'instance compte 800 champs, dont des dizaines de doublons — « Client », « client », « Nom du client », « Customer ». La recherche JQL devient lente et les écrans illisibles.
La règle d'or : un champ personnalisé doit avoir un contexte restreint aux seuls projets qui l'utilisent. Un champ global non justifié est une dette payée par toute l'instance.
La discipline consiste à : réutiliser avant de créer, restreindre le contexte, et auditer régulièrement les champs orphelins (jamais remplis, jamais recherchés).
Les systèmes (ou schèmes) (i.e., workflow, écrans, types de tickets, permissions) sont le squelette de configuration de Jira. La question structurante est : faut-il les partager entre projets, ou en donner un par projet ?
La bonne pratique pour une organisation qui grandit : un petit nombre de systèmes standards partagés (par exemple un workflow logiciel, un workflow service, un workflow simple), et des exceptions documentées plutôt qu'un système sur mesure par équipe.
Sur Jira Cloud, deux types de projets coexistent, et le choix a des conséquences durables.
Le piège classique : laisser se multiplier les projets team-managed pour la vitesse de configuration, puis découvrir qu'on ne peut pas produire de rapport cohérent à l'échelle de l'organisation, car chaque projet a ses propres statuts et champs incompatibles. La migration vers un projet company-managed est alors coûteuse.
Un workflow doit refléter le travail réel, pas un organigramme. Trois principes guident une conception saine.
La gouvernance n'a pas besoin d'être bureaucratique. Elle a besoin d'exister. Un modèle minimal et efficace tient en quatre points :
Chez Nimbax, nous commençons souvent par un audit d'instance : inventaire des champs, des schemes et des projets, repérage des doublons et des contextes globaux injustifiés. C'est rarement spectaculaire, mais c'est ce qui rend une instance Jira rapide, lisible et capable de grandir sans s'effondrer.
