Aller au contenu

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)

  1. POC GSD : Install, test phases, mapper story simple, analyser fichiers générés
  2. Extensions Cerveau Positronic : /gsd:pmo-gate, scoring, verdicts, /gsd:multi-llm
  3. Intégrations externes : Jira, GitLab, hooks (pre-initialize, post-gate, post-execute)
  4. Intégration n8n : Workflow n8n appelle GSD via CLI, retry logic, dashboard
  5. Interface OpenClaw : Skills, notifications WhatsApp

Références


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)

  1. Fondations (1 sem) : Deploy n8n + AI-Gov, PostgreSQL, webhook API
  2. Workflow complet (1 sem) : 11 étapes, gates via API, agents LLM
  3. Dashboard (3-4 jours) : Event Store, WebSocket, artefacts versionnés
  4. Migration progressive (2 sem) : Story pilote, comparaison, ajustement
  5. 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