Suivi de projet OpenClaw: gestion d'état event-driven au lieu de Kanban

Le Kanban échoue en silence.

Pas parce que l'idée est mauvaise, mais parce que la boucle de mise à jour est manuelle. On oublie de déplacer les cartes. On perd le "pourquoi" d'un changement. Trois semaines plus tard, on ne sait plus ce qui a été décidé, ce qui bloquait, ou ce qui a été livré.

Un suivi de projet event-driven corrige ça en collant à la réalité: on travaille avec des updates du type "j'ai fini X, je commence Y, je suis bloqué par Z". OpenClaw capture ces updates en événements structurés, met à jour l'état du projet, et conserve l'historique. Le standup quotidien se génère tout seul.

Ce que vous allez construire

Un système de gestion d'état projet qui:

• Stocke projets, événements et blocages dans une base (SQLite ou Postgres)
• Permet de mettre à jour l'état via des messages en langage naturel
• Conserve le contexte des décisions ("pourquoi on a pivoté") comme donnée de première classe
• Lie des commits git aux événements pour la traçabilité
• Poste un standup quotidien sur Discord ou Telegram

C'est une alternative forte au "déplacer des cartes".

Pourquoi l'event-driven bat Kanban pour les solopreneurs

Kanban optimise pour des équipes avec un process explicite. Le solo est plus chaotique. Vous passez d'un projet à l'autre, vous prenez des décisions seul, et personne ne va déplacer vos cartes pour vous.

Le suivi event-driven marche car:

• Friction faible: vous dites ce qui s'est passé, point. Pas besoin d'ouvrir un board, trouver la carte, la déplacer, mettre à jour la description.
• Historique riche: vous pouvez demander "pourquoi on a pris cette décision ?" six mois plus tard et obtenir une réponse avec le contexte original.
• Statut réel: actif ou bloqué est dérivé des événements, pas d'un drag-and-drop oublié. Si le dernier événement est "Blocked on API access", le statut est bloqué. Automatiquement.
• Automatisable: résumés quotidiens, alertes de blocage, et rapports hebdomadaires se génèrent sans effort.
• Multi-projet natif: vous gérez 3 SaaS, un side-project et du freelance ? Un seul flux d'événements, filtrable par projet.

Avec un Kanban, vous avez un snapshot. Avec l'event-driven, vous avez un film complet.

Skills et prérequis

• Un canal de messages (Discord ou Telegram)
• Une base de données (SQLite suffit au début)
• Optionnel: GitHub CLI ou accès git pour scanner les commits
• Cron ou scheduler pour les résumés

Pour l'onboarding skills: /blog/openclaw-guide-competences

Modèle de données (simple et puissant)

Commencez avec trois tables:

• projects
• events
• blockers

Schéma exemple:

CREATE TABLE projects (
  id INTEGER PRIMARY KEY,
  name TEXT UNIQUE,
  status TEXT,
  current_phase TEXT,
  last_update TEXT
);

CREATE TABLE events (
  id INTEGER PRIMARY KEY,
  project_id INTEGER,
  event_type TEXT,
  description TEXT,
  context TEXT,
  timestamp TEXT
);

CREATE TABLE blockers (
  id INTEGER PRIMARY KEY,
  project_id INTEGER,
  blocker_text TEXT,
  status TEXT,
  created_at TEXT,
  resolved_at TEXT
);

Vous pourrez ajouter des tables "liens" plus tard (PRs, docs, designs). Ne démarrez pas là.

Setup pas-à-pas

Étape 1: créer un canal dédié aux updates

Créez un canal Discord du type:

• #project-state

Ou un topic Telegram.

Règle: les updates projets vont là, pour garder un signal propre.

Étape 2: définir des patterns de langage

OpenClaw a besoin d'indices cohérents. Pas besoin de commandes strictes, mais des patterns aident.

Exemples:

• "Je commence [tâche] sur [projet]"
• "J'ai fini [tâche] sur [projet]"
• "Bloqué sur [problème] pour [projet]"
• "Décision: [décision] pour [projet] parce que [raison]"
• "Pivot: [nouvelle approche] pour [projet] parce que [raison]"

Étape 3: donner le prompt opératoire

Copiez-collez:

Tu es mon project state manager.

Au lieu d'un Kanban, je te donne des updates conversationnels.

Quand je dis:
- "Finished [task]" -> log un event de progression et mets à jour l'état
- "Starting [task]" -> log un event et mets à jour current_phase
- "Blocked on [issue]" -> crée un blocker et passe le projet en "blocked"
- "Decision: ..." -> log un event décision avec contexte
- "Pivot: ..." -> log un event pivot avec le raisonnement

Quand je demande:
- "What's the status of [project]?" -> renvoie events récents, blockers, phase
- "Why did we decide [X]?" -> retrouve l'event décision et le contexte
- "What's blocking us?" -> liste tous les blockers ouverts

Tous les matins à 09:00:
1) Scanne les commits git des dernières 24h
2) Lie commits aux projets (branch, message, ou mapping)
3) Poste un standup dans #project-state:
- hier (events + commits)
- aujourd'hui (1-3 next actions)
- blocages (blockers ouverts)

Règles:
- Toujours préserver le contexte des décisions
- Poser une question si le nom projet est ambigu
- Résumés concis et actionnables

Étape 4: choisir une stratégie de lien commits -> projets

Trois options:

1. Convention dans les messages de commit

• Ajouter une clé projet: [Project:ClawRapid] ou proj:clawrapid

2. Convention sur les branches

• feature/clawrapid-billing

3. Fichier mapping

• Un fichier qui mappe repo ou dossiers -> projet

Choisissez une option et soyez cohérent. La convention de branches est souvent la plus simple pour un solopreneur qui utilise déjà git flow.

Étape 5: configurer le scan de commits automatique

OpenClaw peut scanner vos repos git via le GitHub CLI ou un accès local. Voici un prompt pour automatiser le lien commits-projets:

Toutes les 24h (avant le standup):
1) Pour chaque repo listé dans ~/projects/.repos:
   - git log --since="24 hours ago" --oneline
2) Pour chaque commit:
   - Extrais le nom de projet depuis la branche ou le message
   - Crée un event de type "commit" avec: hash, message, fichiers modifiés
3) Lie l'event au projet correspondant dans la base
4) Si un commit mentionne "fix" + un blocker existant, marque le blocker comme résolu

Ce scan transforme votre historique git en données de suivi projet sans aucune action manuelle.

Étape 7: définir le format de standup

Format stable et lisible:

📊 Standup - [Projet] - [Date]

✅ Hier:
- [event 1: type + description]
- [event 2: type + description]
- Commits: [hash1] message1, [hash2] message2

🎯 Aujourd'hui:
- [action 1]
- [action 2]
- [action 3]

🚧 Blocages:
- [blocker 1] (ouvert depuis [date]) - prochaine étape: [action]

Si vous gérez plusieurs projets, le standup peut être un résumé agrégé. Demandez à OpenClaw de trier par priorité et de ne détailler que les projets actifs.

Étape 8: hygiène de décisions

Beaucoup ne tracent pas les décisions et le regrettent.

Règle:

• À chaque "on devrait" ou "on fait ça", log une décision avec:
  • quoi
  • pourquoi
  • trade-offs
  • ce qui ferait changer d'avis

Prompts du quotidien

Log de progression

Finished: interface billing.
Project: ClawRapid Web
Context: attente du copy marketing, UI terminée.
Next: brancher les webhooks Stripe.

Log de blocage

Blocked on: attente accès compte analytics.
Project: ClawRapid Web
Impact: impossible de valider le funnel de conversion.

Log de décision

Decision: garder l'onboarding en 3 étapes.
Project: ClawRapid Web
Because: réduit l'abandon et est plus simple à A/B tester.
Trade-offs: moins flexible pour les power users.

Requêtes avancées

Une fois que votre base contient quelques semaines de données, les requêtes deviennent puissantes.

Résumé de sprint

Résume les 2 dernières semaines sur ClawRapid:
- Nombre d'events par type (progression, blocage, décision, pivot)
- Temps moyen entre blocage et résolution
- Commits liés
- Décisions majeures prises

Recherche de contexte

Pourquoi a-t-on décidé d'utiliser Stripe au lieu de LemonSqueezy pour ClawRapid ?

OpenClaw va chercher dans les events de type "décision" et vous restituer le raisonnement original, les trade-offs, et la date.

Rapport hebdomadaire

Tous les vendredis à 18h:
- Résume la semaine par projet (events, commits, blockers résolus)
- Liste les blockers encore ouverts
- Propose 3 priorités pour la semaine prochaine
- Envoie dans #project-state

Détection de projets en sommeil

Quels projets n'ont eu aucun événement depuis plus de 7 jours ?
Liste-les avec le dernier événement et la raison probable (bloqué, en pause, ou oublié).

Dépannage

L'assistant ne sait pas quel projet vous visez

• Utilisez un nom projet canonique (ex: "ClawRapid", pas "le site" ou "le projet").
• Ou ajoutez un code court dans chaque message: [CR] pour ClawRapid, [GF] pour Grepfeed.
• Si l'ambiguïté persiste, ajoutez un fichier de mapping ~/projects/aliases.json.

Le système devient trop lourd

• Réduisez le nombre de types d'events. Progression, blocage, et décision suffisent au début.
• Gardez le contexte bref: 1-2 phrases, pas un paragraphe.
• Pensez "journal de bord" plus que "outil PM complet".
• Archivez les projets terminés pour ne pas polluer les requêtes.

Vous arrêtez de l'utiliser

• Le plus petit rituel: 1 update en fin de journée, même une phrase.
• Le standup du matin devient la récompense: vous voyez le résultat sans effort.
• Astuce: liez l'update à un geste existant (fermer le laptop = envoyer un récap).

Les commits ne sont pas liés au bon projet

• Vérifiez votre convention (branche ou message).
• Ajoutez un fallback: si aucun projet n'est détecté, marquez l'event comme "unlinked" et triez manuellement une fois par semaine.

FAQ

Q: Peut-on garder Kanban et utiliser ça ? A: Oui. Beaucoup gardent un board pour communiquer, et utilisent les événements comme vérité interne et historique.

Q: SQLite ou Postgres ? A: SQLite est parfait au début. Passez à Postgres si vous avez besoin d'écritures multi-device, de concurrence, ou d'hébergement distant.

Q: Comment ça aide le context switching ? A: Le standup et la requête "status projet" vous permettent de re-rentrer dans un sujet sans relire 200 messages.

Q: Plusieurs agents peuvent-ils écrire dans le même état projet ? A: Oui. C'est excellent avec une équipe multi-agents (openclaw-multi-agent-team). Un agent synthétise, un agent exécute.

Q: Et si OpenClaw classe mal un événement ? A: Ajoutez une commande de correction: "Update: ce n'est pas fini, remets en in progress." Gardez une trace.

Q: Peut-on exporter les données vers un outil externe ? A: Oui. La base SQLite est un fichier standard. Vous pouvez l'interroger avec n'importe quel outil SQL, ou exporter en CSV pour un tableau de bord.

Q: Où voir d'autres workflows OpenClaw ? A: Notre index de use cases regroupe tous les workflows. Pour la config skills: guide des skills.

Comparaison avec les outils classiques

Le but n'est pas de remplacer tous les outils. C'est de capturer ce qui échappe aux boards: le contexte, les raisons, et les liens entre code et décisions.

Prochaines étapes

Une fois le suivi event-driven en place:

• Ajouter la visibilité Todoist pour les runs longs (openclaw-todoist)
• Ajouter un morning brief incluant l'état projet (openclaw-morning-brief)
• Faire tourner une équipe multi-agents où Stratégie lit cet état et assigne (openclaw-multi-agent-team)

Si vous en avez marre des boards périmés, arrêtez de déplacer des cartes et commencez à logger des événements. La couche d'automatisation est l'endroit où OpenClaw brille.