Construire un environnement de travail cumulatif pour l'IA
Enjeu
Une spécification et un vérificateur ont besoin d'un environnement stable : sans lui, l'utilisateur doit réexpliquer ses règles, ses données et ses méthodes à chaque nouvelle tâche. Une conversation très longue ne suffit pas à créer cet environnement — l'objectif est de structurer les informations pour que l'agent sache où les trouver et comment les utiliser, troisième couche de la méthode des trois couches.
Notions
Un fichier de règles générales, nommé CLAUDE.md dans cette méthode, est présenté comme automatiquement fourni à Claude au début de son intervention : fonctionnement du dépôt ou de l'espace de travail, architecture des fichiers, emplacement des connaissances, compétences personnalisées disponibles, règles permanentes, contrôles obligatoires. Une présentation complémentaire de ce même fichier insiste sur son rôle de table des matières plutôt que de contenu exhaustif : il ne détaille pas tout, il renvoie vers les fichiers pertinents selon le problème à résoudre. Une base de connaissances — désignée « LLM knowledge base » — regroupe documents de référence, données historiques, règles métier, modèles de livrables, exemples validés et procédures récurrentes ; elle peut être gérée dans un outil comme Obsidian, connecté à l'agent pour qu'il retrouve les fichiers pertinents sans les charger tous. Les tâches répétitives peuvent être formalisées en compétences personnalisées : un manuel opérationnel décrivant conditions de déclenchement, informations nécessaires, étapes, outils, règles, contrôles et forme du résultat — une compétence peut être créée en fin de conversation par une simple demande à l'IA de transformer l'échange en compétence, sans procédure manuelle distincte. Un quatrième élément, les guardrails, complète ces trois : des fichiers markdown listant anti-patterns et règles de comportement (par exemple, ne jamais traiter la pensée de l'utilisateur comme si elle existait isolément), référencés depuis CLAUDE.md et organisés dans un dossier dédié qui peut aussi accueillir un journal de l'évolution du système et une liste d'idées à intégrer.
Mécanisme et relations
La valeur d'une base de connaissances dépend moins du volume accumulé que de son organisation : l'agent doit pouvoir déterminer quelle information existe, où elle se trouve, dans quel cas l'utiliser, quelle version fait autorité et quelles informations ne doivent pas être confondues. Une compétence ne devient pas fiable uniquement parce qu'elle a été documentée — elle doit être utilisée, observée et corrigée, par un cycle qui formalise une première méthode, l'utilise sur une tâche réelle, observe les échecs et ambiguïtés, corrige les instructions, la réutilise, puis stabilise progressivement le processus.
Une instruction donnée à un modèle n'est pas toujours une contrainte effective : écrire « n'invente pas d'informations » ou « ne modifie pas ce dossier » exprime une règle, mais le modèle peut encore produire une information non étayée ou appeler un outil de modification. Lorsqu'une erreur aurait des conséquences critiques, la contrainte doit être appliquée au niveau du système ou de l'outil plutôt que dans le seul texte des règles — par exemple, un contrôle exécuté avant l'outil d'écriture peut bloquer matériellement la modification d'un dossier donné, là où une ligne dans CLAUDE.md ne fait que l'orienter. Cette distinction structure un classement des actions en trois niveaux d'autonomie : celles que l'IA peut exécuter automatiquement (suffisamment maîtrisées, coût d'erreur acceptable), celles qui nécessitent une validation humaine avant exécution (choix important, modification sensible), et celles qui ne doivent jamais être exécutées, l'interdiction étant imposée par une barrière technique chaque fois que possible plutôt que par une simple consigne.
Implications
Plus le coût d'une erreur est élevé, moins la sécurité doit dépendre de la seule obéissance du modèle à une instruction écrite. L'amélioration d'une compétence documentée vient de l'accumulation de retours concrets sur des tâches réelles, pas d'une tentative de perfection dès la première formalisation. Cette architecture (fichier de règles, base de connaissances, compétences réutilisables) recoupe partiellement le Principe du coffre orienté IA et obsidian-second-brain — les deux visent à faire persister des connaissances au-delà d'une conversation isolée — mais celle-ci cible la fiabilité d'une tâche ponctuelle réalisée avec un environnement de règles, quand l'autre vise la maintenance continue d'une base de connaissances comme produit en soi.
Limites
Le fichier d'environnement doit rester suffisamment clair pour orienter le système ; une accumulation de règles imprécises, redondantes ou contradictoires en réduit l'utilité, sans qu'une méthode formelle de construction de la base de connaissances ne soit détaillée par la source. Le comportement exact d'injection automatique de CLAUDE.md dans le contexte de Claude est une information datée, dépendante de la version de l'environnement utilisée, et signalée comme à risque d'obsolescence élevé.
Synthèse
Un fichier de règles, une base de connaissances organisée et des compétences réutilisables transforment une conversation isolée en environnement cumulatif. La méthode correcte fait dépendre le niveau de contrôle du coût d'une erreur — instruction simple pour le réversible, barrière technique pour le critique — et améliore les compétences par l'usage plutôt que par anticipation ; l'erreur la plus documentée est de faire reposer une interdiction critique sur la seule formulation d'une règle écrite, sans contrôle technique qui l'accompagne.