Deuxième cerveau de l’entreprise : du wiki aux compétences, tout est une question de contexte10 min read

J’ai beaucoup réfléchi à tout le battage médiatique autour du « second cerveau ». J’en ai discuté avec d’autres personnes dans le domaine et avec mes collègues qui construisent un deuxième cerveau ou en ont une version.

Pour ceux qui ne le connaissent pas, le deuxième mouvement cérébral a commencé avec l’idée du « Wiki » d’Andrej Karpathy : organiser les connaissances personnelles de l’agent dans une sorte de structure Wiki interconnectée de fichiers MD locaux. Cela s’est ensuite étendu à l’organisation des données personnelles dans un format beaucoup plus large, les utilisateurs utilisant souvent Obsidian pour organiser et visualiser des notes et en ajoutant des données de réunions (transcriptions Granola/Whisperflow/Zoom) dans le wiki.

bases de connaissances sur la karpathie-fusée : début

bases de connaissances sur la karpathie-fusée : fin

Au fur et à mesure que ce « Wiki » s’est développé, il est devenu évident qu’il y avait une réelle valeur à partager les informations qu’il contient. C’est ainsi que les projets de « second cerveau de l’entreprise » ont commencé à fleurir. La version utopique d’un deuxième cerveau consiste à transcrire tout ce qui est possible : les appels zoom, les réunions F2F, même les interactions occasionnelles, les e-mails, les messages Slack, les documents – le tout dans une énorme base de données comme Snowflake. Imaginez que n’importe qui dans l’entreprise puisse demander à cette instance Snowflake tout ce qu’il veut et obtenir instantanément une réponse à toutes les questions.

Oups, ce n’est pas une bonne idée. Premièrement, c’est très cher. La quantité de données entrant dans quelque chose comme celui-ci est tout simplement folle et la récupération de données devient extrêmement difficile, lente et coûteuse. La sécurité et la séparation des données deviennent un problème. Comment éviter que des données personnelles 1:1, des données financières, des décisions de gestion, des données RH ou encore des décisions de licenciement ne se glissent dans les relevés de notes et soient accessibles. Pas tout le monde devrait je sais tout…

De plus, qui en a besoin, qu’est-ce que cela nous sauve et est-ce même une bonne idée ?

Je dirais qu’en général, une version contenue de ceci est une bonne idée. L’existence du management intermédiaire est en grande partie due à la nécessité de faire remonter les problèmes en amont et de clarifier les décisions en aval. Une grande partie de cela peut désormais être réalisée avec un deuxième cerveau.

Deuxième cerveau des équipes techniques

Un deuxième cerveau technique peut être beaucoup plus facile à entretenir. De nombreuses entreprises utilisent simplement un annuaire Dropbox/Google drive/OneDrive contenant des connaissances partagées que Claude/Codex peut partager. L’automatisation pour transférer cela vers un dépôt Git est assez simple, ou vous pouvez vraiment utiliser Github pour gérer cela également (je suppose que c’est un très petit effort pour OpenAI/Anthropic pour prendre en charge ce scénario sans avoir à installer des compétences personnalisées pour gérer ce type de chose). La source de vérité devient désormais le dépôt Github et les copies locales sont des dépôts git locaux.

Cela peut ajouter des connaissances et des capacités telles que des compétences partagées, des décisions partagées, des conceptions architecturales, des conceptions visuelles (décisions relatives au système de conception, par exemple) et diverses autres décisions relatives aux produits de l’entreprise.

Les petites équipes n’ont pas vraiment besoin de grand-chose au-delà d’une simple synchronisation autour du dépôt, mais les grandes entreprises comptant de nombreuses équipes plus importantes se heurteront très rapidement à de sévères limitations. Les problèmes les plus graves concernent l’empoisonnement du contexte, dans lequel un utilisateur particulier peut prendre des décisions locales qui entrent en conflit avec les données du deuxième cerveau, soit en introduisant des données contradictoires, soit en annulant les décisions de l’entreprise par inadvertance (dans certains cas, peut-être intentionnellement ?).

Le conserver dans git et la fusion peuvent être effectués à l’aide d’un agent dédié qui recherche les conflits et peut alerter un utilisateur si ses modifications sont contradictoires, résoudre les conflits et fusionner les résultats.

Notez que ce n’est pas une bonne méthode pour conserver la documentation du projet. Pour cela, la meilleure façon est d’inclure le wiki comme partie intégrante du projet lui-même. C’est assez facile à créer. Vous mettez simplement de côté un agent de codage et lui demandez d’examiner le projet, de le documenter de manière approfondie dans un dossier de documentation, divisé par architecture, pièges, décisions de produit, décisions techniques et autres éléments qui, selon lui, pourraient être utiles dans de petits fichiers md contenant. La clé est de lui dire de s’assurer que le code et readme.md pointent tous vers le répertoire des documents pour garantir qu’il est référencé partout et considéré comme une partie du projet et non comme une ressource externe. L’élément clé que l’agent doit savoir est que l’intention ici est de permettre l’intégration rapide d’un autre agent dans le projet afin d’éviter les pièges, les nids-de-poule et les gouffres techniques…

Une fois intégré dans la structure du projet de dépôt lui-même, l’agent de codage le conservera comme s’il s’agissait de code. Il le lira comme s’il faisait partie du code et si quelque chose change, il adaptera ou modifiera la documentation (rappelez-vous que « la documentation est que le code est facile à lire et à effacer » ou « la documentation devient obsolète à la minute où elle quitte votre clavier » – faites confiance à l’IA pour les maintenir, donc elles ne sont plus vraies).

Deuxième cerveau pour les équipes produit, marketing et non techniques

Ce type de deuxième cerveau peut être vraiment intéressant pour les équipes techniques, mais faire la même chose pour les équipes non techniques sera extrêmement difficile.

Prenons l’exemple d’une équipe d’avocats : ils possèdent des connaissances très spécifiques qui couvrent les e-mails, Slack, les fichiers Word et d’autres documents. Il en va de même pour les comptables, les ventes, la réussite des clients, etc. Ils ont chacun leur propre seconde connaissance cérébrale.

En plus de cela, la direction souhaite probablement que les données remontent (non filtrées via la direction intermédiaire) et l’équipe pourrait avoir besoin d’informations générées par la direction. Comment produire un graphe de connaissances évolutif, sécurisé et séparé ?

Il existe quelques approches qui pourraient rendre les choses plus faciles, au moins jusqu’à ce que les grands résolvent ce problème, si possible de manière ouverte, mais plus probablement par le biais d’une solution fermée et coûteuse.

1. Deuxième cerveau personnel – chaque personne qui le souhaite peut retranscrire ses propres réunions et entretenir son propre deuxième cerveau. L’obsidienne est très utile pour cela, n’importe quel agent peut la trier et la nettoyer. Utilisez le mécanisme de sommeil paradoxal pour l’optimiser : un agent doit se réveiller la nuit, identifier toutes les informations qu’il a collectées pendant la journée, trouver toutes les informations critiques et importantes à conserver pour l’avenir et les organiser de manière facilement récupérable dans des dossiers et des fichiers MD. Cela signifie que si vous avez parlé à un client particulier, ce client aura un fichier md mis à jour reflétant les informations qu’il est important de retenir à son sujet, ce sur quoi vous travaillez ensemble, etc. Il en va de même pour les projets. Il y aura des chevauchements : le chevauchement est une bonne chose – il n’y a rien de mal à ce que les informations sur un projet particulier se trouvent à la fois dans le dossier de la personne à qui vous avez parlé, dans l’entreprise et dans les dossiers du projet. Laissez l’agent gérer cela pour vous. Lorsque vous avez des questions, faites-en votre principale source de données pour votre agent. Vous pouvez exposer votre agent à vos e-mails/conversations/etc. – veillez simplement à ne pas retranscrire des choses que vous ne souhaitez pas documenter (n’en faisons pas une émission de téléréalité ou un feuilleton).

2. Deuxième cerveau au niveau de l’équipe – une deuxième couche de données comprend des données qui se trouvent soit dans le deuxième cerveau personnel et dont l’agent est sûr à 100 % qu’elles sont pertinentes pour l’ensemble de l’équipe, soit des données provenant de réunions d’équipe qui, de par leur nature, sont basées sur l’équipe. Un agent peut également collecter des données pour ce deuxième cerveau à partir des canaux Slack de votre équipe – elles ne devraient pas figurer dans vos canaux 1:1 ou vos appels Zoom. Une fois les données récupérées, un agent peut les organiser en temps réel ou de nuit et signaler les incohérences lorsque les décisions ont été annulées ou ne correspondent pas aux décisions personnelles ou de direction. Ceux-ci doivent être mis en évidence et alertés auprès de la personne qui prend la décision incompatible afin qu’elle puisse faire son choix en toute connaissance de cause.

3. Deuxième cerveau au niveau de la gestion – il s’agit essentiellement d’un deuxième cerveau au niveau de l’équipe, mais en raison de la sensibilité des données et des décisions prises, cela devrait être traité de manière beaucoup plus nuancée. Seules les décisions finales et les données publiques doivent être partagées ici pour éviter d’éventuelles fuites dans le reste de l’entreprise. Il pourrait être judicieux qu’un humain examine certaines données, au moins au début, pour garantir la sécurité des données. C’est également une bonne idée de laisser le cerveau de la direction en dehors du deuxième cerveau de l’entreprise.

4. Deuxième cerveau de l’entreprise – c’est le plus difficile et ne doit contenir que des données concrètes, informatives susceptibles d’être pertinentes pour l’ensemble de l’entreprise. Résultats financiers déclarés uniquement, par exemple, informations sur le personnel (qui occupe quel poste).

Cela laisse de côté de nombreuses données, y compris les données sur les sentiments, par exemple, que la direction souhaite entendre de la part de l’ensemble de l’équipe. Cela peut être collecté séparément ou récolté à partir de Slack et d’autres sources. Ce n’est pas une bonne idée de récolter ce type de données directement à partir du cerveau de l’entreprise.

Alors, que recherchez-vous dans un deuxième cerveau ou dans un cerveau d’entreprise, avez-vous tenté d’en construire un et quelles ont été vos conclusions ?