Un fil de tickets contient ce que personne n’a relu
Un dépôt de code ne contient pas seulement du code. Ses tickets portent des traces d’exécution collées telles quelles, avec le nom d’un client dedans. Ses revues portent la discussion d’une faille avant qu’elle soit corrigée. Ses commentaires portent parfois un jeton que quelqu’un a collé pour aider un collègue à reproduire un bug.
Une IA branchée sur ce matériau devient très utile à vos équipes techniques. Elle devient aussi le chemin le plus court pour qu’une phrase écrite dans un dépôt ressorte devant quelqu’un qui n’a jamais eu accès à ce dépôt. Le connecteur traite ce risque en réduisant ce qu’il lit et en durcissant ce qu’il ouvre.
Ce qu’un dépôt contient, et ce que votre Kastel en fait
Le connecteur n’interroge que la liste des tickets d’un dépôt, les commentaires d’un ticket, et les droits d’accès du dépôt. Les exclusions ci-dessous ne sont donc pas un filtre appliqué après lecture.
| Dans votre dépôt GitHub | Ce que votre Kastel en fait |
|---|---|
| Le titre et le corps d’un ticket | Lus |
| Les commentaires d’un ticket, revues comprises | Lus |
| Une pull request, son titre et son corps | Lus, une pull request est traitée comme un ticket |
| Un ticket fermé il y a trois ans | Lu, les tickets sont demandés dans tous leurs états |
| Le diff d’une pull request | Jamais demandé |
| Le code des fichiers du dépôt | Jamais demandé |
| Le README et le wiki du dépôt | Jamais demandés |
| Les étiquettes, les personnes assignées et le jalon | Renvoyés par GitHub, jamais écrits |
Le code reste dehors pour deux raisons. Un secret oublié dans un fichier n’a alors aucun chemin vers votre Kastel. Et le code ne répond à aucune question de gestion, alors que la discussion qui l’entoure y répond souvent.
Le droit de lecture se calcule sur le dépôt
GitHub ne pose aucun droit sur un ticket. Un ticket n’a pas d’audience propre, il hérite de celle de son dépôt, et il en va de même d’une pull request. Le connecteur va donc chercher l’accès du dépôt. C’est une différence de fond avec un ticket Jira, qui peut porter son propre niveau de sécurité, et cette différence vient de l’outil, pas de nous.
Cet accès se compose de deux listes. Les collaborateurs ajoutés directement au dépôt, et les équipes qui y ont accès, chaque équipe étant déployée en personnes. L’union des deux doit relever d’un seul service pour que les tickets du dépôt soient lisibles par ce service. Deux services dans l’union, une équipe impossible à déployer, une personne sans adresse lisible dans votre organisation, et les tickets du dépôt ne sont rangés nulle part.
Chaque liste est parcourue jusqu’au bout. Quand une page annonce une suite sans donner le moyen de l’atteindre, le connecteur refuse de conclure sur une liste partielle, et il le refuse aussi quand il énumère vos dépôts. Une énumération partielle ferait croire que les tickets non lus ont disparu, ce qui est la manière la plus discrète de perdre des données.
Un dépôt dont les tickets sont désactivés est sauté sans faire échouer le passage, et un dépôt que le jeton ne peut plus lire ne fait pas tomber les autres. Le reste du compte continue d’être lu.
Un dépôt public est le cas le plus strict
L’intuition dit qu’un dépôt public ne pose aucun problème, puisque le monde entier le voit déjà. Le connecteur fait l’inverse de cette intuition. Un dépôt public part directement en attente, et ses collaborateurs ne sont même pas consultés.
La raison tient à ce que le connecteur cherche à reproduire. Il ne classe pas un contenu par sa sensibilité, il reproduit l’audience de la source. Un dépôt privé a une audience finie, qu’on peut ramener à des personnes puis à un service. Un dépôt public n’a pas d’audience finie, donc il n’y a rien à reproduire, et le connecteur s’arrête là.
Le fait que tout le monde puisse lire un fil de tickets ne le rend pas anodin dans votre Kastel. Rangé dedans, il cesse d’être une page que quelqu’un pourrait trouver et devient une réponse donnée avec l’autorité de votre entreprise, à qui interroge une IA branchée. Un administrateur peut décider d’ouvrir ce dépôt à un service, et c’est une décision qui se prend et se trace. Le connecteur ne la prend pas à sa place, ce qui est la différence entre régler un accès et le gouverner.
Les tickets et les revues, jamais le code
Deux listes, l’une pour le contenu écrit dans votre Kastel, l’autre pour ce que le connecteur ne demande jamais à GitHub.
Les collaborateurs et les équipes sont lus comme une règle de droit, jamais comme du contenu. Ils servent à calculer qui peut lire les tickets du dépôt, et leurs noms n’apparaissent pas dans ce qu’une IA reçoit.
Ce que ce connecteur ne fait pas
Il ne travaille pas dans GitHub. Aucun ticket n’est ouvert, commenté ou fermé, aucune pull request n’est relue ni fusionnée. Le transport utilisé ne connaît que la lecture, et le jeton voyage dans l’en-tête, jamais dans une adresse.
Rien ne trie un ticket par son contenu. Un jeton collé dans un commentaire entre avec le commentaire, une trace d’exécution nominative entre avec le rapport de bug qui la contient. Le texte d’un commentaire est d’ailleurs conservé sans son auteur, donc une IA branchée ne pourra pas vous dire qui a écrit la phrase qu’elle vous cite.
Un changement d’accès n’est pas vu tout de suite. GitHub ne modifie pas la date d’un ticket quand une équipe gagne ou perd un dépôt, et il n’émet aucun signal par ticket pour ce genre de changement. Un passage de rapprochement recalcule l’accès de chaque dépôt suivi et re-range ses tickets, et jusque-là un dépôt repartagé garde le rangement qu’il avait.
Un ticket supprimé chez GitHub n’est pas effacé de votre Kastel. Il y est signalé comme disparu à la source et conservé, lisible par les mêmes personnes qu’avant, jusqu’à ce qu’un administrateur décide de l’effacer. Ce comportement est commun à tous les connecteurs de Kastel. Un dépôt qui sort de la portée du jeton n’est même pas touché, parce que rien ne prouve que ses tickets ont été supprimés.
Branchez un dépôt privé et regardez ce qu’une IA obtient.
Le cœur de Kastel est gratuit en self-host, avec tous ses connecteurs. La page des tarifs dit ce que ce cœur contient, ce que les plans ajoutent au-dessus, et à partir de quand un plan devient nécessaire.
Voir les tarifs
