Comment coordonner plusieurs agents IA de code sans créer de collisions
Découpage, contexte, worktrees et intégration : une méthode pour faire travailler plusieurs agents IA de code en parallèle sans multiplier les conflits.
9 min de lecture
Créer une application complète avec l’IA demande d’organiser plus que la génération de code. Il faut définir l’usage, conserver les données, appliquer les droits, gérer les erreurs et livrer un environnement que quelqu’un peut réellement utiliser.
Une équipe d’agents peut prendre en charge des missions successives ou indépendantes. Son autonomie se mesure aux résultats acceptés et aux interventions humaines nécessaires pour les obtenir. Ce guide propose une méthode et un exemple de périmètre ; il ne présente pas une application prétendument construite sans intervention.
Définir ce que signifie complète
Une application n’est complète que relativement à un objectif. Une petite application interne peut être terminée sans paiement ni messagerie. Une démonstration d’écran ne suffit pas si l’objectif exige des comptes, des données persistées et un accès par plusieurs personnes.
Écrivez le parcours principal avant la liste des écrans. Qui commence, quelle action accomplit-il et quel état doit retrouver l’utilisateur suivant ? Ajoutez l’erreur principale et la manière de reprendre le travail après une interruption.
Un membre se connecte, crée une demande et suit son état. Un responsable peut l’affecter et la clôturer après traitement. Les demandes sont conservées après reconnexion. Les membres d’une autre équipe ne peuvent pas les consulter. L’application indique clairement les erreurs et permet de reprendre une création interrompue sans doublon.
Les notifications externes, les paiements et le mode mobile natif ne font pas partie de cette première version. Ils deviennent des projets distincts si le besoin se confirme.
Cet exemple impose déjà de vérifier interface, API, données et permissions. Il donne aussi une définition de fin qui peut être rejouée. Pour préparer ces entrées, utilisez le brief de projet IA.
Préparer le terrain de l’autonomie
Choisissez le dépôt, la branche de travail, l’environnement de développement, les services externes autorisés et la cible de déploiement. Préparez les accès sans mettre de secrets dans les documents de projet. Vérifiez les ressources disponibles et les actions qui nécessitent une validation.
Cette préparation compte dans l’expérience. Une application produite sans code manuel peut avoir demandé beaucoup de configuration et de décisions. Conservez ces interventions dans le journal au lieu de les retirer du récit final.
Les fichiers AGENTS.md et CLAUDE.md expliquent aux exécutants les règles du dépôt. Les droits effectifs du runner déterminent ce qu’ils peuvent lire, écrire ou lancer. Les deux niveaux doivent rester cohérents.
Décomposer le projet en résultats intégrables
Commencez par les contrats qui conditionnent le reste : modèle de données, autorisations et formats d’échange. Une interface et un backend conçus séparément sur des hypothèses différentes produisent du travail à refaire.
Préparez ensuite des cartes dont le résultat est vérifiable. « Faire le backend » est trop large. « Un membre autorisé peut créer et relire une demande, avec validation des champs et refus inter-équipe » permet une mission et une revue utiles.
Faites défiler pour lire toutes les colonnes
| Mission | Livrable | Vérification principale |
|---|---|---|
| Cadrage | Parcours, critères et questions ouvertes | Les décisions nécessaires au prochain travail sont prises |
| Données et API | Contrats et mutations | Validation, persistance et permissions |
| Interface | Parcours utilisateur complet | Saisie, attente, succès, erreur et reprise |
| Intégration | Parcours relié aux vraies données | Interface et serveur décrivent le même état |
| Déploiement | Version accessible sur la cible prévue | Parcours principal et configuration de production |
Donner un rôle au pilote
Le pilote suit le mandat et les dépendances. Il peut déléguer l’exploration, la réalisation et la vérification à des contributeurs différents. Il doit demander une décision lorsqu’une ambiguïté change le produit ou sort de son autorité.
Dans Stellary, le pilotage de projet conserve cette coordination autour des cartes et de leur revue. Des tâches peuvent avancer ensemble lorsque leurs prérequis et leurs ressources le permettent. Un dépôt partagé ne doit pas devenir un lieu d’écriture concurrente non maîtrisée.
Le guide de coordination explique comment attribuer les périmètres. Gardez un responsable de l’intégration finale : trois contributions réussies séparément ne prouvent pas que l’application assemblée fonctionne.
Construire puis vérifier indépendamment
Le créateur rend un livrable identifiable et les contrôles qu’il a exécutés. Le vérificateur ouvre ensuite le résultat et rejoue les critères. Il ne doit pas accepter une capture ou un message de réussite comme preuve unique du parcours.
Pour l’application de demandes, testez une création valide, une donnée invalide, un accès non autorisé, une reconnexion et une action interrompue. Vérifiez que l’état affiché correspond à l’état réellement stocké. Les contrôles doivent rester adaptés aux risques du changement.
Le workflow avec superviseur peut formaliser création, revue et correction. Un critère non satisfait revient à l’exécutant avec l’écart observé et la manière de le reproduire. L’étape suivante démarre après une revue suffisante.
Corriger les échecs sans perdre le projet
Une longue mission peut rencontrer un outil indisponible, une dépendance incompatible ou une hypothèse fausse. Le compte rendu doit préciser le dernier résultat vérifié, les fichiers modifiés et la prochaine action utile.
Avant de relancer, regardez si une action a déjà eu lieu. Recréer un compte, une migration ou un déploiement peut produire un doublon. La reprise part de l’état réel et du travail restant, pas uniquement du dernier message de l’agent.
Si une même approche échoue plusieurs fois, changez de stratégie ou demandez un avis indépendant. Ajouter des agents ne résout pas une décision de produit absente. Préservez les résultats valides des autres branches pendant que le blocage est traité.
Passer du développement au déploiement
La build doit être vérifiée avec la configuration de destination. Contrôlez les adresses de services, les variables nécessaires, les droits, les migrations éventuelles et la procédure de retour à une version précédente. Une réussite locale ne prouve pas la configuration distante.
L’automatisation du déploiement dépend des accès accordés et du mandat. Une publication sensible peut demander une validation ; une cible de démonstration explicitement autorisée peut suivre un circuit différent. Décrivez ce qui a été réellement exécuté au lieu de réunir tous ces cas sous le mot « autonome ».
Après publication, ouvrez la version servie et rejouez le parcours. Vérifiez également une erreur utilisateur et les données conservées après reconnexion. L’application est disponible lorsque la destination attendue sert le bon comportement, pas au seul moment où une commande se termine.
Mesurer la totale autonomie honnêtement
Tenez un journal avec l’heure, la demande, le rôle, le résultat et l’intervention éventuelle. Distinguez préparation initiale, décision produit, approbation, relance technique et code modifié à la main.
Un résultat peut être obtenu sans code manuel mais avec cinq arbitrages. Un autre peut demander une correction directe. Les deux expériences sont instructives si elles sont décrites correctement. Une durée ou un coût sans ce contexte serait difficile à comparer.
Mesurez le temps jusqu’au parcours accepté, les coûts observables, les tentatives, les écarts et les interventions. Comparez ensuite un agent seul et une équipe sur un périmètre similaire si vous voulez évaluer l’intérêt de la coordination. Gardez les critères constants et les limites de l’essai visibles.
Faire vivre l’application après la première livraison
La première version crée un historique : décisions, contrats, incidents, tests et procédure de mise en service. Conservez-le avec le projet pour que le prochain agent ne redécouvre pas les mêmes contraintes.
Les nouvelles fonctionnalités repartent d’une carte et d’une définition de fin. La stabilisation d’un prototype approfondit les points qui deviennent importants après la démonstration. Un rapport d’avancement permet de suivre ce qui est livré et ce qui attend encore une décision.
Commencez par une application suffisamment petite pour être revue de bout en bout. L’expérience utile est celle qui permet de montrer le produit, de rejouer son parcours et d’expliquer exactement ce que les agents ont pris en charge.
Préparer une revue par une personne extérieure au développement
Donnez à un utilisateur le point d’entrée, un compte prévu pour l’essai et une tâche à accomplir. Observez où il hésite, ce qu’il comprend et la manière dont une erreur est présentée. Un parcours qui n’existe que dans les explications de l’agent n’est pas encore autonome pour son utilisateur.
Conservez les écarts comme des cartes vérifiables. « L’application n’est pas claire » doit devenir une observation située : après telle action, le prochain état n’est pas compréhensible. Le correcteur peut alors travailler sans inventer un nouveau produit.
Cette revue ne remplace pas les contrôles techniques. Elle les complète avec la preuve que le résultat est utilisable. Les deux doivent porter sur la version servie qui sera acceptée, avec les données et les droits de l’environnement prévu.
Si les échanges n’aboutissent pas à un choix visuel précis, créer un petit outil de réglage avec l’IA peut débloquer la suite. ParamRig permet de préparer ce type d’exploration avant d’intégrer les valeurs retenues dans l’application.
Conserver une preuve de livraison
Le rapport d’avancement sépare les fonctions acceptées de celles encore en revue. Conservez la version, l’environnement et le parcours vérifié dans le même projet. La coordination des agents Stellary sert à organiser les contributions ; elle ne remplace pas la recette de l’application livrée.
