Hyper Company Brain : concevoir une base de connaissances pour AI Agent

Quand vous demandez à Claude Code de modifier du code, il ne sait pas pourquoi votre équipe a supprimé cette branche il y a trois mois. Quand vous interrogez ChatGPT sur une décision produit, il doit relire tous les documents pour répondre. Réexpliquer l’historique du projet à chaque appel montre une différence importante entre un Agent et un RAG classique : le second sait retrouver des documents statiques, mais la connaissance d’entreprise ajoute trois dimensions qu’il ne traite pas nativement — la validité des facts, le périmètre des permissions et la chaîne de raisonnement derrière les décisions.

Sur Hacker News, Hyper dit vouloir construire un « company brain ». L’expression peut sonner marketing. Mais les détails d’architecture partagés par le fondateur dans le fil de lancement ont une vraie valeur technique : mémoire en deux couches, episodes + facts, typed edges, modèle de timestamps, et deux chemins d’injection avec hooks et MCP. Ce n’est pas un test produit. J’utilise ces informations publiques pour décortiquer le problème de conception d’une « mémoire d’entreprise » : une checklist en cinq couches, un pilote de 7 jours et une grille de risques pour l’évaluation.

Trois types de contexte que le RAG classique ne sait pas porter

Le RAG recherche des documents, renvoie des fragments et laisse le modèle répondre. Ce flux fonctionne pour une base de connaissances statique, mais la connaissance d’entreprise a trois dimensions que le RAG ne traite pas par défaut.

Un RAG traditionnel trie par recency ou relevance. Il ne sait pas déterminer si une information a été remplacée par un newer fact qui la supersedes. Hyper associe deux timestamps à chaque fact : introduced_at indique sa première apparition, invalidated_at indique son moment d’invalidation. Lors du retrieval, les facts invalidés sont filtrés, sans dépendre de la date de mise à jour d’un document.

Le périmètre des permissions devient plus sensible dans une organisation. Un appel Agent peut représenter un membre d’équipe précis. Il ne doit pas lire des contenus hors de son projet. Hyper utilise des access-control tags pour marquer la visibilité de chaque fact, puis la couche de retrieval filtre les résultats selon l’identité de l’appelant avant de répondre. C’est plus fin qu’une « recherche d’entreprise » classique, qui s’arrête souvent à la permission au niveau du document. Un company brain doit couper au niveau du fact.

La raison de la décision est ce que le RAG classique attrape le moins bien. Si vous demandez « pourquoi PostgreSQL plutôt que MongoDB ? », le RAG peut retrouver le paragraphe de conclusion dans un document d’architecture. Mais ce paragraphe ne contient pas forcément la discussion technique d’il y a trois mois, les compromis et la logique finale. La couche episodes de Hyper conserve les nœuds de conversation d’origine, tandis que la couche facts pointe vers l’episode source via un typed edge derived from. Le retrieval peut donc suivre la relation jusqu’à la chaîne de raisonnement, pas seulement jusqu’au résultat.

Décomposition de l’architecture mémoire en deux couches de Hyper

Hyper organise la mémoire en deux couches : Episodes pour le stockage brut, Facts pour la couche structurée, puis un knowledge graph pour les relier.

Couche Episodes : elle conserve les nœuds de conversation d’origine et ne jette pas le contexte. Elle sert d’ancre de provenance pour les facts. Quand un Agent doit remonter le processus de décision, il peut suivre un edge derived from depuis le fact vers le fragment de conversation d’origine, au lieu de lire seulement une conclusion résumée.

Couche Facts : elle structure l’information en triplets subject-predicate-object. Chaque fact contient un sujet, une relation et un objet, plus des timestamps et des typed edges. Le fondateur a décrit publiquement trois types de typed edges :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Modèle de timestamps : chaque fact a deux lignes de temps. La ligne T indique quand l’événement a eu lieu, par exemple « la décision a été prise en mars ». La ligne T’ indique quand le système a ingéré le fact, par exemple « ce fact a été écrit dans la base en juin ». Cette séparation existe parce que la connaissance d’entreprise arrive souvent en retard. Une conclusion de réunion peut être saisie une semaine plus tard. Le système doit distinguer le moment où le fait s’est produit et celui où il l’a appris.

Points clés de l’architecture :

• Les Episodes ne sont pas résumés puis jetés ; ils conservent les nœuds de conversation d’origine, selon le fondateur sur HN et le contexte du papier Zep.
• Les Facts sont structurés en triplets, avec timestamps et typed edges, d’après les éléments partagés sur HN.
• introduced_at / invalidated_at marquent le cycle de vie du fact, et la couche de retrieval filtre les contenus invalidés.
• Le knowledge graph utilise les typed edges pour représenter les « relations », pas seulement les « facts ». C’est la différence majeure avec une simple base vectorielle.

L’objectif de cette architecture n’est pas de stocker plus de données. Il est de permettre à l’Agent de trouver du contexte en suivant des relations. Une base vectorielle classique renvoie des fragments similaires, mais elle ne connaît ni dépendance logique, ni relation de remplacement, ni conflit entre fragments. La combinaison typed edges + timestamps permet aux résultats de retrieval de transporter des métadonnées : d’où vient ce fact, est-il encore valide, a-t-il été remplacé ?

Deux chemins : retrieval et injection

Une fois la connaissance écrite, l’Agent dispose de deux chemins d’usage : le retrieval, où il interroge activement, et l’injection, où il reçoit passivement du contexte.

Mécanisme de retrieval d’après le fondateur sur HN :

• Recherche full-text Postgres : correspondance par mots-clés, utile pour les requêtes exactes comme « la définition de tel API endpoint ».
• Recherche sémantique par embedding : similarité vectorielle, utile pour les questions floues comme « quelle était la conclusion sur l’optimisation des performances ? ».
• Reciprocal Rank Fusion (RRF) : fusionne les rappels full-text et sémantique, puis renvoie un classement global.
• Filtrage par access-control tags : ajuste les résultats selon l’identité de l’appelant pour préserver la frontière des permissions.

Cette combinaison diffère d’une base purement vectorielle. Celle-ci ne fait que du rappel sémantique et peut manquer des requêtes à mots-clés exacts. Hyper combine les deux chemins avec RRF, puis tient compte à la fois des correspondances de mots-clés et de la similarité sémantique au moment du classement.

Comparaison des chemins d’injection : hooks et MCP sont deux canaux de données différents.

Les deux chemins peuvent coexister. Le fondateur de Hyper explique que les hooks servent à injecter du contexte en temps réel dans l’Agent, par exemple charger automatiquement les documents projet quand vous ouvrez Claude Code. MCP sert à l’appel actif d’outils externes, par exemple interroger Notion ou Gmail. Mais certains retours dans le fil ont questionné la transparence des hooks : l’utilisateur sait-il clairement quelles données sont injectées automatiquement dans la conversation de l’Agent ?

À l’évaluation, vérifiez deux points : les hooks ont-ils des invites d’installation explicites, et le périmètre de permissions du MCP server est-il contrôlé par un administrateur ? La documentation developer mode d’OpenAI indique que les MCP apps exigent une vérification de sécurité, et que les plans Enterprise peuvent utiliser RBAC pour contrôler l’accès. Le cadre MCP est donc relativement mûr côté gouvernance, alors que la transparence des hooks dépend du design produit.

Checklist de conception en cinq couches pour un company brain

Que vous construisiez ou choisissiez une solution, vérifiez si ces cinq couches ont une réponse. L’absence d’une couche finira par se voir en usage réel.

Première couche : connexion des sources de données

• Choix des outils : Notion, Gmail, Slack, GitHub, Linear, Jira, selon le workflow de l’équipe.
• Mode de connexion : webhooks pour le temps réel ou polling périodique ; les webhooks répondent vite mais nécessitent le support du système source.
• Nettoyage des données : filtrer le bruit, comme les canaux Slack de discussion libre, marquer les informations sensibles, unifier l’encodage.
• Import initial : historique complet ou seulement nouvelles données ; l’historique peut contenir beaucoup de facts obsolètes.

Deuxième couche : Fact Schema

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Structure du fact : triplet subject-predicate-object, avec un format unique pour chaque fact.
• Timestamps : introduced_at pour la première apparition + invalidated_at pour l’invalidation. Sans les deux, il devient difficile de juger le cycle de vie.
• Typed edges : au minimum derived from pour la provenance, supersedes pour le remplacement et tension pour le conflit.
• Stratégie de conflit : marquer automatiquement tension pour revue humaine, ou choisir le newer fact selon le timestamp.

Troisième couche : retrieval

• Combinaison de rappel : full-text (mots-clés) + sémantique (embedding) + fusion RRF ; le rappel purement sémantique peut manquer les requêtes exactes.
• Filtrage des permissions : access-control tags au niveau fact, selon l’identité de l’appelant.
• Classement : combiner recency, relevance et fact validity, puis filtrer les facts invalidés.
• Objectif de latence : réponse de retrieval < 500 ms en pratique ; au-delà, les appels Agent deviennent nettement plus lourds.

Quatrième couche : injection

• Choix du chemin : hooks pour l’injection de contexte en temps réel, MCP pour l’appel actif de l’Agent. Les deux peuvent coexister.
• Compatibilité Agent : Claude Code, Cursor, ChatGPT, Codex doivent supporter le chemin retenu.
• Cadre de gouvernance : les hooks doivent afficher clairement leur installation ; les permissions MCP server doivent être contrôlées par les administrateurs.
• Contrôle du volume de données : limiter la longueur du contexte injecté pour éviter le dépassement de tokens, et privilégier les facts les plus pertinents.

Cinquième couche : gouvernance

• Héritage des permissions : traduire les permissions de la source en visibilité au niveau fact. Un fact issu d’un canal Slack privé ne doit pas devenir visible par tous.
• Journaux d’audit : qui a injecté quel fact, à quel moment, et quels facts l’Agent a lus. En cas de problème, il faut pouvoir remonter la chaîne.
• Correction humaine : marquer les facts erronés, concevoir un flux invalidated, permettre l’ajout manuel de facts de clarification.
• Export de données : vérifier si le fact store complet peut être exporté en JSON/CSV afin d’évaluer le lock-in fournisseur.

La logique de cette checklist est simple : la couche source décide « d’où ça vient », la couche fact décide « quelle structure stocker », la couche retrieval décide « comment trouver », la couche injection décide « comment donner », et la couche gouvernance décide « qui contrôle et comment corriger ». S’il manque une couche, la base de connaissances d’entreprise finira par bloquer.

Parcours de pilote sur 7 jours

Une petite équipe ne devrait pas connecter tout Slack, les e-mails ou le CRM dès la première semaine. Les permissions sont complexes, le bruit est élevé, et les problèmes de gouvernance risquent de prendre toute la place dès le pilote. Commencez par des sources peu risquées, validez le rappel et la correction, puis élargissez.

Day 1-2 : choisir des sources peu risquées

• Documents Notion publics, comme une roadmap produit ou des spécifications techniques.
• GitHub README et Wiki, comme l’architecture projet ou la documentation d’API.
• Exclusions : canaux Slack privés, historiques d’e-mails, données CRM client, car ils sont sensibles côté permissions et très bruyants.

Day 3 : concevoir le Fact Schema

• 3 à 5 champs : subject, predicate, object, introduced_at, source.
• Ne cherchez pas la perfection : l’objectif du pilote est de valider le chemin de retrieval, le Schema pourra évoluer.
• Convenez de noms : subject avec un format uniforme, par exemple ProjectX, et predicate sous forme de verbe, par exemple uses.

Day 4-5 : tester le retrieval et l’injection

• Test retrieval : préparez 5 à 10 requêtes et vérifiez si les facts clés sont retrouvés.
• Test injection : choisissez un Agent, par exemple Claude Code ou Cursor, et vérifiez qu’il peut lire le contexte injecté.
• Mesurez la latence : la réponse de retrieval est-elle < 500 ms, et l’Agent cite-t-il correctement les facts après injection ?

Day 6-7 : replay et correction humaine

• Rejouez d’anciennes requêtes pour voir si les résultats contiennent des facts faux ou obsolètes.
• Notez les erreurs : listez les facts à invalidated et concevez le flux de marquage.
• Concevez la correction : ajout humain de facts de clarification + timestamp invalidated_at sur les facts erronés.

À éviter la première semaine :

• Ne connectez pas Slack, e-mail ou CRM : permissions et bruit sont trop complexes.
• Ne poursuivez pas un Schema parfait : validez d’abord le chemin de retrieval, puis itérez.
• Ne connectez pas de sources de production : utilisez des données de test ou des documents publics pour valider le flux.

À la fin du pilote, vous devriez avoir un flux retrieval + injection fonctionnel, 5 à 10 facts vérifiés et un processus de correction. Ce sont les prérequis avant d’élargir les sources : d’abord vérifier que le système peut trouver, lire et corriger, puis connecter plus d’outils.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Tableau des risques de sélection

Au moment de décider, vérifiez sept dimensions de risque. Chaque dimension doit porter une source et un niveau de confiance.

Parmi ces sept dimensions, l’export de données et le lock-in fournisseur sont les points à examiner en priorité. Le fondateur indique dans les commentaires que l’export est pris en charge, mais je n’ai pas trouvé d’engagement officiel complet. Il faut donc confirmer si le format est structuré, JSON ou CSV, s’il exporte tout le fact store avec typed edges et timestamps, et quel nettoyage serait nécessaire pour migrer vers un autre système.

La transparence des hooks est un autre risque facile à sous-estimer. Les hooks injectent du contexte côté client, et l’utilisateur peut ne pas savoir quelles données sont automatiquement chargées dans la conversation de l’Agent. Pendant l’évaluation, vérifiez si le produit affiche clairement l’installation et si l’utilisateur peut voir et contrôler le périmètre injecté.

L’héritage des permissions a une direction technique publique via les access-control tags, mais ses règles précises ne sont pas publiques. Les questions concrètes sont simples : comment un fact issu d’un canal Slack privé devient-il visible au niveau fact ? Comment couper les données CRM client par équipe ? Que vous achetiez ou construisiez, cette logique de mapping doit être conçue.

Étapes suivantes et lectures liées

Pour approfondir le lien entre Agents et bases de connaissances, ces articles BetterLink complètent bien le sujet :

• RAG + Agent : architecture d’application IA de nouvelle génération — comment les résultats de retrieval peuvent piloter les décisions d’un Agent.
• Systèmes de mémoire pour AI Agent : aider les agents à garder le contexte — architecture de mémoire personnelle d’Agent et différence avec une mémoire partagée d’entreprise.
• Tutoriel Workers AI + Vectorize RAG — détails pratiques de Cloudflare Vectorize pour construire un petit système RAG.
• Monitoring et auto-récupération d’AI Agent — connecter mémoire et exécution pour détecter et relancer les échecs.
• Agent tool calling en pratique — détails MCP et tool calling utiles pour compléter le chemin d’injection.

Conclusion

Hyper reste un produit jeune. Ses détails d’architecture publics — mémoire en deux couches, typed edges, modèle de timestamps, double chemin hooks/MCP — forment néanmoins un bon cas d’étude pour comprendre la conception d’une « mémoire d’entreprise ». Pour une petite équipe qui évalue ou construit ce type de système, les trois points à vérifier en priorité sont l’export de données, la transparence des hooks et la gestion des conflits.

En phase pilote, partez d’un workflow étroit : des documents Notion publics ou un GitHub README, puis validez le rappel du retrieval et le mécanisme de correction avant de brancher Slack ou l’e-mail. Ne cherchez pas un Schema parfait dès le départ. Le cycle de vie des facts, l’héritage des permissions et la correction humaine doivent être ajustés à partir d’essais réels.

Si vous utilisez déjà Claude Code ou Cursor, vous pouvez d’abord injecter les documents projet via hooks et observer si l’Agent cite correctement les facts. L’étape suivante consiste à fermer la boucle entre mémoire et exécution : monitoring et auto-récupération de l’Agent, afin que les échecs soient détectés et réessayés automatiquement.