Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Mener une fonctionnalité approuvée dans Jira et une modification Claude Code vérifiée

> Faites avancer une fonctionnalité approuvée dans un véritable epic Jira, toutes ses stories et des sous-tâches utiles. Vérifiez chaque modification Claude Code, les mises à jour des tickets et la décision sur les consignes du projet.

By BIG CHANGE Editorial

Published: 2026-10-20T13:23:38.288Z
Updated: 2026-10-20T13:23:38.288Z
Canonical: https://bigchange.ai/blog/claude-code-jira-approved-feature-guide

![Conceptual charcoal illustration of a developer at a standing counter reviewing a generic two-column code diff on an arm-mounted display.](https://bigchange.ai/api/media/file/claude-code-jira-feature-review-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Une fonctionnalité approuvée peut traverser trois systèmes avant d’être terminée : un document d’exigences, une hiérarchie de tickets Jira et un dépôt. Claude Code peut aider à rédiger et implémenter, mais les liens entre ces systèmes nécessitent une approbation humaine et des contrôles directs. Ce guide accompagne un développeur ou responsable d’équipe sur une véritable fonctionnalité, avec **chaque story approuvée**, ses tests d’origine, les mises à jour Jira autorisées et une décision examinée sur les consignes du projet.

Cette procédure repose sur la documentation. BIG CHANGE n’a accédé à aucun projet Jira, exécuté Claude Code, modifié un dépôt ni mesuré un délai de livraison. Les types de tickets, champs, transitions, commandes et coûts exacts dépendent de votre projet et compte.

## Le grand changement

- **Ce qui a changé :** Une fonctionnalité peut être suivie de son exigence approuvée à un véritable parent Jira et à chaque story, puis au code revu, aux contrôles d’origine et aux mises à jour autorisées.
- **Pourquoi c’est important :** La carte des tickets, les résultats de tests et les relectures directes dans Jira montrent le travail approuvé terminé et les stories encore ouvertes.
- **À surveiller :** Les champs et transitions propres au projet, les écritures incertaines et les contrôles échoués nécessitent une résolution humaine ; les consignes de Claude Code n’autorisent pas le travail à elles seules.

## Avant de commencer

Choisissez une fonctionnalité avec un brief approuvé par son responsable, un dépôt modifiable avec permission et une vérification d’acceptation d’origine exécutable. Le travail réel doit justifier un parent de niveau epic, ses stories approuvées et au moins une sous-tâche utile sous une story du projet Jira Cloud choisi. Sans véritable sous-tâche, ce résultat complet reste en attente ; ajouter un ticket décoratif fausserait le plan. Notez demandeur, autorité d’approbation, révision source, données permises, commit Git initial, isolation ou retour arrière et personne habilitée à revoir le code et changer le statut Jira.

Vérifiez les paramètres installés : [version de Claude Code, l’authentification et les permissions](https://code.claude.com/docs/en/permissions). Confirmez que le `CLAUDE.md` du dépôt donne des consignes sans autoriser les modifications, commandes ou envois de données. Décidez quelles exigences et quel code Claude peut recevoir, quelles commandes il peut exécuter et la limite d’utilisation pour cette fonctionnalité. L’usage peut consommer un quota d’abonnement ou entraîner des frais fournisseur ; [le guide des coûts d’Anthropic](https://code.claude.com/docs/en/costs) ne détermine pas votre facture à l’avance.

Pour Jira, obtenez la permission de consulter et créer les types concernés puis, ultérieurement, de commenter ou faire évoluer les tickets en tant qu’acteur autorisé. Un script privé peut utiliser [la méthode par adresse e-mail et jeton API documentée par Atlassian](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis) ; une intégration peut nécessiter OAuth. Conservez les secrets dans un stockage privé. Excluez-les des prompts, du texte des tickets, de `CLAUDE.md`, des journaux et du contrôle de versions. Convenez de la visibilité avant d’envoyer les exigences à Jira.

Conservez sept enregistrements privés au fil du travail : `docs/feature-prd.md`, `ticket-plan.json`, un journal d’écriture des tickets avec ajout uniquement, `ticket-map.json`, un reçu d’implémentation par story, un journal des mises à jour Jira et une décision rétrospective. Ils concernent votre fonctionnalité ; ce ne sont pas des fichiers fournis ou exécutés par BIG CHANGE.

## 1. Approuver un PRD exact

Donnez à Claude Code le véritable brief approuvé et demandez-lui d’identifier les questions non résolues avant de rédiger `docs/feature-prd.md`. Le document doit préciser demandeur et responsable approbateur, révision d’entrée, problème et utilisateur visé, périmètre et exclusions, identifiants d’exigences numérotés, contrôles d’acceptation et sources de preuve, contraintes non fonctionnelles, projet Jira et questions ouvertes. Une personne responsable compare le brouillon au brief et approuve une révision de contenu et son empreinte exactes. Résolvez les questions importantes avant de créer des tickets ou de modifier le code.

L’empreinte fournit une source précise aux enregistrements ultérieurs. Si le PRD change, revoyez le plan de tickets et les contrôles affectés ; un échec d’implémentation ne justifie pas de réécrire les critères pour obtenir une réussite.

## 2. Découvrir la hiérarchie et les champs Jira de ce projet

Avec des requêtes Jira REST API v3 autorisées en **lecture seule**, parcourez les pages de `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes`. Pour chaque type proposé, parcourez les pages de `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}` pour connaître les champs de création obligatoires et valeurs permises. Atlassian marque l’opération générale `GET /issue/createmeta` comme obsolète dans sa [référence de l’API des tickets](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/).

Confirmez un véritable parent équivalent à un epic, des enfants de niveau story et les sous-tâches prises en charge. Atlassian décrit [la hiérarchie par défaut et sa configuration](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) ; les noms et identifiants de types ne sont pas universels. Examinez le champ Parent à chaque niveau enfant et les champs personnalisés ou paramètres de visibilité obligatoires. Si le projet ne peut représenter le graphe approuvé, notez le type, champ ou droit manquant et suspendez la création. Un simple lien entre tickets ne crée pas une relation parent-enfant.

## 3. Examiner tout le plan de tickets avant d’écrire

Associez chaque exigence et contrôle d’acceptation du PRD dans `ticket-plan.json`. Notez son `planVersion`, l’empreinte du PRD, le site et la clé de projet Jira, un identifiant d’exécution local ainsi que l’approbateur du plan et l’heure. Pour chaque ticket proposé, indiquez un identifiant local unique, l’identifiant local du parent prévu, le type découvert, les champs obligatoires, le résumé, la description, les identifiants d’exigences et d’acceptation, le responsable et la visibilité permise. Le travail approuvé fixe le nombre de stories et sous-tâches. Chacune doit faire un travail réel sous sa véritable story.

Jira REST v3 utilise **Atlassian Document Format (ADF)**, un document JSON structuré, pour les descriptions et commentaires multilignes. Préparez ces documents à partir du contenu approuvé et vérifiez les métadonnées de champs renvoyées par le site avant chaque requête. [L’API des tickets](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) documente la création, mais ne fournit pas un objet de champs prêt à l’emploi pour un projet inconnu. Une personne doit approuver le graphe entier, la couverture de toutes les exigences, les relations parentales et la destination exacte avant tout `POST`.

## 4. Créer les parents d’abord et relire chaque ticket

Créez le parent approuvé avec `POST /rest/api/3/issue`, puis ses stories, puis chaque véritable sous-tâche. Avant **chaque** requête, ajoutez au journal privé l’identifiant d’exécution, l’identifiant local du ticket, la clé du parent confirmé si applicable, la destination, l’empreinte de la requête exacte approuvée, l’heure UTC et l’état `pending`. N’incluez aucun jeton. Sur HTTP 201, notez l’identifiant et la clé renvoyés par Jira, puis effectuez directement `GET /rest/api/3/issue/{issueIdOrKey}`. Comparez projet, type, résumé, description ou référence PRD et parent au plan approuvé. Marquez la ligne `confirmed` seulement après cette relecture. Un parent confirmé débloque ses enfants.

Si une requête expire ou sa réponse est perdue, marquez-la `unknown`. Cherchez dans Jira par projet, heure, résumé approuvé et référence du plan, puis ouvrez directement chaque résultat probable et faites trancher son identité par le responsable autorisé. [Atlassian avertit que la recherche peut être en retard après une écriture](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/). L’absence de résultat ne prouve pas l’échec de la création. L’identifiant d’exécution et le journal facilitent le rapprochement sans faire rejeter les doublons par le serveur. Ne rejouez jamais un `POST` incertain à l’aveugle.

Relisez directement le graphe fini dans `ticket-map.json` : identifiant local, identifiant et clé Jira réels, URL canonique, projet, type, clé parent, identifiants PRD et d’acceptation, heure de relecture et référence du journal. Comparez **tous** les tickets et critères approuvés au PRD. Arrêtez les écritures si un ticket manque ou a le mauvais parent ; utilisez le processus de correction examiné du projet.

## 5. Implémenter et faire revoir indépendamment chaque story approuvée

Traitez les stories dans l’ordre des dépendances. Pour chacune, notez sa clé Jira, le commit initial et la branche ou copie de travail, la commande d’acceptation d’origine, les chemins et commandes permis. Demandez à Claude Code d’utiliser [Plan mode](https://code.claude.com/docs/en/common-workflows) pour relier les critères de cette story au dépôt. Un développeur vérifie le plan et autorise une modification limitée. La limite de story rend le changement examinable ; elle ne retire pas les autres stories de la fonctionnalité.

Après modification, conservez le diff exact, la commande de contrôle d’origine avec sortie complète et code de fin, les tests ciblés pertinents et un verdict pour chaque identifiant d’exigence. Examinez le code et les journaux réels. Un plan écrit, des fichiers générés ou l’affirmation de Claude que les tests passent ne prouvent pas un changement fonctionnel. Suspendez la story en cas de contrôle échoué, secret inattendu, dépendance modifiée, écriture externe ou refonte large ; réparez dans le périmètre et relancez le contrôle d’origine. Un réviseur distinct décide d’accepter le commit ou de suspendre le diff. Notez cette décision pour chaque story. [Notre précédent guide d’une modification Claude Code revue](https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide) couvre cette étape plus étroite ; le PRD et le graphe Jira complet donnent ici le périmètre global.

## 6. Vérifier les mises à jour Jira autorisées

Pour chaque story revue, lisez son statut actuel et demandez `GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields`. Examinez la transition réellement proposée à cet acteur, sa destination, les champs obligatoires et valeurs permises. Un responsable autorisé peut alors soumettre la transition choisie par `POST /rest/api/3/issue/{key}/transitions` avec les champs résolus pour le projet. Relisez directement le ticket et confirmez son nouveau statut. Un contrôle de code réussi n’autorise pas en soi Done, la fusion ou le déploiement.

Notez le statut avant écriture, la transition prévue, l’acteur, la requête et la réponse dans le journal Jira. Publiez un commentaire de preuve ADF factuel avec `POST /rest/api/3/issue/{key}/comment` : commit accepté ou diff suspendu, contrôle d’origine et tests ciblés, échecs restants et décision du réviseur. Relisez l’identifiant et le contenu du commentaire créé via [l’API des commentaires](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) de Jira. Si une écriture a une réponse incertaine, examinez directement statuts ou commentaires avant toute autre requête. Une liste de transitions vide ou un champ obligatoire indisponible est un manque de processus ou de permission à résoudre avec le responsable, pas une invitation à inventer un identifiant.

## 7. Décider si `CLAUDE.md` doit changer

Comparez les véritables journaux de PRD, tickets, diff, tests, revue et Jira. Demandez une courte rétrospective fondée sur les incompréhensions observées ou contrôles manquants. Un humain choisit une modification précise des consignes ou une décision de ne rien changer, avec réviseur et heure. Si c’est approuvé, examinez puis faites un commit uniquement de ce diff de `CLAUDE.md` et son empreinte. [Le guide de mémoire d’Anthropic](https://code.claude.com/docs/en/memory) décrit les consignes de projet ; cette revue n’autorise pas automatiquement le travail futur. N’ajoutez aucun secret et ne transformez pas une leçon spéculative en règle.

## Achèvement et récupération

La fonctionnalité n’est terminée que si la révision approuvée du PRD correspond au graphe epic/story/sous-tâches directement confirmé ; **chaque story approuvée** possède son état initial, diff accepté, contrôle d’origine, preuves de tests ciblés et revue indépendante ; chaque transition et commentaire autorisés ont été relus directement ; et un humain a décidé de la rétrospective. Si un élément manque, notez l’étape exacte restante. [Choisir une première tâche d’IA](https://bigchange.ai/blog/map-work-choose-first-ai-task-guide) s’arrête plus tôt, au choix et à une proposition de contrôle ; cela n’établit pas le résultat de cette implémentation.

Une création Jira incertaine reste `unknown` jusqu’à ce qu’une personne établisse son identité. Un mauvais parent bloque la création des enfants. Les tests échoués laissent intacts les critères d’origine. Une transition absente ou un quota épuisé laisse un état partiel daté pour le responsable. Limitez exigences et données clients au minimum approuvé pour Claude et Jira, vérifiez coûts et permissions actuels et prévoyez une revue humaine du code. Ce guide documente un chemin conditionnel ; BIG CHANGE ne rapporte aucune fonctionnalité livrée, écriture Jira, exécution de modèle, économie mesurée, fusion ou déploiement.

## Sources et lectures complémentaires

- [Atlassian, opérations de tickets Jira Cloud REST API v3](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) : métadonnées de création ciblées, création et lecture, transitions. Les champs et identifiants du projet doivent être découverts sur place.
- [Atlassian, commentaires de tickets](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) : création ADF et relecture des commentaires. Permissions et réponses sont propres au site.
- [Atlassian, recherche et rapprochement](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) : explique pourquoi l’absence dans la recherche juste après une écriture ne résout pas une création incertaine.
- [Atlassian, hiérarchie des types de tickets](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) : niveaux par défaut et configuration ; la structure du projet choisi doit encore être examinée.
- [Anthropic, méthodes de travail Claude Code](https://code.claude.com/docs/en/common-workflows), [permissions](https://code.claude.com/docs/en/permissions), [mémoire](https://code.claude.com/docs/en/memory) et [coûts](https://code.claude.com/docs/en/costs) : planification, autorité de modification, consignes `CLAUDE.md` et utilisation. Ces documents ne décrivent pas une exécution de cette fonctionnalité.

## Sources

- [Atlassian Jira Cloud REST API v3 : tickets](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) — Décrit les métadonnées ciblées, POST/GET et transitions ; les métadonnées générales sont obsolètes. Champs, identifiants et transitions permises doivent venir du site du lecteur.
- [Atlassian Jira Cloud REST API v3 : commentaires](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) — Décrit création ADF et relecture sous les permissions réelles. Aucun commentaire n’a été publié pour ce guide.
- [Atlassian : recherche et rapprochement](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) — Confirme la cohérence à terme des recherches ; une absence ne prouve pas celle d’un ticket après une réponse de création incertaine.
- [Atlassian : configurer la hiérarchie des types](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) — Explique les niveaux par défaut et configurables. Ceux du projet et le comportement de Parent exigent une découverte directe.
- [Atlassian : authentification de base pour les API REST](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/) — Permet e-mail et jeton API pour un petit script privé et distingue les intégrations ; les secrets doivent rester privés.
- [Anthropic Claude Code : méthodes courantes](https://code.claude.com/docs/en/common-workflows) — Documente Plan mode et les pratiques de développement ; ne prouve pas l’implémentation ou les contrôles du lecteur.
- [Anthropic Claude Code : permissions](https://code.claude.com/docs/en/permissions) — Documente les permissions et approbations effectives ; les consignes CLAUDE.md seules n’autorisent ni commandes ni écritures.
- [Anthropic Claude Code : mémoire](https://code.claude.com/docs/en/memory) — Explique les consignes CLAUDE.md ; la modification rétrospective proposée exige une revue humaine et n’est pas un apprentissage automatique.
- [Anthropic Claude Code : coûts](https://code.claude.com/docs/en/costs) — Usage et facturation varient selon abonnement et fournisseur ; aucune dépense ou économie n’a été mesurée dans ce guide documentaire.