Du LLM Wiki de Karpathy à un second cerveau opérationnel : mon implémentation avec Amazon Quick Desktop

Dima Kramskoy — Senior Cloud Architect chez DoiT International Plus de 20 ans d'ingénierie logicielle · 10 certifications AWS · AWS Community Builder 2026 · Ancien élève de l'Architect Master Class de Juval Löwy (2022)

Le problème : chaque conversation repart de zéro

Voici l'anti-pattern qui me rend fou : vous avez une conversation de fond de 45 minutes avec un assistant IA sur vos décisions d'architecture, vos arbitrages, vos contraintes. Vous fermez l'onglet. Le lendemain, vous ouvrez un nouveau chat. Il ne sait plus rien. Retour à la case onboarding.

Étendez ce constat à l'ensemble de vos connaissances : threads Slack dont le contexte ne sera plus jamais recherchable, fils d'e-mails où les décisions sont enfouies au 14ᵉ message, documents qui existent en trois versions sur deux drives, et savoir tacite qui ne vit que dans la tête des gens.

Personne n'accepterait de former son remplaçant avec pour seule ressource son historique Slack. Et pourtant, c'est exactement ce qu'on fait avec nos outils IA : on leur livre des fragments en attendant de la cohérence.

Le vrai problème n'est pas l'intelligence. GPT-4, Claude, Gemini — tous brillants. Le problème, c'est l'amnésie. Chaque session est un démarrage à froid. Votre contexte est éparpillé dans une dizaine d'outils, dont aucun ne communique avec les autres via un modèle unifié de vous et de votre travail.

J'y réfléchis depuis des mois. Puis Karpathy a publié un tweet qui a cristallisé la solution.

L'inspiration de Karpathy : RAG récupère, le wiki capitalise

En avril 2026, Andrej Karpathy a publié sur X à propos du LLM Wiki — 17 millions de vues et ça continue. L'idée centrale m'a fait l'effet d'un design pattern qui s'imbrique d'un coup :

"RAG retrieves. A wiki compounds."

Son framework est élégant. Trois couches :

1. Sources brutes — articles, papers, tweets, conversations, notes
2. Wiki — pages de connaissances distillées, structurées, interconnectées
3. Schema — l'ontologie qui régit l'organisation de la connaissance

L'analogie qu'il propose est parfaite : "Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase."

Matt Paige en a fait une excellente analyse. Le basculement clé : au lieu de déverser des documents bruts dans une base vectorielle en espérant que la recherche tombe sur le bon morceau, vous construisez une base de connaissances vivante et structurée que le LLM entretient et enrichit dans la durée.

Le RAG, c'est une consultation. Un wiki, c'est un système. L'un est en O(1) par requête. L'autre capitalise.

Mais voici ce qui me dérangeait dans la version de Karpathy : elle est manuelle. C'est vous l'opérateur. Vous promptez, vous relisez, vous collez, vous organisez. Le LLM assiste, mais c'est vous qui pilotez. Je voulais autre chose : un assistant qui fasse tout cela à ma place, et non un système que je dois maintenir moi-même.

Pourquoi Amazon Quick Desktop

Au moment d'évaluer les outils pour cette implémentation, j'avais une checklist directement dérivée de l'architecture de Karpathy :

• ✅ Mémoire long terme persistante d'une conversation à l'autre
• ✅ Knowledge graph (extraction automatique d'entités et de relations depuis Slack, e-mail, calendrier)
• ✅ Recherche sémantique sur les fichiers locaux
• ✅ Accès en lecture/écriture à mon système de fichiers
• ✅ Tâches en arrière-plan (recherches pendant que je travaille sur autre chose)
• ✅ Outils connectés (Gmail, Slack, Google Calendar, serveurs MCP)
• ✅ Couche d'action (rédiger des e-mails, créer des docs, planifier des réunions)

Amazon Quick Desktop offrait déjà ce que Karpathy décrit — mais nativement intégré et relié à de vrais outils de travail. Ce n'est pas une fenêtre de chat. C'est un runtime.

Comparatif rapide :

La décision clé : je voulais un assistant qui capitalise la connaissance À MA PLACE, et non un système à entretenir moi-même. Le coût de maintenance d'un wiki manuel tue l'adoption. Je l'ai vu une dizaine de fois.

Ce que j'ai construit (en 1 semaine)

Structure des dossiers

~/SecondBrain/
├── raw/                          # Entrées non traitées
│   ├── articles/
│   ├── transcripts/
│   └── captures/
├── wiki/                         # Connaissance distillée
│   ├── concepts/                 # Modèles mentaux, frameworks
│   │   ├── second-brain-architecture.md
│   │   ├── rag-vs-wiki-pattern.md
│   │   └── approval-workflow-pattern.md
│   ├── entities/                 # Personnes, organisations, outils
│   │   ├── doit-international.md
│   │   └── amazon-quick.md
│   ├── projects/                 # Travaux en cours
│   │   ├── genai-skill-share-talk.md
│   │   └── voice-capture-pipeline.md
│   ├── sources/                  # Références indexées
│   │   └── karpathy-llm-wiki.md
│   └── log/                      # Suivi quotidien
│       ├── 2026-05-19.md
│       ├── 2026-05-20.md
│       └── ...
├── SCHEMA.md                     # L'ontologie
└── mkdocs.yml                    # Documentation auto-servie

SCHEMA.md (extrait)

# SecondBrain Schema v1.0

## Types de pages
- **concept** : un modèle mental, un pattern ou un framework. Doit inclure : définition, contexte d'usage, anti-patterns, concepts liés.
- **entity** : une personne, une organisation ou un outil. Doit inclure : rôle/finalité, lien avec mon travail, date de la dernière interaction.
- **project** : travail en cours ou terminé. Doit inclure : statut, parties prenantes, journal des décisions, prochaines actions.
- **source** : un article, un talk ou un paper ingéré. Doit inclure : URL, enseignements clés (5 maximum), liens avec les concepts existants.
- **log** : entrée quotidienne. Auto-générée. Suit : pages créées, pages mises à jour, questions traitées, actions effectuées.

## Convention de nommage
kebab-case. Pas de dates dans les noms de fichiers (utiliser le frontmatter).

## Règles de cross-référencement
Chaque nouvelle page DOIT pointer vers au moins une page existante. Les pages orphelines sont un signal d'alarme.

La stack

• MkDocs + thème Material — sert automatiquement le wiki en local sur localhost:8000
• launchd plist — lance MkDocs au démarrage de la session (macOS). Aucune friction pour naviguer.
• Amazon Quick — lit et écrit dans le wiki, propose des mises à jour, répond aux questions à partir de son contenu
• Indexation sémantique — Quick indexe ~/SecondBrain/ et l'interroge contextuellement

Le workflow d'approbation

C'est critique. Rien ne s'écrit sans mon feu vert. Le flow :

1. Je dis "ingère cet article" ou je partage un lien
2. Quick le lit et propose une nouvelle page wiki (ou des mises à jour de pages existantes)
3. Je consulte le diff — nouveau contenu mis en évidence, cross-références affichées
4. J'approuve, je modifie ou je rejette
5. Le contenu approuvé est écrit sur le disque, MkDocs se rafraîchit automatiquement

Plus de 15 pages wiki dès la première semaine. Sans m'acharner — juste à partir de conversations que j'avais déjà.

Une journée type

Le matin :

"Bonjour"

Quick me renvoie : les e-mails prioritaires (signalés ou émanant de personnes clés), les threads Slack qui attendent ma réponse, l'agenda du jour assorti de notes de préparation pour chaque réunion. Pas un déluge — un briefing.

Pendant la journée :

"Ingère ceci : [lien vers un article d'architecture]"

Quick le lit, identifie 3 concepts clés, propose une nouvelle page sources/ et des mises à jour de deux pages concepts/ existantes. Je parcours le diff, j'approuve, c'est terminé. 90 secondes.

"Rédige un article de blog sur l'implémentation du Second Brain"

Il puise dans mes pages wiki, connaît ma voix (grâce à la mémoire de mes écrits passés), structure selon mon format préféré. Je relis et j'édite, je ne rédige plus depuis zéro.

"Bloque 2 heures de deep work demain sur le pipeline de voice capture"

Il consulte mon agenda, trouve un créneau, le réserve et ajoute des notes de préparation issues de la page projects/voice-capture-pipeline.md.

En arrière-plan :

Pendant que je suis en réunion, des tâches en arrière-plan creusent les sujets que j'ai mis en file. À mon retour : "J'ai trouvé 3 papers pertinents sur la maintenance des knowledge graphs. Tu veux que je les ingère ?"

L'effet de capitalisation est réel. Au 5ᵉ jour, il répondait à des questions en croisant plusieurs pages wiki dont j'avais oublié avoir validé l'écriture.

L'extension Voice Capture (PoC)

Mes meilleures idées arrivent quand je marche, pas à mon bureau. J'ai donc construit un pipeline :

Architecture

iPhone Shortcuts (ou wearable Plaud NotePin)
    → API Gateway (REST)
        → Lambda (gestionnaire d'upload)
            → S3 (bucket audio)
                → Événement S3 → Lambda (déclencheur de transcription)
                    → AWS Transcribe
                        → Lambda (post-traitement)
                            → Amazon Quick Knowledge Base
                                → Page wiki proposée

Fonctionnement

1. Je lance un Shortcut sur mon iPhone (ou le NotePin enregistre en ambiant)
2. L'audio est envoyé sur S3 via API Gateway + Lambda
3. L'événement S3 déclenche la transcription via AWS Transcribe
4. La transcription est nettoyée, découpée et poussée dans la knowledge base de Quick
5. À la prochaine ouverture de Quick : "Tu as une voice capture sur [sujet]. Tu veux que je crée une page wiki ?"

Coût AWS total : des fractions de centime par capture. Les fonctions Lambda sont triviales — 50 lignes chacune. La valeur tient à la boucle qui se referme : pensée → capture → connaissance structurée → action.

Bilan honnête : 7/10

Ce qui fonctionne

• Structure — Le schema impose la cohérence. Les pages se retrouvent facilement et servent vraiment.
• Capitalisation — Les réponses de la semaine 2 sont nettement meilleures que celles de la semaine 1. Il sait des choses.
• Outils connectés — Le contexte Slack enrichit les pages wiki. La connaissance du calendrier permet une vraie planification.
• Couche d'action — Il ne se contente pas de savoir ; il agit. Brouillons, slides, réservations.
• Recherche sémantique — "Qu'est-ce que j'ai décidé à propos de X ?" fonctionne réellement sur tout le wiki.

Ce qui reste à faire

• Cross-référencement — Pas encore totalement automatique. Certaines pages restent sous-liées.
• Health checks — Pas encore d'audits planifiés pour les pages obsolètes ou orphelines.
• Ingestion planifiée — Aucun cron pour "vérifier ces 5 flux RSS chaque jour". Le déclenchement reste manuel.
• Détection de contradictions — Pas encore testée. Que se passe-t-il quand une nouvelle info entre en conflit avec une page wiki existante ?

Ce qu'on a fait MIEUX que la vision originale de Karpathy

Sa vision pose les plans. Mais elle reste en lecture seule — des fichiers que l'on interroge. La mienne produit : rédige des e-mails, crée des slides, réserve des réunions, écrit des articles de blog. Le wiki n'est pas seulement une référence ; c'est une source d'action.

Comment vous lancer (5 étapes)

Vous n'avez pas besoin de mon setup complet pour en tirer de la valeur. Voici la progression :

Les 5 étapes

1. Connectez vos outils — Slack, Gmail, Calendar, un dossier local. 10 minutes dans les paramètres.
2. Commencez à parler — La mémoire capitalise dès le premier jour. Chaque conversation lui apprend quelque chose sur vous.
3. Dites "retiens ceci" après les conversations importantes — des ancres mémorielles explicites.
4. Créez ~/SecondBrain/ + SCHEMA.md — pour aller plus loin, donnez-lui une structure.
5. Posez-lui une question transversale — "Quelles ont été mes décisions clés la semaine dernière ?" Vous êtes accro.

Trois niveaux d'engagement

Commencez au niveau 🟢. Sérieusement. La capitalisation opère, que vous bâtissiez de l'infrastructure ou non. La structure du wiki ne fait que la rendre visible et vérifiable.

Conclusion

Votre IA ne devrait pas repartir de zéro à chaque conversation.

Les outils existent. Le pattern a fait ses preuves. Karpathy a posé l'architecture ; Amazon Quick fournit le runtime. L'écart entre assistant IA et second cerveau tient à trois ingrédients : structure, persistance et outils connectés.

Capitaliser > Récupérer. Chaque conversation, chaque article ingéré, chaque page wiki approuvée rend l'interaction suivante plus pertinente. Ce n'est plus de la récupération — c'est de la croissance.

Commencez petit. La capitalisation fait le reste. C'est tout l'enjeu.

Une dernière idée — et elle vient de Jocko Willink, pas de la recherche en IA : l'Extreme Ownership appliqué à la connaissance. Si une information traverse votre quotidien — un thread Slack, un talk de conférence à moitié oublié, une idée surgie lors d'une promenade matinale — et que vous ne la capturez pas, vous ne la possédez pas. C'est elle qui vous possède, en se dérobant au moment où vous en avez le plus besoin.

Capturez. Structurez. Laissez la connaissance capitaliser.

Cet article a été rédigé avec l'aide de mon Second Brain — en puisant dans les pages wiki que j'avais bâties la semaine précédente. L'ironie ne m'échappe pas. C'est précisément l'idée.

Présenté lors du GenAI Community Skill Share de DoiT, le 22 mai 2026. Merci aux quelque 27 collègues qui ont posé des questions pointues et nourri la réflexion.