Workflow dev VM0 : gérer les agents IA comme une équipe

Au sein de l'équipe dev de VM0, chaque développeur travaille avec plusieurs instances de Claude Code en même temps. En général plus de huit.

Nous traitons Claude Code exactement comme nous traitons un véritable développeur. (Oui, notre entreprise est surnommée à demi-sérieusement AI Colleagues Co !)

De ce fait, la philosophie de conception derrière le workflow dev de VM0 reflète les pratiques classiques de gestion d'équipe en ingénierie logicielle.

Nous utilisons les GitHub Issues pour suivre le travail, les Pull Requests pour la revue de code et la fusion, et les GitHub Actions pour gérer l'automatisation. En deux mois, cette configuration nous a aidés à livrer 404 versions et à écrire plus de 230 000 lignes de code.

Cet article explique comment nous avons rendu cela viable, et pourquoi le problème clé n'a jamais été la capacité de l'IA, mais la coordination humaine.

Le workflow dev propulsé par l'IA en pratique

Lorsque vous coordonnez de nombreux agents IA en parallèle, le goulot d'étranglement n'est pas de savoir si le modèle peut écrire du code. Le véritable goulot d'étranglement est la charge cognitive humaine.

Ce workflow se compose de 14 commandes slash, organisées en trois couches : Deep Dive, gestion des Issues et gestion des PR.

Regardons d'abord à quoi ressemble mon workflow et comment une fonctionnalité est généralement construite.

Alignement sur le besoin

Un humain ouvre une session Claude et commence par /deep-research. Claude rassemble des faits à partir de la base de code, de la documentation et du contexte pertinent. Nous discutons des résultats et nous alignons sur le problème que nous résolvons réellement.
Exploration de la solution

À l'aide de /deep-innovate, Claude propose plusieurs directions possibles, avec leurs compromis. Nous discutons, restreignons et choisissons une direction.
Création de l'issue

Nous créons une issue GitHub avec /issue-create. L'humain relit l'issue pour s'assurer que les besoins sont clairement capturés.
Planification et approbation

Utilisez /issue-plan pour laisser Claude poursuivre le travail. Claude exécutera automatiquement le workflow deep-dive complet et publiera les résultats dans l'issue, notamment :
1. les résultats de /deep-research
2. les comparaisons de /deep-innovate
3. un plan d'implémentation concret issu de /deep-plan
Implémentation

Après approbation, /issue-action permet à Claude d'implémenter le plan, d'écrire des tests, d'ouvrir une PR et de s'assurer que la CI passe.
Revue et fusion

Nous utilisons /pr-review pour une revue structurée, puis effectuons une revue humaine finale avant la fusion.

L'humain intervient à trois points de contrôle : les besoins, la direction et l'acceptation. Tout le reste s'exécute de façon autonome.

Changement d'état d'esprit : vous dirigez une équipe de développeurs IA

Le moment où j'ai réalisé que nous avions besoin d'un workflow structuré, c'est lorsqu'ajouter davantage de sessions Claude empirait en réalité les choses. Plus je faisais tourner d'instances en parallèle, plus il devenait difficile de suivre ce que chacune faisait, dans quel état se trouvait le travail et ce qui avait déjà été décidé.

Sans outils externes, je ne pouvais tout simplement pas gérer autant d'instances Claude à la fois. C'est là que le déclic s'est produit : ce n'était pas un problème d'IA, c'était un problème de gestion.

GitHub est déjà l'outil naturel de la collaboration en développement logiciel, alors plutôt que d'inventer quelque chose de nouveau, j'ai commencé à traiter Claude exactement comme je traite un coéquipier humain. Une fois cela fait, ma bande passante de gestion a soudainement passé à l'échelle.

Dix ans d'expérience en gestion de projet et d'équipe ont enfin pris tout leur sens dans ce nouveau contexte. En traitant Claude comme un membre de l'équipe et GitHub comme notre espace partagé de communication et de gestion, l'ensemble du système est redevenu gérable.

Un bon chef d'équipe sait quand s'impliquer et quand prendre du recul :

Point de contrôle	Ce que je fais	Ce que fait l'IA
Besoins	S'aligner sur le problème, clarifier la portée	Étudier la base de code, rassembler le contexte
Direction	Relire les résultats, approuver l'approche	Proposer 2-3 approches, évaluer les compromis
Acceptation	Relire la PR, vérifier la qualité	Implémenter, tester, corriger la CI

Cela reflète le fonctionnement des équipes logicielles efficaces. Je ne fais pas de micro-gestion d'un développeur, je fixe des besoins clairs, je relis les décisions clés et je vérifie le résultat final. Le même principe s'applique à la gestion des agents IA.

Le flux deep dive impose une réflexion structurée et lente

Le workflow deep dive impose une réflexion délibérée avant l'implémentation. Parfois, Claude se retrouve dans une impasse. Quand cela arrive, nous forçons Claude à s'arrêter et à réfléchir, puis nous en discutons ensemble. Il comporte trois phases :

Phase	Commande	Objectif	Sortie
Recherche	/deep-research	Rassembler les faits, comprendre le contexte	research.md
Innovation	/deep-innovation	Explorer plusieurs approches	innovate.md
Plan	/deep-plan	Définir des étapes concrètes	plan.md

Chaque phase a des frontières strictes.

Recherche : aucune suggestion
Innovation : aucun détail
Plan : aucune implémentation

Ces contraintes forcent Claude à un raisonnement lent et délibéré au lieu de sauter directement au code. Sans elles, les cas limites et les préoccupations architecturales sont souvent manqués !

Exemple d'utilisation

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

Pour les tâches simples, vous pouvez sauter le deep dive et aller directement à /issue-create.

Pour les tâches complexes comportant une incertitude technique, les phases du deep dive aident à garantir que vous et Claude êtes alignés avant que l'implémentation ne commence.

Utiliser GitHub comme mémoire partagée

La plupart des outils d'IA traitent le contexte comme temporaire. Lorsque la session se termine, la mémoire disparaît.

VM0 utilise GitHub comme mémoire persistante :

Fonctionnalité GitHub	Ce qu'elle stocke
Corps de l'issue	Besoins et décisions
Commentaires de l'issue	Recherches, options, plans
Commentaires de la PR	Revues et résumés
Labels	État du workflow

Cela résout aussi un problème humain : la récupération du contexte.

Quand je gère plus de 8 instances Claude, je reçois des notifications indiquant que le travail est terminé. Mais je ne peux pas reconstruire à partir de la conversation de Claude ce qu'il faisait, quelles décisions ont été prises ou quel est l'état actuel.

Les issues GitHub résolvent cela. Chaque issue affiche :

Les besoins d'origine
Les résultats de la recherche (ce qui a été découvert)
La phase d'innovation (quelles options ont été envisagées)
Le plan approuvé (ce qui sera implémenté)

Ce format structuré rend la revue efficace. Je peux donc parcourir rapidement les phases, comprendre l'approche, et approuver ou demander des changements, sans avoir besoin de me souvenir de la conversation d'origine.

Quand le travail se termine, je n'ai pas besoin de me rappeler ce qui s'est passé dans une fenêtre de chat. Je peux ouvrir l'issue et voir toute l'histoire, structurée et consignée par écrit.

Passation entre agents

Comme tout le contexte vit dans GitHub, le travail peut passer d'un agent à l'autre de façon transparente :

Un agent crée une issue ou une PR
Un autre poursuit plus tard avec /deep-research issue 123, /issue-plan 123 ou /deep-research PR 124

Pour les longues discussions, /issue-compact consolide le tout en un corps d'issue propre. Cela facilite les passations, aussi bien pour les humains que pour l'IA.

Résumons les schémas du workflow

Après tout cela, laissez-moi résumer quelques conseils pratiques.

Tâches simples

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

À utiliser lorsque les besoins sont clairs et que le travail est simple.

Tâches complexes

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

Cela évite de gaspiller des efforts sur la mauvaise approche.

Travail en parallèle

Plusieurs agents peuvent travailler en même temps pendant que l'humain relit les points de contrôle achevés. C'est là que le workflow passe le mieux à l'échelle.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Référence des commandes

Commandes deep dive

Commande	Objectif
`/deep-research`	Rassembler des informations, comprendre la base de code. Aucune suggestion autorisée.
`/deep-innovate`	Explorer 2-3 approches, évaluer les compromis. Aucun code autorisé.
`/deep-plan`	Créer des étapes d'implémentation concrètes. Aucune implémentation autorisée.

Commandes des issues

Commande	Objectif
`/issue-create`	Créer une issue à partir du contexte de la conversation
`/issue-bug`	Créer un rapport de bug avec les étapes de reproduction
`/issue-feature`	Créer une demande de fonctionnalité axée sur les besoins
`/issue-plan`	Exécuter le workflow deep-dive complet, publier les résultats dans l'issue
`/issue-action`	Poursuivre l'implémentation après approbation humaine
`/issue-compact`	Consolider le corps de l'issue + les commentaires pour la passation

Commandes des PR

Commande	Objectif
`/pr-check`	Surveiller le pipeline CI, corriger automatiquement, réessayer jusqu'à 3 fois
`/pr-review`	Relire la PR commit par commit selon les standards du projet
`/pr-comment`	Résumer la discussion de la conversation en commentaire de PR

Pour commencer

Commencez simple : utilisez /issue-create → /issue-plan → /issue-action pour votre première tâche
Ajoutez le deep dive pour les tâches complexes : lorsque les besoins sont flous ou techniquement complexes, commencez par /deep-research
Passez à l'échelle progressivement : ajoutez d'autres instances Claude à mesure que vous vous familiarisez avec le rythme de revue
Faites confiance au processus : laissez Claude travailler de façon autonome entre les points de contrôle

Le workflow est conçu pour être adopté de façon incrémentale. Vous n'avez pas besoin d'utiliser les 14 commandes dès le premier jour. Commencez par le flux d'issues de base, puis ajoutez les phases de deep dive et le travail en parallèle à mesure que vous gagnez en confiance.

Considérations de passage à l'échelle : que faire quand vous avez plus d'agents

Le workflow a été testé avec plus de 10 instances Claude simultanées. Notre recommandation :

Jusqu'à 10 agents : confortable pour une collaboration approfondie avec chacun
Au-delà de 10 : non recommandé

Le facteur limitant n'est pas le workflow, c'est l'attention humaine et la qualité de décision. Quand vous gérez plus de 10 agents, vous risquez de devenir un goulot d'étranglement aux points de contrôle de revue, et la qualité de décision commence à se dégrader.

Le principe classique de l'« équipe deux pizzas » s'applique ici. Les mêmes contraintes qui limitent la taille d'une équipe humaine limitent aussi le nombre d'agents IA qu'une personne peut gérer efficacement.

J'explore actuellement une structure d'équipe à deux niveaux 8×8 pour passer au-delà de 10 agents, mais je n'ai pas encore développé de pratiques efficaces. Je partagerai davantage lorsqu'il y aura des résultats concrets…

Le workflow dev de VM0 change notre façon de penser le développement logiciel quand l'IA devient membre de l'équipe.

Lorsque vous traitez les agents IA comme des membres de l'équipe plutôt que comme des outils, tout se met en place. GitHub devient la mémoire partagée de votre équipe. Les issues deviennent des éléments de travail. Les PR deviennent des livrables. Et vous devenez le chef d'équipe, concentré sur l'architecture, la direction et la qualité, pendant que votre équipe d'IA s'occupe de l'implémentation.

C'est ainsi que nous avons livré 404 versions en 2 mois. Et c'est ainsi que vous pouvez faire passer votre propre développement à l'échelle avec l'IA.