Le pourquoi d’un changement vit dans la discussion d’une demande de fusion
Le code dit ce que fait le logiciel. Il ne dit presque jamais pourquoi il le fait ainsi. Cette raison vit dans la discussion d’une demande de fusion, dans l’échange où quelqu’un a proposé autre chose et où l’équipe a tranché en trois commentaires.
Un nouvel arrivant qui reprend ce module va poser la question à voix haute, ou refaire le détour qu’on avait décidé d’éviter dix-huit mois plus tôt. Une IA qui a lu ces discussions peut lui répondre en citant l’échange d’origine.
C’est aussi une des sources les plus mal rangées d’une entreprise technique. Un arbitrage peut vivre dans un projet privé de deux personnes, dans un projet interne, ou dans un dépôt public, et ces trois cas ne se traitent pas de la même façon.
GitLab a trois visibilités, et une seule décrit une audience bornée
Un projet GitLab est privé, interne ou public. Un projet privé a une liste de membres, donc une audience que l’on peut nommer. Un projet public est ouvert à tout Internet. Entre les deux, le projet interne est visible par tous les comptes connectés de l’instance, et comme cette version du connecteur ne parle qu’à gitlab.com, cela désigne l’ensemble des comptes de gitlab.com.
Le connecteur traite l’interne et le public de la même manière. Dès qu’un projet n’est pas privé, il ne regarde même pas la liste de ses membres. Ses tickets et ses demandes de fusion ne sont rangés dans aucun service et attendent la décision d’un administrateur.
Ce choix surprend, parce qu’un projet interne ressemble de loin à un projet d’entreprise. C’est justement le piège. Le mot interne ne désigne pas votre entreprise, et un connecteur qui l’assimilerait à votre organisation rangerait dans vos services du contenu dont l’audience réelle n’a rien à voir avec elles.
L’audience d’une demande de fusion n’est pas écrite sur elle
Rien sur un ticket ne dit qui a le droit de le lire. C’est son projet qui le dit, et le projet lui-même hérite de son groupe. Le connecteur additionne donc deux listes, les membres directs du projet et les membres du groupe qui le contient, hérités le long de la hiérarchie de groupes au-dessus de lui.
Un projet rangé dans l’espace personnel de quelqu’un n’hérite de rien, et son audience se limite à ses membres directs. Un projet rangé sous un groupe, avec des groupes parents au-dessus, reçoit en plus tous leurs membres. C’est ce qui fait qu’une demande de fusion relue par trois personnes peut avoir un public bien plus large.
Une fois l’addition faite, la règle est stricte. Si toutes ces personnes appartiennent à un seul service de votre organisation, les tickets du projet sont rangés dans ce service. Si elles couvrent deux services, personne ne les lit avant qu’un administrateur ne décide. Si une seule adresse ne correspond à personne de connu chez vous, le résultat est le même.
Aucune de ces listes n’est lue à moitié. Quand une page de membres annonce une suite que le connecteur ne peut pas atteindre, ou qu’un groupe refuse de se déployer en personnes, le projet entier passe en attente. Le connecteur ne complète jamais une liste de droits par une hypothèse. Chaque mise en attente laisse une trace, et la décision qui la lève en laisse une autre, ce qui est le travail que Kastel appelle gouverner son savoir.
Deux listes lues, tout le reste ignoré
Le connecteur n’appelle que deux points d’entrée par projet. Tout le reste de GitLab n’est pas écarté après coup, il n’est jamais appelé.
La visibilité et les listes de membres servent uniquement au calcul du droit de lecture. Elles ne sont pas écrites dans votre Kastel, donc une IA branchée ne reçoit jamais l’annuaire de vos projets, seulement le texte des tickets auxquels elle a droit.
Ce que les équipes techniques demandent en premier
Est-ce que notre code entre dans votre Kastel ?
Non. Le connecteur appelle deux listes par projet, les tickets et les demandes de fusion, et il en retient le titre, la description et les commentaires. Le code, les branches, les différences de fichiers, le wiki et les fichiers du dépôt ne sont pas lus, et il n’existe aucun réglage pour les faire lire.
Une IA branchée peut-elle commenter, approuver ou fermer une demande de fusion ?
Non. Le transport utilisé n’expose que des lectures. Aucune méthode de création, de modification, de suppression ni de commentaire n’existe dans ce connecteur, donc la question ne se joue pas au niveau des droits de votre jeton, elle est fermée un cran plus bas.
Si je retire quelqu’un d’un groupe, quand est-ce pris en compte ?
Au rapprochement suivant, pas à la seconde. GitLab ne modifie pas la date d’un ticket quand les droits de son projet changent, donc aucun flux de modifications ne peut signaler ce retrait. Le connecteur recalcule pour cette raison le périmètre de tous les enregistrements qu’il suit, à intervalle régulier.
Notre jeton ne voit pas les membres de certains projets, que se passe-t-il ?
Rien n’est deviné. Quand GitLab refuse de dire qui sont les membres d’un projet, ses tickets attendent un administrateur et le passage continue sur les autres projets. Un jeton révoqué, lui, arrête le passage entier avec une erreur explicite plutôt que de laisser croire que tout s’est bien déroulé. Les autres sources du catalogue des connecteurs appliquent la même discipline avec le vocabulaire de leur outil.
Si nous supprimons un ticket, disparaît-il de votre Kastel ?
Non, pas tout seul. Il demeure dans votre Kastel avec une mention de disparition à la source, lisible par les personnes qui le lisaient déjà, jusqu’à la décision d’effacement d’un administrateur. C’est le comportement de tous les connecteurs de Kastel, et il vaut mieux le savoir avant de brancher.
Ce que ce connecteur ne fait pas
Cette version ne parle qu’à gitlab.com. Un GitLab installé sur votre propre infrastructure n’est pas lu par ce connecteur en l’état, et son ajout se décide déploiement par déploiement. Si votre GitLab est auto-hébergé, c’est la première chose à nous dire, parce que la réponse change la conversation.
Il ne travaille pas dans GitLab. Aucun ticket n’est ouvert, aucune demande de fusion n’est commentée, approuvée ni fusionnée. Une IA branchée peut vous dire ce qu’une discussion contient, elle ne peut pas y répondre à votre place.
La lecture des commentaires n’est pas garantie exhaustive. Quand la pagination d’un fil très long ne peut plus être suivie, le connecteur s’arrête là où il en est plutôt que de faire échouer le passage. L’enregistrement arrive donc avec moins de commentaires, jamais avec plus, et ce manque n’est pas signalé dans ce que l’IA reçoit.
Il ne comprend pas votre méthode de travail. Les étiquettes, les jalons, les tableaux et le temps passé ne sont pas lus, donc rien de ce que votre équipe a construit autour de GitLab pour se piloter n’entre dans votre Kastel. Ce connecteur retient du texte de décision, pas votre outillage. Une source qui expose deux couches de droits contradictoires, comme Jira, pose un problème différent, et sa page le raconte.
Voyez ce que Kastel fait du contenu qu’il lit.
La page produit montre comment votre Kastel range ce qui entre, qui peut l’interroger, et ce qu’une IA externe reçoit quand elle demande quelque chose. C’est le point de départ le plus court si vous évaluez sérieusement la question.
Voir le produit
