Dans une équipe, la connaissance la plus précieuse est aussi la plus fragile : elle vit dans les têtes. Pourquoi telle décision d'archi, quelle convention pour ce module, ce qui a déjà été tenté et abandonné. Quand quelqu'un part, ou simplement oublie, cette mémoire s'efface. Et les agents IA de l'équipe, eux, n'y ont jamais eu accès. Une mémoire d'équipe répond aux deux problèmes à la fois.
La connaissance d'équipe vit dans les têtes
Une équipe accumule un contexte partagé : décisions, conventions, raisons des choix, historique des essais. Ce contexte est rarement écrit au bon endroit. Il transite par des discussions, des revues de code, des réunions, et finit par exister surtout dans la mémoire des personnes.
Le problème est double. D'abord, cette mémoire est volatile : elle part avec les gens et s'érode avec le temps. Ensuite, les assistants IA de l'équipe n'y accèdent pas, puisqu'ils oublient tout d'une session à l'autre, comme expliqué dans pourquoi ton IA oublie tout. Chaque membre recolle son contexte dans son coin.
Décisions, conventions, ADR : la mémoire commune
La solution est de consigner la connaissance d'équipe à un endroit stable et de la rendre interrogeable. Trois familles d'objets forment cette mémoire commune :
- les décisions et leur justification (le pourquoi, pas seulement le quoi) ;
- les conventions : nommage, patterns, règles maison ;
- les ADR (Architecture Decision Records) : les choix d'architecture documentés, avec leur contexte et leurs conséquences.
Écrits une fois, ces objets cessent d'être à la merci des oublis. Encore faut-il pouvoir les retrouver à la demande, plutôt que de fouiller un dossier de docs que personne ne relit.
Une mémoire que les agents de l'équipe interrogent
C'est là qu'une mémoire IA entre en jeu. Une fois la connaissance d'équipe consignée en notes, un RAG local la rend interrogeable : on pose une question, le système retrouve la décision ou l'ADR pertinent, sourcé.
L'intérêt pour les agents : ils cessent de répéter les erreurs déjà tranchées. Un agent qui peut consulter les ADR de l'équipe ne repropose pas une architecture écartée. On développe ce point dans un RAG local comme mémoire d'un agent de code.
Comment ça marche, concrètement et honnêtement
Soyons précis sur ce que fait le produit, sans inventer une plateforme collaborative. Smart Brain est un moteur de RAG local : chaque membre l'exécute sur sa machine et indexe un vault de notes. La dimension « équipe » vient du vault partagé : si l'équipe maintient ses décisions, conventions et ADR dans un vault commun (par exemple versionné avec git), chacun indexe ce même contenu localement, et son assistant interroge la même mémoire de référence.
Autrement dit, le partage se fait au niveau de la connaissance (les notes versionnées), pas d'un serveur multi-utilisateur. Le retrieval, lui, reste local chez chaque personne : recherche hybride, graphe des liens, reranking, avec une précision mesurée (Hit@1 de 0,909, voir la page technique). C'est honnête, et c'est suffisant : ce qui compte, c'est que l'équipe écrive sa mémoire au même endroit.
Local, pour la souveraineté de la connaissance d'équipe
Garder cette mémoire en local n'est pas anecdotique pour une équipe. Décisions stratégiques, architecture, code propriétaire : cette connaissance n'a pas à transiter par un service tiers. Chaque membre indexe et interroge sur sa machine, rien ne part. La question local contre cloud est traitée dans RAG local vs RAG cloud.
Écrire la mémoire de ton équipe
Une équipe qui écrit ses décisions et les rend interrogeables cesse de dépendre de la mémoire des individus. Ses agents IA, eux, gagnent un contexte commun fiable.
Si tu veux mettre ça en place, la page technique détaille le moteur, la documentation couvre l'installation, et les offres incluent Smart Brain à partir du tier Studio. Commence par le cas le plus direct : la mémoire IA pour développeur.