Aller au contenu

Implémentation du LLM Wiki V1

Billet #252 : Implémentation du LLM Wiki - base de connaissance IA structurée
Type : Architecture / Gouvernance / Outillage IA
Composants concernés : docs/llm-wiki/, .github/agents/copilot-instructions.md, .github/workflows/wiki-guard.yml, tests/test_wiki_structure.py, mkdocs.yml, specs/006-llm-wiki/

1. Contexte et objectif

La décision d'implémenter un LLM Wiki est venue d'un constat simple : sans base de connaissance organisée, l'IA repart de trop loin à chaque session. Elle parcourt un grand volume de fichiers, consomme inutilement des tokens, et peut donner des réponses inégales d'une conversation à l'autre.

L'objectif de ce chantier est donc clair : offrir à l'IA un point d'entrée fiable et structuré pour répondre plus vite, plus juste, et de manière plus constante.

Avant cette implémentation, un nettoyage du bruit documentaire a été réalisé pour réduire les informations à faible valeur. Ce travail préparatoire est documenté dans le Billet #245 — Nettoyage du bruit token. Le présent rapport couvre la phase suivante : l'implémentation du LLM Wiki.

2. Point de départ et décisions de cadrage

La session a commencé par une question de fond : faut-il ajouter Obsidian (et, par extension, des approches plus avancées comme GraphRAG) pour bien gérer le LLM Wiki ?

  • Décision prise : non pour l'instant.

  • Pourquoi :

    • le périmètre actuel du wiki n'est pas encore assez volumineux ;
    • ajouter un nouvel outil maintenant augmenterait la complexité de maintenance ;
    • la priorité business était de livrer une base utile tout de suite, puis d'itérer.

  • Position retenue :

    • V1 = structure simple, discipline documentaire, garde-fous automatiques ;
    • V2 = enrichissement du contenu selon les besoins réels observés.

3. Solution implémentée

Le travail a été mené en 6 blocs, avec une logique progressive.

  1. Mise en place de la structure

    • création des sections du wiki ;
    • intégration au build de documentation ;
    • marquage explicite des sections prévues pour V2.

  2. Cadrage du comportement IA

    • mise à jour des instructions Copilot pour lire le wiki en priorité ;
    • création d'un point d'entrée clair (README wiki) pour orienter rapidement la recherche d'information.

  3. Consolidation des décisions d'architecture

    • centralisation des décisions majeures dans un endroit unique ;
    • objectif : éviter de redébattre des choix déjà validés et accélérer l'onboarding.

  4. Mise en place de patterns récurrents

    • formalisation de guides pratiques simples pour les cas fréquents (retries, erreurs, sécurité, tests) ;
    • objectif : réduire la variabilité des réponses et des implémentations.

  5. Index par tâche métier

    • création d'un index orienté usage ;
    • objectif : trouver rapidement la bonne page sans connaître l'arborescence technique.

  6. Qualité et gouvernance

    • ajout de tests automatiques sur la structure du wiki ;
    • ajout d'une garde CI pour éviter les évolutions de code sans mise à jour de la connaissance associée.

4. Validation, preuves et tests

Le chantier a été validé sur 3 axes : stabilité, publication, et utilité opérationnelle.

  • Stabilité : la suite de tests est restée verte, avec les nouveaux contrôles du wiki ajoutés.
  • Publication : le build documentaire génère correctement les pages du wiki.
  • Utilité : des mesures de temps ont été réalisées avant/après sur 5 requêtes LLM standards.

Mesure avant/après (SC-009)

  • Observations :
    • Baseline T007 (sans wiki) : 105 sec en moyenne
    • Test post-déploiement T024 (avec wiki) : 81 sec en moyenne
    • Gain moyen observé : -23 %

Le gain est net mais en dessous de la cible initiale de 40 %. 2 requêtes de test sur 5 atteignent le niveau attendu, tandis que 3 requêtes restent limitées parce que les sections correspondantes sont encore en contenu V2 (stubs).

  • Conclusion de validation :
    • V1 est validée et utile ;
    • la performance cible complète dépend du l'exécution de V2.

5. Impact business

Les effets positifs déjà visibles :

  • moins de dispersion : les décisions clés ne sont plus éparpillées ;
  • plus de cohérence : l'IA repart d'une source stable, pas d'un scan large et variable ;
  • meilleure vitesse d'exécution : gain de temps mesuré sur les questions les mieux couvertes ;
  • gouvernance renforcée : la garde CI limite la dérive documentaire dans le temps.

En clair : on a transformé une dépendance implicite à l'historique du projet en actif explicite, maintenable et réutilisable.

6. Limites assumées en V1

Les limites observées sont connues et maîtrisées :

  • la V1 ne couvre pas encore en profondeur certaines zones (données, workflows, opérations, lessons learned) ;
  • la mesure de baseline a été reconstituée dans un contexte post-déploiement, ce qui impose de rester prudent dans l'interprétation ;
  • le résultat SC-009 est donc partiel à ce stade.

Ces limites ne remettent pas en cause la valeur de V1 ; elles définissent clairement le scope V2.

7. Trajectoire et prochaine étape (V2)

Prochaine étape : exécuter le plan V2.

Priorités V2 :

  • compléter les sections encore en attente ;
  • enrichir les runbooks sur les 3 questions qui sous-performent ;
  • refaire la mesure avant/après pour viser le seuil complet de performance.

Objectif : passer d'un wiki déjà utile à un wiki complètement performant sur l'ensemble des cas de référence.

8. Conclusion

La V1 du LLM Wiki est un succès pragmatique : nous avons privilégié la clarté, la rapidité d'impact, et la discipline de maintenance.

Le système est en production documentaire, les preuves sont présentes, les limites sont explicites, et le chemin V2 est clair.