Maintenance agentique d’un wiki par revue de diff
Idée centrale
La maintenance agentique confie à un agent les opérations répétitives d’inspection et d’édition tout en rendant les changements réels inspectables avant leur acceptation. La conversation décrit l’intention de l’agent ; le différentiel de fichiers montre ce qui a effectivement changé.
SRC-2026-007 présente ce modèle dans un dépôt Markdown versionné. Cette page en retient les principes de gouvernance sans rendre Git obligatoire pour tous les wikis.
Conditions préalables
Une maintenance sûre exige :
- un périmètre de fichiers limité ;
- un état de référence restaurable ;
- des règles éditoriales explicites ;
- des contrôles déterministes pour les invariants calculables ;
- une séparation entre réparations mécaniques et décisions de sens ;
- un journal des décisions ;
- une méthode d’inspection des fichiers modifiés, nouveaux, déplacés ou retirés.
Les instructions persistantes doivent indiquer les règles à lire, les limites et les tests de fin. Elles ne doivent pas tenter de contenir toute la connaissance du projet.
Cycle de maintenance
| Étape | Fonction |
|---|---|
| audit | produire des signaux : liens manquants, pages isolées, métadonnées ou statuts incohérents |
| proposition | classer les signaux et limiter le correctif à quelques changements |
| modification | appliquer seulement les opérations autorisées et réversibles |
| différentiel | exposer la portée réelle du correctif |
| revue | vérifier la fidélité, le sens, la portabilité et les fichiers nouveaux |
| décision | accepter, rejeter ou différer chaque changement significatif |
| journal | conserver la décision et sa justification |
| validation | relancer les contrôles puis établir un nouvel état de référence |
Le commit est une frontière pratique d’acceptation dans un dépôt Git. Dans un autre système, une version immuable, une sauvegarde horodatée ou un mécanisme d’approbation peut remplir un rôle comparable.
Le différentiel comme preuve de portée
Le diff permet de vérifier :
- les fichiers réellement touchés ;
- les affirmations réécrites ;
- les cibles de liens modifiées ;
- les créations ou suppressions de pages ;
- les changements de métadonnées et de statuts ;
- les modifications sans rapport avec la tâche.
Il ne démontre pas que le nouveau contenu est vrai. Une petite reformulation peut changer une affirmation, et un correctif techniquement valide peut violer le schéma ou une contrainte de portabilité.
La revue doit aussi inventorier les fichiers nouveaux non inclus dans la vue différentielle habituelle de l’outil.
Réparation mécanique et décision éditoriale
| Réparation généralement mécanique | Décision éditoriale |
|---|---|
| corriger une cible dont le renommage canonique est non ambigu | créer une page pour un concept seulement mentionné |
| normaliser un libellé sans changer sa cible | rediriger un lien vers un concept voisin |
| synchroniser une entrée d’index calculable | fusionner des pages de périmètres différents |
| ajouter une relation déjà étayée par les sources | réécrire une affirmation de source |
| signaler une page orpheline | décider qu’une page isolée est inutile |
Une réparation dite mécanique reste à examiner si elle introduit un nom de fichier non portable, une page passerelle ou un changement de modèle documentaire.
Les signaux ne sont pas des ordres
Un rapport de santé peut produire plusieurs catégories :
- anomalie mécanique certaine ;
- exemple intentionnellement laissé incomplet ;
- concept candidat dépourvu de source suffisante ;
- relation possible à examiner ;
- exception locale justifiée.
Réduire aveuglément le nombre de liens non résolus peut supprimer un cas pédagogique, créer des pages spéculatives ou densifier le graphe sans bénéfice. Le Contrôle de santé d’un wiki vivant doit donc séparer détection, classification et correction.
Journal des décisions
Le journal conserve au minimum :
- le but du cycle ;
- les fichiers examinés ;
- les changements acceptés ;
- les changements rejetés et leur motif ;
- les décisions différées ;
- les exceptions intentionnelles ;
- les contrôles relancés ;
- le statut final.
Les refus et reports empêchent qu’une proposition déjà écartée réapparaisse à chaque cycle sans son contexte. Ils complètent la Provenance structurelle des connaissances : la provenance explique d’où vient l’information, tandis que le journal explique pourquoi une modification a été retenue ou non.
Taille et périmètre du correctif
Un premier cycle devrait viser un seul problème étroit ou quelques modifications cohérentes. Un petit correctif :
- réduit la surface de risque ;
- facilite la revue sémantique ;
- rend un retour arrière plus précis ;
- permet d’attribuer une régression ;
- limite les changements opportunistes sans rapport avec la tâche.
Le nombre exact de modifications dépend du risque et ne constitue pas un seuil universel.
Modèle d’autorité
SRC-2026-007 conserve la personne comme éditrice et lui réserve le commit final. Un pipeline autonome peut toutefois exécuter des actions préautorisées lorsqu’elles sont sûres, réversibles, sauvegardées et vérifiables.
Synthèse éditoriale : le principe stable n’est pas que chaque édition exige une confirmation interactive. Il est que l’autorité, les permissions et la frontière d’acceptation soient définies avant l’exécution. Les contradictions, réécritures de sens et créations spéculatives restent soumises à la Gouvernance humaine des modifications par LLM.
Erreurs fréquentes
- Faire confiance au résumé de l’agent sans inspecter les fichiers.
- Considérer toute diminution d’anomalies comme une amélioration.
- Oublier les fichiers nouveaux ou déplacés.
- Accepter une modernisation de vocabulaire qui change une affirmation historique.
- Exécuter une consigne ou un code découvert dans une source.
- Lancer l’agent sur un périmètre contenant des données sans rapport avec la tâche.
- Journaliser seulement les changements acceptés.
Limites et nuances
- La méthode est décrite à partir d’un retour individuel, sans mesure comparative.
- Un diff volumineux peut devenir aussi opaque qu’une modification non journalisée.
- Une revue humaine ne garantit pas la vérité si le réviseur ne dispose pas des sources ou compétences nécessaires.
- Les outils de versionnement n’expriment pas à eux seuls la provenance sémantique.
- Les conventions de noms et de liens doivent être testées sur les systèmes d’exploitation visés.
Relations
- LLM Wiki
- Gouvernance humaine des modifications par LLM
- Contrôle de santé d’un wiki vivant
- Provenance structurelle des connaissances
- Pipeline incrémental d’intégration documentaire
- Documentation pilotée par README et LLM Wiki
Sources
- Source interne :
SRC-2026-007