Créer une application complète avec des agents IA, de l’idée au déploiement
Organisez la création d’une application avec des agents IA : cadrage, données, interface, tests, correction et déploiement. Évaluez l’autonomie réelle.
8 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.
Coordonner le projet avec un pilote Stellary
Le pilotage de projet part d’un mandat activé par un humain : objectif, critères de réussite, pilote, équipe autorisée et jalons qui demandent une décision humaine. Le pilote délègue les contributions et suit les prérequis entre les cartes. Un contributeur peut être un agent ou un membre humain.
Cette coordination répond à trois questions : quel travail peut commencer, qui dispose du contexte et des accès nécessaires, et qu’est-ce qui permet d’accepter le résultat ? Elle complète le découpage en fichiers sans le remplacer.
Réserver les ressources partagées
Une ressource d’écriture commune doit rester réservée à la contribution qui l’utilise. Un dépôt partagé est sérialisé par défaut dans le contrat de pilotage, de même qu’un périmètre d’écriture inconnu. La fin d’un bail ne suffit pas à libérer une ressource si le processus travaille encore.
Le parallélisme reste utile pour des tâches indépendantes. Des recherches en lecture seule peuvent préparer les options pendant qu’un exécutant réalise un changement. Le pilote doit cependant garder un ordre d’intégration et une vérification du résultat commun.
Passer du résultat annoncé à l’acceptation
Une mission terminée place son résultat en revue. L’acceptation s’appuie sur les critères et une inspection indépendante du livrable. Le message « c’est fait » de l’exécutant ne suffit pas à clore la carte.
En cas d’échec répété, la suite doit changer : stratégie, affectation ou décision à demander. Le contrat prévoit un changement de stratégie ou d’exécutant après deux corrections infructueuses dans la même configuration. Une question conserve le blocage explicite sans relancer indéfiniment le modèle.
Distinguer coordination et circuit de workflow
Le pilote choisit le prochain travail dans le mandat du projet. Un workflow décrit un circuit réutilisable, par exemple création, vérification, correction et validation. Une contribution coordonnée peut suivre ce circuit avec les outils compatibles.
Le guide des workflows avec superviseur détaille les rôles. Pour un premier usage, le guide d’adoption en entreprise aide à sélectionner un périmètre. Le cas de création d’application donne une définition de livraison à rejouer.
Préparer une coordination utilisable
Ajoutez le brief et les sources aux cartes, vérifiez l’équipe et les capacités des moteurs, puis définissez la revue attendue. Tous les moteurs ne peuvent pas tenir tous les rôles avec les mêmes restrictions : être disponible comme exécutant ne prouve pas la compatibilité comme pilote.
Commencez avec des contributions dont les dépendances sont explicites. Conservez les décisions, les questions et les résultats dans le projet. Le rapport d’avancement peut ensuite montrer les livraisons acceptées et les arbitrages restants.
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.
Passer du découpage au dispositif de travail
Le workflow supervisé définit les livrables entre explorateur, exécutant et vérificateur. Les consignes AGENTS.md et CLAUDE.md fixent les règles du dépôt. La page d’orchestration des agents décrit le cadre Stellary ; si vous utilisez un client externe, commencez par la connexion Claude Code ou Codex.
Ces guides constituent une méthode et une configuration documentée. Ils ne prouvent pas qu’une équipe donnée gagnera du temps : conservez les conflits, les reprises et le résultat intégré pour évaluer votre propre essai.
