L’agent Pinky gère un CRM de plus de 1000 personnes : un Second Brain fondé sur des fichiers md et git plutôt que Notion

Le problème est bien connu : notes, tâches, contacts et objectifs sont éparpillés dans une dizaine de services, et l’on passe son temps à maintenir de l’ordre dans Notion plutôt qu’à travailler. L’auteur de la chaîne « Tochki nad II » a opté pour une solution radicale : créer un dossier de fichiers markdown et y connecter un agent. Un an plus tard, il dit ne plus comprendre comment il faisait sans.

De quel système s’agit-il ?

L’agent s’appelle Pinky. Il lit et écrit lui-même dans la base, se souvient du point où la conversation s’est arrêtée et, selon son créateur, le contredit plus souvent qu’il ne le souhaiterait. Le système héberge un CRM de plus de 1000 personnes : les appels sont enregistrés dans MacWhisper, puis l’agent en répartit le contenu dans les fiches correspondantes. On y trouve aussi un gestionnaire de tâches que l’auteur a développé avec l’agent en mode « vibe coding », un tableau de bord du bootcamp — paiements, tunnel de conversion, contrats avec les entreprises —, des résultats d’analyses médicales, des finances, des objectifs annuels, un journal d’idées et un profil psychologique auquel sont confrontées les décisions importantes.

Le principal bénéfice tient à cette mémoire commune. Activité professionnelle, santé, relations et réflexions peuvent être mises en regard. Selon l’auteur, c’est précisément à leurs intersections que naissent les idées les plus intéressantes.

L’agent dispose de plusieurs rôles : médecin, mentor pour le bootcamp, analyste financier, rédacteur et professeur d’anglais. Il les active de lui-même lorsque le sujet de la conversation s’y prête, ce qui permet d’examiner une même décision sous plusieurs angles. Il suit également des protocoles, autrement dit des actions exécutées sans demande explicite. Au début d’une session, il présente les points laissés en suspens la fois précédente ; à la fin, il consigne les idées et crée un commit des modifications. Il rappelle aussi de faire le point sur les objectifs et de passer la base en revue.

Comment cela fonctionne techniquement

Les données sont stockées dans des fichiers markdown, versionnés avec git et organisés selon le système Johnny Decimal. Chaque entité possède un seul fichier de référence ; partout ailleurs, on utilise des liens vers ce fichier. Cette organisation évite les doublons et les divergences, le principal fléau des bases faites maison.

Les règles de fonctionnement figurent dans CLAUDE.md, que l’agent lit au début de chaque session. Les détails sont placés dans des spécifications séparées pour éviter d’alourdir le fichier principal. Les rôles et les compétences disposent de leur propre dossier, également sous forme d’instructions md et de scripts. Il existe environ 70 scripts au total : ils récupèrent des données dans des bases, des sources financières, des actualités et des calendriers.

La recherche passe par un serveur MCP développé sur mesure. Il associe ChromaDB et des embeddings multilingues à une recherche par mots-clés BM25, puis fusionne les résultats avec RRF (reciprocal rank fusion). L’index est actualisé toutes les demi-heures. Cette combinaison retrouve aussi bien les correspondances sémantiques que les intitulés exacts, les noms et les nombres, sur lesquels les embeddings seuls échouent souvent.

Sur Mac, les tâches de fond sont exécutées via launchd : synchronisation du CRM avec la base du bootcamp, traitement des appels et réplication des tâches. Le gestionnaire de tâches est déployé sur Railway. Depuis un téléphone, il s’ouvre comme une PWA avec Face ID ; depuis une Apple Watch, les dictées sont envoyées directement à l’API. La mémoire entre les sessions est conservée dans de courts résumés mentionnant les points en suspens et dans un fichier aide-mémoire contenant des liens vers les fichiers utiles.

Par où commencer, et quelles sont les limites ?

Le conseil de l’auteur : ne concevez pas le système à partir de zéro, commencez par un entretien. Ouvrez le LLM qui possède le plus d’historique de vos échanges et demandez-lui de préparer 50 questions sur votre travail, vos projets, vos habitudes et ce que vous oubliez régulièrement. Fixez d’emblée l’objectif : à l’issue de l’entretien, le modèle doit produire un PRD pour votre Second Brain. Confiez ce PRD à l’agent, qui en réalisera une première version. Le système évoluera ensuite progressivement, à partir de retours réguliers.

Il y a aussi des limites. Il s’agit du témoignage d’une seule personne, sans indicateurs chiffrés ni comparaison avec des outils existants. La mise en place suppose une certaine familiarité avec git, les scripts et le terminal. Réunir des données de santé, des finances et un profil psychologique dans une même base accessible à un agent impose aussi de réfléchir sérieusement à la sécurité : où fonctionne l’index, quelles données sont envoyées aux modèles cloud et que se passe-t-il en cas de fuite d’un jeton d’accès ? Le billet se termine par une publicité pour un bootcamp payant, un élément à prendre en compte dans son évaluation.

Pour un développeur ou un responsable produit, l’enseignement pratique est le suivant : l’architecture d’un agent personnel opérationnel est aujourd’hui assez simple. Elle repose sur markdown et git comme source de vérité, un fichier de référence unique par entité, un CLAUDE.md contenant les règles, une recherche hybride via MCP et quelques tâches de fond. On peut la mettre en place en un week-end, puis l’améliorer à mesure que de vrais cas d’usage apparaissent.