Dans mon précédent article, je présentais le Target Operating Model (TOM) comme l’outil stratégique permettant d’aligner une organisation autour de ses flux de valeur, de ses rôles et de ses mécanismes de pilotage.
Un TOM bien construit clarifie qui fait quoi, sur quoi, selon quel flux de décision et avec quel niveau d’autonomie.
Mais lorsqu’on passe à l’opérationnel, un problème majeur apparaît systématiquement : Comment traduire ce modèle opérationnel propre, conceptuellement clair, dans les outils du quotidien ?
Et surtout, comment produire des KPI fiables, cohérents, non manipulables, qui reflètent réellement la santé du delivery, la capacité des équipes, le pilotage des engagements et le respect des flux de valeur définis dans le TOM ?
Ou comment éviter les indicateurs « pastèques », verts à l’extérieur mais rouges à l’intérieur ?
C’est là que l’articulation TOM + Jira devient critique. C’est la dernière pièce manquante de la transformation agile soit faire en sorte que les outils reflètent la réalité de l’organisation.
Cet article explore comment TOM + Jira constituent le chaînon manquant entre transformation et pilotage.
Nous verrons pourquoi le TOM prépare le terrain, comment Jira cristallise les flux opérationnels. Et surtout comment cette combinaison permet enfin de produire des indicateurs fiables, continus et cohérents à l’échelle d’une organisation.
Pourquoi les KPI agiles sont presque toujours faux
Avant de construire une transformation, il faut comprendre la faille systémique. Et cette faille n’est pas technique mais organisationnelle.
Dans la plupart des organisations, Jira est utilisé comme un outil de tickets.
Les équipes créent leurs propres workflows, leurs champs, leurs boards, leurs définitions du terminé (Definition of Done).
Les managers demandent du reporting qui varie d’un service à l’autre.
Les dépendances se perdent.
Les types de travaux se mélangent.
Les consommateurs de données (directeurs, PMO, comex) reçoivent des dashboards Power BI qui semblent précis mais qui reposent sur des données structurellement fausses.
Et lorsque l’organisation veut en tirer des KPI fiables comme lead time, débit (throughput), time to market, capacité, prédictibilité, taux d’adhérence au plan, elle découvre :
- Que deux équipes ne mesurent pas la même chose derrière un même mot.
- Que les workflows n’ont pas les mêmes étapes.
- Que les backlogs n’ont pas la même structure.
- Que ce qui est mesuré comme "valeur" dans une équipe n’a aucun rapport avec la valeur de la voisine.
- Que les dépendances ne sont jamais modélisées proprement.
Jira ne peut pas résoudre un problème d’organisation mais ne peut que refléter ce qui existe.
C’est ici que le TOM intervient car il définit :
- le modèle opérationnel cible,
- les flux,
- les rôles,
- les interactions,
- le vocabulaire,
- la granularité,
- et les règles.
Jira ne fait ensuite que les implémenter.
Rappel sur le rôle du TOM dans une transformation agile
On ne peut pas parler de KPI sans rappeler brièvement la logique du TOM (Target Operating Model) et pourquoi il est indispensable.
Dans mon article précédent, j’expliquais que le TOM apporte le squelette de l'organisation, soit :
- La structure,
- les rôles,
- les responsabilités,
- les interactions,
- la gouvernance,
- la circulation de la valeur,
- la synchronisation,
- et les mécanismes de pilotage.
Le TOM répond à des questions que Jira ne peut pas inventer :
- Qu’est-ce qu’un flux de valeur et comment circule-t-il réellement ?
- Quels sont les rôles qui créent de la valeur, ceux qui arbitrent et ceux qui tranchent ?
- Comment se structure un backlog produit ? Un backlog transverse ?
- Quelle est la granularité des items à chaque niveau ?
- Comment les dépendances sont-elles identifiées, représentées et suivies ?
- Quels sont les points de synchronisation obligatoires ?
- Qui est responsable de quelle donnée ?
- Quelle est la source de vérité ?
- Qu’entend-on exactement par "KPI" ?
Tant que ces éléments ne sont pas clarifiés, il est impossible de configurer Jira correctement. Et encore moins crédible d’en tirer un pilotage.
Le TOM structure l’organisation. Jira capte l’activité réelle exactement selon ce modèle.
C’est la jonction entre les deux qui produit enfin des indicateurs cohérents, comparables, transverses, utiles au pilotage et surtout crédibles.
En bref, le TOM est la théorie, Jira est son exécution observable et les KPI sont la synthèse des deux.
Pourquoi Jira devient fiable uniquement lorsqu’il reflète le TOM
Dans les transformations agiles, l’une des erreurs les plus courantes est de vouloir configurer Jira avant d’avoir clarifié le fonctionnement cible.
Les équipes passent des semaines à débattre de champs personnalisés, de types de tickets, de workflows supposés optimiser la fluidité alors que la question fondamentale n’est jamais posée : que voulons-nous mesurer et surtout pourquoi ?
Le TOM répond à cette question et Jira l’exécute.
Lorsque le TOM est correctement traduit dans Jira, les KPI cessent d’être des interprétations arbitraires et deviennent une mesure fidèle du fonctionnement réel de l’organisation.
La vitesse devient la vitesse d’un produit et non plus la somme bancale de trois équipes qui ont parfois peu en commun.
L’avancement transverse cesse de dépendre du bon vouloir de chaque squad et devient un flux mesuré objectivement.
Les engagements deviennent comparables, les temps de cycle deviennent interprétables, les dépendances cessent de disparaître entre les mailles du filet.
En réalité, Jira n’est pas qu’un outil de gestion de tickets, mais c’est un véritable capteur de l’organisation :
- S’il capte un TOM cohérent, il restitue des KPI cohérents.
- S’il capte une organisation incohérente, il en restitue toutes les contradictions.
Comment TOM + Jira transforment le pilotage opérationnel et stratégique
Quand un TOM clair est associé à un Jira configuré pour le refléter, l’organisation observe un basculement presque immédiat dans son pilotage.
Les directions obtiennent pour la première fois une vision stable de leurs flux.
Les équipes voient enfin l’impact de leurs arbitrages.
Les Product Managers disposent d’indicateurs qui reflètent réellement la capacité de leur tribu.
Les responsables transverses identifient plus rapidement les dépendances et peuvent arbitrer en connaissance de cause.
Les KPI ne sont plus des chiffres isolés, mais des éléments d’un récit opérationnel cohérent, capable d’expliquer :
- où va l’organisation,
- quel est son rythme,
- comment les priorités impactent la capacité,
- et quelles décisions augmentent ou diminuent la vitesse globale.
Jira devient la manifestation concrète du TOM.
Le pilotage cesse d’être un reporting. Il devient une lecture directe du fonctionnement de l’organisation.
Les KPI ne sont plus des artefacts produits en fin de mois, mais des signaux vivants qui reflètent en temps réel la santé de l’écosystème.
Cas pratique : TOM et Jira dans un service DSI
Voyons maintenant tout cela dans un cas pratique concret.
Dans l'une de mes précédentes expériences, je suis arrivé dans un service DSI qui souffrait d’un paradoxe courant :
- Un usage intensif de Jira,
- des dizaines de dashboards (compréhensibles seulement par le responsable),
- des centaines de tickets
- mais aucune donnée permettant de piloter la transformation.
Les équipes considéraient Jira comme un outil de suivi local (voire de flicage), plutôt que comme un système d’information opérationnel.
Le TOM, quant à lui, était inexistant ou réduit à quelques diagrammes PowerPoint réservés à "l’élite".
1) Clarifier la chaîne de valeur avant de toucher à Jira
La première étape a été de clarifier la chaîne de valeur, soit :
- Ce que l’entité produisait réellement,
- comment elle le produisait,
- quelles équipes y contribuaient,
- et selon quelles interactions.
Ce travail a été mené produit par produit, mais aussi par grands flux transverses (data, sécurité, plateforme, conformité, architecture).
Une fois ces flux identifiés, nous avons redéfini :
- Les responsabilités,
- les rôles,
- les décisions attendues,
- et les moments où la synchronisation était indispensable.
L’objectif était de révéler les zones où la coordination échouait.
2) Trois problèmes structurels qui rendaient les KPI inutilisables
Ce travail de clarification a rapidement mis en évidence trois problèmes majeurs qui rendaient toute tentative de pilotage illusoire :
- Les tickets Jira n’étaient pas alignés avec la chaîne de valeur réelle.
- Les équipes créaient leurs propres types de tickets, leurs propres définitions de « terminé » (Definition of Done), leurs propres workflows.
- Et enfin, les managers consolidaient manuellement des données issues de tableaux Excel mis à jour à la main.
La simple mesure du lead time variait d’un facteur de un à cinq en fonction de l’équipe qui l’avait produit (début de l’Epic ou de la User Story comme point de départ…).
3) Structurer Jira à partir du TOM
Nous avons donc décidé de structurer Jira autour du TOM.
Le premier changement a été de créer un modèle unique de représentation du travail : un workflow commun par type de flux.
Il s’agissait de garantir qu’à travail identique on ait des données identiques.
Un ticket de Feature dans un flux applicatif comme dans un flux transverse devait permettre de tracer les mêmes informations.
Un ticket n’était plus un artefact local, mais un élément du flux de valeur modélisé dans le TOM.
Nous avons également normalisé la structure des projets Jira, en posant quelques règles simples mais non négociables.
Cette étape a été l’une des plus sensibles politiquement.
4) Résistances, arbitrages et ce qui n’a pas marché du premier coup
Cette mise en cohérence a néanmoins :
- impliqué des arbitrages difficiles,
- rencontré des résistances managériales,
- nécessité plusieurs itérations avant d’obtenir des données réellement exploitables.
Certaines équipes ont initialement vécu la standardisation comme une perte d’autonomie.
Des managers ont exprimé la crainte de « perdre leur reporting spécifique », ou leur capacité à présenter la situation sous un angle favorable.
Le PMO, de son côté, était inquiet de voir disparaître certains indicateurs historiques au profit de métriques plus simples mais plus exigeantes.
Tout n’a pas fonctionné du premier coup.
Les premiers workflows définis étaient trop fins et ont ralenti inutilement le flux.
Certains champs obligatoires ont été supprimés après quelques semaines, car ils n’apportaient pas la valeur attendue.
La modélisation initiale des dépendances s’est révélée trop lourde, et a dû être simplifiée pour rester utilisée dans la durée.
5) Quand Jira reflète enfin la réalité
Progressivement, les informations remontées par Jira ont commencé à reproduire fidèlement le fonctionnement réel décrit dans le TOM.
Les points de blocage observés dans la vraie vie se matérialisaient enfin dans les métriques.
Les dépendances entre squads, auparavant invisibles, réapparaissaient dans les temps d’attente.
Les zones où le management intervenait de manière intempestive se révélaient dans les ruptures de cadence.
Les segments de flux sous-dimensionnés étaient visibles dans les files d’attente.
En moins de deux mois, le dashboard Jira était devenu un instrument de pilotage.
Non pas grâce à un plugin miracle, mais grâce à la cohérence entre le modèle opérationnel (TOM) et l’outil opérationnel (Jira).
Tableau de synthèse
Ce tableau reprend les éléments clés de la démarche, en montrant à chaque fois
- ce qui se passe lorsqu’on n’a pas de TOM,
- ce que Jira produit dans ce contexte,
- et ce qui change lorsque TOM et Jira sont alignés.
Élément clé | Sans TOM (situation initiale) | Avec TOM seul | Avec TOM + Jira aligné | Résultat sur les KPI |
|---|---|---|---|---|
Structure des flux | Floue, variable, dépendante des individus | Clarifiée conceptuellement | Modélisée dans Jira avec des workflows cohérents | KPI lisibles par flux et comparables |
Définition du travail | Hétérogène, chaque équipe invente | Standardisée au niveau conceptuel | Implémentée sous forme de types de tickets unifiés | Lead time, cycle time, throughput enfin exploitables |
Gestion des dépendances | Invisible, gérée à l’oral | Identifiée dans le TOM | Visible dans Jira grâce aux liens inter-flux | Dépendances pilotées plutôt que subies |
Gouvernance | Basée sur l'urgence et les relations personnelles | Redéfinie dans le TOM | Matérialisée dans les statuts, rôles et champs Jira | KPI liés à la prise de décision, pas au bruit organisationnel |
Pilotage transverse | Tableau Excel bricolé | Cadence définie mais théorique | Données fiables consolidées automatiquement | Roadmaps fiables et pilotage prévisible |
Conclusion
L’alignement entre un Target Operating Model et Jira ne se limite pas à produire des KPI fiables, mais il transforme la façon dont l’organisation pense son pilotage.
Il crée une visibilité transverse qui révèle les goulets d’étranglement, clarifie les priorités et expose les points de friction invisibles jusqu’alors.
Cette approche permet non seulement de mesurer, mais également de comprendre et d’anticiper l’impact des décisions sur les flux de valeur.
Les indicateurs deviennent des leviers d’action et non des témoins passifs.
Pour autant, cette articulation n’est ni automatique ni neutre. Sans sponsoring clair, sans règles d’usage explicites et sans gouvernance des indicateurs, TOM + Jira peut au contraire renforcer des illusions de pilotage.
Des chiffres cohérents sur le papier peuvent masquer des arbitrages non assumés, des décisions contournées ou une absence de responsabilité réelle sur les flux.
C’est précisément là que se joue la maturité d’une transformation agile.
Non pas dans l’outil, ni dans les métriques, mais dans la capacité de l’organisation à accepter ce que les indicateurs révèlent et à agir en conséquence.
Le TOM fixe le cadre de lecture, Jira enregistre les faits. Le pilotage commence lorsque l’on accepte que les deux soient alignés et que les décisions suivent.
