Qu’est-ce que l’automatisation des checklists Jira ?
L’automatisation des checklists joint un modèle enregistré à un ticket Jira au moment de votre choix : à sa création, lors d’un changement de statut ou via une règle Jira Automation plus élaborée. La structure reste identique à chaque fois : la Definition of Done sur une Story, une checklist de tests QA au passage à Ready for test, une checklist de mise en production lorsque le statut devient Ready to release. L’équipe continue de cocher les lignes ; le processus apparaît simplement sans qu’il faille aller le chercher.
Un modèle peut s’ajouter automatiquement depuis l’onglet Advanced. Un validateur de workflow peut attendre que la liste soit terminée. Une post-fonction peut réinitialiser les éléments à la réouverture du ticket. Jira Automation couvre les cas qui dépendent de libellés, de composants ou d’une exécution planifiée. Choisissez le niveau d’automatisation en fonction des personnes autorisées à modifier le processus.
Pourquoi les équipes automatisent leurs checklists
Une Definition of Done qui reste dans Confluence n’aide que les personnes qui pensent à l’ouvrir. L’ajout automatique place les mêmes étapes sur le ticket : la progression devient visible sur le tableau et dans JQL. Les nouvelles stories disposent immédiatement d’un cadre. Les testeurs reçoivent leur parcours au bon statut. À la réouverture d’un bug, la liste repart de zéro pour refléter fidèlement le nouveau cycle de test.
Résultat : des points d’équipe plus sereins. La question « avons-nous pensé à la checklist QA ? » ne se pose plus, puisqu’elle se trouve déjà sur le ticket. Les modèles Protected verrouillent le libellé pendant que chacun coche les éléments et leur attribue des statuts comme In Progress et Blocked. L’ajout automatique par modèle est intégré à Checklist for Jira et ne consomme aucun crédit Jira Automation.
Quand l’utiliser
Ajoutez automatiquement dès la création les listes nécessaires au premier jour : la Definition of Done sur les Stories, une courte checklist de cadrage ou une base QA sur les Bugs. Déclenchez l’ajout au changement de statut pour une phase ultérieure : Ready for test, Ready to release ou In Review. Utilisez un validateur de complétion si Done doit réellement signifier que toutes les exigences sont satisfaites. Réinitialisez la liste lorsqu’un même ticket doit repasser par le processus.
Évitez de créer une règle pour une liste rare ou facultative. Checklist for Jira permet toujours aux personnes autorisées à modifier les checklists d’appliquer un modèle via Add → Add from template. Validez d’abord le contenu de la liste, puis activez la règle dans l’onglet Advanced.
Trois niveaux qui fonctionnent ensemble
Checklist for Jira vous offre trois niveaux pour intégrer le processus. Ils se complètent, sans se remplacer.
- Ajout automatique par modèle dans l’onglet Advanced : à la création du ticket ou lors d’un changement de statut, avec un comportement de réapplication si la liste est déjà présente.
- Validateurs de workflow et post-fonctions : imposer une liste terminée ou non vide, puis réinitialiser ou terminer ses éléments lors d’une transition.
- Actions Jira Automation — Apply template, Complete all, Reset all — lorsque la condition va au-delà de la création ou d’un seul statut.
Mettez la checklist sur l’élément de travail, pas dans la description
Checklist for Jira apporte les modèles, l’automatisation, les validateurs de workflow et un agent Rovo. Gratuit pour les équipes jusqu’à 10 utilisateurs.
Recettes : déclencheur, action, résultat
| Scénario | Déclencheur | Action | Résultat |
|---|---|---|---|
| Chaque nouvelle story reçoit la Definition of Done | Ticket créé, de type Story | Ajout automatique du modèle à la création | Definition of Done apparaît immédiatement sur le ticket. |
| Checklist QA lorsque le travail est prêt à tester | Le statut passe à Ready for test | Ajout automatique du modèle au changement de statut | Les testeurs retrouvent un parcours standard sans rien copier depuis Confluence. |
| Runbook de release au moment du déploiement | Le statut passe à Ready to release | Ajout automatique du modèle au changement de statut | La checklist de mise en production accompagne le changement livré. |
| Empêcher la livraison d’un travail incomplet | Transition vers Done | Validateur de complétion ciblé sur le modèle Done | Jira bloque la transition tant que les éléments restants ne sont pas cochés. |
| Réouvrir signifie recommencer la checklist | Transition de Done vers In Progress | Post-fonction de réinitialisation ou action Reset all de Jira Automation | Les éléments repassent à Open pour que le nouveau parcours reflète la réalité. |
| Appliquer en masse après une évolution du processus | Règle Jira Automation planifiée ou déclenchée par une mise à jour | Action Apply template | Les tickets existants adoptent la nouvelle norme sans intervention manuelle sur chacun. |
Droits, modèles Protected et réapplication
Les administrateurs de projet gèrent les modèles de projet ; les administrateurs Jira gèrent les modèles globaux. Toute personne autorisée à modifier les checklists d’un ticket peut les appliquer via Add → Add from template. Les modèles Protected verrouillent la structure : l’équipe peut cocher les éléments et modifier leur statut, mais pas réécrire les étapes, y compris depuis le chat. Un ticket ne peut contenir qu’une checklist Protected issue d’un même modèle.
Lors d’un changement de statut, choisissez le comportement de réapplication avant de déployer la règle sur tout le projet. Do nothing conserve un runbook unique : un second passage à Ready to release n’ajoute pas de copie. Reset checklist convient lorsqu’un même ticket doit repasser le contrôle, par exemple après Reopened. Add the template again conserve l’historique de chaque passage. Les modèles archivés ignorent l’ajout automatique et disparaissent du sélecteur ; désarchivez-les avant de modifier leurs règles. Retrouvez les détails dans la documentation produit.
Enregistrez un modèle, puis activez la règle
- Checklist for Jira ajoute un panneau de checklist à la vue du ticket. Collez une première liste — la Definition of Done, la checklist de tests QA ou une checklist de mise en production — puis enregistrez-la comme modèle de projet ou modèle global dans Checklist settings.
- Marquez le modèle comme Protected si son libellé doit rester verrouillé pendant que l’équipe coche les éléments.
- Dans l’onglet Advanced, configurez l’ajout à la création du ticket pour tous les types ou certains d’entre eux, ou au changement de statut. Pour un modèle global, définissez ces règles projet par projet. Ces automatisations sont intégrées à Checklist for Jira et ne consomment aucun crédit Jira Automation.
- Si Done doit garantir que toutes les exigences sont satisfaites, ajoutez le validateur All Checklist Items Completed à cette transition et ciblez ce modèle afin que les autres listes du ticket puissent rester en cours. Checklist Not Empty constitue un garde-fou plus léger si vous souhaitez seulement imposer la présence d’une liste.
- Une post-fonction peut réinitialiser ou terminer les éléments lors d’une transition. Utilisez Jira Automation lorsque la condition dépend de libellés, de composants ou d’une exécution planifiée. Associez cette approche à l’agent de checklist Rovo lorsqu’une personne a besoin du bon modèle au bon moment.
Associez-la aux autres checklists de livraison
Partez du catalogue de modèles : la Definition of Done à la création, la checklist de tests QA au passage à Ready for test et la checklist de mise en production au passage à Ready to release. Gardez chaque liste sur le ticket parent lorsqu’elle représente un seuil de qualité ; créez une sous-tâche lorsque le travail mérite son propre ticket. Le comparatif entre checklists et sous-tâches vous aide à choisir. Utilisez l’agent de checklist Rovo pour les cas inhabituels et réservez les règles au fonctionnement par défaut.
Questions fréquentes
Peut-on imposer uniquement la checklist de release, sans bloquer sur les autres listes du ticket ?
Oui. Ciblez le validateur All Checklist Items Completed sur un modèle ou un nom de checklist pour que les autres listes puissent rester en cours. Si cette liste ciblée n’est pas présente sur le ticket, la transition reste autorisée : ajoutez d’abord automatiquement le modèle si le contrôle doit toujours s’appliquer.
Jira Automation remplace-t-il l’ajout automatique du modèle ?
L’ajout automatique configuré sur le modèle reste l’option la plus simple et ne consomme aucun crédit Automation. Utilisez Jira Automation lorsque la condition dépasse la création ou un seul statut, par exemple pour des libellés, des composants ou une exécution planifiée.
Que se passe-t-il si le modèle est déjà sur le ticket ?
À la création, les modèles correspondants ne sont ajoutés qu’une fois. Lors d’un changement de statut, le comportement de réapplication décide s’il faut ne rien faire, réinitialiser la liste existante ou ajouter une nouvelle copie. Les modèles Protected restent limités à une copie par ticket.
Peut-on automatiser un modèle archivé ?
Les modèles archivés ignorent l’ajout automatique et disparaissent du sélecteur. Désarchivez d’abord le modèle si vous devez modifier ses règles ou l’appliquer de nouveau.
Mettez la checklist sur l’élément de travail, pas dans la description
Checklist for Jira apporte les modèles, l’automatisation, les validateurs de workflow et un agent Rovo. Gratuit pour les équipes jusqu’à 10 utilisateurs.