Brief de projet pour l’IA : le modèle qui évite les prompts sans fin
Un brief de projet IA relie objectif, périmètre, sources, contraintes et validation. Voici un modèle prêt à adapter avant de lancer un agent.
7 min de lecture
Lancer trois agents IA en parallèle peut réduire le temps d’attente. Cela peut aussi produire trois implémentations incompatibles, deux migrations concurrentes et une intégration plus longue que le travail initial.
Le parallélisme devient utile lorsque les missions peuvent avancer indépendamment, possèdent des frontières explicites et reviennent avec des preuves comparables.
Quand faut-il utiliser plusieurs agents IA de code ?
Utilisez plusieurs agents lorsque le travail se sépare réellement : analyser des zones différentes, écrire des tests indépendants, préparer une documentation pendant qu’une fonctionnalité est développée ou implémenter des modules qui partagent un contrat déjà stable.
Gardez un seul agent lorsque les décisions se succèdent : choisir le modèle de données avant l’API, fixer l’API avant l’interface, ou comprendre une panne dont la cause reste inconnue. Paralléliser des questions dépendantes ne réduit pas leur ordre logique.
La documentation d’OpenAI sur l’orchestration multi-agent distingue notamment le pilotage centralisé, où un agent gestionnaire garde la main, et les handoffs, où le contrôle passe à un spécialiste. Pour du code, cette décision doit être complétée par la propriété des fichiers et l’ordre d’intégration.
Séparer
Trouver une frontière qui ne dépend pas d’une décision encore ouverte.
Attribuer
Nommer les fichiers, le contrat et le résultat dont chaque agent est responsable.
Réunir
Prévoir qui intègre, dans quel ordre et avec quels tests.
Une méthode en 6 étapes pour coordonner des agents en parallèle
- Écrivez le résultat commun. Une phrase décrit ce que l’utilisateur pourra faire une fois les contributions réunies.
- Dessinez les dépendances. Marquez les décisions qui doivent précéder le reste : schéma, contrat API, composant partagé, format de fichier.
- Découpez par propriété, pas par quantité. « Fais la moitié » est flou. « Tu possèdes le validateur et ses tests » donne une frontière vérifiable.
- Donnez une base de départ identique. Même révision Git, mêmes règles de projet, mêmes critères et mêmes contrats.
- Isolez les espaces de travail. Une branche ou un worktree par contribution évite que deux agents écrivent dans le même index ou interprètent les changements non terminés de l’autre.
- Intégrez par risque croissant. Contrats et tests d’abord, implémentations ensuite, interface en dernier lorsque son comportement dépend du backend.
Git documente les worktrees comme plusieurs arbres de travail rattachés au même dépôt, chacun avec son propre HEAD et son propre index. Ils isolent les modifications ; ils ne résolvent pas les conflits de conception. Cette partie reste un problème de pilotage.
Un bon découpage réduit les surfaces partagées
Le nombre de tâches n’est pas le bon indicateur. Regardez plutôt combien de décisions et de fichiers sont partagés.
Collision probable
Deux agents modifient le même formulaire
L’un ajoute les champs, l’autre change la validation et tous deux réécrivent le même composant.
Frontière plus nette
Contrat, backend et interface s’enchaînent
Le contrat est fixé d’abord. Le backend et les tests peuvent ensuite avancer avant l’intégration visuelle.
Parallélisme utile
Documentation et tests exploratoires
Ces travaux peuvent avancer depuis le même comportement attendu sans modifier les mêmes fichiers.
Si deux missions ont besoin de changer le même contrat, ne les lancez pas ensemble. Faites décider le contrat une seule fois, puis redistribuez le travail à partir de cette nouvelle source commune.
Chaque mission a besoin d’un contrat de contribution
Une consigne d’agent ne doit pas seulement décrire quoi construire. Elle doit préciser ce que l’agent possède et comment il rend la main.
Résultat attendu : un utilisateur autorisé télécharge le rapport filtré affiché à l’écran.
Propriété : service d’export, route backend et tests associés. Le composant de filtre et le modèle de permission restent inchangés.
Contrat partagé : paramètres from, to et status, encodage UTF-8, ordre des colonnes validé avant le lancement.
Preuves : test du service, validation stricte de la route, essai avec filtre vide et filtre actif, exemple de fichier produit.
Retour : fichiers modifiés, décisions prises, limites non testées et conflits potentiels pour l’intégrateur.
Ce format protège aussi l’agent : il sait ce qu’il peut changer, ce qui appartient à quelqu’un d’autre et dans quel état sa contribution sera évaluée.
L’intégration est une mission distincte
Une série de contributions qui compilent séparément peut échouer une fois réunie. L’intégrateur doit donc vérifier le système après chaque apport, pas seulement résoudre les marqueurs de conflit Git.
Son ordre de travail :
- relire le résultat attendu et les contrats partagés ;
- intégrer la contribution qui définit le contrat ;
- exécuter ses tests ;
- intégrer les consommateurs un par un ;
- rejouer le parcours utilisateur complet ;
- documenter les écarts et les arbitrages effectués.
Un merge réussi signifie que Git a combiné les fichiers. Il ne signifie pas que les comportements sont compatibles. Pour distinguer ces états, consultez comment vérifier le travail d’un agent IA.
Garder humains et agents sur la même carte
Dans Stellary, chaque mission peut conserver son objectif, son propriétaire, ses sources, ses dépendances et sa validation dans le board. Les décisions stables restent dans la base de connaissances, tandis que les agents reçoivent le contexte utile sans transformer une conversation en source de vérité permanente.
Le but n’est pas d’afficher davantage d’agents. C’est de voir quel travail avance, quelle frontière pourrait bouger et quelle contribution attend une intégration.
Une consigne pour préparer le découpage
Découper un changement entre plusieurs agents
Analyse la demande et le dépôt sans modifier de fichier.
Formule d’abord le résultat utilisateur commun. Identifie ensuite les décisions qui doivent être prises avant tout travail parallèle : données, API, composants partagés, permissions et formats.
Propose des missions indépendantes. Pour chacune, indique le propriétaire, les fichiers ou modules autorisés, les éléments à ne pas modifier, les dépendances, les tests et le format du compte rendu.
Signale toute paire de missions qui toucherait la même surface ou dépendrait d’une décision encore ouverte.
Termine par l’ordre d’intégration et le parcours de validation de bout en bout. N’exécute aucune mission avant validation du découpage.
Paralléliser l’attente, pas la confusion
Plusieurs agents sont efficaces quand ils suppriment des temps morts sans multiplier les versions de la vérité. Une base commune, des frontières de propriété et une intégration explicite comptent davantage que le nombre d’agents lancés.
Commencez par deux missions réellement indépendantes. Mesurez le temps d’intégration, les reprises et les collisions. Si la coordination coûte plus que l’attente économisée, réduisez le parallélisme et améliorez le découpage.
Questions fréquentes
Combien d’agents IA peut-on faire travailler en parallèle ?
Il n’existe pas de nombre optimal universel. Le plafond utile dépend du nombre de missions indépendantes, des surfaces de code partagées et de la capacité de l’équipe à relire et intégrer les résultats.
Une branche Git suffit-elle à éviter les collisions ?
Elle isole les modifications, mais pas les décisions. Deux branches peuvent implémenter des contrats incompatibles. Il faut aussi une propriété claire et une source commune pour les choix structurants.
Qui doit intégrer le travail des agents ?
Une personne ou un agent explicitement responsable de l’ensemble. Cette mission comprend l’ordre des merges, les tests après chaque apport et la validation du parcours complet.
