Vision long terme — Orchestration n8n + Interface conversationnelle¶
Archive : Ce document contient le détail des anciennes sections 1, 2, 4, 8 du TODO.md, condensées le 2026-02-26. Le contenu reste pertinent comme vision à long terme mais n'est plus prioritaire (context rot résolu autrement, OpenClaw/PicoClaw en attente de maturité).
1. Orchestration n8n + Interface OpenClaw¶
Objectif : Moderniser l'orchestration du workflow de gouvernance avec une interface conversationnelle mobile.
Note : PicoClaw (Go, <10MB RAM) est une alternative ultra-légère à OpenClaw, déployable sur IA-Server, multi-canaux (Telegram, Discord), multi-LLM natif.
Architecture proposée¶
WhatsApp
|
OpenClaw / PicoClaw (interface conversationnelle)
|
n8n (orchestration workflow - IA Server 192.168.1.82)
|
+--------------------------------------------------+
| Agents : Claude, ChatGPT, Ollama |
| Outils : Jira, GitLab, Vault |
| Storage : Fichiers YAML, Markdown |
+--------------------------------------------------+
Avantages attendus¶
Interface utilisateur : - Pilotage mobile via WhatsApp (lancement stories, vérification état, approbation gates) - Interface conversationnelle naturelle : "Lance l'étape 3 pour PD-42" - Notifications temps réel (gate prête, verdict disponible, workflow bloqué)
Orchestration n8n : - Dashboard visuel du workflow (état en temps réel) - Gestion robuste des erreurs (retry, fallback, alertes) - Intégrations natives (Jira, GitLab, HTTP, file system) - Traçabilité complète (historique de chaque exécution)
Tâches d'implémentation¶
Phase 1 - Infrastructure : - Installer n8n sur ProbatioVault-IA-Server (via Ansible) - Configurer n8n (port, auth, webhooks) - Installer OpenClaw/PicoClaw - Configurer interface (WhatsApp, webhooks vers n8n)
Phase 2 - Mapping workflow : - Créer workflow n8n pour étapes 0-2 (besoin, spec, tests) - Créer sub-workflow n8n pour gates (review + confrontation + verdict) - Implémenter boucle de correction (verdict NON_CONFORME) - Créer workflow n8n pour étapes 4-6 et 7-10
Phase 3 - Intégrations : - Nodes Jira, GitLab, Claude API, ChatGPT, Ollama, File System
Phase 4 - Interface conversationnelle : - Skills OpenClaw/PicoClaw (gov-start, gov-status, gov-approve, gov-reject, gov-step)
Phase 5 - Tests et migration : - Tester workflow complet, comparer avec shell actuel, migration progressive
Risques et mitigations¶
| Risque | Impact | Mitigation |
|---|---|---|
| Complexité intégration agents | Moyen | Commencer par agent simple (Claude HTTP) |
| Performance n8n (workflows longs) | Faible | Async + webhooks |
| Perte de traçabilité fichiers | Moyen | Garder artefacts Git + n8n logs |
| Dépendance OpenClaw/n8n | Élevé | Garder scripts shell en fallback |
| Courbe d'apprentissage n8n | Moyen | POC sur workflow simple d'abord |
Références¶
2. Intégration get-shit-done (GSD)¶
Objectif : Utiliser GSD comme moteur d'exécution pour résoudre le context rot tout en conservant le cerveau positronic de gouvernance ProbatioVault.
Contexte : get-shit-done (14.2k stars) est un système de context engineering et meta-prompting pour Claude Code.
Note 2026-02-26 : Le context rot a été résolu autrement (subprocess delegation, prompt caching, session recording, compaction awareness). GSD n'est plus nécessaire comme solution au context rot, mais reste intéressant comme framework de structuration.
Répartition des responsabilités¶
| Composant | Rôle |
|---|---|
| GSD | Moteur d'exécution + context engineering (infrastructure) |
| Cerveau Positronic | Gouvernance métier + gates PMO + règles (intelligence) |
Mapping ProbatioVault → GSD¶
| Étape ProbatioVault | Phase GSD | Extension Positronic |
|---|---|---|
| 0 - Expression de besoin | Initialize | Base GSD OK |
| 1 - Spécification | Plan | Base GSD OK |
| 2 - Tests & Validation | Plan | Base GSD OK |
| 3 - Review spécification | Gate PMO | Extension /gsd:pmo-gate |
| 4 - Plan d'implémentation | Plan | Base GSD OK |
| 5 - Review plan | Gate PMO | Extension /gsd:pmo-gate |
| 6 - Implémentation | Execute | Base GSD (multi-agents) |
| 7 - Acceptabilité | Verify | Base GSD + reviews auto |
| 8 - Review acceptabilité | Gate PMO | Extension /gsd:pmo-gate |
| 9 - Retour d'expérience | Iterate | Extension /gsd:retro |
Extensions Cerveau Positronic (custom)¶
/gsd:pmo-gate <type>: Gates PMO avec scoring convergence/gsd:multi-llm <agent>: Appel ChatGPT ou Ollama avec contexte frais/gsd:retro <story-id>: Retour d'expérience structuré/gsd:jira-sync <story-id> <status>: Sync Jira automatique/gsd:gitlab-commit <story-id>: Commit Git + surveillance pipeline
Tâches d'implémentation (5 sprints)¶
- POC GSD : Install, test phases, mapper story simple, analyser fichiers générés
- Extensions Cerveau Positronic :
/gsd:pmo-gate, scoring, verdicts,/gsd:multi-llm - Intégrations externes : Jira, GitLab, hooks (pre-initialize, post-gate, post-execute)
- Intégration n8n : Workflow n8n appelle GSD via CLI, retry logic, dashboard
- Interface OpenClaw : Skills, notifications WhatsApp
Références¶
- get-shit-done (14.2k stars)
4. Patterns Orthanc (Production-Ready)¶
Objectif : Implémenter les patterns runtime critiques d'Orthanc (fencing tokens, working memory) pour sécuriser l'exécution n8n en production.
Contexte : Orthanc est un orchestrateur distribué multi-agents (Scala + Rust).
Pattern 1 : Fencing Tokens (ADR-0014)¶
Problème : Gate 8 v3 (GO) arrive après Gate 8 v2 (RESERVE) à cause d'un délai → Verdict final faux
Solution : Fencing tokens (compteur BIGSERIAL monotoniquement croissant) + validation runtime
# WORKFLOW-STATE.yaml
metadata:
fence_token: 47
steps:
- id: "8"
gate_verdict:
version: 3
status: "GO"
fence_token: 47 # Écrase v2 (token 42) et v1 (token 35)
def apply_verdict(workflow_state, new_verdict):
if new_verdict['fence_token'] <= workflow_state['fence_token']:
raise StaleVerdictError("Verdict ignoré")
workflow_state['fence_token'] = new_verdict['fence_token']
workflow_state['current_verdict'] = new_verdict
Bénéfices : 100% élimination stale verdicts, ordre garanti, debugging facilité
Voir aussi : docs/architecture/orthanc-patterns-analysis.md
8. Convergence AI-Governance + n8n — Architecture n8n-first¶
Contexte : Le projet AI-Governance existe déjà avec un Control Plane complet.
Architecture cible¶
- n8n = Moteur d'exécution du workflow (orchestration des 11 étapes)
- AI-Governance = Surcouche de visualisation + event store + analytics + governance
Répartition des responsabilités¶
| Responsabilité | n8n | AI-Governance |
|---|---|---|
| Exécution workflow | Orchestration 11 étapes | - |
| Appel agents LLM | Nodes OpenAI/Anthropic/Ollama | - |
| Jira/GitLab sync | Nodes natifs | - |
| Visualisation | Basique (canvas) | Dashboard riche React |
| Historique runs | Limité | Event Store append-only |
| Audit & Replay | - | PostgreSQL Event Sourcing |
| Analytics & KPIs | - | Métriques, trends, scoring |
| Governance (RBAC) | - | Policy engine |
| Cost tracking | - | LLM usage budgets |
Modifications AI-Governance¶
À supprimer (délégué à n8n) : pmo-engine/, agent-runners/, workflow-api/execute-*
À conserver (surcouche) : event-bus/, audit/, cost-governance/, policy-management/, web-dashboard/, narration-layer/, knowledge-scoping/
À ajouter : n8n-integration/ (event listener + API service)
Stack technique¶
n8n + AI-Governance + PostgreSQL + Redis (docker-compose)
Plan de migration (5 phases)¶
- Fondations (1 sem) : Deploy n8n + AI-Gov, PostgreSQL, webhook API
- Workflow complet (1 sem) : 11 étapes, gates via API, agents LLM
- Dashboard (3-4 jours) : Event Store, WebSocket, artefacts versionnés
- Migration progressive (2 sem) : Story pilote, comparaison, ajustement
- Interface conversationnelle (1 sem) : OpenClaw/PicoClaw + WhatsApp
Métriques de succès¶
| Métrique | Baseline | Target |
|---|---|---|
| Temps exécution workflow | ~19h | ~15h |
| Taux d'échec étapes | 15-20% | <10% |
| Time to dashboard | Manuel | Temps réel |
| Modification workflow | 2-3h | 30 min |
Effort total estimé : 3-4 semaines