Mes outils de pilotage
Les tableaux de bord Jira et les pages Confluence que je construis pour piloter une équipe, une recette ou un programme. Chaque planche montre l'écran, explique comment il est construit et donne la requête JQL utilisée.
Reproductions à partir de mes propres écrans : les noms de projets, d'équipes et de personnes ont été remplacés, les intitulés de tickets réécrits, et certaines données sont illustratives.
Planche 1
Le cockpit du matin
Le premier écran que j'ouvre chaque jour : va-t-on tenir le sprint, et quoi débloquer aujourd'hui.
Tableaux de bord
Cockpit Scrum Master
Projet GED · Sprint 9 · 29 tickets au démarrage, 11 ajoutés en cours de sprint
0
jour restant · fin de sprint
- En cours7 En cours
- En test4 Test
- En review1 Review
- Pas démarrés2 À faire
- GED-104 En attente d'arbitrage métierBloqué
- GED-105 Accès à l'environnement de recetteBloqué
- GED-106 Dépôt impossible au-delà de 20 MoHighest
- GED-107 Tri incorrect dans les résultatsHigh
- GED-108 Circuit de signature : relancesTest
- GED-109 Export de synthèseReview
Comment c'est construit
Tableau de bord Jira personnel (gadgets natifs)
- Ligne du haut, lecture en 5 secondes : jours restants, santé du sprint, burndown.
- Ligne du bas, ce sur quoi agir : reste à faire, tickets bloqués, bugs prioritaires ouverts, tickets immobiles.
- Chaque liste est un gadget « Résultats du filtre » branché sur un filtre JQL enregistré.
- Données du sprint présenté : 65 % et +38 % calculés en nombre de tickets à partir du bilan du sprint ; le gadget Jira calcule selon la statistique d'estimation du board.
Ce que ça a permis
Préparer le daily avec les bons sujets, et lever une alerte avant le comité quand le périmètre gonfle en cours de sprint.
Requêtes JQL
Reste à faire du sprint
project = GED AND sprint in openSprints() AND statusCategory != Done ORDER BY status ASCTickets bloqués
project = GED AND sprint in openSprints() AND labels = BLOQUEBugs prioritaires ouverts
project = GED AND issuetype = Bug AND priority in (Highest, High) AND statusCategory != Done ORDER BY priority DESCTickets immobiles depuis plus de 3 jours
project = GED AND sprint in openSprints() AND statusCategory = "In Progress" AND updated < -3dPlanche 2
Lire le flux colonne par colonne
Où les tickets s'accumulent-ils ? Review, Test : la donnée montre le goulot avant qu'on le ressente.
Pilotage GED / Rétrospectives
Analyse des données : sprints 6 à 9
Diagramme de flux cumulé du board, puis lecture colonne par colonne
Diagramme de flux cumulé · sprints 6 à 9
Lecture en rétrospective : nombre moyen de tickets présents dans la colonne
Sprint 6
Sprint 7
Sprint 8
Sprint 9
Review
8
5,3
1,25
2
Test
3
11
5
4,3
Forte accumulation en Review, livraisons groupées en fin de sprint.
Review allégée, mais le stock se déplace en Test.
Flux continu, livraison dès le début du sprint.
Pics ponctuels en Review, stock de recette à purger.
Comment c'est construit
Diagramme de flux cumulé Jira (rapport natif du board), puis lecture colonne par colonne en rétrospective
- Diagramme de flux cumulé : une bande par colonne du board. Une bande qui s'épaissit signale un goulot ; la pente de Terminé donne le débit.
- Lecture : à l'horizontale, le lead time (de l'arrivée dans le backlog à la fin) et le cycle time (du démarrage à la fin) ; à la verticale, le WIP (travail en cours) et le backlog (travail en attente).
- Rapport « Diagramme de flux cumulé » du board, une colonne affichée à la fois (Review, puis Test).
- Une ligne de moyenne posée sur chaque graphique, puis un sprint par colonne pour comparer.
- La lecture est écrite sous chaque sprint et sert de point de départ à la rétrospective.
Ce que ça a permis
Limite de WIP posée sur les colonnes Review et Test, âge des tickets affiché sur le board, atelier de simplification du workflow.
Planche 3
WIP, débit, temps de cycle
Trois courbes pour lire le flux de l'équipe : moins de travail en parallèle, des livraisons plus rapides.
Pilotage GED / Rétrospectives
Suivi du flux : sprints 6 à 11
Nombre moyen de tickets démarrés mais pas encore terminés : le travail mené en parallèle.
Nombre de tickets terminés par jour : la vitesse de livraison de l'équipe.
Nombre de jours entre le démarrage d'un ticket et sa fin : le délai vu par le métier.
Comment c'est construit
Graphique de contrôle Jira pour le temps de cycle, puis page Confluence de rétrospective (macro Graphique alimentée par un tableau)
- Le temps de cycle est mesuré dans le graphique de contrôle Jira, en ne retenant que les colonnes de En cours à Terminé ; le même graphique donne le temps passé dans chaque étape.
- Le WIP et le débit sont relevés à chaque fin de sprint, puis les trois indicateurs sont saisis dans un tableau Confluence.
- La macro Graphique transforme le tableau en courbes, une par indicateur.
Ce que ça a permis
Le WIP est devenu le premier levier discuté en rétrospective : quand il remonte, l'équipe sait que le temps de cycle va suivre.
Planche 4
Engagé contre réalisé sur 19 sprints
La vélocité ne sert pas à juger l'équipe, elle sert à dire ce qui tient dans le prochain sprint.
Projets / Programme GED / Rapports
Graphique de vélocité
Vélocité moyenne : 77,6 story points
Comment c'est construit
Rapport de vélocité Jira (natif, story points)
- Rapport natif du board Scrum : en gris l'engagement en début de sprint, en vert ce qui est réellement terminé.
- Estimation du board réglée sur les story points, sprints clôturés systématiquement.
- Vélocité moyenne relevée : 77,6 points.
Ce que ça a permis
Calibrer l'engagement sur la vélocité réelle plutôt que sur la demande, et rendre visibles les sprints où l'engagement a dérivé.
Planche 5
Piloter une recette dans Confluence
Une page unique pour la recette : le compte à rebours, l'état des bugs, et qui doit retester quoi.
Pilotage GED / Release / Version 1.1
Recette Version 1.1
Canal de discussion : équipe projet recette
- Backlog = 7
- À faire = 4
- Pending = 1
- Frozen = 1
- Review = 1
- En cours = 1
Nombre total de tickets : 15 · Type de statistique : État
6
jours restants
| Clé | Résumé | État |
|---|---|---|
| GED-310 | Tri par date inversé dans la liste des documents | Backlog |
| GED-311 | Pièce jointe non affichée en prévisualisation | Backlog |
| GED-312 | Notification de validation envoyée en double | À faire |
| GED-313 | Filtre par auteur sans effet | En cours |
| GED-314 | Libellé tronqué dans l'écran de dépôt | Frozen |
| GED-315 | Bouton « Archiver » actif sans les droits | À faire |
| GED-316 | Pagination bloquée au-delà de 50 résultats | Backlog |
| GED-317 | Date de révision non mise à jour | Backlog |
| GED-318 | Doublon créé lors d'un dépôt simultané | Backlog |
| GED-319 | Export PDF sans en-tête | À faire |
| GED-320 | Recherche sensible aux accents | Backlog |
| GED-321 | Info-bulle vide sur l'icône de statut | Backlog |
| GED-290 | Service émetteur vide après migration | Pending |
| GED-291 | Versions antérieures non reprises | À faire |
| GED-292 | Dates de création décalées d'un jour | Review |
| GED-293 | Liens entre documents perdus | Deploying |
| GED-294 | Droits d'accès hérités incorrects | Deploying |
Aucune demande trouvée.
Aucune demande trouvée.
Comment c'est construit
Page Confluence, macros Jira (liste de tickets) et Graphique Jira (camembert)
- Camembert des statuts des tickets de recette, compteur de jours restants.
- Une liste par origine de bug : applicatif, reprise de données, recette utilisateur.
- Circuit de correction piloté par labels : un correctif à tester côté MOA reçoit le label TEST_MOA ; s'il échoue, il reçoit RETOUR et repart en colonne To Do.
Ce que ça a permis
Arriver au Go / No-Go avec une liste exacte de ce qui reste ouvert, par origine, et un circuit de retest sans perte.
Requêtes JQL
Bugs applicatifs majeurs ou bloquants
project = GED AND issuetype = Bug AND priority in (Highest, High) AND labels != GED_RDD AND statusCategory != DoneBugs de reprise de données
project = GED AND issuetype = Bug AND labels = GED_RDD AND statusCategory != DoneCorrectifs à tester côté MOA
project = GED AND issuetype = Bug AND labels = TEST_MOA AND statusCategory != DonePlanche 6
Reporting de version et périmètre gelé
245 tickets, leur nature, leur état, ce qui attend une décision métier, et ce qui est arrivé après le gel.
Pilotage GED / Suivi des sprints
Reporting Version 1.2
- Bogue = 89
- Story = 78
- Enabler = 58
- Tâche = 17
- Incident = 2
Nombre total de tickets : 245 · Type de statistique : Type de ticket
Total : 245 tickets
| GED-400 | Règle d'affichage d'une fiche à confirmer | Unité A |
| GED-401 | Durée de conservation par type de document | Socle |
| GED-402 | Format attendu de l'export de synthèse | Socle |
| GED-403 | Classement automatique : règles à arbitrer | Unité A |
| GED-404 | Liste des métadonnées obligatoires | Socle |
| GED-405 | Périmètre des documents confidentiels | Socle |
| GED-406 | Circuit de validation à deux niveaux | Socle |
| GED-407 | Vocabulaire des statuts documentaires | Socle |
| GED-408 | Champs du formulaire de dépôt à figer | Unité B |
| GED-409 | Profils d'accès pour le déploiement | Unité B |
| GED-410 | Dossiers en cours au moment de la bascule | Unité B |
| Clé | Résumé | Créé |
|---|---|---|
| GED-450 | Ajout d'un critère de tri dans la recherche Unité B | 08/09 |
| GED-451 | Export des résultats au format tableur Socle | 12/09 |
| GED-452 | Nouveau champ obligatoire sur le formulaire de dépôt Unité A | 19/09 |
Comment c'est construit
Page Confluence, macros Graphique Jira, Statistiques de filtre et liste de tickets
- Camembert par type de ticket sur toute la version.
- Statistiques de filtre sur la résolution : la part réellement terminée.
- Liste des besoins bloqués en attente de clarification métier, avec le lot concerné.
- Liste des besoins créés après la date de gel : chacun est porté en comité pour décider s'il entre dans la version ou s'il est reporté.
Ce que ça a permis
Tenir le périmètre gelé : tout besoin arrivé après le gel est visible et arbitré en comité, au même titre que les points qui attendent une décision métier.
Requêtes JQL
Périmètre de la version
project = GED AND fixVersion = "V1.2"Besoins en attente de clarification métier
project = GED AND fixVersion = "V1.2" AND labels = ATTENTE_MOA AND statusCategory != DoneNouveaux besoins après le gel
project = GED AND fixVersion = "V1.2" AND created > "2026-09-01"Planche 7
Un portefeuille pilotable dans Big Picture
Du backlog fourre-tout à un portefeuille à plusieurs niveaux : chaque epic a un vrai pourcentage d'avancement et une place dans le planning.
Programmes / PROG-1 IN PROGRESS
Programme GED
| Clé | Résumé | Statut | Avancement | janv.févr.marsavr.maijuinjuil.août |
|---|---|---|---|---|
| GED-10 | ⌄ Socle : lot MVP | Done | | |
| GED-11 | › Authentification unique | Done | | |
| GED-12 | › Consultation | Done | | |
| GED-13 | ⌄ Cycle de vie | Done | | |
| GED-131 | Définir le valideur par défaut | Done | | |
| GED-132 | Notifier le valideur suivant | Done | | |
| GED-133 | Gérer l'absence d'un valideur | Done | | |
| GED-134 | Archiver les versions remplacées | Done | | |
| GED-135 | Statut non mis à jour après un rejet | Done | | |
| GED-14 | › Recherche | Done | | |
| GED-15 | › Accessibilité | Done | | |
| GED-20 | ⌄ Unité A : lot MVP | In Progress | | |
| GED-21 | › Plan de classement | Done | | |
| GED-22 | › Circuit de signature | Done | | |
| GED-23 | › Tableau de bord | In Progress | | |
| GED-24 | › Reprise de données | In Progress | | |
| GED-30 | › Unité B : lot MVP | In Progress | | |
| GED-40 | › Unité C : lot MVP | To Do | | |
| GED-50 | › Dette technique | In Progress | | |
Comment c'est construit
Big Picture (module de gestion de portefeuille pour Jira), vue d'ensemble avec Gantt
- Hiérarchie à trois niveaux : une epic par unité (plus le socle commun), des features par grand domaine applicatif et pour la reprise de données, puis les stories et les bugs.
- Le travail déjà réalisé a été recomposé dans cette structure, et l'équipe technique a estimé tous les tickets non estimés pour obtenir un macro-chiffrage.
- Big Picture calcule l'avancement de chaque niveau à partir de ses tickets enfants.
- Le Gantt place chaque epic et chaque feature dans le temps, pour vérifier que tout rentre.
Ce que ça a permis
Une epic par unité avec un vrai pourcentage d'avancement, et un planning qui montre ce qui rentre ou non : on passe de la réaction à l'anticipation.
Planche 8
Atelier story mapping : faire exprimer, puis prioriser
Le responsable métier voulait des fonctionnalités avancées pour la prochaine unité. Plutôt que d'opposer mon avis au sien, je lui ai proposé de poser lui-même ses besoins sur la carte.
Pilotage GED / Ateliers
Story mapping : unité suivante
Atelier avec le responsable métier et son équipe
Paquet P0 →
Paquet P1 →
Paquet P2 →
Comment c'est construit
Atelier collaboratif sur tableau blanc, avec le responsable métier et son équipe
- En haut, à l'horizontale : les grandes activités des utilisateurs, dans l'ordre où ils les font.
- Sous chaque activité, le métier pose ses fonctionnalités et distingue lui-même le socle (déjà livré ailleurs, coût connu) des demandes avancées.
- Les fonctionnalités sont ensuite rangées par priorité, du haut vers le bas : P0 indispensable à la bascule, P1 attendu au démarrage, P2 peut attendre.
- Chaque ligne de priorité forme un paquet, qui part directement dans l'atelier d'extreme quotation.
Ce que ça a permis
Le métier exprime tout ce qu'il veut, mais c'est lui qui classe : les paquets P0, P1 et P2 sont les siens, pas les miens.
Planche 9
Atelier extreme quotation : chiffrer par comparaison
Chaque paquet est chiffré en le comparant à des features déjà livrées, puis posé face à la capacité réelle de l'équipe. Le constat vient du métier, pas de moi.
Pilotage GED / Ateliers
Extreme quotation : unité suivante
Dans la foulée du story mapping, avec le même groupe
Le tableau d'estimation : suite de Fibonacci × 10
1. Chaque feature comparée à l'étalon
| Feature | P0 | P1 | P0 + P1 | vs circuit (50) |
|---|---|---|---|---|
| Déposer | 20 | 30 | 50 | = autant |
| Rechercher | 20 | 50 | 70 | > plus |
| Valider | 30 | 50 | 80 | > plus |
| Diffuser | 10 | 20 | 30 | < moins |
| Archiver | 20 | 30 | 50 | = autant |
| Piloter | - | 30 | 30 | < moins |
| Total | 100 | 210 | 310 | P2 : 150 pts |
2. Face à la capacité
Capacité = vélocité moyenne de 77,6 pts × 3 sprints.
Les P0 tiennent (100 pts). P0 + P1 dépasse de 77 pts. Tout le demandé : 460 pts.
Comment c'est construit
Atelier collaboratif sur tableau blanc, dans la foulée du story mapping
- Un tableau en colonnes suivant la suite de Fibonacci × 10 (10, 20, 30, 50, 80, 130, 210) : les écarts grandissent avec la taille, comme l'incertitude.
- Sur la première ligne, les features de référence déjà livrées, posées dans la colonne de leur poids réel.
- Sur la ligne suivante, chaque feature de l'unité est posée deux fois, son P0 et son P1, chacun dans la colonne de la référence qui lui ressemble le plus.
- Feature par feature, son P0 et son P1 sont comparés à ces références : « plus qu'un circuit de signature », « autant », « moins ». Pas d'estimation story par story.
- À droite, la capacité de l'équipe sur la fenêtre : la vélocité moyenne mesurée multipliée par le nombre de sprints disponibles.
- On empile les paquets dans l'ordre de priorité jusqu'à la ligne de capacité : ce qui dépasse se voit immédiatement.
Ce que ça a permis
Le responsable métier a constaté lui-même que tout ne rentrait pas : P0 embarqué, P1 arbitré, P2 reporté. S'en sont suivis des ateliers de risques et une replanification.
Planche 10
Une roadmap multi-unités sur un an
Développement, conduite du changement et reprise de données, unité par unité, avec les jalons qui comptent.
Pilotage GED / Pilotage
Roadmap du programme
Diagramme draw.io
Comment c'est construit
Diagramme draw.io, créé et affiché dans Confluence grâce à l'application draw.io (module de la marketplace Atlassian)
- Le diagramme est dessiné dans l'éditeur draw.io, ouvert directement depuis la page Confluence ; la macro draw.io l'affiche ensuite dans la page, où l'équipe peut le consulter et le mettre à jour.
- Un couloir par unité, trois lignes par couloir : développement, reprise de données, conduite du changement.
- Développement, puis recette finale avec les utilisateurs, puis correctifs majeurs avant la mise en production.
- Les durées varient selon l'unité : une unité qui reprend le natif avec quelques ajustements va vite, une unité très sur-mesure demande un développement et des correctifs plus longs.
- Trois types de jalons : version figée, mise en production sans ouverture de service, ouverture de service.
- La conduite du changement suit le même calendrier : plan d'accompagnement, préparation des supports, formations juste avant l'ouverture.
Ce que ça a permis
Montrer d'un coup d'œil les dépendances entre version figée, reprise de données et formation, et arbitrer l'ordre de bascule des unités.
Planche 11
Des boards Jira configurés pour piloter
Un board de sprint outillé pour le daily, et un board de préparation qui amène chaque ticket jusqu'à « prêt pour sprint ».
Projets / GED / Board
GED Sprint 9
Workflow simplifié à 5 colonnes · fin de sprint
À FAIRE 2
EN COURS 7
REVIEW 1 Max 6
TEST 4 Max 6
TERMINÉ 26
Projets / GED / Board
Préparation du backlog
Board Kanban de la PO · un statut par étape de préparation
EN RÉDACTION
La PO rédige le ticket
RELECTURE TECH LEAD
Relecture technique
TRES AMIGOS
À valider à trois
PRÊT POUR AFFINAGE
À présenter à l'équipe
PRÊT POUR SPRINT
Validé en affinage
Comment c'est construit
Configuration de board Jira : workflow, colonnes, filtres rapides
- Board de sprint : un workflow simple à 5 colonnes (À faire, En cours, Review, Test, Terminé), avec des filtres rapides pour le daily.
- Limites de WIP posées sur les colonnes Review et Test (contrainte « nombre de tickets » dans la configuration des colonnes) : la colonne passe en rouge dès que la limite est dépassée.
- Board de préparation : un board Kanban dédié à la PO, avec son propre workflow en 5 étapes, une colonne par statut.
- Le ticket est rédigé par la PO, relu par le tech lead, validé en Tres Amigos (métier, développement, test), puis présenté à toute l'équipe en affinage.
- Seuls les tickets validés en affinage passent en « Prêt pour sprint » : c'est la définition de prêt rendue visible.
Ce que ça a permis
Un daily centré sur ce qui bloque, et des sprints qui ne démarrent qu'avec des tickets compris, relus et validés par toute l'équipe.
Requêtes JQL
Filtre rapide : bug bloquant
issuetype = Bogue AND "Criticité" = BloquantFiltre rapide : ticket immobile
updated < "-3d"Filtre du board de préparation
project = GED AND status in ("En rédaction", "Relecture tech lead", "Tres Amigos", "Prêt pour affinage", "Prêt pour sprint") ORDER BY Rank ASCPlanche 12
Mises en production et gestion de crise
Un pipeline de mise en production qui se met à jour seul, et une page de crise qui dit quand on en sort.
Pilotage PRJ / Release
Suivi des mises en production
- MEP 1
- MEP 2
- MEP 3
Chaque MEP est une sous-page ; la liste se met à jour seule.
11
US candidates10
bugs candidatsAucune demande trouvée. Un sujet y bascule seul dès que la date de MEP est ajoutée dans son fixVersion.
Pilotage GED / Release
Pilotage de la situation de crise
Page co-construite
Après une montée de version de la préproduction, les temps de réponse s'effondrent et le dépôt de documents échoue : la recette utilisateurs est suspendue.
Objectifs : relancer la recette au plus vite, sécuriser la date de mise en service, éviter que l'incident se reproduise.
| Action | Statut | Suivi |
|---|---|---|
| Diagnostiquer | Terminé | Base de données saturée après la montée de version : un paramètre de connexion n'avait pas été reporté. |
| Rétablir le service | Terminé | Paramètre corrigé, files de traitement purgées, recette relancée sur un périmètre réduit. |
| Stabiliser | En cours | Test de charge pour confirmer la correction, contrôle ajouté à la procédure de montée de version. |
Conditions de sortie de crise
Cause identifiée✓
Recette relancée✓
Test de charge concluant✗
Comment c'est construit
Pages Confluence : macro Affichage enfant, macros Jira, tableau de suivi
- Suivi des MEP : chaque MEP est une sous-page, listée automatiquement par la macro Affichage enfant.
- Un sujet candidat devient sélectionné quand on ajoute la date de MEP dans le champ fixVersion, en plus du numéro de PI : il bascule seul d'une liste à l'autre.
- Page de crise (co-construite) : constat, analyse, objectifs, plan d'actions avec porteur et statut, critères de sortie de crise.
Ce que ça a permis
Une release note toujours à jour sans saisie manuelle, et une sortie de crise décidée sur des critères explicites, pas sur une impression.
Requêtes JQL
Sujets candidats à la prochaine MEP
project = PRJ AND status = "READY TO MEP" AND type in (Story, Task, TMA) AND fixVersion = "PI 1"Release note : stories livrées sur le PI
project = PRJ AND fixVersion = "PI 1" AND issuetype in (Story, Task) AND status in ("Ready to MEP", Done)Sujets d'une MEP
project = PRJ AND status = Done AND type in (Story, Bogue, TMA) AND fixVersion = "MEP 2024-S50"