Comment construire un company brain
La plupart des écrits sur ce sujet s'arrêtent à l'idée. L'idée n'est pas la partie difficile. Un company brain est un compte-rendu à jour de comment une entreprise fonctionne, tenu pour que les gens et l'IA puissent tous deux travailler à partir de lui, et quiconque a vu un agent inventer son propre tarif avec assurance comprend déjà pourquoi ça vaut la peine d'en avoir un.
La partie difficile, c'est qu'un document décrivant votre entreprise est obsolète la semaine où vous le terminez, et qu'un document auquel personne ne fait confiance est un document que personne ne lit. Donc c'est une question de mécanisme : qu'est-ce qui écrit les pages, qu'est-ce qui les garde vraies, et comment un agent les atteint-il en cours de tâche. Trois mécanismes, dans cet ordre. Puis les deux décisions qu'aucun mécanisme ne prend à votre place.
1. Les pages sont écrites à partir des outils
Le premier réflexe est toujours de s'asseoir et d'écrire, en général dans le wiki que l'entreprise paie déjà. C'est le bon réflexe et la mauvaise méthode, pour une raison : le compte-rendu n'est vrai qu'à hauteur de la dernière personne qui a eu envie de le mettre à jour.
L'alternative, c'est de le dériver. Presque tout ce que vous voudriez écrire existe déjà quelque part comme trace du travail lui-même. Comment un deal progresse vraiment est dans le CRM. Comment le support escalade vraiment est dans l'historique des tickets. En quoi consiste un processus est dans les invitations de calendrier, les fils et les documents qui y sont attachés. Lire à travers tout ça et le synthétiser en une page est un travail qu'une machine fait vraiment bien, et ça a une propriété que l'écriture manuelle n'aura jamais : relancer, c'est bon marché.
C'est toute l'astuce. Pas qu'une machine écrive mieux que votre responsable ops, parce que ce n'est pas le cas. Qu'une machine le refasse le mois prochain sans qu'on le lui demande.
| Écrit à la main | Dérivé des outils | |
|---|---|---|
| Qui l'écrit | Qui a le temps | Un processus qui se rejoue |
| Ce que ça couvre | Ce que quelqu'un s'est souvenu d'écrire | Ce que les systèmes enregistrent vraiment |
| Rester vrai | Discipline, indéfiniment | Relance, bon marché |
| Coût d'une mise à jour | Un après-midi de quelqu'un | Presque nul |
| Mode de défaillance | Devient obsolète en silence tout en restant cru | Hérite de ce que les systèmes sources font mal |
La dernière ligne est la plus honnête. Un brain dérivé n'est pas exempt d'erreurs ; il déplace l'erreur là où vous pouvez la voir et la corriger, à savoir le système source, plutôt que de la laisser dans un document que personne n'a ouvert depuis mars.
2. Chaque page porte une source et une date
Une page synthétisée a un mode de défaillance évident : elle se lit comme faisant autorité, qu'elle ait raison ou non. Le remède n'est pas de la rendre plus prudente. C'est de la rendre vérifiable.
Deux métadonnées font l'essentiel du travail. D'où ça vient, pour qu'une affirmation contestée se règle en trente secondes en ouvrant la chose dont elle est tirée plutôt qu'en devenant une réunion. Et quand c'était vrai pour la dernière fois, pour qu'un lecteur pèse différemment une page écrite ce matin et une qui n'a pas bougé depuis mars.
Un contexte sans date est la chose la plus coûteuse que vous puissiez donner à un agent, parce qu'un modèle n'a aucun instinct de l'obsolescence. Il traitera une phrase de l'an dernier exactement comme il traite une de ce matin. Une personne qui lit la même page marque au moins une pause.
3. Un agent peut l'atteindre en cours de tâche
Un brain que personne ne peut atteindre au moment du travail est un classeur. Le mécanisme qui referme cet écart est le Model Context Protocol, un standard ouvert publié par Anthropic en novembre 2024 et depuis adopté bien au-delà, que les agents utilisent pour parler à des systèmes extérieurs. Pointez-en un vers votre contexte et l'agent peut récupérer ce dont une question a besoin, au moment où il en a besoin, sans que personne n'ait à coller quoi que ce soit.
Deux propriétés comptent plus que les détails du protocole. C'est du pull, pas du push : l'agent demande ce que la tâche exige au lieu de tout recevoir en amont, ce qui rend un large volume de contexte abordable à manier. Et c'est le même contexte partout — les mêmes réponses dans Claude, dans ChatGPT, dans Slack — si bien que l'entreprise arrête d'entretenir une mémoire officieuse différente par outil et par personne.
Connecter un agent à un serveur MCP est l'affaire de cinq minutes une fois le serveur en place, et c'est la même forme quel que soit l'agent utilisé : une adresse, une identification, et une décision de permission sur ce qu'il peut atteindre. La spécification du protocole est l'endroit où vérifier ce qu'un serveur doit réellement implémenter. La collection de serveurs de référence est le moyen le plus rapide de voir ce qu'un serveur doit réellement implémenter.
Les deux décisions qui vous reviennent
Le mécanisme vous donne un brain qui s'écrit lui-même. Il ne répond à aucune des deux questions qui décident si les gens lui font confiance.
Ce qui y a sa place. L'échec le plus courant est de le pointer vers tout, sur la théorie que plus de contexte vaut mieux. C'est faux. Un brain devrait contenir comment l'entreprise fonctionne : processus, décisions, définitions, la forme de l'activité. Il ne devrait pas contenir des enregistrements bruts qu'il vaut mieux interroger là où ils vivent, et il ne devrait jamais contenir d'identifiants. Le périmètre est ce qui garde les réponses précises.
Qui voit quoi. Un company brain qui ignore les règles d'accès des systèmes dont il a lu est un incident de données avec une belle interface. Ce que vous construisez doit porter les frontières que les systèmes sources ont déjà, et la question « l'agent de cette personne peut-il voir ça » demande une réponse avant l'arrivée de la première équipe, pas après.
Aucune des deux n'est un problème technique. Les deux sont la raison pour laquelle un déploiement réussit ou s'abandonne en silence.
À quoi ça ressemble quand ça marche, et par où commencer
Personne ne l'annonce. Ce qui se passe, c'est que le paragraphe de briefing que les gens collaient en haut de chaque chat arrête d'être écrit, parce que les réponses sont déjà justes sans lui. Les nouvelles recrues arrêtent de poser la question qu'on leur a posée quarante fois. Quelqu'un remarque que l'agent connaissait un changement de tarif que personne ne lui avait dit.
C'est la version honnête du gain. Ce n'est pas un moment de démo. C'est l'absence d'une friction quotidienne que tout le monde avait cessé de remarquer qu'il payait.
Si vous démarrez, démarrez étroit. Une équipe, deux outils connectés, et le processus que cette équipe explique le plus souvent aux autres. C'est suffisant pour découvrir si les pages dérivées sont réellement vraies, la seule question qui vaille la peine d'être posée tôt, et c'est assez petit pour qu'une erreur coûte une semaine plutôt qu'un trimestre. Pour une équipe sales, ce premier processus peut être aussi restreint que retrouver le bon enregistrement d'appel à partir d'un nom ou d'une entreprise, avec la réponse réécrite pour la prochaine fois. La page processus en contient d'autres, chacun avec le prompt qui le fait tourner.
Si vous préférez assembler le vôtre plutôt que l'acheter, le domaine est particulièrement riche en ce moment : les projets open source à connaître couvre ce que chacun fait vraiment. Si vous hésitez encore entre construire et acheter, un company brain comparé à ce que vous avez déjà le place à côté du wiki, de la barre de recherche et de la plateforme d'agents. Et si c'est le principe lui-même qui vous fait hésiter, pourquoi votre IA ne connaît pas votre entreprise est l'argument qui sous-tend celui-ci.
Common questions
- How long does it take to build one?
- The mechanism is not the long part. Connecting the first tools and getting readable pages out is days rather than months; what takes real time is deciding what belongs in it and who can see what, and then keeping the pages true after the first quarter turns. Teams that treat it as a one-off project rather than a loop end up with a snapshot.
- Does it need to hold everything the company has?
- No, and pointing it at everything is the commonest failure. A company brain should hold how the company operates: processes, decisions, definitions, the shape of the business. Raw records are better queried where they live, and credentials do not belong in it at all.
- What is MCP, and do we have to use it?
- The Model Context Protocol is an open standard, published by Anthropic in late 2024 and adopted well beyond it, that lets an assistant pull from an outside system at the moment of a question. You do not have to use it, but the alternative is a custom integration per assistant, which is the work it exists to remove.
- Can we build this on top of our existing wiki?
- Partly. A wiki is a good place to keep the things a person judged worth writing, and there is no reason to throw that away. What it cannot do on its own is stay current without someone maintaining it, so the derived pages have to come from the tools rather than from the wiki.