Architecture Multi-Agents — Matthias Carmillet

Vue d'ensemble

Flux global

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.

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.

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

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

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

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é.

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

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.