Ce qui a changé
Auparavant, une organisation pouvait créer plusieurs Bases de Connaissances indépendantes, librement liées aux Espaces : un Espace pouvait pointer vers plusieurs Bases de Connaissances, et une seule Base de Connaissances pouvait être partagée entre plusieurs Espaces. En parallèle, chaque Espace avait également une zone « Contexte » séparée, où les fichiers étaient téléchargés pour être chargés automatiquement dans chaque conversation.
Nous avons fusionné ces deux mécanismes en un seul, maintenant appelé Connaissances, construit directement dans l'Espace. Il n'y a plus de Bases de Connaissances indépendantes vivant en dehors d'un Espace, ni de zone « Contexte » séparée.
Pourquoi nous avons fait ce changement
Un modèle plus simple à comprendre. Le modèle précédent demandait aux utilisateurs de gérer un concept abstrait — la Base de Connaissances — indépendamment de l'endroit où ils travaillaient réellement, ainsi que la relation entre ce concept et leurs Espaces. Cela soulevait des questions sans réponse évidente : à quoi sert une Base de Connaissances en elle-même ? Pourquoi la lier à cet Espace plutôt qu'à un autre ? Où un fichier devrait-il aller, dans le Contexte ou dans une Base de Connaissances ? En attachant les Connaissances à l'Espace, le concept devient concret : les Connaissances sont ce que cet Espace sait. Cela n'existe plus dans l'abstrait — cela appartient à l'objectif de l'Espace. Fusionner l'ancien « Contexte » dans les Connaissances élimine un deuxième point d'hésitation : il y a maintenant un seul endroit pour mettre les fichiers d'un Espace.
Une gouvernance des données plus claire. Dans l'ancien modèle, une seule Base de Connaissances pouvait être partagée entre plusieurs Espaces avec des membres différents. Cela rendait les droits d'accès difficiles à comprendre : qui pouvait voir quels fichiers, une fois que la même base servait des Espaces distincts ? En attachant les Connaissances à un seul Espace, l'accès aux Connaissances suit maintenant l'accès à l'Espace : les membres d'un Espace voient ses Connaissances, et personne d'autre. La portée de partage d'un fichier devient prévisible — ce qui importe particulièrement pour les organisations soumises à des exigences de confidentialité et de protection des données.
Un périmètre mieux ciblé. Un Espace a un objectif spécifique — organiser un événement, maintenir un ensemble de fichiers à jour, suivre un sujet récurrent. Les Connaissances délimitées à cet objectif tendent à améliorer la pertinence des informations récupérées lors d'une recherche : sur un ensemble cohérent de fichiers, la recherche est moins susceptible de faire remonter un document hors sujet. C'est un principe de conception qui accompagne le changement, plutôt qu'un objectif de performance en soi.
Comment les Connaissances s'insèrent parmi les sources de données d'un Espace
Pour positionner correctement les Connaissances, il est utile de voir les trois façons dont les données peuvent atteindre le LLM dans Goodweek — de la plus large à la plus ciblée :
Intégrations — le LLM récupère les informations du système d'information de l'entreprise (OneDrive, SharePoint...) lorsque l'utilisateur en a besoin. Le volume potentiel est énorme, et le défi consiste à extraire la portion pertinente par la recherche.
Les Connaissances de l'Espace — un ensemble de fichiers plus petit que le système d'information complet, mais entièrement dédié à l'objectif de l'Espace. Ces fichiers, dans n'importe quel format, sont vectorisés puis utilisés par le LLM au sein de l'Espace. C'est la mémoire durable et ciblée de l'Espace.
Fichiers ajoutés dans la conversation — un fichier déposé directement dans l'invite, utilisé pour l'échange actuel. C'est la couche la plus immédiate, ponctuelle.
Les Connaissances se situent donc dans la couche intermédiaire : plus ciblée qu'une intégration à l'échelle du système d'information, plus durable qu'un fichier ajouté à la volée dans une conversation.