Jira Admin Hub

À quoi sert cette extension ?

Jira Admin Hub est une extension de navigateur (Chrome et Firefox) qui ajoute à Jira Cloud un panneau d'outils accessible depuis la barre latérale. Elle a été développée en interne pour couvrir des besoins que Jira ne traite pas nativement : pilotage de la capacité d'équipe, estimation collective, nettoyage de données, recherche avancée, modèles de projets.

Ouvrir le hub

Trois chemins, au choix :

Le hub s'ouvre en surcouche de Jira, sans quitter la page en cours. Il est redimensionnable (la taille est mémorisée) et se ferme avec la croix ou Échap.

L'écran d'accueil

Le hub s'ouvre sur un écran d'accueil (nouveau en 2.2) qui donne l'essentiel en un coup d'œil :

• le sprint en cours du board que vous suivez (choisi dans la tuile, mémorisé ; à défaut, le dernier board ouvert dans le Sprint Manager — et si le board porte plusieurs sprints actifs, un second sélecteur mémorise le sprint suivi) : barre de progression de l'estimé complété, repère du temps écoulé sur la barre, badge en avance / dans les temps / en retard, jours restants et date de fin ;
• les notes d'équipe : des messages courts (« gel des mises en prod jusqu'à jeudi… ») adressés à une équipe Atlassian précise ou à tout le monde. Vous ne voyez que les notes des équipes dont vous êtes membre, plus les notes générales — chaque note affiche son équipe, son auteur et sa date. Ajout et suppression directement depuis la tuile, le tout tracé au Journal ;
• l'état du partage d'équipe, avec accès direct à sa configuration ;
• le dernier sprint clôturé (complétés / restants) et la vélocité moyenne — « Voir les tendances » ouvre la Rétro directement sur ce sprint ;
• les dernières actions en masse de l'équipe, tirées du Journal ;
• des accès rapides : vos modules récents, puis tous les modules actifs ;
• un lien vers ce guide.

Activer et configurer les modules

Le module Paramètres modules (en bas de la navigation) liste tout ce qui est disponible. Chaque module a un interrupteur, et une roue crantée ⚙ quand il a des réglages propres (clé de projet, champ Story Points, jetons d'intégration…).

Un module désactivé disparaît de la navigation et ne s'exécute plus.

Partage d'équipe (optionnel)

Par défaut, vos réglages sont personnels : ils vivent dans votre navigateur. Le partage d'équipe permet de diffuser certaines configurations à vos collègues : presets et favoris JQL, templates de projet.

Le principe : un projet Jira dédié (par convention ADMINHUB) sert d'espace commun. Les configurations partagées y sont stockées dans des tickets techniques.

Si un collègue a déjà créé l'espace, l'extension vous propose de le rejoindre à l'ouverture du hub. Depuis la 2.2, rejoindre l'espace configure l'extension toute seule : les réglages de référence de l'équipe (Capacity Manager, seuils d'ancienneté) sont appliqués immédiatement, et si vous n'aviez encore rien réglé, le jeu de modules recommandé par l'équipe est activé pour vous. Vous pouvez refuser, ou demander à ne plus être sollicité — et vous déconnecter à tout moment.

Dans « Module settings », le bouton « 📌 Recommander ma sélection » publie votre sélection de modules comme point de départ des nouveaux arrivants (jamais imposée à ceux qui ont déjà leurs réglages).

Depuis la 2.1, l'espace d'équipe porte aussi :

• des configurations de référence — un membre de l'équipe peut publier les réglages d'instance du Capacity Manager (heures/jour, champ Story Points…) et les seuils d'ancienneté du Sprint Manager. Elles s'appliquent automatiquement à qui n'a rien réglé localement ; vos réglages locaux gardent toujours la priorité, et un bouton « Suivre les réglages d'équipe » permet de s'aligner (vos jetons restent locaux) ;
• les instantanés de sprint qui alimentent les Tendances de la Rétro ;
• le journal des actions en masse, consultable dans le module Journal.

Modules de gestion

Ces modules servent au pilotage quotidien d'une équipe : sprints, capacité, estimation, données de référence.

Sprint Manager

Une vue de board plus dense que celle de Jira, avec les actions groupées qui manquent nativement.

Le board

• Choix du board, bascule entre sprints actifs et futurs.
• Colonnes issues de la configuration du board, avec compteur de tickets et total de Story Points par colonne.
• Sur chaque carte : clé, Story Points, assigné, priorité, étiquettes, et un badge d'ancienneté (nombre de jours depuis le dernier changement de statut — les seuils de couleur sont configurables).
• Glisser-déposer entre colonnes, ou bouton → pour une transition rapide.
• Filtres : texte libre, champ dynamique, ou filtre JQL (y compris vos filtres Jira sauvegardés).
• Clic sur une carte : panneau de détail avec description, commentaires et pièces jointes (les fichiers HTML sont prévisualisables directement).

Actions en masse

Chaque carte porte une case à cocher. Dès qu'un ticket est sélectionné, une barre d'actions apparaît en bas : transition vers une colonne, ou assignation à quelqu'un (recherche par nom, ou bouton « Moi »). Les opérations s'enchaînent une par une, avec le compte de succès et d'échecs à la fin.

Clôture assistée du sprint

Le bouton « Terminer le sprint » ouvre un assistant plutôt qu'une simple confirmation :

• Bilan chiffré : tickets terminés / non terminés.
• Liste des tickets restants, groupée par colonne (replrepliable quand la liste est longue).
• Destination au choix, ticket par ticket : cochez des tickets puis affectez-les au sprint suivant, au backlog, ou laissez-les en place. Chaque ligne affiche sa destination, et un récapitulatif compte les groupes.
• Après clôture, un bouton mène directement à la Rétro du sprint que vous venez de fermer.
• Si le partage d'équipe est configuré, la clôture écrit aussi un instantané du sprint (tickets et Story Points complétés / restants, destinations choisies) dans l'espace commun — c'est lui qui alimente les Tendances de la Rétro.

Capacity Manager

Répond à la question « combien de travail cette équipe peut-elle réellement absorber ? », puis « où est passé le temps ? » après coup. Quatre onglets.

Vue capacité

• Basée sur les équipes Atlassian : vous associez une ou plusieurs équipes à des boards (avec un taux d'allocation si l'équipe n'est pas à 100 % sur ce board).
• Deux modes : Sprints (les sprints à venir du board) ou Calendrier (semaines ou mois, horizon paramétrable jusqu'à 6 mois, avec vues Tableau, Gantt et Heatmap).
• Pour chaque sprint : charge engagée, capacité disponible, et détail par membre — disponibilité en jours, taux de pilotage (part de temps non productif), et reste à faire.
• Les champs Dispo et Pilotage s'éditent sans recalcul à chaque frappe (2.1) : les valeurs modifiées passent en pointillés, et un bouton « ✓ Appliquer » valide le tout en une fois (« Annuler » rétablit).
• Les absences sont déduites automatiquement à partir de tickets d'absence désignés (congés, formation…). Avec un jeton Tempo renseigné, la déduction est faite personne par personne.
• Un encart « backlog à distribuer » indique ce qui reste à placer.

Rétro sprint

Analyse d'après-coup d'un sprint terminé (ou en cours). L'onglet répartit les tickets en trois familles :

• Engagement initial — ce qui était dans le sprint à son démarrage ;
• Ajouts estimés — arrivés en cours de route, mais chiffrés ;
• Travail fantôme — arrivés en cours de route et sans estimation. C'est le travail invisible qui fait rater un sprint sans laisser de trace dans le burndown.

Pour chaque famille : nombre de tickets, estimation, et surtout le temps réellement imputé pendant la fenêtre du sprint. Une barre montre la répartition, les tickets fantômes sont listés par temps consommé, et un bouton copie un résumé prêt à coller dans un compte-rendu de rétrospective.

Depuis la 2.1, l'onglet affiche aussi les Tendances : un graphe des derniers sprints clôturés (complété en vert, restant en orange, % de complétion par sprint, bascule Tickets / Story Points) et quatre indicateurs — vélocité moyenne, taux de complétion, tendance de vélocité (moyenne des 3 derniers sprints comparée aux 3 précédents, avec les deux valeurs affichées), et reste moyen à la clôture. Ces données viennent des instantanés écrits à la clôture assistée ; pour les sprints fermés autrement (ou avant la 2.1), le bouton « 📸 Enregistrer l'instantané de ce sprint » reconstitue l'instantané depuis l'analyse Rétro.

La détection des ajouts en cours de sprint ne demande aucune discipline particulière à l'équipe : elle repose sur l'historique Jira, pas sur des étiquettes posées à la main.

Poker Planning

Sessions d'estimation collective, sans serveur tiers ni compte à créer : l'état de la session est stocké dans un ticket Jira technique, et tous les participants s'y synchronisent.

• Créer une session : un nom, un filtre JQL pour la liste de tickets, et l'unité de vote (Story Points en Fibonacci, ou jours).
• Rejoindre : par la clé de session, ou via un lien direct que l'animateur copie et colle dans le chat d'équipe — un clic ouvre Jira, le hub et la session.
• Chaque participant voit le ticket courant (description et pièces jointes incluses) et vote. Les votes restent masqués jusqu'à la révélation.
• Révélation automatique quelques secondes après le dernier vote (le bouton manuel reste disponible pour forcer). Consensus parfait = confettis.
• L'estimation retenue est écrite sur le ticket Jira. Un ticket peut aussi être refusé (commentaire de motif, étiquette de backlog, et transition vers le statut choisi).
• En fin de session, l'extension propose de nettoyer les étiquettes « poker » restées sur les tickets déroulés, et applique un statut de clôture au ticket technique de session pour ne pas polluer le backlog.

Component Manager

Fait le ménage dans les composants d'un projet, que Jira ne permet de gérer qu'un par un.

• Chargement des composants d'un projet avec leur usage (nombre de tickets) et leur dernière utilisation.
• Filtres prêts à l'emploi : usage = 0, hors standard (nommage non conforme), doublons probables, inactif depuis N jours.
• Renommage et suppression en masse sur la sélection, avec historique des opérations.
• Raccourcis clavier pour les habitués : Shift+F (filtrer), Shift+R (renommer), Shift+D (supprimer).

Gestionnaire de labels

Les étiquettes Jira prolifèrent : variantes d'écriture, tags posés une fois puis oubliés. Ce module les recense et permet de reprendre la main.

• Charger + compter : toutes les étiquettes de l'instance avec leur nombre d'utilisations. Recherche, tri, export CSV.
• Doublons & orphelins : détecte les variantes réellement problématiques (tirets, points, espaces, accents) et les étiquettes utilisées 0 ou 1 fois.
• Comparer : pour un groupe de variantes, affiche combien de tickets portent exactement chaque forme — utile pour savoir si deux étiquettes recouvrent le même périmètre avant de les fusionner.
• Fusionner : remplace plusieurs étiquettes par une seule sur tous les tickets concernés (la variante la plus utilisée est proposée par défaut).
• Supprimer en masse la sélection — pratique combiné à « Sélectionner les orphelins ».

Modules outils

Ces modules accélèrent des tâches ponctuelles : chercher, créer, diagnostiquer.

JQL Quick Search

Un éditeur de recherche Jira plus confortable, avec deux façons d'exprimer un besoin.

Onglet IA (optionnel)

Décrivez ce que vous cherchez en français ; l'extension génère le JQL correspondant et l'exécute. Nécessite votre propre clé API Claude, renseignée dans les réglages du module — sans clé, l'onglet reste inactif et l'onglet JQL est utilisé par défaut. Un configurateur de périmètre (projets, types, statut, assigné) cadre la génération ; son résumé est visible en permanence.

Onglet JQL

• Éditeur avec autocomplétion locale immédiate, et autocomplétion Jira à la demande (Ctrl+Espace). Sur les champs de personnes (assigné, rapporteur, observateur…), la recherche porte sur les utilisateurs réels.
• Exécution : Ctrl+Entrée.
• Favoris et presets réutilisables, personnels ou partagés à l'équipe (👥). Accès également à vos filtres Jira sauvegardés.
• Résultats en liste ou en hiérarchie (parents et enfants), tri par colonne, filtre sur les résultats déjà chargés, pagination.
• Export CSV, ou rapport HTML enrichi (titre, description, commentaires et liens inclus) pour partager une analyse.
• Changer un statut sans quitter la recherche (2.1) : la pastille de statut de chaque résultat est cliquable — un menu liste les transitions réellement disponibles pour ce ticket, un clic l'applique et la pastille se met à jour.
• Actions en masse (2.1) : chaque ligne a une case à cocher (et « Tout cocher » coche les résultats filtrés). La barre qui apparaît permet trois opérations sur la sélection : transition vers un statut (chaque ticket cherche sa propre transition par nom — ceux qui n'en ont pas sont comptés « sans transition », pas en erreur), assignation (recherche d'utilisateur, ou désassigner), et labels (ajout ou retrait, plusieurs à la fois). Bilan chiffré à la fin, et tout est tracé dans le Journal.

Templates de projet

Crée d'un coup une arborescence complète de tickets à partir d'un modèle : épic, tâches, sous-tâches, estimations et liens de dépendance.

Modèles fournis

Cinq modèles sont livrés avec l'extension et utilisables immédiatement, sans configuration :

Variables

Les modèles contiennent des variables entre accolades, par exemple {CLIENT} ou {FEATURE}. À l'instanciation, l'extension détecte ces variables et vous demande leur valeur : tous les titres et descriptions sont remplis avec ce que vous saisissez. Un même modèle sert ainsi pour chaque nouveau client ou chaque nouvelle fonctionnalité.

À l'instanciation

• Vérification du projet cible : si un type de ticket du modèle n'y existe pas, l'extension propose un équivalent à choisir plutôt que d'échouer.
• Création dans l'ordre de l'arbre, avec priorités, estimations et liens ; progression ticket par ticket, puis récapitulatif avec chaque clé créée cliquable.
• Option : créer une page Confluence (depuis un modèle Confluence ou vierge) et la lier au ticket racine.

Vos propres modèles

Deux façons de créer un modèle maison : partir d'une copie d'un modèle fourni, ou utiliser « Depuis l'existant » — vous donnez la clé d'une épic déjà bien structurée, son arborescence est importée dans l'éditeur, et vous pouvez remplacer un nom de client par la variable {CLIENT} en une étape. Vos modèles sont stockés dans un projet Jira dédié, ce qui les rend partageables avec l'équipe.

Pré-remplissage de tickets

Si vous créez souvent des tickets avec les mêmes valeurs (même type, même composant, même équipe), ce module mémorise ces choix et les remet en un clic.

• L'extension scanne le formulaire de création de Jira et liste ses champs.
• Vous cochez ceux qui doivent être mémorisés — les autres sont ignorés.
• Depuis le formulaire, un bouton capture les valeurs courantes, et un bouton « Appliquer » les réinjecte lors des créations suivantes.
• L'application est volontairement manuelle par défaut (option d'automatisation disponible), et ne touche pas un champ texte que vous avez déjà rempli.

Confluence Bridge

Deux services rendus autour de Confluence :

• Modèles de page : liste des modèles Confluence réellement disponibles, filtrée, pour créer une page à partir du bon gabarit sans chercher dans l'arborescence.
• Zone de transfert riche : un presse-papier intermédiaire qui permet de coller du contenu mis en forme dans l'éditeur Confluence, là où l'insertion directe est bloquée ou dégradée.

Issue Access Diagnostic

Répond à la question qui revient toutes les semaines : « pourquoi Untel ne voit-il pas ce ticket ? »

Vous désignez un utilisateur et un ticket ; le module vérifie la chaîne complète de visibilité : appartenance au projet et aux rôles, permissions applicables, niveau de sécurité du ticket, schémas d'écran et configuration de champs. Il indique le maillon qui bloque, au lieu de laisser deviner.

Watcher Cleanup

Retire un observateur (« watcher ») de tous les tickets qu'il suit, en une opération.

Cas d'usage typique : un compte technique ajouté automatiquement comme observateur par une intégration, qui déclenche des notifications inutiles pour toute l'équipe.

• Recherche de l'utilisateur par nom ou e-mail ; le dernier compte nettoyé est proposé en un clic (ces nettoyages sont souvent récurrents).
• Restriction facultative par JQL (un projet, une période) pour ne pas ratisser tout l'historique.
• Analyse d'abord : la liste des tickets concernés s'affiche, cases cochées, avant toute action.
• Retrait séquentiel avec bilan, puis nouvelle analyse automatique pour montrer l'état réel après nettoyage.

Journal

Le module Journal (nouveau en 2.1) regroupe deux vues, en onglets :

• Actions de l'extension — chaque action en masse effectuée via l'extension (transitions, assignations, labels, fusions, clôtures de sprint, retraits d'observateurs, instantanés de rétro) est tracée dans l'espace d'équipe partagé : qui, quoi, quand, combien, et le nombre d'erreurs éventuelles. Filtres par module, par personne et par texte.
• Audit Jira — les événements d'administration enregistrés nativement par Jira (permissions, workflows, gestion des utilisateurs, projets…), dans une vue plus consultable que l'écran natif : recherche envoyée à Jira, bornes de dates, filtre par catégorie, détail des valeurs modifiées au clic sur une ligne, pagination. Cet onglet demande la permission « Administrer Jira ».

L'onglet Audit Jira affiche l'auteur de chaque événement, résolu en nom réel (y compris dans les valeurs modifiées et les éléments associés — les listes d'identifiants deviennent des noms, avec la nature du compte : « client portail », « application »). Le champ Auteur cherche parmi tous les utilisateurs de la plateforme : l'API d'audit ne filtrant pas par auteur, l'extension balaye alors les événements page par page (profondeur bornée, progression affichée) jusqu'à trouver les actions de la personne. Certains événements n'ont pas d'auteur : Jira n'enregistre que les comptes authentifiés — auto-inscription d'un client sur le portail, synchronisation d'annuaire, politique d'organisation.

Les colonnes des deux tables sont redimensionnables à la souris (double-clic sur la poignée pour revenir à la largeur d'origine) ; vos largeurs sont mémorisées. Sélectionner du texte dans une ligne ne la déplie pas — le copier/coller reste naturel.

Intégrations optionnelles

Ces modules parlent à des services externes. Chacun s'active avec votre propre jeton, renseigné dans les réglages du module et conservé localement.

Tempo — Durée minimale

Tempo impose par défaut une durée minimale d'imputation de 15 minutes. Ce module permet de la remplacer par la valeur de votre choix, à la fois sur les suggestions de saisie et dans la modale d'imputation, y compris lorsqu'elle s'affiche dans une iframe Tempo.

HubSpot Monitor

Repère les workflows désactivés parmi ceux que vous surveillez et propose de créer un ticket Jira en un clic pour chacun. Utile quand une partie de la chaîne commerciale dépend d'automatisations qui s'arrêtent silencieusement. Nécessite un jeton HubSpot (scope automation).

L'API HubSpot ne publie pas d'état d'erreur d'exécution : le signal exploitable est l'activation du workflow. La surveillance périodique ne tourne que lorsque le module est ouvert.

Améliorations directes dans les pages Jira

Certains modules n'ont pas d'écran dans le hub : ils enrichissent discrètement les pages de Jira. Ils s'activent et se désactivent comme les autres, depuis les Paramètres modules.

Confidentialité et données

Dépannage

L'entrée « Administration addon » n'apparaît pas / disparaît après un rechargement

C'est le cas le plus fréquent, et il concerne Firefox : les extensions n'ont pas automatiquement accès aux sites. Clic droit sur l'icône de l'extension → « Toujours autoriser sur … », ou about:addons → l'extension → onglet Permissions → autoriser l'accès au domaine atlassian.net. Sans cette autorisation, l'extension ne s'exécute que sur l'onglet où vous venez de cliquer sur son icône, et l'effet disparaît au rechargement de la page.

Un module affiche « aucun board / aucune équipe »

Vérifiez les réglages du module (roue crantée dans Paramètres modules) : clé de projet, board associé, équipe sélectionnée. Les listes de boards et d'étiquettes sont mises en cache environ 30 minutes ; le bouton de rafraîchissement force le rechargement.

Une action en masse rapporte des échecs

Les opérations sont indépendantes : un échec n'interrompt pas les autres. La cause habituelle est une permission manquante sur le projet concerné (gérer les observateurs, modifier un ticket, appliquer une transition), ou une transition inexistante depuis le statut courant.

Après une mise à jour, un module se comporte étrangement

Rechargez la page Jira (Ctrl/Cmd+Shift+R). Si le problème persiste, désactivez puis réactivez le module dans les Paramètres modules.

Et une dernière chose…

L'extension contient un easter egg. Il s'active avec le code Konami : ↑ ↑ ↓ ↓ ← → ← → B A, tapé sur une page Jira (hors champ de saisie).

Jira passe alors en rose à paillettes. Les effets animés (paillettes qui s'accumulent en bas de l'écran, licornes et nounours géants qui traversent la page, messages qui défilent) ne se déclenchent qu'après 45 secondes d'inactivité — de quoi rester présentable en réunion, et surprendre au retour de la pause déjeuner. Le même code désactive le mode.