Modifier le systeme

Agent OS est concu pour evoluer. Mais pas n'importe comment. Chaque modification suit un processus. Pas de YOLO.

Types de modifications

Processus de modification

Etape 1 : Identifier le besoin

Pourquoi modifier ? Documenter la raison.

Besoin : Le health check toutes les heures est trop frequent.
Raison : Cout token excessif, infra stable depuis 30 jours.
Proposition : Passer a toutes les 2 heures.

Etape 2 : Evaluer l'impact

Questions a se poser :

• Quels composants sont touches ?
• Y a-t-il des dependances en cascade ?
• Le changement est-il reversible ?
• Quel est le cout du rollback ?

Etape 3 : Proposer

Le CEO formule une proposition a l'utilisateur.

Proposition : Modifier CRON-001 de "0 * * * *" a "0 */2 * * *"
Impact : CRON-002 (brief) recevra des donnees infra datant de max 2h au lieu de 1h.
Risque : Faible. Un probleme infra serait detecte avec max 2h de retard.
Reversible : Oui (un commit Git).

Etape 4 : Valider

L'utilisateur repond :

• "Ok" → appliquer
• "Non" → archiver
• "Modifie" → retour a l'etape 3

!!! warning "Pas de modification sans validation" Le CEO ne modifie JAMAIS le systeme sans validation utilisateur. Exception : les corrections d'urgence (plan B, voir gestion des erreurs).

Etape 5 : Appliquer

# Faire la modification
# Valider
openclaw validate
# Commit
git add -A && git commit -m "chore: CRON-001 frequency 1h -> 2h"

Etape 6 : Verifier

Apres application, verifier que :

• Le systeme fonctionne normalement
• Les dependances ne sont pas cassees
• Les metriques restent dans les cibles

Etape 7 : Documenter

• Mettre a jour la documentation concernee
• Ajouter une entree dans le changelog
• Logger dans le brief du lendemain

Dependances

Le systeme a des dependances internes. Modifier un composant peut impacter d'autres.

Carte des dependances

OpenClaw (runtime)
├── Agents (tous)
│   ├── MCPs (outils)
│   ├── OpenMemory (preferences)
│   └── SOUL.md (config)
├── Crons (scheduling)
│   └── Agents (executants)
├── Telegram (delivery)
└── Notion (donnees)

Matrice d'impact

Rollback

Chaque modification est dans Git. Le rollback est simple.

Rollback d'un fichier

git checkout HEAD~1 -- .openclaw/cron/jobs.json
openclaw cron reload

Rollback complet

git log --oneline -10
git revert <commit-hash>
openclaw reload

Rollback d'urgence

Si le systeme est casse et qu'on ne sait pas pourquoi :

# Revenir au dernier etat stable connu
git checkout last-stable-tag
openclaw reload

!!! tip "Tagger les etats stables" Apres chaque semaine sans probleme, creer un tag Git.

git tag stable-2026-w14

Modifications interdites sans validation

Lecture liee

• Modifier la documentation pour les changements de docs
• Auto-modification pour ce que le CEO peut faire seul
• Changelog pour l'historique des changements