Un ticket porte souvent la seule trace d’un arbitrage
Un ticket Jira porte souvent la seule trace écrite d’un arbitrage technique. Pourquoi cette bibliothèque plutôt qu’une autre, pourquoi ce contournement provisoire est devenu définitif, ce que le client avait vraiment demandé avant qu’on reformule. La décision est dans un commentaire, six mois plus bas.
Une IA qui ne lit pas ces commentaires proposera de refaire ce qui a déjà été essayé. C’est le genre de perte que personne ne mesure, parce qu’elle ressemble à du travail normal.
Le niveau de sécurité d’un ticket prime sur les droits du projet
Jira a deux couches de droits qui peuvent se contredire, et c’est exactement là qu’un connecteur naïf fuit. La première couche est le droit de parcours du projet, qui dit qui peut voir les tickets de ce projet. La seconde est le niveau de sécurité posé sur un ticket précis, qui le restreint à quelques personnes, groupes ou rôles nommés.
Reprendre la première couche seule serait une fuite. Un incident de sécurité, un dossier de litige ou un ticket lié à un départ vivent dans un projet largement accessible, et c’est le niveau de sécurité qui les protège. Le connecteur applique donc toujours la couche la plus étroite : quand un ticket porte un niveau de sécurité, ce sont ses membres qui décident, et le projet ne compte plus.
Chaque liste de membres est parcourue jusqu’à sa dernière page. Quand un groupe ne peut pas être déployé, ou qu’une page de résultats laisse un doute sur son exhaustivité, le ticket n’est rangé nulle part et attend un administrateur. Un doute sur une liste de droits ne se résout pas en devinant la fin de la liste.
Le ticket en trois champs
Le connecteur ne demande à Jira que six champs. Tout ce qui n’est pas dans cette liste n’est pas filtré après lecture, il n’est jamais demandé.
Le niveau de sécurité est lu comme une règle de droit, jamais comme du contenu. Il sert à décider qui peut lire le ticket, et son intitulé n’apparaît pas dans ce que l’IA reçoit.
Les cinq cas où un ticket attend un administrateur
Aucun de ces cas ne produit une erreur visible pour vos équipes. Le ticket est simplement lu par personne jusqu’à ce que quelqu’un décide, et la décision est enregistrée.
- Le projet est consultable sans compte, donc son audience réelle n’est pas définissable.
- Un rôle ou un groupe nommé dans les droits n’a pas pu être déployé en personnes.
- Une des personnes nommées n’est pas identifiable dans votre organisation.
- Les personnes autorisées couvrent plus d’un service.
- Une liste de membres est revenue tronquée, sans moyen de savoir s’il manquait une page.
Chaque passage relit tous les tickets accessibles
C’est un choix d’ingénierie qui coûte cher et que nous assumons. Jira ne modifie pas la date de mise à jour d’un ticket quand ses droits changent. Un ajout de niveau de sécurité, un rôle retiré, un groupe modifié ne laissent donc aucune trace dans le flux des tickets récemment modifiés.
Filtrer sur la date de mise à jour serait plus rapide, et manquerait précisément les repartages, c’est-à-dire la seule chose que ce connecteur doit attraper. Chaque passage réénumère donc tous les tickets accessibles et recalcule leur périmètre. Un ticket dont le texte n’a pas bougé ne coûte rien à revoir, et un ticket dont les droits ont bougé se re-range.
Ce que ce connecteur ne fait pas
Il ne travaille pas dans Jira. Aucun ticket n’est créé, commenté, transitionné ni fermé, et le transport utilisé n’expose aucune méthode d’écriture. Une IA branchée peut vous dire ce qu’un ticket contient, elle ne peut pas le faire avancer.
Il ignore vos champs personnalisés, et sur un Jira mûr c’est souvent là que vit la moitié de la méthode. Les six champs demandés sont ceux qui portent le texte de la décision, pas votre modèle de gestion.
La relecture complète à chaque passage rend le rafraîchissement plus lourd qu’avec une source qui sait dire ce qui a bougé. C’est le prix d’un périmètre qui suit les repartages, et nous le payons plutôt que de laisser un ticket restreint remonter dans un service qui n’y a plus droit.
Installez le cœur gratuit et vérifiez sur un projet restreint.
Le cœur de Kastel est gratuit en self-host, avec tous ses connecteurs. Le test le plus parlant est aussi le plus court. Posez un niveau de sécurité sur un ticket, puis demandez ce ticket à une IA branchée pour quelqu’un qui n’y a pas droit.
Lire le guide de connexion
