Rapport de changements (export delta)
La plupart des exports répondent à la question « à quoi cela ressemble-t-il en ce moment ? ». Un rapport de changements répond à la question réellement posée en réunion de suivi : « qu'est-ce qui a bougé depuis la dernière fois ? »
Disponible en Standard pour les exports JQL, de tableau, de sprint, de version et de backlog. Il donne le meilleur de lui-même en export planifié : un rapport hebdomadaire « ce qui a bougé » qui arrive dans votre boîte de réception le lundi matin.
Ce qu'il n'est pas
Ce n'est pas un déversement du journal des modifications de Jira. Le composant Historique des modifications le fait déjà, ticket par ticket.
Un rapport de changements travaille au niveau de l'ensemble exporté :
- quels tickets sont apparus,
- quels tickets ne sont plus dans le résultat,
- quels tickets ont bougé — statut, responsable, priorité, date d'échéance, ainsi que tout champ que vous ajoutez,
- les nouveaux commentaires et journaux de travail.
« Plus dans le résultat » ne veut pas dire supprimé
C'est le point le plus important à comprendre à propos de ce rapport.
Lorsqu'un ticket apparaît sous Plus dans le résultat, il ne fait plus partie de l'ensemble de résultats de l'export. Cela ne signifie pas qu'il a été supprimé. Il a pu être déplacé vers un autre projet, réattribué, réétiqueté ou simplement modifié de sorte que votre filtre ne le trouve plus.
Chaque liste de tickets sortants porte cette note dans le document exporté, dans toutes les langues et tous les formats, et la compaction ne la supprime jamais. Un rapport affirmant que du travail a été supprimé alors qu'il avait seulement été réétiqueté serait un malentendu coûteux.
Pour la même raison, les tickets sortants sont listés par clé uniquement. Exportelier n'en conserve aucune copie, et interroger leur état actuel ne dirait rien sur la raison de leur sortie.
Mise en place
- Ouvrez le modèle dans le concepteur.
- Activez Rapport de changements et choisissez un point de référence.
- Placez les trois composants :
- Synthèse des changements — les compteurs, la ligne de référence et les notes.
- Liste delta de tickets — une liste, réglée sur Ajoutés ou Plus dans le résultat. Ajoutez-la deux fois pour les deux.
- Tableau des changements — une ligne par champ modifié.
- Enregistrez et utilisez le modèle comme n'importe quel autre.
Points de référence
| Référence | Signification | À utiliser pour |
|---|---|---|
| Export précédent | La dernière fois que ce modèle a exporté cette portée | Rapports ponctuels |
| Exécution planifiée précédente | La dernière exécution réussie de cette planification | Rapports hebdomadaires et mensuels |
| Date fixe | Une date que vous saisissez | « Tout depuis la création de la branche de version » |
Champs suivis
Statut, responsable, priorité et date d'échéance sont toujours suivis. Ajoutez les vôtres — points d'effort, sprint, un champ personnalisé — dans les paramètres du modèle. Les nouveaux commentaires et journaux de travail comptent aussi comme des changements et peuvent être désactivés s'ils constituent du bruit pour votre public.
La première exécution
Le premier rapport pour un modèle et une portée n'a rien à quoi se comparer. Plutôt que d'échouer, il produit un rapport complet de l'ensemble actuel et le signale :
Ceci est le premier rapport de changements pour ce modèle et cette portée ; il liste donc l'ensemble actuel complet. Les rapports suivants n'afficheront que ce qui a changé.
À partir de la deuxième exécution, vous obtenez un véritable delta.
Un exemple concret
Une équipe exécute un export planifié chaque lundi à 08h00 sur project = EX AND sprint in openSprints(), avec les trois composants et la référence Exécution planifiée précédente.
Lundi 3 août — première exécution. Aucune exécution antérieure n'existe : le rapport liste les 14 tickets du sprint et porte la note de première exécution. C'est la référence de départ.
Pendant la semaine. EX-104 est créé et intégré au sprint. EX-77 part vers un autre projet et sort du filtre. EX-42 passe par To Do → In Progress → Review → In Progress → Review → Done en cinq jours. EX-51 est réattribué d'Ada à Grace et reçoit deux commentaires. Dix tickets restent inchangés.
Lundi 10 août — deuxième exécution. Le rapport s'ouvre sur :
Changements depuis le 3 août 2026
Ajoutés : 1 · Plus dans le résultat : 1 · Modifiés : 2 · Inchangés : 10
Puis le tableau des changements :
Clé Champ De À Changements EX-42 statut To Do Done 5 EX-51 responsable Ada Grace 1
Notez la ligne EX-42. Ce ticket a changé de statut cinq fois, et c'est une seule ligne montrant d'où il est parti, où il est arrivé et combien d'étapes ont été nécessaires. Cinq lignes distinctes pour un seul ticket enseveliraient les deux tickets qui méritent vraiment l'attention.
Temps de lecture : une quinzaine de secondes, contre le défilement de quatorze descriptions pour comprendre ce qui a changé.
Lorsque l'historique ne peut pas être reconstitué
Jira n'enregistre pas d'entrée de modification pour chaque champ, et les historiques très longs sont tronqués à la récupération. Lorsque l'historique disponible ne couvre pas toute la période du rapport, le ticket est signalé comme non reconstituable dans la synthèse, plutôt que d'être silencieusement compté comme inchangé.
Les sous-tâches et les niveaux de hiérarchie plus profonds n'ont pas d'historique propre et entrent donc dans ce groupe. Ils restent comptés dans les totaux : le delta travaille toujours sur l'ensemble plat des tickets exportés, afin que les chiffres soient cohérents.
Ce qu'Exportelier stocke
Pour vous dire ce qui a été ajouté et ce qui est sorti, Exportelier doit se souvenir des tickets présents dans le dernier export. Il stocke les clés de ticket, et rien d'autre.
Pas de résumés, pas de valeurs de champ, pas de descriptions, pas de commentaires. Les valeurs avant/après du tableau des changements sont lues dans l'historique de Jira au moment de la génération du rapport et ne sont jamais conservées. La liste de clés stockée expire au bout de 180 jours.
C'est un choix délibéré : conserver les valeurs de champ simplifierait le rapport, mais ferait d'Exportelier une seconde copie de votre contenu Jira, avec tout ce que cela implique pour la protection des données.
Limites
- Indisponible pour les exports d'un seul ticket — utilisez le composant Historique des modifications.
- Indisponible pour les archives ZIP à un fichier par ticket : un rapport portant sur l'ensemble n'a pas de document unique où loger.
- Jusqu'à 2 000 clés sont mémorisées par modèle et par portée. Au-delà, le rapport précise que les décomptes d'ajouts et de sorties peuvent être incomplets.
- Le tableau des changements est plafonné à 500 lignes par rapport ; si le plafond est atteint, le document le signale.