Le Company Brain de Hyper : comment concevoir une base de connaissances pour agents IA

Ce qui m’a fait m’arrêter sur Hyper, ce n’est pas l’expression company brain. C’est sa façon de nommer un problème dans lequel beaucoup d’équipes tombent déjà : les agents IA savent désormais modifier du code sur plusieurs tours, écrire des e-mails et exécuter des scripts, mais ils ignorent souvent quel plan l’équipe a rejeté hier. Demandez à Codex de modifier une page de checkout et il s’appuiera peut-être sur le langage produit d’un ancien PR. Demandez à Claude Code d’inspecter une contrainte d’API et il rouvrira Drive en manquant la décision Slack plus récente. Une collègue humaine ajoute naturellement : « N’utilise plus ce plan. » Un agent ne développe pas cette mémoire partagée tout seul.

Je traiterais Hyper d’abord comme une étude de cas d’architecture. C’est encore tôt, et les documents publics ne valent pas une validation par des tiers. Pourtant, les détails de sa page YC et de la discussion Launch HN aident à clarifier ce qu’une base de connaissances d’entreprise pour agents IA doit vraiment faire : ce n’est pas juste de la recherche de documents, ni juste un connecteur MCP. C’est une façon de laisser les agents agir dans le bon contexte d’entreprise, à jour et conscient des permissions.

Là où le RAG classique se bloque

Le RAG classique est bon pour trouver des chunks dans des documents. Vous découpez Markdown, PDF et pages web en chunks, vous les embeddez, vous récupérez du contenu similaire à la requête, et vous laissez le modèle composer une réponse. BetterLink a couvert cette voie dans l’architecture RAG + agent, et elle suffit pour le Q&A de connaissances, les FAQ de support et l’explication de codebase.

Le contexte d’entreprise est plus désordonné. L’agent ne doit pas seulement trouver du contenu similaire. Il doit aussi savoir si le contenu est toujours valide, qui peut le voir et pourquoi la décision a été prise.

Les anciennes et nouvelles informations se télescopent

Prenez une petite décision de release. La réunion du lundi dit : « Livrer vendredi. » Le mercredi, le retour client change, et le product owner repousse le lancement à lundi prochain. Une base vectorielle peut stocker les deux affirmations. Laquelle vient en premier dépend de la requête, de l’embedding, du chunking et du ranking. Si l’agent récupère l’ancienne note « vendredi », il continuera d’écrire la mauvaise annonce et de planifier le mauvais travail.

Un design plus sûr conserve les deux faits mais marque le nouveau comme remplaçant l’ancien : qui l’a dit, quand, quelle portée est affectée et pourquoi la conclusion précédente est devenue invalide. Alors, quand l’agent répond à « Pourquoi a-t-on reporté ? », il peut retracer l’historique de décision au lieu de perdre l’ancien contexte.

Les permissions doivent agir avant la réponse

Dès qu’une base de connaissances d’entreprise alimente un agent capable d’agir, les permissions cessent d’être un détail. Sales, support, ingénierie et direction peuvent interroger le même client et devraient recevoir des portées d’information différentes. Les recommandations d’OpenAI sur les connecteurs d’équipe font un point similaire : ChatGPT ne voit que le contenu auquel l’utilisateur a déjà accès, et les connecteurs respectent les limites de permissions existantes.

Cette vérification doit se faire avant le retrieval, pas après que le modèle a déjà vu le contexte et qu’on lui demande d’être sage. Filtrez d’abord les données invisibles ; ensuite récupérez, classez et injectez. Sinon l’agent peut divulguer des informations sensibles via les logs, les brouillons ou les appels d’outils.

Les agents ont aussi besoin du pourquoi

Beaucoup de documents d’entreprise consignent des résultats, pas des raisons. Un plan de design a peut-être été rejeté parce que l’adéquation à la marque était mauvaise, que les ventes ont entendu des clients résister, que la dette technique était trop élevée, ou que l’équipe manquait simplement de bande passante à ce moment-là. Si l’agent ne voit que le résultat, il peut répéter la même erreur dans un cadre légèrement différent.

La mise à jour mémoire d’OpenAI cadre la mémoire utile autour de reporter le contexte, suivre les préférences et rester à jour dans le temps. Au niveau de l’entreprise, j’ajouterais une exigence : le système devrait expliquer les contraintes derrière une décision. Sans cette couche, un agent cherche seulement plus vite, il ne comprend pas mieux l’entreprise.

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

Tester l'MVP →Pub

Ce que révèlent les documents publics de Hyper

Quelques détails du lancement public de Hyper m’importent. Ils ne prouvent pas que le produit est parfait, mais ils sont plus concrets que « mettre Slack et Drive dans une base vectorielle ».

Le premier détail est la séparation entre episodes et facts. Dans le fil de lancement HN, les fondateurs décrivent les sources brutes comme des episodes : documents, e-mails, calendriers, Slack, notes Granola, etc. Les facts sont le sens extrait de ces episodes. Ils ont la forme d’enregistrements subject-predicate-object, avec un plain summary plus des horodatages d’introduction et d’invalidation. Le matériel brut reste disponible comme source of truth, tandis que les facts extraits soutiennent un raisonnement et un retrieval plus rapides.

Le deuxième détail est les arêtes de relation entre facts. La discussion publique mentionne des facts en tension les uns avec les autres, derived l’un de l’autre, ou superseded par un fait plus récent. C’est important pour les agents car le contexte d’entreprise n’est pas un dossier plat de notes. C’est un historique de décisions changeantes.

Le troisième détail est le retrieval hybride. Hyper a mentionné query expansion, recherche sémantique par embedding, Postgres full-text search et reciprocal rank fusion. Rien de mystique, mais c’est pratique. Le retrieval sémantique est bon pour le sens. La recherche full-text est meilleure pour les noms de clients exacts, les ID de tickets, les noms de fonctions et les numéros de contrat. La fusion réduit la dépendance à une seule voie de retrieval.

Le quatrième détail est le marquage des permissions. Chaque fait porte une provenance et des access-control tags, et le retrieval n’est évalué que contre les facts et episodes auxquels l’utilisateur a accès. Sans cela, un company brain devient vite une faille de sécurité.

Le cinquième détail est la répartition entre hooks et MCP. La documentation MCP décrit MCP comme un standard ouvert pour connecter les applications IA à des systèmes externes, et l’OpenAI Agents SDK prend aussi en charge plusieurs intégrations MCP. MCP est utile quand un agent interroge activement un outil, mais il dépend du fait que l’agent reconnaisse quand l’outil doit être appelé. Hyper a dit dans le fil HN que pour des outils comme Claude Code, Codex et Cursor, il utilise aussi des lifecycle hooks pour injecter ou extraire du contexte quand une session démarre, qu’un prompt est soumis ou qu’un tour d’agent se termine. Ce compromis est controversé, surtout sur la transparence d’installation, mais il pointe un vrai problème : certain contexte ne peut pas dépendre du fait que l’agent pense à le demander.

Construire un company brain en pièces vérifiables

Si votre équipe ne veut pas encore introduire un nouveau fournisseur, vous pouvez quand même bâtir une petite version. Ne commencez pas par connecter chaque source de données. Commencez par séparer le système en pièces que vous pouvez réellement examiner.

Source : les inputs bruts doivent être rejouables

La couche source n’a pas besoin d’une couverture totale dès le premier jour. De meilleurs points de départ sont les fichiers Markdown de décisions produit, les résumés de PR récents, les issues publiques et les articles de base de connaissances de support. Les données Slack, e-mail et CRM sont denses, mais aussi bruitées et lourdes en permissions. Ajoutez-les plus tard.

Chaque élément source doit porter des métadonnées de base : type de source, URL ou chemin de fichier d’origine, date de création, date de mise à jour, auteur, portée de visibilité et un hash. Si un fait est extrait incorrectement plus tard, l’équipe doit pouvoir revenir au texte original.

Fact : un fait devrait être plus qu’un résumé

Un fait utilisable a besoin de champs comme subject, predicate, object, summary, source, date d’introduction, date d’invalidation, tags de permission, confiance et enregistrements de correction humaine. Ce n’est pas de l’accumulation de champs. Cela donne des limites à l’agent quand il répond.

Par exemple :

L’extraction de faits ne sera pas parfaite au premier essai, donc il faut une voie de correction humaine. Dans la discussion HN, quand quelqu’un a interrogé sur les données désordonnées et contradictoires d’entreprises matures, le fondateur de Hyper a mentionné des corrections dures via un skill MCP comme /correct. Cette direction vaut la peine d’être copiée : laissez un humain dire explicitement « C’est faux ; utilise ceci à la place » et gardez la trace de correction.

Retrieval : la recherche hybride est plus fiable qu’une seule voie

Le retrieval vectoriel est utile pour le sens flou, mais les noms de clients, SKU, ID de tickets, noms de fonctions et numéros de contrat nécessitent souvent des correspondances par mots-clés. Je diviserais le retrieval en trois étapes :

1. Filtrer par identité, projet, source de données et permissions de l’utilisateur.
2. Lancer en parallèle recherche sémantique, recherche full-text et expansion de voisinage de graphe.
3. Fusionner ou reranker les résultats, puis n’injecter qu’un petit ensemble de faits hautement pertinents.

Plus de contexte n’est pas toujours mieux. Si le contexte est trop large, le modèle traitera des faits non liés comme des indices. Une meilleure valeur par défaut est d’injecter 5-15 faits étroits avec provenance et confiance. Si l’information manque, l’agent doit poser une question ou vérifier la source d’origine.

Injection : MCP, hooks et contexte manuel ont des limites différentes

MCP est un point d’entrée, pas un système de mémoire complet. Il laisse les agents accéder à des outils et sources de données, et peut exposer des capacités comme search_company_facts, correct_fact ou get_decision_history. Vous pouvez étendre le modèle de l’appel d’outils par les agents et exposer la base de connaissances d’entreprise comme un outil.

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

Commencer →Pub

Les hooks sont plus stables car ils peuvent injecter du contexte automatiquement au démarrage d’une session ou à la soumission d’un prompt, sans attendre que le modèle appelle un outil. Ils comportent aussi un risque. Les utilisateurs doivent savoir ce qui a été installé, quand cela s’exécute, ce que cela lit et comment le désactiver. Ce point a suscité des réticences dans les commentaires HN, et les petites équipes devraient rendre visibles les notifications, logs et interrupteurs.

Le contexte manuel reste utile. Pour les tâches à haut risque, laisser un humain choisir quelle connaissance projet est autorisée pour ce run peut être plus sûr que l’automatisation totale. AI-first ne veut pas dire que chaque étape doit être sans surveillance.

Gouvernance : correction, export et audit doivent venir tôt

Plus un company brain devient utile, plus il est coûteux de migrer ailleurs. Des gens sur HN ont soulevé des inquiétudes de vendor lock-in, et elles sont raisonnables. Si chaque agent dépend de la même couche de connaissances, export, suppression, sauvegarde et audit ne sont pas des fonctionnalités bonus.

Je poserais ces questions pendant le pilote : peut-on exporter les facts en JSON ou CSV ? Peut-on supprimer les episodes bruts ? Un changement de permission déclenche-t-il un re-filtrage ? Y a-t-il un log de quel fait un agent a utilisé dans quelle tâche ? Une correction humaine écrase-t-elle un ancien fait ou préserve-t-elle une chaîne d’historique ? Demander tôt évite des dettes plus tard.

Comment choisir entre les options

Ces options résolvent des problèmes différents, les noms peuvent donc induire en erreur.

Si les employés veulent seulement demander « Où est la politique de notes de frais ? », la recherche entreprise ou le RAG classique suffit. Si un agent va modifier du code, envoyer des e-mails, écrire des relances commerciales ou résumer le risque client, le système a besoin de plus : ce fait est-il toujours valide ? La source est-elle fiable ? L’utilisateur est-il autorisé à le voir ? L’action a-t-elle besoin d’une confirmation ?

Les connecteurs d’équipe d’OpenAI amènent déjà du contenu des outils d’équipe dans les conversations. L’écosystème MCP facilite la connexion des agents à plus d’outils. Un company brain se situe entre ces couches : il transforme du contenu épars en contexte d’entreprise continuellement mis à jour, traçable, filtré par permissions et réutilisable par différents agents.

Un pilote de 7 jours : commencer par un workflow étroit

Vous n’avez pas besoin de connecter toute l’entreprise pour tester un company brain. Choisissez un workflow d’agent à faible risque et à fréquence élevée, et faites-le tourner une semaine.

Jours 1-2 : choisir le workflow et les sources

Choisissez un scénario clairement délimité, comme « demander à Codex de mettre à jour une petite fonctionnalité selon les dernières contraintes produit » ou « demander à un agent support de rédiger une réponse à partir de notes de bugs récentes ». Ne connectez que trois types de sources : docs de décisions produit, résumés de PR récents et issues publiques. Ne commencez pas avec toutes les données Slack, e-mail et CRM.

Notez la portée interdite : pas d’e-mails réels, pas de changements de configuration de production, pas de données finance ou RH, et pas de faits sans source traités comme des conclusions.

Jours 3-4 : extraire faits et relations de conflit

Extrayez 50-100 faits de ces sources. Faites-en une partie manuellement, puis avec l’aide d’un modèle. Chaque fait doit inclure source, temps, permissions et confiance. En cas de conflit, ne supprimez pas l’ancien à la hâte. Marquez la relation : supersedes, supplements, conflicts with ou needs confirmation.

Vous pouvez commencer avec un schéma simple. Une base de données de graphe complexe n’est pas nécessaire pour un pilote. Tables Postgres, JSONB, index full-text et extensions vectorielles peuvent porter une petite expérience. La discussion publique de Hyper mentionnait aussi que Postgres reste pratique dans ce type de système, car métadonnées structurées et relations de type graphe peuvent cohabiter.

Jours 5-6 : injecter le contexte et rejouer les tâches

Ajoutez un outil ou un hook à l’agent : pour la tâche en cours, il renvoie 5-15 faits pertinents avec provenance. Puis rejouez 20 tâches réelles et suivez trois chiffres :

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

Obtenir -15 % →Pub

• Combien de fois des humains doivent-ils encore ajouter du contexte de fond ?
• Combien de fois l’agent cite-t-il des faits périmés ou faux ?
• Un fait non autorisé apparaît-il, ou un contexte trop large fait-il dévier l’agent ?

Ne jugez pas seulement si la sortie semble soignée. La valeur d’un company brain est de réduire les explications répétées, de diminuer les erreurs de faits périmés et de rendre l’agent plus prudent quand les preuves sont incomplètes.

Jour 7 : étendre, mettre en pause ou changer de direction

Si seules quelques-unes des 20 tâches en profitent, n’étendez pas encore à toute l’entreprise. Le workflow ne convient peut-être pas, ou l’extraction de faits est trop grossière. Si les relances baissent, les citations périmées diminuent et aucun fait non autorisé n’apparaît, ajoutez une source de plus, comme des notes de réunion ou un canal Slack sélectionné.

L’étape suivante est de combiner cela avec le monitoring et la récupération des agents IA : quand l’agent utilise un fait à faible confiance, un fait contradictoire ou une action à haut risque, routez-le vers une confirmation humaine.

Rendre les risques explicites avant l’adoption

Dès qu’une base de connaissances d’entreprise se connecte aux agents, ce n’est plus un simple projet de retrieval d’information. Quelques risques doivent être inscrits tôt dans le plan.

Le premier est la confidentialité et les limites d’entraînement. Le fondateur de Hyper a dit dans les commentaires HN qu’ils n’entraînent pas sur les données hébergées et ne les vendent pas, et a renvoyé vers la FAQ et la politique de confidentialité. Comme la page de confidentialité officielle n’était pas lisible via mon crawler, je n’en déduirais pas les détails. Les équipes devraient examiner contrats, conditions de traitement des données, durées de conservation et workflows de suppression plutôt que de se fier à un post de lancement.

Le deuxième est la transparence des hooks. L’injection automatique de contexte est plus fiable qu’espérer qu’un agent pense à appeler MCP, mais les utilisateurs doivent savoir ce qui est installé sur leurs machines. Notifications d’installation, logs d’exécution, interrupteurs de désactivation et configuration visible devraient être évidents.

Le troisième est l’historique pollué. Les entreprises matures ont souvent de vieux documents contradictoires, et plus récent n’est pas toujours plus autoritaire. Dans les workflows juridiques, financiers, religieux ou gouvernementaux, un document plus ancien peut être la source qui fait foi. Le système ne peut pas tout classer par récence. Différentes sources et différents rôles ont besoin de poids différents.

Le quatrième est le vendor lock-in. Plus un company brain est utilisé, plus il ressemble à une partie du système d’exploitation de l’entreprise. Formats d’export, stratégie de sauvegarde, options d’auto-hébergement et plans de sortie de secours doivent être vérifiés tôt. Sans eux, le flux à court terme peut devenir un piège à long terme.

Laissez le système dire qu’il n’est pas sûr

J’aime la direction que Hyper pousse : si les agents s’enfoncent plus profond dans les workflows d’équipe, ils ont besoin d’un contexte d’entreprise plus stable que ce que le retrieval de documents classique peut offrir. Mais l’implémentation doit rester ancrée. Avant de l’appeler un cerveau de toute l’entreprise, assurez-vous que le système peut distinguer anciens et nouveaux faits, revenir aux sources, filtrer par permissions, accepter des corrections humaines et dire « Je ne suis pas sûr » quand les preuves sont minces.

Une petite équipe peut commencer par un workflow étroit : trois types de sources à faible risque, quelques dizaines de faits et 20 tâches réelles. Faites cela d’abord, puis décidez d’étendre. C’est moins spectaculaire, mais pour des agents qui doivent livrer un vrai travail, c’est bien plus proche de l’utilisable.