Claude Code : plusieurs agents sans multiplier les conflits

Plusieurs agents peuvent accélérer un projet, mais ils peuvent aussi produire des modifications incompatibles plus vite qu’une seule personne. La parallélisation devient utile lorsque les tâches sont indépendantes, les interfaces explicites et l’intégration organisée. Le nombre d’agents n’est pas, à lui seul, un indicateur de productivité.

Découper par livrable vérifiable

Une bonne tâche déléguée possède un objectif limité, des fichiers ou un périmètre définis et un résultat testable. Une recherche documentaire, des tests ciblés et un composant isolé peuvent parfois avancer ensemble. Deux agents modifiant la même logique centrale risquent davantage de se gêner.

Dans un exemple fictif, un agent examine un problème de formulaire pendant qu’un autre prépare des tests du parcours commercial existant. Leurs travaux se complètent. Si tous deux réécrivent simultanément le formulaire sans contrat commun, le temps gagné au départ peut être perdu à réconcilier les versions.

Isoler les modifications

Lorsque les sessions travaillent sur des changements distincts, des espaces de travail séparés permettent d’éviter les écrasements directs. Chaque contribution doit rester identifiable et réversible. Cette isolation ne garantit pas la compatibilité finale, mais rend les différences plus faciles à examiner.

La documentation de Claude Code sur les worktrees décrit ce principe d’espaces séparés partageant l’historique du dépôt. Il faut distinguer cette isolation des sous-agents qui peuvent participer à une même session : le mode choisi influence la manière de coordonner les fichiers.

Partager un contrat commun

Avant de commencer, fixez les interfaces, les conventions importantes et les éléments à préserver. Précisez qui peut modifier une structure de données ou une dépendance partagée. Un agent ne devrait pas déplacer une frontière de responsabilité sans prévenir les autres.

Les consignes doivent rester courtes et applicables. Un long document contradictoire ne remplace pas une décision claire. Si une tâche dépend d’un résultat encore inconnu, traitez cette dépendance avant de lancer les deux parties comme si elles étaient déjà indépendantes.

Garder un responsable de l’intégration

Une personne ou un agent coordinateur doit relire les contributions, vérifier les conflits et exécuter les tests d’ensemble. Des validations locales réussies ne prouvent pas que les composants fonctionnent ensemble. L’intégration mérite du temps dans le plan, pas seulement à la fin.

La méthode pour reprendre un projet avec Claude Code rappelle qu’il faut comprendre l’état existant avant d’agir. Cette exigence devient encore plus importante en parallèle : chacun doit préserver les changements qui ne lui appartiennent pas et signaler les chevauchements.

Mesurer le temps livré, pas le temps écrit

Comparez la durée jusqu’à une livraison vérifiée, en incluant la relecture, les reprises et les incidents. Une production simultanée de code peut sembler impressionnante sans réduire le délai réel. Arrêtez la parallélisation lorsqu’elle crée davantage de coordination que de travail utile.

Dans un développement orienté business, plusieurs agents sont un moyen, pas une démonstration. Commencez par quelques tâches réellement séparables, conservez une intégration explicite et augmentez seulement si la qualité et le délai de livraison s’améliorent ensemble.