# Roadmap : wol-proxy → Orchestrateur Ollama

## Vision

Transformer le wol-proxy en point d'entree central pour TOUS les appels a Ollama,
avec des fonctions d'orchestration.

## Fonctionnalites futures

### 1. Logs centralises
- Enregistrer chaque requete : modele, prompt (taille), duree, status
- Detecter les erreurs recurrentes (timeout, 502, VRAM full)
- Tableau de bord des performances par modele

### 2. Temporisation / File d attente
- Si Open WebUI utilise deja Ollama (GPU occupe), mettre en file d attente
- Empecher les conflits VRAM entre services
- File FIFO avec timeout max

### 3. Orchestration multi-services
- Open WebUI (port 3000)
- Hermes Agent (profil local)
- Scripts de test automatises
- Futurs outils (n8n, pipelines RAG...)

### 4. Cache intelligent
- Mettre en cache les reponses identiques (system prompt identique)
- Cache-hit pricing comme DeepSeek
- Invalidation par duree ou par modele

### 5. Mode degraded
- Si PC gaming en veille : renvoyer une reponse "PC en veille, reessayez"
- Planifier un reveil automatique (cron)
- Fallback vers un petit modele local sur le J5040 si PC indisponible

### 6. Healthcheck / Monitoring
- Ping regulier du PC pour savoir s'il est eveille
- Statistiques : temps de reveil moyen, duree des requetes
- Alertes si PC injoignable depuis plus de X minutes

## Stack technique envisagee

```yaml
# Proposition d evolution du docker-compose
wol-orchestrator:
  build: ./wol-orchestrator
  volumes:
    - ./logs:/var/log/orchestrator
    - ./cache:/var/cache/orchestrator
  environment:
    - REDIS_URL=redis://redis:6379  # File d attente
    - LOG_LEVEL=info
    - WAKE_TIMEOUT=180
    - REQUEST_TIMEOUT=300
    - MAX_QUEUE=10
```

## Priorite

| Fonction | Priorite | Effort | Impact |
|----------|----------|--------|--------|
| Logs | Haute | Faible | Utile tout de suite |
| File attente | Haute | Moyen | Evite conflits VRAM |
| Cache | Moyenne | Moyen | Economise tokens |
| Orchestration | Moyenne | Important | Architecture propre |
| Mode degrade | Basse | Moyen | Securite |
| Monitoring | Basse | Faible | Visibilite |

## Note

Idee originale de Folzo (juin 2026) — a implementer avec OpenCode Go ou un
langage adapte (Go, Rust ou Python selon les besoins de performance).