Guru sait qu’une fiche vieillit, et il le dit
Guru existe pour que le savoir d’une entreprise reste vérifié. Une fiche a un propriétaire, une personne chargée de la revoir, et un état qui indique si elle fait encore autorité ou si elle demande un nouveau passage. C’est la raison pour laquelle les équipes de support et les équipes commerciales y rangent leurs réponses au lieu de les laisser dans un dossier de documents.
Une IA branchée sur cette base n’a aucune raison de deviner cet état. Elle lit un texte, elle répond, et elle répond de la même façon que la fiche ait été revue hier ou abandonnée depuis trois ans. Sur une base de connaissance, c’est le point qui décide de tout, et brancher davantage de sources ne le règle pas.
L’état de vérification arrive avec la fiche
Le connecteur ne classe pas vos fiches par fraîcheur et n’en cache aucune. Il fait quelque chose de plus simple, et de vérifiable dans le comportement du produit. Le texte d’une fiche est écrit dans votre Kastel accompagné du nom de sa collection, de l’état de vérification tel que Guru le renvoie, et de sa date de dernière modification. L’IA qui reçoit la fiche reçoit donc dans le même mouvement de quoi savoir ce qu’elle vaut.
Le connecteur ne connaît d’ailleurs pas les libellés de vos états. Il transmet la valeur que Guru lui donne, sans seuil, sans note et sans hiérarchie inventée de notre côté. Une fiche qui demande un nouveau passage de vérification le dit dans les termes de Guru, et c’est votre convention interne qui reste la référence.
Ce qui n’entre pas, en revanche, ce sont les personnes. Le propriétaire d’une fiche, ses collaborateurs et celui qui l’a vérifiée ne sont jamais lus. L’état de vérification entre dans votre Kastel sans le nom de la personne qui en répond, et c’est le même arbitrage que sur les autres sources de savoir, du connecteur Confluence aux documents ClickUp.
Le droit de lecture se reconstruit à l’envers, collection par collection
Guru ne place pas les droits sur la fiche, il les place sur la collection qui la contient. Et son interface ne dit pas qui a le droit de lire une collection. Elle dit l’inverse, groupe par groupe, quelles collections ce groupe peut ouvrir. Il faut donc retourner l’information pour obtenir la seule chose qui nous intéresse, à savoir la liste des personnes qui peuvent lire chaque collection.
Le connecteur refait ce travail à chaque passage. Il parcourt les groupes jusqu’au dernier, les collections de chaque groupe, les membres de chaque groupe, puis les attributions accordées à des personnes en direct. Chaque liste est suivie jusqu’à sa dernière page. La collection obtient alors le service que ses lecteurs ont en commun, et la fiche prend le périmètre de sa collection.
Refaire la carte plutôt que la mémoriser a une conséquence directe. Retirer quelqu’un d’un groupe dans Guru lui retire l’accès au passage suivant, sans que personne ait à s’en souvenir chez nous, et c’est aussi la seule façon d’attraper un repartage, puisque changer les membres d’un groupe ne modifie pas la date des fiches concernées.
Le doute, lui, ferme toujours la porte. Une liste de membres qui revient incomplète met en attente les collections qu’elle touche. Un incident dont la portée n’est pas bornable, une liste de groupes tronquée par exemple, met en attente la totalité des collections. Et une audience répartie sur plus d’un service n’est jamais résolue en choisissant le service le plus probable, elle attend la décision d’un administrateur.
Ce qu’une fiche laisse entrer
Le connecteur ne lit qu’une chose dans une fiche, son corps, et il le nettoie avant de l’écrire.
Le nettoyage du texte a une raison précise. Une fiche de support contient souvent un lien d’accès à un outil, l’adresse d’un client ou la mention d’un collègue. Ces trois choses sont remplacées par un repère neutre avant que la fiche ne soit écrite, y compris quand l’adresse était encodée dans le code de la page plutôt qu’écrite en clair.
Les questions que pose une base de connaissance
Voici quatre objections précises, avec la réponse que le connecteur permet de donner, et rien de plus.
Est-ce qu’une IA peut me répondre depuis une fiche qui n’est plus à jour ?
Oui, si cette fiche est encore vivante dans Guru et que la personne pour qui l’IA travaille a le droit de lire sa collection. Le connecteur ne juge pas le contenu d’une fiche. Ce qu’il fait, c’est transmettre l’état de vérification et la date de dernière modification avec le texte, pour que la réponse puisse en tenir compte au lieu de supposer.
Qui décide qu’une collection revient à tel service ?
Vos droits dans Guru, et rien d’autre. Le service d’une collection est celui que ses lecteurs ont en commun, une fois les groupes déployés en personnes réelles. Il n’y a pas de réglage Kastel qui ouvre une collection à un service, et une collection dont les lecteurs couvrent deux services attend un administrateur au lieu d’être attribuée d’office.
Que se passe-t-il quand l’audience d’une collection n’a pas pu être établie ?
Les fiches de cette collection entrent dans votre Kastel et n’y sont lues par personne. Elles ne sont attribuées à aucun service, elles n’apparaissent dans aucune réponse, et elles attendent qu’un administrateur tranche. Une carte des droits impossible à reconstruire produit ce résultat pour toutes vos collections d’un coup, ce qui se voit immédiatement et se corrige dans Guru.
Est-ce qu’une IA peut créer ou corriger une fiche dans Guru ?
Non. Le connecteur n’expose aucune méthode de création, de modification ni d’archivage, et il ne parle qu’à un seul serveur, celui de Guru. Une IA branchée peut vous dire ce qu’une fiche contient et vous signaler qu’elle demande un nouveau passage. La corriger reste un geste humain, dans Guru.
Ce que le connecteur Guru ne fait pas
Il ne vérifie rien à votre place. L’état d’une fiche est celui que Guru donne, transmis tel quel. Si vos fiches ne sont pas tenues à jour dans Guru, votre Kastel transmettra fidèlement des fiches qui ne le sont pas, avec la mention qui va avec. Aucune relecture et aucune notation de qualité ne sont faites de notre côté.
Il ne sait pas être plus fin qu’une collection. Guru n’expose pas d’audience par fiche, donc deux fiches de la même collection ont exactement le même public dans votre Kastel. Une fiche sensible rangée dans une collection largement ouverte sera lisible par tout le service auquel cette collection revient, et le seul endroit où corriger cela est Guru.
Le nettoyage du texte fait perdre de l’information utile. Un lien vers une procédure interne devient un repère neutre, donc une IA qui lit la fiche ne pourra pas vous rendre ce lien. Nous préférons cette perte à la sortie d’adresses et de liens d’accès dans un contexte partagé, et c’est un arbitrage discutable que nous écrivons plutôt que de le taire.
Il n’efface pas une fiche que vous archivez. Une fiche archivée cesse d’entrer dès le passage suivant, et la copie déjà absorbée est marquée comme disparue à la source, puis conservée. Elle reste lisible par les mêmes personnes qu’avant jusqu’à ce qu’un administrateur l’efface. C’est le point à connaître quand on retire une fiche parce qu’elle était devenue fausse, puisque l’archiver ne suffit pas à la faire disparaître de votre Kastel.
Voyez ce que votre Kastel fait d’un savoir déjà écrit.
La page produit montre comment votre Kastel se construit, ce qu’il retient des sources qu’on lui branche, et ce qu’une IA en reçoit selon la personne pour qui elle travaille.
Voir le produit
