J'ai des centaines de notes atomiques dans mon vault personnel. La semaine dernière, une phrase notée en fin de sprint me trottait dans la tête : "la donnée est la base d'un bon assistant IA. Le RAG, oui, mais comment." Le RAG (retrieval-augmented generation) : une technique qui permet à une IA d'aller chercher dans tes propres notes avant de répondre, au lieu de répondre uniquement avec ce qu'elle a appris à l'entraînement. Le "comment" appelle une réponse technique : quel moteur d'embeddings, quelle base vectorielle, quel pipeline.

J'ai commencé à répondre à cette question. Puis je me suis arrêtée sur une autre, plus gênante : est-ce que j'ai vraiment besoin de RAG, ou est-ce que je veux juste avoir l'air sérieuse sur ma gestion de la connaissance ?

Ce que tout le monde fait dès que la base grossit

Le réflexe, dès qu'une base de connaissances dépasse quelques centaines de notes, c'est de se dire qu'elle "mérite" une infrastructure de recherche plus intelligente. Embeddings, recherche sémantique, RAG branché sur un assistant IA : la promesse est séduisante, l'outil existe, le tutoriel est à trois clics. Le problème, c'est que cette envie ne part presque jamais d'une limite constatée.

Elle part d'un volume qui impressionne ("j'ai des centaines de notes, ça commence à faire beaucoup") et d'un signal de sérieux qu'on veut s'envoyer à soi-même. Ajouter une brique d'infra donne l'impression de professionnaliser un système. Mais un système mal rangé, interrogé par un moteur plus intelligent, reste un système mal rangé. Le moteur ira juste plus vite chercher le désordre.

L'audit avant l'infra

Avant de toucher au "comment" du RAG, j'ai vérifié l'état réel de la base. Résultat : plus de 200 liens cassés entre notes, dus à des incohérences de formatage jamais corrigées. Plusieurs zettels orphelins, écrits puis jamais reliés au reste de la base : invisibles pour quiconque naviguerait par liens.

Une carte thématique (MOC) qui n'avait jamais été recalculée depuis plusieurs dizaines de notes. Rien de cela n'aurait été résolu par un moteur d'embeddings. Un embedding sait rapprocher deux notes qui parlent du même sujet ; il ne sait pas qu'une note existe si elle n'a jamais été classée nulle part, et il ne corrige pas un lien cassé, il l'ignore silencieusement.

La règle : calibrer l'effort au coût de l'erreur

Shane Parrish le formule clairement dans sa manière de penser la décision : toutes les décisions ne méritent pas le même niveau de rigueur, il faut calibrer l'effort au coût potentiel de se tromper. Ajouter une infrastructure RAG sur une base non assainie, c'est prendre un risque disproportionné pour un problème qui n'est pas encore prouvé : le coût (temps de mise en place, maintenance, dépendance technique) est certain, le bénéfice (le RAG résout un vrai manque de recherche) ne l'est pas encore, puisque je n'ai jamais atteint la limite où les tags et les MOC ne suffisent plus.

C'est le même principe que le StageGate utilisé en gestion de projet industrielle : chaque étape franchit une porte de validation avant d'accéder aux ressources de l'étape suivante. Je n'ai pas franchi la porte "les tags ne suffisent plus". Construire l'étape suivante avant cette porte, c'est allouer des ressources à un problème hypothétique.

Ce que ça change dans la façon de décider quand construire

La conséquence pratique n'est pas "je ne ferai jamais de RAG". C'est : je ne construis pas d'infrastructure tant que je n'ai pas identifié la limite précise qu'elle est censée résoudre. Pour ma base de connaissances, cette limite n'est pas "j'ai beaucoup de notes", c'est plutôt "je cherche quelque chose et ni les tags, ni les MOC, ni la recherche plein texte ne me le trouvent". Ce jour-là, le RAG devient une réponse à un problème constaté. Aujourd'hui, ce serait une réponse à un problème anticipé, et anticiper un problème n'est pas la même chose que le rencontrer.

Le résultat concret de la semaine n'est donc pas une infrastructure IA plus intelligente. C'est une base réparée : plus de 200 liens restaurés, plusieurs notes reclassées, une couverture vérifiée note par note. Moins impressionnant à raconter qu'"j'ai branché un RAG sur mon vault". Plus honnête sur ce qui manquait vraiment.

La vraie question, avant d'ajouter une brique d'infrastructure, n'est jamais "est-ce que l'outil existe". C'est toujours la même : qu'est-ce qui, précisément, ne fonctionne plus sans elle. Tant que la réponse est "rien de constaté, juste une intuition de volume", ce n'est pas encore le moment de construire : c'est le moment de vérifier ce qu'on a déjà. Et consolider ce qui existe n'est pas une pause avant la vraie construction : c'est ce qui permet à la base de tenir quand le nombre de notes continue de grimper. Une structure solide absorbe la croissance. Une structure bancale, elle, n'a besoin que d'un moteur plus rapide pour révéler à quel point elle l'était.

Une infrastructure censée faire 'scaler' une base de connaissances peut-elle corriger une structure qui ne tient déjà plus ?

Localisation

Le Mans, France

Contacts

ashlyne@qiveo.co

Qiveo
Je vois ce que les équipes ont normalisé. Je le questionne. J'écris ce que ça donne.

© 2026 Qiveo