Aller au contenu

Implémentation du LLM Wiki V2

Billet #253 : Implémentation du LLM Wiki V2 — validation et clôture
Type : Architecture / Gouvernance / Outillage IA
Composants concernés : docs/llm-wiki/, logs/t007_baseline.md, tests/test_wiki_structure.py

1. Contexte et objectif

Ce travail est la deuxième phase d'un chantier planifié en trois étapes :

  1. Nettoyage du bruit token (Billet #245) — réduction de la consommation inutile et création d'une base documentaire propre.
  2. Implémentation du LLM Wiki V1 (Billet #252, 1/2) — création d'une structure de wiki Markdown avec 5 décisions clés, 4 patterns et une navigation orientée tâches.
  3. Implémentation du LLM Wiki V2 (Billet #253, 2/2) — le présent rapport.

Pourquoi diviser en V1 et V2 ?

Approche pragmatique : V1 a d'abord livré le minimum viable (2 sections essentielles : architecture + patterns) pour valider rapidement que le concept fonctionne. V2 ajoute les sections opérationnelles manquantes une fois le ROI mesuré.

Résultat : validation progressive avec mesure à chaque étape, plutôt qu'une tentative exhaustive d'emblée.

Résultat V2 : le temps moyen de première réponse correcte passe de 105 sec (baseline) à 42,4 sec après V2, soit -59,6 %. Le critère SC-009 (réduction moyenne >= 40 %) est donc atteint.

3. Actions réalisées en V2

Les actions ont été exécutées en trois blocs :

  1. Activation des sections V2

    • conversion des sections 02_data-models/, 03_workflows/, 04_operations/, 06_lessons-learned/ en statut current ;
    • ajout de contenu opérationnel structuré (Context, Details, Links).

  2. Ajout de runbooks ciblés sur les gaps SC-009

    • Des runbooks (guides opérationnels étape par étape) ont été ajoutés pour trois processus critiques :
      • documentation du workflow GitHub Issue bridge ;
      • documentation du workflow d’alertes SMTP ;
      • documentation opérationnelle de la rotation des logs ;
    • ajout d’analyses “lessons learned” dédiées au gap SC-009.

  3. Mise à jour de la navigation wiki

    • enrichissement de README.md pour refléter la couverture V2 ;
    • extension de l’index orienté tâches pour pointer directement vers les nouveaux runbooks.

4. Re-test SC-009 (post-V2)

Méthode : mêmes 5 requêtes executées dans V1, mêmes règles de mesure, comparaison contre la baseline T007.

Source de mesure : logs/t007_baseline.md.

# Question Baseline (sec) Re-test V2 (sec) Gain
1 retry strategy 95 26 -72,6 %
2 E2E choice 150 44 -70,7 %
3 GitHub bridge 135 46 -65,9 %
4 log rotation 75 35 -53,3 %
5 SMTP failures 70 61 -12,9 %
Moyenne 105,0 42,4 -59,6 %
  • Bilan du re-test :
    • l’objectif SC-009 est dépassé ;
    • les gains les plus forts concernent précisément les sujets qui étaient incomplets en V1 ;
    • la question SMTP progresse moins vite que les autres, mais reste en amélioration.

4. Validation qualité

Les contrôles de structure du wiki ont été relancés après les ajouts V2.

Résultat : 7 tests passés, 0 échec sur tests/test_wiki_structure.py.

Conclusion : la V2 apporte du contenu supplémentaire sans casser la qualité documentaire ni les liens internes.

5. Impact business

Cette phase 2/2 transforme la V1 utile en wiki pleinement performant :

  • vitesse : réduction moyenne de 59,6 % sur le temps de réponse correct ;
  • cohérence : l’IA trouve plus vite les bonnes sources sur les sujets opérationnels ;
  • fiabilité : validation automatique maintenue verte après enrichissement ;
  • exploitation : les runbooks (guides opérationnels pour l'agent IA) couvrent désormais les cas critiques du quotidien.

En pratique, le wiki passe d’un “bon point d’entrée” à un “accélérateur opérationnel”.

6. Statut final

  • SC-009 : atteint (objectif >= 40 %, résultat = 59,6 %)
  • V2 LLM Wiki : livrée
  • Dossier Billet #248 : clos en 2/2

7. Leçon apprise

Voici un bilan de la consommation de tokens pour le périmètre courant du rapport (implémentation LLM Wiki), en excluant le nettoyage du bruit token déjà comptabilisé dans le Billet #245 (may-26_ai-token-noise-cleanup-prior-to-llm-wiki) :

  • Borne de périmètre utilisée : depuis le premier événement de travail sur le rapport LLM Wiki détecté dans les logs (2026-05-05T11:18:16Z) jusqu'à la fin de la session courante ;
  • Consommation totale : 22 748 008 tokens sur 325 requêtes LLM ;
  • Répartition entrée/sortie : 22 544 312 tokens d'entrée (~99,10 %) vs 203 696 tokens de sortie (~0,90 %) ;

  • Modèles les plus consommateurs :

    • claude-sonnet-4.6 : 10 906 219 tokens (~47,94 %),
    • gpt-5.3-codex : 8 833 508 tokens (~38,83 %),
    • claude-haiku-4.5 : 3 008 281 tokens (~13,22 %).

  • Éléments ayant le plus consommé les tokens pendant ce périmètre :

    • les requêtes avec contexte cumulé très volumineux (121 requêtes >= 80 000 tokens d'entrée, soit 37,2 % des requêtes) ;
    • la réinjection de grands blocs de contexte et de sorties outils au fil des itérations, notamment après read_file (139 appels) et run_in_terminal (51 appels) ;
    • les mises à jour itératives d'état via manage_todo_list (48 appels).

  • Impact sommaire du wiki sur la consommation token (ce périmètre) :

    • 95 appels outils sur 417 (~22,8 %) ont explicitement ciblé docs/llm-wiki/ ;
    • 68 appels read_file sur 139 (~48,9 %) ont porté sur des fichiers wiki, ce qui confirme que le wiki est devenu une source primaire pendant l'exécution ;
    • cela a probablement augmenté la consommation pendant la phase de rédaction/validation, mais a réduit la latence de recherche (SC-009 : -59,6 %), donc améliore l'efficience token pour les sessions futures.

Prochaine étape : stabiliser ce niveau de performance dans le temps avec un contrôle périodique léger (re-test SC-009 trimestriel) et mise à jour continue des runbooks lors de chaque changement de workflow.