Vibe-Coding - Ateliers IA Generative pour le Développement

← Documentation GenAI | ↑ .. | → Claude Discovery

Cette série couvre les ateliers de vibe-coding : décrire ce que vous voulez construire en langage naturel, et l’IA écrit le code. Deux assistants majeurs sont couverts (Claude Code et Roo Code), avec des exercices progressifs allant de la découverte à l’automatisation avancée, plus un module d’agents autonomes (Claw Systems).

Structure du répertoire

Vibe-Coding/
├── Claude-Code/          # Ateliers Claude Code (5 modules)
├── Roo-Code/             # Ateliers Roo Code (5 modules + avances)
├── Claw-Systems/         # Agents IA autonomes (NanoClaw, OpenClaw)
├── Claudish/             # Proxy multi-provider (route assistants vers Anthropic/GLM/Qwen)
└── docs/                 # Documentation commune et introductions

Claude Code - Ateliers

Assistant de codage agentique développé par Anthropic. Interface CLI + Extension VS Code.

Module	Nom	Durée	Niveau	Description
01	Découverte	2-3h	Débutant	Installation, sessions, @-mentions, CLAUDE.md
02	Orchestration	2-3h	Débutant+	Agents Explore/Plan, recherche web
03	Assistant Developpeur	3h	Intermédiaire	/commit, /review, debug, refactoring
04	Création de Code	3h	Intermédiaire	Génération projet, tests, documentation
05	Automatisation Avancée	3-4h	Avancé	Skills, Subagents, MCP, Hooks

Durée totale : 13-16 heures

Ressources supplémentaires Claude Code

Scripts/ - Scripts PowerShell de preparation des workspaces
workspaces/ - Espaces de travail par participant
docs/ - Documentation spécifique Claude Code

Installation Claude Code

# Installation CLI - chemin canonique : installation native (Node.js non requis)
#   Windows : installateur depuis https://claude.com/code
#   macOS   : brew install --cask claude-code
#   Linux   : curl -fsSL https://install.claude.com | sh
claude --version

Configuration OpenRouter : passe par le proxy local openrouter-proxy (ANTHROPIC_BASE_URL = http://127.0.0.1:8899/api), guide pas-a-pas dans OPENROUTER_SETUP.md. Alternative npm : npm install -g @anthropic-ai/claude-code (voir le guide d’installation).

Roo Code - Ateliers

Framework de codage IA avec interface VS Code uniquement. Idéal pour les débutants.

Module	Nom	Contenu
01	Découverte	Premiers pas, conversations, vision
02	Orchestration des tâches	Gestion des tâches et workflows
03	Assistant Pro	Mode assistant professionnel
04	Création de contenu	Génération de code et contenu
05	Projets avancés	Projets complexes et integration

Ressources supplémentaires Roo Code

Ateliers avances/ - Modules supplémentaires avancés
Corrections/ - Solutions des exercices
Demo-Roo-Capabilities/ - Démonstrations des capacités Roo
Scripts/ - Scripts de preparation
workspaces/ - Espaces de travail par participant
docs/ - Documentation spécifique Roo Code

Préparation de l’environnement

# Creer son workspace
./Scripts/prepare-workspaces.ps1 -UserName "VotreNom"

# Nettoyer après la formation
./Scripts/clean-workspaces.ps1 -UserName "VotreNom"

Claw Systems - Agents Autonomes

Plateformes d’agents IA conteneurisés, self-hosted, opérant de manière autonome via Telegram et API.

Document	Description
README	Vue d’ensemble, comparaison avec Claude/Roo
Architecture	Architecture technique NanoClaw
Déploiement	Guide de déploiement Docker
ASR Integration	Transcription vocale Whisper

Cas d’usage : Agent Telegram avec transcription vocale, orchestration multi-agents, déploiement production.

Claudish - Proxy Multi-Provider

Proxy/routeur qui rend les assistants (Claude Code, Roo Code) et les bots (Hermes, NanoClaw) agnostiques du fournisseur : un wire Anthropic en entrée, le provider budgeté en sortie (Anthropic, z.ai GLM, Qwen self-hosté), jamais de bascule silencieuse.

Document	Description
README	Vue d’ensemble, écosystème 3 tiers, pipeline
Proxy en détail	Principe wire, topologie, router, connecter un agent, avancées du fork, troubleshooting
Config	Template de configuration (placeholders uniquement)

Mémoire sémantique et grounding — voir la section dédiée

Le backend de mémoire sémantique qui donne aux agents de codage une mémoire long-terme et les ancre dans des faits vérifiables (grounding) a été promu en section top-level : RAG et Mémoire Sémantique. Là où les ateliers ci-dessus décrivent les front-ends agents, cette section documente l’infrastructure qui les alimente — base vectorielle Qdrant, embeddings, indexation, et un notebook pratique de grounding — avec les incidents d’ops réels (dérives de montage, pertes de données, durcissement des sauvegardes) comme matière pédagogique.

Notre harnais réel — la couche sous les front-ends

Les sections précédentes (Claude Code, Roo Code, Claw Systems, Claudish) décrivent les front-ends agents tels qu’un utilisateur final les voit. Cette section décrit la couche qui les fait tenir à l’échelle d’une flotte : un MCP maison d’orchestration, un écosystème de MCPs de domaine, et un pattern coordinateur/workers multi-machines. C’est le « vibe-coding » vu du côté opérationnel, pas du côté session unique.

roo-state-manager — le MCP d’orchestration

roo-state-manager est un MCP maison qui regroupe 15 outils d’orchestration inter-agents et de mémoire collective. La doc pérenne détaille le rôle de chacun : HARNESS-OVERVIEW.md §2 (6 coordination + 4 mémoire/recherche + 5 infrastructure). Pour le cycle de vie et le diagnostic des serveurs MCP eux-mêmes, voir docs/reference/architecture_mcp_roo.md.

Les 15 outils, dans les trois catégories de HARNESS-OVERVIEW.md :

Catégorie	Outil	Rôle
Coordination (6)	`roosync_dashboard`	Canal principal entre agents — 3 types : `global`, `machine`, `workspace`.
	`roosync_messages`	DM point-à-point ; survit à la condensation du dashboard.
	`roosync_inventory`	Inventaire machines, heartbeats, santé du cluster.
	`roosync_config`	Collecte / publication / application de configuration entre machines.
	`roosync_baseline`	Versionnage et restauration d’une configuration de référence.
	`roosync_compare_config`	Diff de configuration entre deux machines.
Mémoire & recherche (4)	`codebase_search`	Recherche sémantique dans le code par concept, pas par mot-clé.
	`roosync_search`	Recherche sémantique ou plein-texte dans l’historique des tâches.
	`conversation_browser`	Navigation dans les sessions d’agents (lister d’abord, puis voir / arborer / résumer).
	`roosync_indexing`	Index Qdrant, cache, archivage — la mémoire collective elle-même.
Infrastructure (5)	`roosync_diagnose`	Diagnostic d’environnement, cycle de vie d’agent, santé du harnais.
	`roosync_mcp_management`	Gestion des serveurs MCP (lecture / écriture de config, rebuild, reload).
	`roosync_storage_management`	Inspection du stockage et maintenance (reconstruction de cache, réparation BOM).
	`read_vscode_logs`	Lecture des logs Extension Host / Renderer — le diagnostic de dernier recours.
	`export_data`	Export XML / JSON / CSV / Markdown d’une tâche, conversation ou projet.

Un point de modèle mental qui trompe souvent quand on découvre MCP : dans cet écosystème, une action n’est pas un outil. roosync_dashboard est un outil dont le comportement est piloté par un paramètre (action: "read" | "append" | "write" | …) ; il n’existe pas de roosync_dashboard_update à côté. C’est un choix de conception délibéré — regrouper une famille d’actions derrière un outil paramétré garde la surface d’outils lisible pour l’agent (15 descriptions à charger, pas 60), au prix d’un schéma d’entrée plus riche. Un agent qui invente <outil>_<action> par analogie échoue à l’appel : la liste ci-dessus est exhaustive.

Ces outils sont le câblage sans lequel les agents travailleraient en silos : un dashboard workspace, c’est ce qui fait qu’un worker sur une machine sait ce que le coordinateur attend de lui, et inversement. Le détail de l’architecture (processus, cycle de vie, configuration mcp_settings.json, redémarrage Python avec nettoyage .pyc) est dans architecture_mcp_roo.md.

MCPs maison de domaine

L’écosystème autour de roo-state-manager est composé de MCPs ciblés sur des domaines opérationnels. En voici trois :

MCP	Domaine	Quand il est utile
`jupyter-papermill`	Exécution de notebooks Jupyter	Ré-exécuter un notebook bout-en-bout avec paramètres injectés (`execute_notebook`), inspecter les cellules (`read_cells`, `inspect_notebook`), gérer le cycle de vie d’un kernel Jupyter (`manage_kernel`). Indispensable pour valider qu’un notebook pédagogique tourne réellement.
`qc-mcp-lite`	QuantConnect (backtests cloud)	Cycle `create_compile` → `create_backtest` → `read_backtest` pour valider une stratégie de trading sur la plateforme cloud. Renvoie Sharpe, CAGR, MaxDD — le trio à surveiller en QC.
`sk-agent`	Vision / multi-agent local	Délégation à des agents locaux spécialisés (vision, OCR, analyse de slides), multi-agent conversation presets, ou simple appel LLM local avec attachment image/document.

D’autres MCPs complètent la palette (recherche web canonique, navigation web automatisée, conversion document→Markdown, etc.). Le catalogue est volontairement modulaire : un MCP = un domaine, jamais un fourre-tout.

Le pattern coordinateur / workers multi-machines

Le harnais réel fonctionne comme une flotte d’agents qui se coordonnent sans fusion. Le schéma est le suivant, anonymisé volontairement — pas de hostnames réels, pas de comptes sensibles, pas de clés.

                 ┌──────────────────────────────────┐
                 │         Coordinateur             │
                 │  (merge, dispatch, dashboard)    │
                 │  Un seul agent dans ce rôle.     │
                 └──────────────────────────────────┘
                    │              │            │
                    │ DM RooSync   │ DM RooSync │ DM RooSync
                    ▼              ▼            ▼
            ┌──────────┐    ┌──────────┐    ┌──────────┐
            │ Worker A │    │ Worker B │    │ Worker C │
            │ (lane-1) │    │ (lane-2) │    │ (lane-N) │
            └────┬─────┘    └────┬─────┘    └────┬─────┘
                 │               │               │
                 ▼               ▼               ▼
            ┌─────────────────────────────────────┐
            │  Dashboards workspace (3 niveaux)   │
            │  global / par machine / par projet  │
            │  + DM inbox point-à-point           │
            └─────────────────────────────────────┘
                 │               │
                 ▼               ▼
            ┌─────────┐    ┌──────────┐
            │ Qdrant  │    │  GitHub  │
            │ (mémoire│    │ (PR /    │
            │  vector)│    │  issues) │
            └─────────┘    └──────────┘

Coordinateur : un seul agent dans ce rôle. Il review et merge les PRs, dispatche le travail via DM + dashboard, lit les deux dashboards workspace co-égaux (jamais un seul), et garde la cohérence cross-machine. Il ne commite jamais dans une branche feature et ne ferme jamais une issue qui ne lui appartient pas.

Workers : N agents, chacun portant typiquement une lane (machine × workspace). Un worker pioche dans le pool d’issues ouvertes (cross-lane, pas siloté par famille), livre une PR, et poste un rapport court sur son dashboard. Il peut aussi déléguer des side-tracks à des sous-agents spécialisés (exécution notebook, audit, prover Lean) en arrière-plan pendant qu’il tient une track principale. Chaque cycle vise plusieurs grains, dont au moins un DEEP de contenu ; le plancher est une substance, jamais un scan-générable.

Gouvernance : les règles de coordination (dispatch DM-first, jamais d’idle sanctionné, deep-queue par lane, fallback perenne quand la queue s’épuise) vivent dans .claude/rules/coordinator-discipline.md et .claude/rules/proactive-coordination.md. Elles sont auto-chargées au début de chaque session — c’est ce qui fait que le comportement du cluster est stable même quand un worker change.

Côté pédagogique : ce pattern montre qu’un « vibe-coding » professionnel n’est pas la délégation totale à un agent pendant une session : c’est l’orchestration de plusieurs agents, sur plusieurs machines, avec gouvernance explicite. C’est aussi une bonne introduction aux systèmes multi-agents (un coordinateur, N workers, une mémoire partagée).

Références croisées

Pour aller plus loin sur ce qui précède (anatomie d’un cycle worker /continue, garde-fous auto-chargés, situation dans le parcours pédagogique) : CLUSTER-ORCHESTRATION.md
Pour le passage de la topologie anonymisée à la galerie nominative fonctionnelle et la liste des séries-workspaces accessibles depuis la flotte : CLUSTER-ORCHESTRATION.md § Séries-workspaces et page collective
Architecture des MCPs (processus, cycle de vie, redémarrage Python) : docs/reference/architecture_mcp_roo.md
Spécialisations infrastructure (machines, GPUs, dispatch par mission) : docs/reference/cluster-agents.md
Mémoire sémantique (Qdrant, embeddings, indexation, notebook Hands-On) : RAG et Mémoire Sémantique
Règles de coordination auto-chargées : coordinator-discipline.md, proactive-coordination.md

Tous les exemples de cette section sont volontairement anonymisés : pas de hostname machine réel, pas de clé d’API, pas de token, pas de compte nominatif. La doc pérenne (architecture_mcp_roo.md, cluster-agents.md) liste les rôles fonctionnels ; les détails d’infra sensibles restent dans des fichiers gitignored.

Documentation commune

Le répertoire docs/ contient :

Document	Description
INTRO-GENAI.md	Introduction pratique à l’IA générative
CLUSTER-ORCHESTRATION.md	Orchestration cluster (coordinateur/workers, MCPs maison, RooSync) — le vibe-coding à l’échelle d’une flotte
CARTE-ESPACES.md	Carte des espaces de la série (#14526) : inventaire mesuré des workspaces et voisins, classification, arborescence cible et plan de PRs atomiques
ROSTER-MACHINES.md	Roster daté des identités machine:workspace du cluster (#14527) : quatre groupes (actifs, dormants, joignables par WAKE, redondants) par faisceau de preuves, en attente du choix utilisateur
Claude-Code/docs/	Documentation Claude Code (installation, concepts, aide-mémoire)
Roo-Code/docs/	Documentation Roo Code (installation, guide)
activites/	Activités pédagogiques (déménagées hors Vibe-Coding, #18223 — lieu unique `GenAI/activites/`)
sessions/	Sessions de formation

Guides disponibles

Claude Code : - INTRO-CLAUDE-CODE.md - Concepts et fonctionnalités - INSTALLATION-CLAUDE-CODE.md - Guide d’installation avec OpenRouter - CHEAT-SHEET.md - Commandes essentielles - CONCEPTS-AVANCES.md - Skills, Subagents, Hooks, MCP - COMPARAISON-CLAUDE-ROO.md - Comparaison Claude Code vs Roo Code

Roo Code : - INSTALLATION-ROO.md - Guide d’installation - ROO-GUIDED-PATH.md - Parcours d’apprentissage guide

Prérequis techniques

VS Code 1.60.0+
Node.js 18+ (pour le proxy OpenRouter et l’alternative npm uniquement — pas requis pour l’installation native de Claude Code)
Un compte OpenRouter avec une clé API
Connaissances de base en programmation

Objectifs d’apprentissage

A l’issue de cette série, vous serez capable de :

Décrire un projet en langage naturel et obtenir du code fonctionnel via l’IA
Orchestrer des workflows multi-agents (recherche, planification, exécution)
Automatiser les tâches courantes du développeur (tests, documentation, déploiement)
Configurer des agents autonomes conteneurisés (Claw Systems)

FAQ

Claude Code ne s’installe pas ou erreur `command not found`

Claude Code (modules 01 a 05) s’installe par le chemin canonique : l’installation native (défaut de la documentation officielle, Node.js non requis — guide : INSTALLATION-CLAUDE-CODE.md). Si erreur claude: command not found après installation native : vérifier que ~/.local/bin est dans le PATH, puis redémarrer le terminal.

Si vous avez utilisé l’alternative npm :

# Verifier Node.js (18+ requis)
node --version

# Installer globalement
npm install -g @anthropic-ai/claude-code

# Si toujours introuvable, verifier le PATH npm
npm config get prefix
# Ajouter au PATH si necessaire (Windows)
# $env:PATH += ";$(npm config get prefix)"

Si vous utilisez VS Code uniquement (sans CLI), l’extension Claude Code dans le Marketplace suffit. Le module 01 couvre les deux modes d’installation.

Quelle différence entre Claude Code et Roo Code ?

Critère	Claude Code	Roo Code
Interface	CLI + VS Code	VS Code uniquement
Agents paralleles	Jusqu’a 10 simultanés	Séquentiel
MCP	Support complet	Partiel
Skills/Commands	Écosystème standardisé	Configuration manuelle
Courbe d’apprentissage	Moyenne	Facile
OpenRouter	Oui	Oui

Recommandation : débutants complets -> commencer par Roo Code (module 01) ; développeurs -> Claude Code (module 01) offre plus de puissance. Les deux coexistent dans le même VS Code. Voir le tableau comparatif ci-dessus pour les différences détaillées.

Erreur d’authentification OpenRouter ou “401 Unauthorized”

Les ateliers Claude Code et Roo Code utilisent OpenRouter comme fournisseur LLM. Si erreur 401 :

# Verifier les variables d'environnement
$env:ANTHROPIC_BASE_URL    # doit etre "http://127.0.0.1:8899/api" (proxy local, cf OPENROUTER_SETUP.md)
$env:ANTHROPIC_AUTH_TOKEN   # doit commencer par "sk-or-v1-..."

Points fréquents :

La clé OpenRouter doit être active sur openrouter.ai/keys avec des credits disponibles.
Ne pas confondre clé OpenAI (sk-...) et clé OpenRouter (sk-or-v1-...) – les deux commencent par sk- mais ne sont pas interchangeables.
Le guide d’installation (INSTALLATION-CLAUDE-CODE.md) détaille la configuration pas-a-pas.

Les scripts PowerShell de preparation échouent

Les scripts Scripts/prepare-workspaces.ps1 et Scripts/clean-workspaces.ps1 (référencés dans les modules Claude Code et Roo Code) préparent les espaces de travail individuels. Si erreur :

# Verifier la politique d'execution PowerShell
Get-ExecutionPolicy
# Si "Restricted", autoriser les scripts locaux
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

# Executer depuis le bon repertoire
cd MyIA.AI.Notebooks/GenAI/Vibe-Coding/Claude-Code
./Scripts/prepare-workspaces.ps1 -UserName "VotreNom"

macOS / Linux : prepare-workspaces.ps1 est un script PowerShell (Windows-only). Le setup du poste contributeur Mac/Linux (kernels, clés, stack GenAI) : setup-linux-macos.md.

Si UserName contient des espaces, l’entourer de guillemets. Les workspaces sont créés dans le dossier workspaces/ de chaque sous-répertoire (Claude Code et Roo Code séparent leurs espaces).

NanoClaw / OpenClaw : comment déployer un agent autonome ?

Les Claw Systems (README) sont des agents IA conteneurisés qui opèrent via Telegram et API. Pour demarrer :

Lire l’Architecture pour comprendre les composants (LLM, ASR Whisper, Telegram bot).
Suivre le Guide de déploiement pour Docker Compose.
Configurer l’ASR Whisper si la transcription vocale est requise.

Prérequis : Docker + Docker Compose, un token Telegram Bot (@BotFather), une clé API LLM (OpenRouter ou OpenAI). Le déploiement complet tourne sur un VPS 4 GB RAM minimum.

Peut-on faire les ateliers sans OpenRouter ?

Oui, partiellement. OpenRouter est le fournisseur par défaut car il aggrege plusieurs modèles (Claude, GPT, Gemini) sous une seule clé. Alternatives :

API Anthropic directe : $env:ANTHROPIC_API_KEY = "sk-ant-..." (sans ANTHROPIC_BASE_URL). Fonctionne avec les modèles Claude uniquement.
API OpenAI directe : configurée via les settings Claude Code (sans OpenRouter). Modèles GPT uniquement.
Mode hors-ligne : les modules 01 et 02 contiennent des exercices de découverte qui ne nécessitent pas d’API (exploration de l’interface, configuration CLAUDE.md, gestion de sessions).

Le module 05 (Skills, Subagents, MCP) nécessite un LLM actif pour les démonstrations avancées.

Version 1.0.0 - Février 2026

Retour au sommet