Dans Ivy Tendril, une issue GitHub devient une pull request à travers une succession ordonnée d'étapes : l'issue arrive dans l'Inbox par webhook, un agent ébauche un plan, un développeur examine et approuve le plan, un agent l'exécute dans un git worktree isolé, la vérification s'exécute, le développeur examine le diff résultant et un agent ouvre la pull request. L'intervention humaine a lieu à exactement deux moments : le plan et le diff. Tout le reste est pris en charge par des agents, et de nombreux tickets progressent simultanément le long de cette chaîne. Cet article suit un ticket à chaque étape de son cycle.
Le cycle de vie en un coup d'œil
Ivy qualifie ce flux de travail « d'usine logicielle » (software factory) : une séquence d'étapes prédéfinies au cours desquelles les agents réalisent le travail opérationnel et les développeurs inspectent les livrables à des points de contrôle précis. Les étapes, les intervenants et la condition de clôture de chaque phase sont résumés ci-dessous. La référence technique exhaustive figure dans la documentation sur le cycle de vie.
| Étape | Intervenant | Condition de sortie |
|---|---|---|
| Inbox | Agent (webhook) | L'issue est enregistrée avec son titre, sa description, ses étiquettes et son lien |
| Draft plan | Agent (CreatePlan) | Un brouillon structurant objectif, périmètre, fichiers cibles et étapes de vérification existe |
| Plan review, point de contrôle 1 | Humain | Le développeur valide le plan, après d'éventuelles annotations et réécritures |
| Execute | Agent (ExecutePlan) | L'agent signale que le plan est achevé dans son worktree |
| Verify | Agent | La suite de tests et le linter ont tourné et le diff est prêt pour examen (portes de vérification) |
| Diff review, point de contrôle 2 | Humain | Le développeur approuve le diff |
| Pull request | Agent (CreatePr) | Une pull request est créée sur GitHub pour la branche du plan via l'API REST des pull requests |
| Merge et nettoyage | Fusion humaine, nettoyage agent | Le worktree est supprimé et les enseignements sont inscrits dans la mémoire |
De l'issue au plan approuvé
Arrivée de l'issue
Un utilisateur soumet l'issue #418 sur le dépôt : "Export to CSV drops rows with commas in the description field." L'intégration GitHub la transmet à l'Inbox de Tendril via webhook. À ce stade, rien ne s'exécute encore. L'Inbox est une file de réception où le développeur choisit quels éléments transformer en plans. Les rapports d'erreurs en provenance de jam.dev parviennent par le même canal.
CreatePlan rédige un plan
Le développeur sélectionne l'issue et clique sur Create plan. Le promptware CreatePlan prend connaissance de l'issue, interroge sa mémoire du dépôt et analyse le code pertinent afin de rédiger un brouillon. Un brouillon type formule l'objectif, identifie les fichiers à modifier (src/export/csv.ts et son fichier de test), l'approche technique retenue (encadrer de guillemets les champs contenant le délimiteur selon la RFC 4180) et les étapes de vérification (ajouter un cas de test avec virgule dans la description, rejouer les tests d'exportation existants). L'ébauche s'affiche dans Drafts.
Point de contrôle 1 : Le développeur examine le plan
Il s'agit du premier des deux points de contrôle humains. Le développeur lit le brouillon et relève une lacune : le plan propose de n'échapper que le champ de description, alors que le dysfonctionnement concerne en réalité toutes les colonnes en texte libre. Plutôt que de réécrire manuellement le plan, le développeur sélectionne le passage concerné et insère une consigne annotée : "Apply the quoting to all string columns, not just description." Le promptware UpdatePlan réécrit alors le plan en intégrant cette directive, et la version révisée lui est soumise pour relecture.
Si l'ébauche manque de précision, le développeur peut lancer ExpandPlan. Si les remarques indiquent que le ticket recouvre en pratique deux chantiers distincts — par exemple la correction du bug et une refonte du module d'exportation vers une bibliothèque CSV partagée —, SplitPlan scinde le travail en deux plans exécutables de manière autonome. Une fois pleinement satisfait, le développeur valide. Le plan fait dès lors foi en tant que cahier des charges strict pour l'exécution, sans que l'agent n'ait besoin de réinterpréter l'issue d'origine.
Exécution et vérification
ExecutePlan s'exécute dans un worktree isolé
Dès approbation, Tendril initialise un git worktree dédié pour le plan sur sa propre branche et y lance l'agent choisi. Le développeur peut sélectionner l'agent par plan : Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode ou tout autre agent CLI. L'organisation du travail reste strictement identique quel que soit l'agent retenu.
Le recours au worktree est capital, car d'autres plans s'exécutent en parallèle. Chacun dispose de son propre répertoire de travail et de sa propre branche : les modifications partielles d'un plan ne risquent donc pas de perturber un autre chantier, et la branche principale reste immaculée jusqu'à la phase d'évaluation. Les fondements de ce choix d'ingénierie sont détaillés dans git worktrees pour agents IA parallèles.
Pendant le travail de l'agent, l'interface Jobs diffuse en direct l'ensemble des logs et des appels d'outils : fichiers consultés, commandes exécutées, tests lancés, consommation de tokens et coûts engagés. Le développeur peut observer le déroulement ou basculer sur la relecture d'un autre plan. En activant un tunnel Cloudflare Quick Tunnel, ce même flux d'information reste accessible sur smartphone.
Lancement de la vérification
Dès que l'agent annonce avoir mené le plan à terme, les procédures de vérification se déclenchent au sein du worktree : exécution de la suite de tests et du linter, puis consolidation du diff résultant pour examen. Ces résultats s'affichent dans l'interface Review sous trois onglets : tests, lint et diff. Un test en échec ou un avertissement de linting devient visible avant même qu'un développeur ne prenne le temps de lire le code. Les abonnements Pro et Enterprise permettent en outre de récupérer les statuts de vérification issus de la CI. La nécessité d'ériger la vérification en porte de blocage infranchissable plutôt qu'en simple recommandation est argumentée dans portes de vérification pour le code généré par IA.
Revue, pull request et nettoyage
Point de contrôle 2 : Le développeur examine le diff
Voici le second point de contrôle humain. Dans Review, le développeur étudie le diff en vis-à-vis du plan initial et des rapports de vérification. Pour l'issue #418, le diff modifie src/export/csv.ts, implémente une fonction d'échappement et enrichit le fichier de test de trois cas d'école : une virgule, des guillemets et un saut de ligne insérés au cœur d'un champ. Les tests sont au vert et le linting est vierge de tout avertissement. Le développeur valide le diff.
Si le diff s'avère non conforme, le développeur refuse l'approbation, enrichit le plan avec les critères manquants et relance l'exécution. Aucun code n'est poussé vers GitHub sans cette validation formelle.
CreatePr ouvre la pull request
Le promptware CreatePr crée la pull request à partir de la branche du plan. À compter de cet instant, le processus standard de revue d'équipe et de merge sur GitHub prend le relais. L'écran Pull Requests de Tendril assure le suivi de chaque PR active initiée par ce mécanisme.
Après le merge
Dès que la PR est fusionnée, Tendril supprime le worktree. Le promptware ExecutePlan consigne alors ses enseignements dans la mémoire persistante. Pour ce ticket, une annotation telle que "The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export" est stockée ; ainsi, le prochain plan amenant à modifier le module d'exportation prendra connaissance de cette exigence avant de démarrer.
L'intégralité du processus, pour un correctif de cette envergure, requiert quelques minutes de calcul agent et deux courtes interventions humaines. L'équipe d'Ivy a ainsi pu passer d'environ 10 à plus de 100 pull requests par jour en adoptant cette méthode, sans jamais transiger sur la rigueur des deux points d'approbation.
Comment démarrer
Installez Tendril, configurez l'intégration GitHub afin d'acheminer vos issues dans l'Inbox, puis menez un premier ticket d'un bout à l'autre de la chaîne avec un unique agent avant d'engager des plans en parallèle.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Sous Windows, exécutez irm https://cdn.ivy.app/install-tendril.ps1 | iex. L'édition communautaire, accessible en source disponible sous licence Functional Source License, intègre le cycle de vie dans sa totalité. Les formules Pro et Enterprise offrent les fonctionnalités d'équipe, l'importation des validations depuis la CI et l'hébergement on-premise.
Foire aux questions
L'agent peut-il contourner un point de contrôle pour un changement minime ?
Non. Les deux points de contrôle s'appliquent systématiquement à chaque plan. Une modification d'une seule ligne requiert l'approbation du plan et la validation du diff, au même titre qu'un chantier majeur. Les plans restreints nécessitent simplement moins de temps d'examen.
Que se passe-t-il si deux plans concurrents éditent le même fichier ?
Chaque plan opère dans son worktree dédié et sur une branche distincte : aucun conflit n'apparaît donc lors de l'exécution. La divergence éventuelle se manifestera lors du rebase ou du merge de la seconde pull request, et se traitera selon les règles habituelles de Git. Découper les plans par modules fonctionnels limite sensiblement ce risque d'interférence.
L'issue provient-elle obligatoirement de GitHub ?
Non. Les plans peuvent être amorcés à partir d'une saisie libre, d'un ticket de bug jam.dev, du CLI, de l'API REST ou du serveur MCP. Le webhook GitHub ne représente que l'un des multiples modes d'alimentation de l'Inbox.
Premiers pas avec Ivy Tendril
Prêt pour une orchestration d'agents parallèle au niveau développeur ?
- Explorer le code: Découvrez Ivy Tendril sur GitHub (Open Source).
- Consulter la documentation: Trouvez des guides d'intégration sur tendril.ivy.app.
- Planifier une session d'architecture: Contactez renco@ivy.app pour une consultation technique de 30 minutes.