Agents de maintenance planifiés
Enjeu
Dans le pattern LLM Wiki d'origine, toute opération de maintenance — réconciliation, synthèse, nettoyage — se déclenche uniquement lorsqu'un humain la demande, ce qui signifie en pratique qu'elle ne se déclenche presque jamais : les wikis se dégradent alors silencieusement, faute d'être maintenus.
Notions
Des agents en arrière-plan, exécutés selon un horaire plutôt qu'à la demande, prennent en charge la maintenance à trois niveaux. Un processus quotidien clôture la journée, classe les idées éparses et met à jour la note du jour. Un processus hebdomadaire exécute la passe complète de réconciliation des contradictions et la passe de synthèse spontanée. Un contrôle de santé, à une fréquence non précisée par la source, repère les notes orphelines, les liens morts et les pages devenues obsolètes. Cette fonction correspond à ce que le gist original de Karpathy nomme Lint, décrit dans un tutoriel pratique comme un audit comparable à un linter de code, exécuté à la demande plutôt qu'à ce stade planifié dans la version minimale du pattern — voir Mettre en place un LLM Wiki avec Obsidian et un agent de code.
Mécanisme et relations
La source oppose explicitement cette approche à une architecture à base de hooks de cycle de vie et de bus d'événements : il ne s'agit pas d'une abstraction technique nouvelle mais simplement d'un ordonnanceur couplé à un fichier de règles. Chaque agent planifié journalise ses changements dans une note de diff quotidienne et attend 24 heures avant qu'un changement ne devienne permanent — une règle ajoutée après l'incident documenté dans gouvernance des contradictions et de l'obsolescence, où une automatisation non réversible avait dégradé le wiki dès son premier lancement.
Implications
Un agent qui peut être lancé à la demande n'est pas la même chose qu'un agent qui maintient effectivement le wiki : sans déclenchement planifié, la maintenance dépend entièrement de la discipline de l'utilisateur à s'en souvenir, ce qui revient en pratique à ne jamais la faire. obsidian-second-brain fournit quatre agents planifiés de ce type.
Limites
La fréquence exacte du contrôle de santé n'est pas précisée dans les sources traitées, pas plus que le mécanisme technique précis de planification au-delà de la mention générale d'un ordonnanceur. Une implémentation plus mature détaille ce contrôle en un balayage à deux temps noté sur barème plutôt qu'un simple contrôle binaire — voir Audit et bibliothécaire : deux couches de contrôle qualité.
Synthèse
Trois niveaux de fréquence — quotidien, hebdomadaire, contrôle de santé — suffisent à faire tenir la maintenance d'un wiki vivant sans intervention manuelle. La méthode correcte couple ce déclenchement planifié à une journalisation réversible ; l'erreur la plus documentée est d'automatiser des réécritures sans mécanisme de retour arrière, ce qui transforme une maintenance censée améliorer le wiki en source de dégradation dès son premier lancement.