Workflow type : Hermes + OpenCode — le duo vibe coding souverain

Guide Publié le 2026-07-29

Workflow type : Hermes + OpenCode — le duo vibe coding souverain

Date : 29 juillet 2026

Objectif : orchestrer Hermes (chef d'orchestre) et OpenCode (chirurgien du code) pour un vibe coding 100% maîtrisé — local-first, zéro dépendance cloud pour le quotidien.

1. L'architecture du duo

┌─────────────────────────────────────────────────────────┐
│  TOI                                                    │
│  Telegram / Terminal                                    │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│  HERMES — chef d'orchestre                              │
│  • Mémoire persistante (conventions, projets)           │
│  • Recherche / plan / architecture                      │
│  • Orchestration OpenCode via terminal                  │
│  • Veille, cron, delegation                             │
└────────────────────────┬────────────────────────────────┘
                         │ terminal: opencode run "..."
┌────────────────────────▼────────────────────────────────┐
│  OPCODE — chirurgien du code                            │
│  • LSP, diffs, éditions précises                        │
│  • Plan/Build, sessions                                 │
│  • MCP (Context7, Playwright...)                        │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│  MODÈLES                                               │
│  Local  : Ollama / LM Studio (MS-S1 Max, 128 Go)       │
│  Cloud  : fallback pour tâches complexes                │
└─────────────────────────────────────────────────────────┘

Règle d'or : Hermes décide QUOI faire, OpenCode décide COMMENT le faire dans le repo.

2. Configuration OpenCode — prête à copier

2.1 `~/.config/opencode/opencode.jsonc` (global)

{
  "$schema": "https://opencode.ai/config.json",

  // Modèles locaux par défaut
  "provider": {
    "ollama": {
      "npm": "@openai/opencode-ollama",
      "models": {
        "qwen3-coder:30b": { "name": "Qwen3 Coder 30B (local)" },
        "glm4.5-coder:32b": { "name": "GLM 4.5 Coder 32B (local)" },
        "deepseek-coder-v3:16b": { "name": "DeepSeek Coder V3 (local)" }
      }
    },
    "lmstudio": {
      "npm": "opencode-lmstudio",
      "options": { "baseURL": "http://localhost:1234/v1" }
    }
  },

  // Modèle par défaut : local
  "model": "ollama/qwen3-coder:30b",

  // Permissions : code OK, bash demandé, web interdit
  "permission": {
    "edit": "allow",
    "bash": "ask",
    "webbrowser": "deny"
  },

  // Commandes personnalisées
  "command": {
    "review": {
      "description": "Revue de code avant commit",
      "prompt": "Faites une revue de code des derniers changements. Listez : bugs potentiels, dette technique, améliorations. Répondez en français."
    },
    "test": {
      "description": "Lancer les tests et corriger",
      "prompt": "Exécutez la suite de tests. Corrigez chaque échec un par un, en expliquant la cause."
    },
    "commit": {
      "description": "Message de commit conventionnel",
      "prompt": "Analysez les changements non commités et proposez un message de commit conventionnel (feat/fix/refactor/docs)."
    },
    "explain": {
      "description": "Expliquer un fichier ou une fonction",
      "prompt": "Expliquez le code demandé en français : rôle, flux, points sensibles. Niveau : développeur junior."
    }
  },

  // Serveurs MCP utiles
  "mcp": {
    "context7": {
      "type": "local",
      "command": ["npx", "-y", "@upstash/context7-mcp"]
    },
    "fetch": {
      "type": "local",
      "command": ["uvx", "mcp-server-fetch"]
    }
  }
}

2.2 `~/.config/opencode/AGENTS.md` (global — TES conventions)

# Conventions personnelles — Sébastien

## Langue et style
- Répondre TOUJOURS en français.
- Commentaires de code en français.
- Messages de commit : conventionnel (feat:, fix:, refactor:, docs:).

## Qualité
- Pas de code mort ni de TODO laissé volontairement.
- Nommage explicite (pas de `x`, `tmp`, `data` génériques).
- Chaque nouvelle fonction : tests associés.

## Projets
- SNCF / ferroviaire : maintenance, inspection, drones, edge AI.
- NE PAS utiliser de métaphores ferroviaires dans les articles éditoriaux.
- IA : local-first, souveraineté des données, modèles open weight.

2.3 `AGENTS.md` projet (à la racine de chaque repo)

# Règles du projet <NOM>

- Stack : <langage/framework>
- Commandes : `npm test` / `make test` / `pytest`
- Linter : <commande>
- Architecture : <points clés>
- Conventions : <spécifiques au repo>

💡 Génération automatique : lance opencode, tape /init — il analyse le repo et écrit le fichier.

3. Les commandes d'orchestration Hermes → OpenCode

3.1 Le mode « je pilote depuis Telegram »

Depuis Hermes (Telegram ou terminal), tu dis simplement :

Hermes, dans le repo ~/projets/mon-projet, lance opencode pour :
1. Analyser le fichier src/auth.js et lister les failles de sécurité
2. Corriger la fonction de connexion (bug 500 sur les mots de passe avec @)
3. Lancer les tests

Hermes exécute alors :

cd ~/projets/mon-projet
opencode run "Analyse src/auth.js, liste les failles de sécurité, corrige le bug de connexion (500 sur mots de passe avec @), lance les tests. Réponds en français."

3.2 Le mode « plan d'abord » (le plus sûr)

Hermes : ouvre une session plan sur mon-projet et propose une
architecture pour ajouter un module de détection de défauts de voie

cd ~/projets/mon-projet
opencode run --agent plan "Propose une architecture pour un module de détection de défauts de voie (capteurs + edge AI). Liste les fichiers à créer/modifier. Réponds en français."

Puis, après validation du plan :

Hermes : exécute le plan sur mon-projet

cd ~/projets/mon-projet
opencode run --continue "Exécute le plan validé, fichier par fichier, avec tests entre chaque étape."

3.3 Le mode « délégation » (tâche longue en background)

Hermes délègue à un subagent qui pilote OpenCode — toi tu continues ta vie :

# Hermes lance en background (delegate_task)
cd ~/projets/mon-projet && opencode run "Refactorise le module utils/date.js en extrayant la logique de calcul dans un module séparé. Ajoute les tests. Réponds en français." && opencode run --continue "Fais une revue de code des changements (/review)."

3.4 Le mode « revue avant commit » (rituel)

Hermes : fais une revue du dernier travail d'opencode sur mon-projet

cd ~/projets/mon-projet
git diff --stat
opencode run "/review" && opencode run --continue "/commit"

4. Workflows types

4.1 Développer une feature (complet)

Étape	Acteur	Action
1	🟦 Hermes	Recherche le contexte (doc, best practices, conventions passées)
2	🟦 Hermes	Rédige la spec de la feature
3	🟩 OpenCode	`opencode run --agent plan "Étudie la spec, propose le plan d'implémentation"`
4	🟦 Hermes	Valide/corrige le plan
5	🟩 OpenCode	`opencode run --continue "Implémente le plan avec tests"`
6	🟩 OpenCode	`opencode run --continue "/review"`
7	🟦 Hermes	Relit la review, vérifie, commit message
8	🟦 Hermes	Déploie / cron de monitoring

4.2 Corriger un bug (rapide)

Hermes : corrige le bug X dans mon-projet (symptôme : ...)
→ terminal : opencode run "Corrige le bug (symptôme). Explique la cause racine. Réponds en français."
→ opencode run --continue "Lance les tests et confirme le fix."

4.3 Refactoring prudent

Hermes : refactore la logique de paiement dans mon-projet
→ opencode run --agent plan "Propose un plan de refactoring pour extraire la logique de paiement"
→ (validation du plan par toi)
→ opencode run --continue "Exécute le plan, étape par étape, tests entre chaque"

4.4 Vibe coding pur (session interactive)

Toi → terminal : cd ~/projets/mon-projet && opencode
→ TUI OpenCode : Tab (Plan) → discuter → Tab (Build) → itérer
→ De temps en temps : demander à Hermes (Telegram) un avis extérieur sur le code

5. Scripts utilitaires

5.1 `~/.local/bin/vibe` — lanceur rapide

#!/usr/bin/env bash
# Usage : vibe <repo> [tâche]
# Lance OpenCode dans le repo, ou exécute une tâche en mode run
REPO="$1"
shift
cd "$HOME/projets/$REPO" 2>/dev/null || { echo "Repo introuvable: $REPO"; exit 1; }
if [ -z "$1" ]; then
  exec opencode
else
  exec opencode run "$*"
fi

chmod +x ~/.local/bin/vibe
vibe mon-projet "corrige le bug 500 de connexion"

5.2 `~/.local/bin/oc-plan` — plan puis build

#!/usr/bin/env bash
# Usage : oc-plan <repo> <description du plan>
REPO="$1"; shift
cd "$HOME/projets/$REPO" 2>/dev/null || { echo "Repo introuvable: $REPO"; exit 1; }
opencode run --agent plan "$*" 
echo "── Plan proposé. Tape Enter pour exécuter, Ctrl+C pour annuler ──"
read -r
opencode run --continue "Exécute le plan."

6. Règles d'usage (ce qui marche, ce qui ne marche pas)

✅ Hermes fait mieux

Recherche et documentation (web, veille)
Architecture de haut niveau et spec
Orchestration multi-outils (test → lint → deploy)
Mémoire de tes conventions entre projets
Travail en background (delegation, cron)
Accès Telegram (coder depuis le canapé)

✅ OpenCode fait mieux

Éditions précises dans le repo (LSP, diffs)
Navigation dans une grosse codebase (symboles, références)
Boucle d'itération rapide dans le terminal
Refactoring multi-fichiers avec vérification à chaque étape
/review et /commit intégrés au flux git

❌ À éviter

Faire coder OpenCode sans AGENTS.md (conventions perdues)
Laisser Hermes éditer 50 fichiers d'un coup sans diff (préférer OpenCode)
Utiliser un petit modèle local pour du refactoring critique (hallucinations)
Donner bash: allow global à OpenCode (un rm -rf et c'est fini)

7. Le mot de la fin

Hermes pense, OpenCode opère. Le workflow qui tient la route : Hermes prépare le terrain (spec, plan, contexte), OpenCode exécute avec précision chirurgicale, Hermes vérifie et orchestre la suite (tests, deploy, veille). Les deux en local sur ton MS-S1 Max — aucun octet ne sort de chez toi.

Sources

opencode.ai/docs — documentation officielle
github.com/sst/opencode
docs.ollama.com/integrations/opencode
github.com/groxaxo/opencode-local-setup
kanaries.net — utiliser OpenCode en français

Workflow type : Hermes + OpenCode — le duo vibe coding souverain

Workflow type : Hermes + OpenCode — le duo vibe coding souverain

1. L'architecture du duo

2. Configuration OpenCode — prête à copier

2.1 ~/.config/opencode/opencode.jsonc (global)

2.2 ~/.config/opencode/AGENTS.md (global — TES conventions)

2.3 AGENTS.md projet (à la racine de chaque repo)

3. Les commandes d'orchestration Hermes → OpenCode

3.1 Le mode « je pilote depuis Telegram »

3.2 Le mode « plan d'abord » (le plus sûr)

3.3 Le mode « délégation » (tâche longue en background)

3.4 Le mode « revue avant commit » (rituel)

4. Workflows types

4.1 Développer une feature (complet)

4.2 Corriger un bug (rapide)

4.3 Refactoring prudent

4.4 Vibe coding pur (session interactive)

5. Scripts utilitaires

5.1 ~/.local/bin/vibe — lanceur rapide

5.2 ~/.local/bin/oc-plan — plan puis build

6. Règles d'usage (ce qui marche, ce qui ne marche pas)

✅ Hermes fait mieux

✅ OpenCode fait mieux

❌ À éviter

7. Le mot de la fin

Sources

2.1 `~/.config/opencode/opencode.jsonc` (global)

2.2 `~/.config/opencode/AGENTS.md` (global — TES conventions)

2.3 `AGENTS.md` projet (à la racine de chaque repo)

5.1 `~/.local/bin/vibe` — lanceur rapide

5.2 `~/.local/bin/oc-plan` — plan puis build