Workflow Jira pour le développement logiciel : configuration, exemples et bonnes pratiques en 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Un workflow Jira pour le développement logiciel est le chemin que suit chaque story, chaque bug et chaque tâche, de l’idée à la production. Quand ce chemin correspond à la façon dont votre équipe travaille réellement, le tableau devient une image fiable de la livraison : chacun voit ce qui est bloqué, ce qui attend une revue et ce qui est prêt à partir. Dans le cas contraire, les développeurs passent leur temps à déplacer des cartes, les managers courent après les mises à jour de statut et les rapports n’apportent rien d’utile.

La plupart des projets Jira que nous reprenons chez nos clients souffrent du second problème. Les workflows s’enrichissent d’un statut après l’autre jusqu’à ce que plus personne ne sache les expliquer, et un même type de ticket se comporte différemment d’une équipe à l’autre. Lorsque nous prenons en charge la livraison dans le cadre de nos équipes de product engineering managées, assainir le workflow Jira de développement logiciel fait généralement partie des tâches des deux premières semaines, car toutes les métriques suivantes en dépendent.

Ce guide explique ce qu’est un workflow Jira, quel workflow convient à la plupart des équipes logicielles, cinq exemples que vous pouvez copier, comment le mettre en place, comment automatiser les transitions depuis GitHub, GitLab ou Bitbucket, ainsi que les bonnes pratiques et les erreurs qui déterminent si Jira vous aide ou vous ralentit. Il s’applique à Jira Cloud comme à Jira Data Center.

Qu’est-ce qu’un workflow Jira pour le développement logiciel ?

Un workflow Jira est l’ensemble des statuts qu’un ticket peut prendre et des transitions qui le font passer de l’un à l’autre. En développement logiciel, il modélise la vie d’un élément de travail : du backlog au développement, à la revue de code et aux tests, jusqu’à la release. Chaque projet Jira utilise un workflow, que l’équipe l’ait conçu ou qu’elle ait accepté celui par défaut.

Le workflow n’est pas le tableau. Le workflow définit quels états existent et quels déplacements sont autorisés ; le tableau est une vue qui associe ces statuts à des colonnes. Vous pouvez avoir plusieurs tableaux sur un même workflow, et masquer ou regrouper des statuts dans une colonne sans modifier le workflow sous-jacent.

Les briques d’un workflow Jira

Six composants constituent tout workflow Jira, et les comprendre facilite grandement la conception d’un workflow propre.

Les projets gérés par l’entreprise (company-managed) exposent directement les conditions, validateurs et post-fonctions. Les projets gérés par l’équipe (team-managed) proposent des règles de transition plus simples pour restreindre, valider et déclencher des actions sur les transitions. Les deux peuvent être enrichis avec Jira Automation.

Schémas de workflow et types de tickets

Un schéma de workflow associe des types de tickets à des workflows au sein d’un projet. C’est ainsi qu’un projet peut faire tourner un workflow pour les stories et les tâches, et un autre pour les bugs. Partager un même schéma entre plusieurs projets est le principal outil pour garder de nombreuses équipes cohérentes, comme nous le verrons dans la section sur le passage à l’échelle ci-dessous.

Quel est le meilleur workflow Jira pour le développement logiciel ?

Le meilleur workflow Jira pour le développement logiciel est le plus simple qui montre encore où le travail attend. Pour la plupart des équipes produit, cela signifie six statuts : Backlog, Selected for Development, In Progress, In Review, In QA et Done. Chaque statut répond à une seule question sur le travail, et chacun a un responsable et une règle de sortie sur lesquels tout le monde s’accorde.

Deux règles font fonctionner ce workflow. D’abord, autorisez les retours en arrière : la revue et la QA doivent pouvoir renvoyer un ticket en In Progress sans l’aide d’un administrateur. Ensuite, laissez « Blocked » hors de la liste des statuts et utilisez plutôt un drapeau (flag). Un statut bloqué masque l’endroit où se trouvait le travail au moment où il s’est enlisé, alors qu’un drapeau garde le ticket dans sa vraie colonne tout en signalant le problème.

Combien de statuts un workflow Jira doit-il compter ?

Une équipe logicielle type a besoin de 5–7 statuts. En dessous de cinq, la revue ou les tests disparaissent généralement, et le travail semble « en cours » pendant des jours sans aucun signal sur la raison. Au-delà de sept, il s’agit souvent de statuts qui décrivent des personnes ou des services plutôt que l’état du travail. Un test utile : si l’équipe ne peut pas expliquer un statut en une phrase, ou si aucun ticket n’y est resté au cours du dernier mois, supprimez-le.

5 exemples de workflows Jira pour le développement logiciel

Les différents types de travail demandent des flux légèrement différents, mais ils doivent partager la même colonne vertébrale. Ces cinq exemples de workflows Jira couvrent presque toutes les équipes logicielles ; copiez celui qui se rapproche le plus de votre processus et n’ajustez que ce que vous pouvez justifier.

1. Workflow de base pour les petites équipes

To Do → In Progress → In Review → Done. Proche du workflow par défaut de Jira, il convient aux équipes de deux à cinq développeurs qui testent leur propre code ou livrent derrière des feature flags. Ajoutez un statut QA dès qu’un testeur dédié rejoint l’équipe, sinon les tests deviennent invisibles.

2. Workflow Scrum

Backlog → Selected for Development → In Progress → In Review → In QA → Done. Le périmètre du sprint vit dans Selected for Development, et le tableau de sprint affiche les quatre statuts de travail. Les rapports de burndown et de vélocité reposent sur le fait que Done signifie « conforme à la Definition of Done » : ne laissez donc jamais un ticket atteindre Done avant la QA. Notre guide du développement logiciel Scrum détaille les rôles et les cérémonies derrière ce flux.

3. Workflow Kanban

Backlog → Ready → In Progress → Review → Testing → Ready to Release → Done. Les équipes Kanban se concentrent sur le flux : elles ajoutent un tampon « Ready to Release » et fixent des limites de WIP sur les colonnes du tableau, par exemple trois tickets en cours par développeur. Le cycle time et le diagramme de flux cumulé deviennent les principaux indicateurs de santé. Consultez Kanban en développement logiciel pour bien régler vos limites de WIP.

4. Workflow de suivi des bugs

Open → Triaged → In Progress → In Review → Verified → Closed, avec des résolutions comme Fixed, Duplicate, Cannot Reproduce et Won’t Fix. L’étape supplémentaire Triaged garantit que quelqu’un vérifie la gravité et la reproductibilité avant qu’un développeur ne prenne le bug. Verified doit être effectué par l’auteur du signalement ou par la QA, pas par le développeur qui a corrigé.

5. Workflow de fonctionnalité et de release avec UAT

Idea → Discovery → Ready → In Development → In QA → UAT → Released. Il convient aux epics ou aux fonctionnalités visibles par le client, pour lesquelles un responsable métier donne son accord. Il s’applique souvent au niveau de l’epic, tandis que les stories qu’elle contient suivent le flux Scrum ou Kanban. L’étape UAT reprend le processus décrit dans notre guide des tests d’acceptation utilisateur.

Comment configurer un workflow Jira pour le développement logiciel en 8 étapes

Configurer un workflow Jira prend un après-midi de paramétrage, mais doit commencer par une heure au tableau blanc. Concevez d’abord le flux sur papier avec l’équipe, construisez-le ensuite dans Jira, puis testez-le sur quelques tickets réels avant de basculer tout le monde.

1. Cartographiez le processus réel. Demandez à l’équipe comment une story avance concrètement aujourd’hui, y compris là où elle attend. Notez chaque passage de relais : du développeur au relecteur, du relecteur à la QA, de la QA à la release.
2. Choisissez des statuts, pas des personnes. Nommez chaque statut d’après l’état du travail (« In Review »), jamais d’après une personne ou une équipe (« Chez Anna », « Backend »). Visez 5–7 statuts.
3. Attribuez les catégories de statut. Placez chaque statut dans To Do, In Progress ou Done. Les rapports, les roadmaps et la couleur des tickets en dépendent.
4. Dessinez les transitions. Autorisez chaque déplacement vers l’avant dont vous avez besoin et les retours en arrière pour les reprises. Évitez « n’importe quel statut vers n’importe quel statut », sauf pour une réinitialisation réservée aux administrateurs.
5. N’ajoutez que les règles nécessaires. Les plus courantes : un validateur qui exige une pull request liée avant In Review, une condition selon laquelle seule la QA peut passer en Done, et une post-fonction qui renseigne la résolution en Done et l’efface à la réouverture.
6. Créez ou mettez à jour le schéma de workflow. Associez les stories, les tâches et les sous-tâches au workflow principal, et les bugs au workflow dédié si vous en utilisez un. Publiez d’abord le schéma sur un projet de test.
7. Configurez le tableau. Associez les statuts aux colonnes, définissez des limites de WIP pour le Kanban et ajoutez des filtres rapides comme « Flagged » ou « Assigned to me ».
8. Pilotez, puis déployez. Faites tourner un sprint sur le nouveau workflow avec une seule équipe, recueillez les points de friction, corrigez-les et ne migrez qu’ensuite les autres projets. Rédigez un guide d’une page qui explique chaque statut et chaque règle de sortie.

Comment relier un workflow Jira à Git, à la revue de code et à la CI/CD ?

Un workflow Jira pour le développement logiciel doit être piloté par les événements de développement, pas par des glisser-déposer manuels. Quand les branches, les pull requests, les builds et les déploiements mettent à jour les tickets automatiquement, le tableau reste exact et les développeurs restent dans leur éditeur.

• Reliez tout grâce à la clé du ticket. Placez la clé, par exemple PAY-142, dans les noms de branches, les messages de commit et les titres de pull requests. Jira affiche alors sur le ticket le panneau de développement avec les branches, commits, pull requests, builds et déploiements.
• Utilisez les smart commits avec modération. Avec Bitbucket et d’autres outils connectés, des messages de commit comme PAY-142 #comment fixed rounding ou PAY-142 #time 2h mettent Jira à jour directement. Les commandes de transition fonctionnent aussi, mais les règles d’automatisation sont plus faciles à gouverner.
• Connectez GitHub ou GitLab via les applications officielles. GitHub for Jira et GitLab for Jira Cloud envoient à Jira les données de développement et les informations de déploiement, ce qui alimente aussi la vue des déploiements et le suivi des releases.
• Remontez les builds et les déploiements. Quand la CI/CD publie le statut des builds et des déploiements, le ticket indique si son code est en staging ou en production, et Done peut signifier « déployé » plutôt que « mergé ».

C’est aussi là que le workflow rejoint votre pipeline de livraison. Si vous êtes encore en train de construire ce pipeline, notre guide de la CI/CD en développement logiciel décrit les étapes qui doivent remonter leurs informations à Jira.

Quelles transitions du workflow Jira faut-il automatiser ?

Automatisez les transitions qui suivent un événement prévisible et gardez le jugement humain là où une décision est nécessaire. Une bonne règle empirique : si la transition se produit toujours quand autre chose se produit, une règle doit s’en charger ; si quelqu’un doit trancher, laissez-la manuelle.

Gardez manuels les approbations, la validation QA et l’UAT. Les fonctionnalités d’IA intégrées d’Atlassian savent désormais résumer les tickets et suggérer les prochaines étapes, mais un statut qui représente une décision de qualité doit toujours être déplacé par la personne qui en est responsable. L’automatisation est la plus efficace une fois le workflow lui-même assaini ; automatiser un workflow désordonné ne fait qu’accélérer le désordre.

Bonnes pratiques du workflow Jira : une checklist en 7 points

Les meilleurs workflows Jira partagent les mêmes habitudes : peu de statuts, des responsabilités claires et une revue régulière. Utilisez cette checklist lorsque vous concevez un nouveau workflow ou auditez un workflow existant.

1. Limitez-vous à 5–7 statuts et nommez-les d’après l’état du travail.
2. Donnez à chaque statut un responsable et une règle de sortie, consignés dans le guide d’une page du projet.
3. Rendez les reprises explicites avec des transitions arrière plutôt qu’en rouvrant des tickets ou en créant des doublons.
4. Utilisez drapeaux et labels pour les états secondaires comme bloqué, design nécessaire ou en attente du client, plutôt que des statuts supplémentaires.
5. Renseignez correctement les résolutions : tout ticket en Done a besoin d’une résolution, et la réouverture doit l’effacer, sinon les rapports compteront du travail inachevé comme terminé.
6. Partagez un seul schéma de workflow entre les équipes qui construisent le même produit, et n’autorisez les variations locales qu’au niveau des tableaux.
7. Révisez le workflow chaque trimestre à l’aide du cycle time, du temps passé par statut et du diagramme de flux cumulé.

Ces habitudes comptent, car la friction liée aux outils coûte cher. Le rapport State of Developer Experience d’Atlassian (2024) a montré que 69% des développeurs perdent au moins huit heures par semaine à cause d’inefficacités, et les processus flous comme les corvées de mise à jour des statuts font partie de la facture. Pour l’ensemble plus large des métriques de suivi, consultez notre guide des KPI du développement logiciel et des benchmarks DORA.

Erreurs fréquentes dans les workflows Jira et comment les corriger

La plupart des workflows Jira défaillants échouent de la même manière, et chaque problème a une solution simple. Le tableau ci-dessous recense les problèmes que nous rencontrons le plus souvent lors des audits de projets clients.

Comment faire passer les workflows Jira à l’échelle sur plusieurs équipes ?

Faites passer les workflows Jira à l’échelle avec une colonne vertébrale commune et une liberté locale uniquement là où elle ne casse pas le reporting. Toutes les équipes travaillant sur un même produit doivent utiliser les mêmes statuts et catégories de statut, afin qu’une vue portefeuille, un plan de release ou un tableau de bord inter-équipes signifie la même chose partout.

• Un schéma de workflow par ligne de produit, partagé par tous ses projets et piloté par un administrateur Jira ou un petit groupe de travail.
• Un projet avec plusieurs tableaux lorsque les équipes travaillent sur la même base de code : chaque équipe filtre son tableau par composant ou par champ équipe, tandis que le workflow reste commun.
• Des variations locales au niveau des tableaux : limites de WIP, couloirs (swimlanes) et filtres rapides peuvent différer d’une équipe à l’autre sans toucher au workflow.
• Un processus de changement : les modifications du workflow passent par une courte demande motivée, sont testées sur un projet bac à sable et annoncées avant leur mise en service.
• Un nettoyage régulier des statuts inutilisés, des champs personnalisés et des workflows inactifs, qui ralentissent Jira et déroutent les nouveaux membres de l’équipe.

Le même principe s’applique lorsque vous travaillez avec un partenaire de livraison externe ou une équipe étendue : il doit travailler dans votre workflow commun, pas dans un workflow parallèle. Notre guide sur le management des équipes de développement logiciel décrit le rythme opérationnel qui l’entoure.

Comment auditer un workflow Jira ? Un bilan de santé trimestriel

Auditez un workflow Jira chaque trimestre en mesurant où les tickets attendent, et non combien de statuts existent. Trois rapports intégrés suffisent à repérer la plupart des problèmes, et l’ensemble du contrôle prend environ une heure.

1. Diagramme de flux cumulé. Une bande qui ne cesse de s’élargir révèle un goulot d’étranglement ; une bande In Review qui s’élargit, par exemple, signifie que les revues sont la contrainte.
2. Control chart ou rapport de cycle time. Regardez la moyenne et les valeurs aberrantes. Les tickets qui prennent trois fois la moyenne révèlent généralement des exigences floues ou des dépendances cachées.
3. Temps passé par statut. Les statuts où les tickets restent inactifs pendant des jours sont candidats à l’automatisation, à des limites de WIP ou à un changement de processus.
4. Statuts et transitions inutilisés. Tout ce qui n’a pas servi au cours du dernier trimestre peut être supprimé.
5. Retours de l’équipe. Demandez quelles transitions les gens contournent. Les contournements sont le signal le plus honnête qu’un workflow n’est plus adapté.

À retenir

• Un workflow Jira est un ensemble de statuts et de transitions ; le tableau n’en est qu’une vue.
• Le meilleur workflow Jira pour le développement logiciel compte 5–7 statuts, chacun avec un responsable et une règle de sortie.
• Copiez l’un des cinq modèles éprouvés : de base, Scrum, Kanban, suivi des bugs ou fonctionnalité avec UAT.
• Utilisez des drapeaux plutôt qu’un statut Blocked, et autorisez toujours les transitions arrière pour les reprises.
• Pilotez les transitions à partir des branches, pull requests, builds et déploiements avec Jira Automation.
• Partagez un seul schéma de workflow entre les équipes d’un même produit et révisez-le chaque trimestre.

FAQ

Publié le 30 octobre 2026. Sources : Atlassian Support, utiliser les workflows ; Atlassian Support, smart commits ; Atlassian, Jira Automation ; Atlassian, rapport State of Developer Experience 2024. Les modèles de workflow reflètent la pratique de livraison de YuSMP Group et constituent des recommandations, pas des paramètres par défaut d’Atlassian.