Architecture Multi-Agents

Comment Matthias a construit et orchestre plusieurs agents spécialisés pour produire du code de qualité production

3
agents spécialisés
2×
plus rapide en parallèle
0
merge sans 'go'
100%
PR reviewées
Overview
Le flux de données, en mouvement
Matthias exprime le besoin Lead Tech analyse & dispatch UI Worker front · sonnet Backend Worker back · sonnet Reviewer valide les PR main merge sur 'go'
Demande Tâche UI Tâche back Review & merge
Vue d'ensemble
Flux global
1 Matthias
Décrit une nouvelle feature

Il exprime son besoin en langage naturel. Le Lead Tech démarre aussitôt, sans questions inutiles.

J'aimerais pouvoir faire telle action directement depuis l'interface.
2 Lead Tech · Claude Code
Analyse et choisit la stratégie

Il évalue la complexité de la demande, puis décide seul de la meilleure approche — et l'annonce avant d'agir.

Tâche front + back, deux périmètres distincts → je lance UI Worker et Backend Worker en parallèle.
3 Lead Tech → GitHub
Création de la branche feature

Une branche de coordination est ouverte sur GitHub. Les Workers y grefferont ensuite leurs propres sous-branches.

git checkout -b feat/nouvelle-feature
git push -u origin feat/nouvelle-feature
4 UI Worker + Backend Worker
Implémentation simultanée

Les deux Workers avancent en parallèle, chacun sur sa propre branche, sans jamais se bloquer.

UI Worker
  • Composants & interface
  • Interactions et états
  • Animations & feedback
∥ en parallèle
Backend Worker
  • Routes & logique serveur
  • Accès aux données
  • Réponses & validation
5 Workers → GitHub
Ouverture des Pull Requests

Chaque Worker ouvre une PR vers la branche de coordination, avec un résumé clair et une checklist de tests.

worker/ui → feat/nouvelle-feature
worker/backend → feat/nouvelle-feature
6 Reviewer
Validation stricte des PRs

Il relit chaque changement, lance les tests et vérifie sécurité, régressions et périmètre. Il itère jusqu'à ce que tout soit propre.

Point bloquant détecté → le Worker corrige → je revérifie → approuvé.
7 Matthias
Dit « go » — merge sur main

Le Reviewer résume ce qui a changé. Matthias donne le feu vert explicite, et le merge se fait proprement sur main.

Parfait, go ! → merge squash sur main, historique propre garanti.
Équipe
Les trois agents
UI Worker
sonnet

Implémente tous les changements d'interface. Propose les améliorations visuelles opportunistes avant de les faire — jamais sans validation.

HTML CSS JavaScript Templates Jinja
Backend Worker
sonnet

Implémente la logique serveur. Propose son approche avant de coder si la solution n'est pas évidente. Jamais de touche au front.

Python Routes Flask Scripts Data
Reviewer
sonnet

Relit les PRs avec exigence maximale. Itère avec les Workers jusqu'à perfection. Ne merge jamais de façon autonome — attend toujours le 'go'.

Review Tests Sécurité XSS
Décision automatique
Quand dispatcher ?
Situation Stratégie Pourquoi
Feature touche front ET back Multi-agents Travail parallèle — 2× plus rapide
Plusieurs fichiers indépendants Multi-agents Pas de risque de conflit, gains en parallèle
Estimation > 50 lignes au total Multi-agents Complexité justifie la séparation des responsabilités
Bug isolé < 20 lignes Traitement direct Overhead des agents non justifié
Changement dans une seule zone Traitement direct Pas besoin de coordination
Question / explication / analyse Traitement direct Conversationnel — aucun code à produire
Économie de tokens
Coût comparatif
×1
Agent unique
Lead Tech traite tout seul. Rapide pour les petites tâches. Contexte partagé, pas de coordination.
×4–7
Subagents (Workers)
Chaque agent a son propre contexte. UI + Backend en parallèle. Reviewer en dernier. Coût justifié sur les grosses features.
×15
Agent Teams
Architecture d'agents totalement autonomes et persistants. Non utilisé ici — coût prohibitif pour ce cas d'usage.

Le Lead Tech décide seul du mode d'exécution selon la complexité — jamais de dispatch superflu pour une correction de 5 lignes.

Versioning
Workflow Git
workflow-git · main 
# Lead Tech crée la branche feature
feat/delete-propale
    │
    ├── worker/ui-delete-propale      ← UI Worker travaille ici
    │       └── PR → feat/  ✓  (reviewée avant merge)
    │
    └── worker/backend-delete-propale ← Backend Worker travaille ici
            └── PR → feat/  ✓  (reviewée avant merge)

# Reviewer valide la PR feat/ → main
Reviewer : "✓ PR #12 approuvée. Dis 'go' pour merger."

# Matthias donne le feu vert
Matthias : "go"  →  merge squash sur main

La règle du 'go' est non négociable. Aucun agent ne peut merger sur main sans instruction explicite de Matthias.

Garde-fous
Règles non négociables
Jamais de merge autonome
Le Reviewer approuve les PRs mais attend toujours le 'go' explicite de Matthias avant tout merge sur main.
Périmètre strict par Worker
UI Worker ne touche pas au Python. Backend Worker ne touche pas au HTML/CSS. Tout débordement est signalé au Lead Tech.
Test minimal obligatoire
Chaque feature ajoutée par un Worker doit être couverte par au moins un test. Absence de test = PR bloquée par le Reviewer.
Zéro XSS, zéro injection
Toute donnée utilisateur injectée dans le HTML sans échappement est un motif de refus immédiat (🔴 bloquant).
Améliorations opportunistes
Si un Worker repère une amélioration hors scope, il la propose à Matthias (via Lead Tech) avant de l'implémenter. Jamais sans validation.
Dispatch automatique
Le Lead Tech décide seul de dispatcher ou traiter directement — Matthias n'a pas à le demander. La stratégie est annoncée avant exécution.
Passe en grand