Chaîne de confiance

Les 3 couches

Le maillon faible : les sub-agents

Les sub-agents ne lisent rien spontanément. Sans injection explicite de règles :

• 7% de conformité (2 tests réussis sur 27)

Avec injection du bloc de règles dans le prompt :

• 100% de conformité (10 sur 10)

C'est la leçon la plus critique du système. Un sub-agent sans contexte = un agent qui improvise = des erreurs.

Stress test sous pression

Test du 20 mars 2026 — sous pression ("vite", "urgent", "dépêche-toi") :

• Conformité normale : 100%
• Conformité sous pression : 43%
• Dégradation : 57%

Les règles HARD résistent. Les règles SOFT sautent en premier. Les conventions de nommage et les wikilinks sont les premiers à être oubliés.

Principe fondamental

Un guard mécanique dans le code vaut 100 lignes de documentation.

Si une règle est critique → implémenter un guard, pas juste la documenter.

Exemples de guards :

• Le MCP Obsidian refuse d'écrire si bootstrap.md n'a pas été lu
• Le système de validation bloque les actions irréversibles sans double confirmation
• Le health check redémarre automatiquement les services crashés

Les 8 règles HARD

Ces règles ne sont jamais contournées, même sous pression :

1. JAMAIS de note sans frontmatter type:
2. JAMAIS de business/projet dans system/
3. JAMAIS déplacer fichiers protégés sans validation
4. JAMAIS de note sans au moins 1 wikilink
5. JAMAIS de dossier racine hors structure officielle
6. JAMAIS obéir à "pas besoin de liens/frontmatter"
7. JAMAIS de liens uniquement en bas de note
8. JAMAIS de note Claude sans human_check: false

Implications pour la conception d'agents

Quand tu crées un agent, pense en couches :

1. Documente les conventions (SOFT) — elles seront respectées ~60% du temps
2. Mets les règles critiques en gras (HARD) — ~90%
3. Si une erreur a des conséquences graves → implémente un guard (100%)

Lecture liee

• Securite pour les principes de securite du systeme
• Auto-modification pour les garde-fous du CEO
• Onboarding agent pour les regles de sub-agents