IA
Une mémoire documentaire à jour, pour une IA qui répond juste
Une IA ne répond bien que si elle retrouve les bons documents. Ce projet a audité l’index documentaire d’un serveur GPU local, l’a jugé obsolète, puis l’a reconstruit proprement : documentation et code source, découpés selon leur nature, enrichis et vérifiés.
Ce qu’elle fait
RAG désigne la technique qui consiste à retrouver des passages pertinents avant de laisser une IA rédiger sa réponse. Sa qualité dépend de l’index : ce qu’il contient, comment c’est découpé, et s’il est à jour.
L’index existant d’un serveur GPU local (un NVIDIA DGX Spark) était figé depuis mars 2026. Il ne contenait que du texte, aucun code, des domaines en double et presque aucune information de contexte. Le projet s’est déroulé en trois temps :
- un audit en sept rapports, qui a établi l’état réel de l’index et décidé de le refaire ;
- un corpus figé de 685 fichiers en 11 domaines (le socle, le Hub, les packs d’extension…), chacun avec son empreinte numérique pour en garantir la version ;
- une chaîne d’ingestion qui découpe chaque fichier selon son type, le convertit en vecteurs et l’insère dans la base.
Pour qui
Pour une organisation dont l’assistant IA répond à partir d’une base documentaire qui a vieilli. Pour une équipe technique qui veut que l’IA connaisse aussi son code, pas seulement ses notes.
Comment elle est construite
Ce projet n’est pas une application du socle Java : c’est un outil en Python, lancé à la demande.
- Cinq stratégies de découpage, une par nature de fichier : un document Markdown par sections, une classe Java par classe, un script SQL par table, une page web par son texte visible, un fichier de configuration en bloc.
- Chaque extrait porte ses informations de contexte : fichier d’origine, version du code, date, méthode de découpage, modèle de vectorisation.
- Les vecteurs sont calculés par le modèle
bge-m3, hébergé sur le serveur GPU, sans coût à l’usage, et rangés dans PostgreSQL avec son extension vectorielle. - Un mode d’essai découpe tout sans rien envoyer, pour vérifier avant d’écrire. 13 tests automatisés couvrent les découpeurs et les connexions.
La migration a eu lieu le 21 avril 2026 : 5 453 anciens extraits supprimés, 3 999 nouveaux indexés en une douzaine de minutes. Les 9 critères chiffrés et les 5 critères qualitatifs fixés à l’avance ont été tenus. Un seul extrait sur les 4 102 produits n’a pas pu être inséré, et sa cause est identifiée.
La suite — réindexation automatique à chaque version du code qui compile — est écrite au plan et reste à réaliser.
Points forts
Un audit avant les travaux
Sept rapports ont établi l’état réel de l’index avant toute décision. Le projet repart de mesures, pas d’impressions.
Le code aussi
L’ancien index ne contenait que du texte. Le nouveau indexe aussi le code Java, le SQL et les pages web, chacun découpé à sa façon.
Des critères fixés à l’avance
Le succès était défini par écrit avant la migration : 9 critères chiffrés, 5 qualitatifs. Tous ont été tenus.
Traçable jusqu’au fichier
Chaque extrait dit d’où il vient, de quelle version et quand il a été indexé. Le corpus figé porte une empreinte par fichier.