📚 Knowledge base interne (RAG)

Dans toute organisation de plus de 5 à 10 personnes, la connaissance se fragmente : un Drive éparpillé, des Slacks archivés, des CR de réunion oubliés, des manuels produit dans les têtes des plus anciens. Les conséquences sont mesurables — onboarding lent (un nouveau collaborateur met des semaines à savoir où trouver l'info), décisions répétitives (on retombe sur les mêmes arbitrages tous les six mois), perte de mémoire en cas de départ d'un collaborateur clé.

L'étude McKinsey 2025 estime à 1,8 heure par jour le temps perdu à chercher l'information dans une organisation moyenne. Un système RAG bien déployé réduit ce temps de 50 à 70 %. Pour une équipe de 20 personnes, cela représente plusieurs centaines d'heures redéployables par mois sur des tâches à valeur ajoutée.

Le cas s'applique à tous les profils d'organisation : industriel avec 30 ans de manuels qualité, cabinet conseil avec une bibliothèque de livrables, startup avec un Slack archivé et une doc produit éclatée, structure publique avec un patrimoine réglementaire dense.

RAG vs Fine-tuning — quand choisir lequel

Recommandation par défaut : commencer en RAG. Passer au fine-tuning seulement si tu as un cas très spécifique avec un domaine stable et un besoin de performance que le RAG ne peut pas couvrir. Pour 90 % des cas d'usage PME / ETI, le RAG suffit.

Deux pipelines : ingestion en amont du corpus dans une base vectorielle, puis interrogation à la demande qui combine recherche sémantique et génération.

En avril 2026, Andrej Karpathy a publié sur GitHub un gist intitulé « LLM Wiki » qui a fait 17 millions de vues, 5 000 stars et 4 282 forks en quelques jours. Le gist propose une alternative architecturale au RAG classique pour les bases de connaissance de petite à moyenne taille. L'idée fondamentale : arrêter de retrieve, commencer à synthétiser.

RAG classique vs LLM Wiki — la différence en deux phrases

• RAG classique : à chaque requête, on cherche dans le vector store → on récupère des chunks → on injecte dans le prompt → on génère une réponse → on oublie tout. Stateless. Pas de mémoire de synthèse.
• LLM Wiki : on maintient une base markdown structurée par un LLM. Quand on ajoute un document, le LLM met à jour les pages markdown affectées (synthèses, entités, contradictions). Quand un utilisateur pose une question, le LLM consulte directement les pages markdown pertinentes.

Le shift conceptuel : synthesis persistante au lieu de retrieval éphémère.

Quand le LLM Wiki bat le RAG vectoriel

Selon les benchmarks publiés et les retours communautaires (mai 2026) :

Cas types où le LLM Wiki est pertinent en PME

• Manuel produit stable (documentation technique d'une machine, manuel d'intégration, procédure qualité)
• FAQ métier structurée (< 50K tokens)
• Procédures internes RH (règlement intérieur, parcours d'onboarding)
• Documentation de projet (cahier des charges, spécifications fonctionnelles)

Cas où ça ne convient pas

• Volume > 200K tokens (le contexte LLM devient trop coûteux et lent)
• Mises à jour temps réel (réindexation continue impossible)
• Corpus très hétérogène (la maintenance markdown devient une charge)
• Besoin de réponses ultra-précises avec citations multiples (le RAG hybride reste meilleur)

Le pattern LLM Wiki post-Karpathy — l'écosystème de mai 2026

Depuis le gist initial de Karpathy (avril 2026), un écosystème de forks open-source s'est développé, qui introduit des patterns complémentaires :

• Persistent memory : la mémoire de l'agent persiste entre les sessions et entre les utilisateurs (avec gestion de droits).
• Self-maintaining KB : la base de connaissances se met à jour automatiquement quand de nouveaux documents sont ingérés (synthèses regénérées).
• Contradiction detection : le système identifie automatiquement les contradictions entre nouveaux contenus et synthèses existantes, et alerte.
• Multi-agent vaults : plusieurs agents spécialisés partagent et enrichissent un vault commun.
• Sleep consolidation : pattern inspiré du sommeil humain — la base se consolide « hors ligne » pendant les périodes creuses (regénération de synthèses, déduplication, archivage).
• Graph-based layers : couche graph (nœuds/relations) ajoutée par-dessus la base markdown pour requêtes structurelles.
• MCP local-first : intégration MCP servers locaux pour la souveraineté.
• Self-healing knowledge graphs : le graph détecte les liens manquants ou incohérents et les corrige.

Pour une PME qui démarre, la fiche outil Beever Atlas est un fork open-source qui matérialise plusieurs de ces principes. L'écosystème est encore en effervescence — plusieurs alternatives sont à benchmarker selon ton corpus.

3 questions à se poser avant de choisir LLM Wiki vs RAG classique

1. Volume du corpus : < 100 K tokens stable et structuré → LLM Wiki potentiellement plus efficace. Volume large et hétérogène → RAG hybride toujours plus pertinent.
2. Évolutivité : tu prévois d'ingérer en continu ? Le LLM Wiki s'enrichit naturellement par synthèse, le RAG nécessite une re-indexation systématique.
3. Qualité des inputs : le LLM Wiki dépend très fortement de la qualité des inputs. Inputs structurés (manuels, procédures) → résultats qualité. Inputs hétérogènes (web, YouTube, X crawl) → bruit. Signal documenté en mai 2026 par la communauté technique.

Durée de vie des stacks RAG actuels — un signal de rupture à 3-6 mois

En mai-juin 2026, quatre sources indépendantes ont signalé la même hypothèse — la trajectoire bascule de « discussion » à « infrastructure » : les architectures RAG classiques pourraient avoir une durée de vie limitée sur certains cas d'usage. Le signal mérite désormais d'être pris très au sérieux par toute PME qui investit dans une stack RAG.

Quatre signaux convergents

• Signal 1 — Long context natif (SubQ, mai 2026) : si les modèles atteignent en production des fenêtres de contexte de 10 M tokens et plus (12 M en recherche, 1 M en production déjà chez SubQ), avec une réduction du coût de l'attention ×1000, alors RAG, multi-agent, chunking et vector DB deviennent des workarounds contre une limite technique qui est en train de tomber. L'argument : « pourquoi orchestrer une retrieval pipeline si on peut donner tout le corpus au modèle directement ?».
• Signal 2 — LLM Wiki post-Karpathy (mai 2026) : le gist initial d'Andrej Karpathy (avril 2026) a atteint 5 000+ stars en un mois. L'écosystème de forks et patterns dérivés s'est structuré en quelques semaines : sheaf cohomology pour contradiction detection, sleep consolidation, persistent multi-agent vaults, graph-based layers, MCP audit trails. Argumentation : « le LLM Wiki ingère, synthétise, fait évoluer la connaissance » vs RAG stateless qui retrieve → answer → forget.
• Signal 3 — Persistent memory pour agents scalables (mai 2026) : Jean Vargas (founder Hermes Agent) formalise : « Persistent memory > RAG stateless pour agents scalables ». Sans mémoire persistante, les agents restent stateless et ne compoundent pas l'intelligence. Avec persistent memory (pattern observé sur Hermes Agent, Beever Atlas, anima AI), les skills et procédures écrites redeviennent du knowledge réutilisable plutôt que perdus dans l'historique.
• Signal 4 — agentmemory et l'écosystème de hooks partagés (mai 2026) : le passage de discussion à infrastructure. Un projet open-source nommé agentmemory (créé par @ghumare64, 13 200+ stars GitHub en quelques semaines) propose une couche de persistent memory commune à tous les coding agents (Claude Code, Hermes Agent, OpenClaw, Codex CLI, Cursor, Gemini CLI) via un serveur local SQLite + FAISS. Les benchmarks publiés sont mesurables : 95,2 % r@5 (recall at 5) vs 86,2 % BM25 fallback + coût token divisé par 100+ vs full context injection. L'argument structurel : si plusieurs coding agents partagent la même mémoire persistante, l'agent ponctuel devient un système qui se souvient du codebase, des décisions passées et des corrections d'erreur — sans réingestion à chaque session.

Ce que ça veut dire pour ta PME en 2026

Si tu démarres un projet RAG maintenant :

• Ne pas surinvestir dans une infrastructure RAG complexe (reranking sophistiqué + multi-stage retrieval + chunking optimisé) avec un horizon d'amortissement supérieur à 18 mois. Le risque que l'architecture devienne obsolète avant l'amortissement est réel.
• Préférer les architectures hybrides qui permettent de basculer vers du long context ou de la persistent memory sans tout réécrire (pattern « RAG-light » : un retrieval minimal + un long context fenêtré + un LLM puissant).
• Surveiller la trajectoire long context sur les modèles que tu utilises (Claude Opus, GPT-5, Gemini). Si la fenêtre disponible à coût raisonnable atteint 1 M+ tokens dans les 6 mois, certains de tes RAG classiques deviennent réinterrogeables.

Si tu as déjà une stack RAG en production :

• Documenter la dette technique RAG : quels composants devraient être réévalués si le long context devient natif ? Quels chunking strategies sont devenus inutiles ? Cette documentation est une assurance.
• Tester en parallèle des approches alternatives sur un cas d'usage non critique (LLM Wiki, persistent memory simple). C'est le moment où le coût d'expérimentation est faible et l'apprentissage maximal.
• Ne pas paniquer : le RAG classique reste pertinent sur les corpus >> 1 M tokens et les besoins de citation précise / sourcing. La rupture n'est pas universelle.

1. Collecte du corpus. Identifier les documents qui répondent réellement aux questions récurrentes de l'organisation : procédures, manuels qualité, base produit, contrats types, CR de comité. Pas besoin de tout ingérer — viser le corpus utile, pas exhaustif. Typiquement, 20 % des documents répondent à 80 % des questions.
2. Préparation. Découpage en chunks (morceaux de 200 à 800 mots), enrichissement avec des métadonnées (type de document, date, auteur, projet, niveau de confidentialité), nettoyage des éléments parasites (en-têtes, pieds de page, watermarks).
3. Indexation vectorielle. Chaque chunk est encodé en vecteur via un modèle d'embedding (OpenAI, Mistral Embed, Cohere, ou modèles open source comme sentence-transformers) et stocké dans une base de données vectorielle (Pinecone, Weaviate, Qdrant, ChromaDB).
4. Interrogation. Quand un collaborateur pose une question, le système recherche les chunks les plus pertinents via similarité sémantique, les transmet au modèle de génération (Claude, GPT, Mistral) avec la question, et produit une réponse en citant les sources.
5. Mise à jour continue. Le système s'enrichit au fur et à mesure que de nouveaux documents sont ajoutés, soit manuellement, soit via une synchronisation automatique avec le Drive ou le Slack source.
6. Curation et gouvernance. Une personne (référent IA ou knowledge manager) supervise la qualité du corpus dans la durée : retire les documents obsolètes, corrige les contradictions identifiées par les utilisateurs, fait évoluer les droits d'accès.

Plateformes RAG simples (no/low-code)

NotebookLM (Google) est la porte d'entrée la plus simple : tu uploads tes documents, tu poses tes questions, c'est tout. Idéal pour des corpus de quelques dizaines de documents et un usage individuel ou en petite équipe. Dify et Flowise sont des alternatives open source déployables en mode SaaS ou on-premise, avec une vraie marge de configuration.

Plateformes professionnelles et scalables

Vectara et Glean sont les références enterprise — connecteurs natifs avec Drive, Slack, Notion, Confluence, gestion fine des droits, audit trail. Stack AI et LangChain (avec configuration custom) permettent un déploiement très calibré pour des cas spécifiques.

Bases vectorielles

Pinecone reste la référence cloud managée. Weaviate et Qdrant proposent des alternatives self-hosted ou cloud, avec une bonne documentation et des intégrations larges. ChromaDB est le choix le plus simple pour un prototype local.

Modèles d'embedding et de génération

Embedding : OpenAI, Mistral Embed, Cohere, ou modèles open source (sentence-transformers). Génération : Claude (excellent sur la nuance et le résumé), GPT-4 / GPT-5 (référence robuste), Mistral (souveraineté EU). Pour les structures sensibles à la souveraineté, le combo Mistral Embed + Mistral Large dans une infrastructure EU est la voie la plus claire.

Alternatives souveraines RAG

Pour les structures avec exigences AI Act renforcées ou données sensibles, deux options 🇫🇷🇪🇺 émergentes méritent examen : Lucie / OpenLLM-France (open-source francophone, financé France 2030) et Pleias-RAG (famille de SLM Pico/Nano/Small entraînés sur le Common Corpus 2T tokens domaine public — particulièrement adapté aux secteurs juridique et compliance avec citations sourcées natives).

Gouvernance multi-LLM

Pour les structures qui veulent fédérer plusieurs LLM avec un cadre de gouvernance, Goodweek et EthiqAIS (alumni QFC) proposent des couches de pilotage avec audit, droits d'accès et traçabilité.

Prérequis

Corpus documentaire au minimum organisable (pas forcément parfait — l'IA peut digérer du désordre, mais la qualité du résultat dépend du corpus), décision sur l'hébergement selon sensibilité, politique d'accès et confidentialité (qui peut interroger quoi), un référent identifié pour la curation dans la durée.

Tu vas suivre les 4 étapes ci-dessous pour construire une première knowledge base interrogeable. Compte 60 à 90 minutes pour faire l'exercice complet.

Le « garbage in, garbage out »

Si la documentation interne est obsolète, contradictoire ou bruitée, le RAG amplifie le problème — il restitue avec assurance des informations qui sont en réalité fausses ou périmées. La qualité du corpus détermine la qualité du système. Investir en amont sur la sélection et le nettoyage est plus rentable que d'élargir la base à tous les documents disponibles.

Les droits d'accès et la confidentialité

Certains documents (rémunérations, dossiers juridiques sensibles, projets confidentiels) ne doivent pas être accessibles à tous. Politique de droits d'accès à concevoir dès l'architecture, pas a posteriori. Sur NotebookLM, créer plusieurs notebooks séparés selon les niveaux de confidentialité. Sur Dify ou les plateformes pro, exploiter les rôles natifs.

La maintenance dans la durée

Une knowledge base qui n'est pas curée se dégrade vite : doublons, documents obsolètes jamais retirés, nouvelles versions qui contredisent les anciennes. Sans curation régulière, la qualité se dégrade en 6 à 12 mois. Inscrire la curation dans le quotidien d'un référent identifié, pas dans une intention diffuse.

Les hallucinations résiduelles

Même avec RAG, le modèle peut produire une réponse qui mélange ses connaissances pré-entraînées avec le corpus. Citer systématiquement les sources et permettre la vérification. Un utilisateur qui ne peut pas vérifier la source ne devrait pas considérer la réponse comme fiable pour une décision engageante.

Conformité sectorielle

Pour les secteurs régulés (santé, défense, finance, juridique), des contraintes spécifiques s'appliquent sur le stockage et le traitement des documents — RGPD renforcé, hébergement souverain, traçabilité d'accès. Vérifier les exigences sectorielles avant tout déploiement, et privilégier les solutions à souveraineté EU.

Réponds aux 6 questions suivantes pour évaluer ta maturité et générer un plan d'action priorisé. Tu pourras exporter le résultat en Markdown ou en texte simple.