Un promptware est une unité d'agent autonome qui stocke ses propres instructions, sa mémoire (Memory), ses autorisations d'outils (Tools) et son historique d'exécution (Logs) sous forme de fichiers, et qui révise ses instructions et sa mémoire après chaque exécution. Dans Ivy Tendril, chaque étape du cycle de vie du plan, de la rédaction d'un plan à l'ouverture d'une pull request, est orchestrée par l'une de ces unités. Les instructions sont des fichiers versionnés dans le dépôt, ce qui permet de les réviser, de visualiser leurs diffs, de les annuler par rollback et de les partager au sein de l'équipe exactement comme n'importe quel fichier source. Cet article détaille la structure d'une unité, sa boucle d'exécution (run loop), les sept promptwares intégrés et les deux modes de défaillance à surveiller.

Ce que contient une unité de promptware

Une unité de promptware est un répertoire structuré en quatre parties. Chaque partie a un rôle précis.

Partie	Contenu	Qui l'écrit
`Program.md`	Les instructions suivies par l'agent pour son étape. Révisées par l'agent après un cycle, revues par des humains.	L'agent et les humains
`Memory/`	Les apprentissages persistants sur le code et les conventions de l'équipe. Enrichi après chaque cycle.	L'agent
`Tools/`	Les autorisations délimitées pour cette étape : commandes, fichiers et intégrations autorisés pour l'agent.	Les humains
`Logs/`	L'historique d'exécution : ce que l'agent a lu, exécuté et modifié, ainsi que ses conclusions.	L'agent (ajout seul)

Program.md est rédigé en prose, pas en code. Une section destinée à une unité d'exécution de plan pourrait ressembler à ceci :

## Avant d'ouvrir une pull request

- Lancez `pnpm lint` et `pnpm test` depuis la racine du dépôt. N'ouvrez pas de PR si l'une des deux commandes échoue.
- Limitez strictement le diff aux fichiers mentionnés dans le plan. Si un autre fichier doit être modifié, justifiez-le dans la description de la PR.
- Utilisez le format de message de commit standard `type(scope): summary`.

Une entrée de mémoire enregistre une observation apprise par l'agent qui n'est pas évidente à la simple lecture du code et qu'une exécution future doit connaître :

### 2026-08-21, plan #412

Le module de facturation sous `src/billing/` ne possède aucun test. Ajoutez des tests avant tout refactoring.
`pnpm test` exécute d'abord les migrations de base de données ; un run prend environ quatre minutes sur une copie propre.

Ces deux fichiers sont de nature très différente. Le programme définit la démarche à suivre. La mémoire consigne ce qui est vérifié et vrai à propos de ce dépôt. Les séparer permet à un réviseur d'accepter un nouveau fait sans accepter une modification de procédure, et inversement.

La boucle d'exécution

Chaque exécution d'un promptware suit les quatre mêmes étapes.

Charger le programme. L'agent charge Program.md et les permissions définies dans Tools/. Rien en dehors de ces autorisations ne lui est accessible.
Lire la mémoire. L'agent lit Memory/ afin que les faits appris lors des cycles précédents soient présents dans son contexte avant de démarrer.
Exécuter la tâche. L'agent réalise le travail de son étape : concevoir un plan, l'étoffer, l'exécuter dans un worktree ou ouvrir une pull request. Chaque appel d'outil et sa sortie sont consignés dans Logs/.
Réfléchir et mettre à jour. L'agent compare ce qui s'est produit avec ce que le programme lui indiquait d'attendre. Les nouveaux constats sont enregistrés dans Memory/. Si une instruction s'est avérée erronée, manquante ou superflue, l'agent met à jour Program.md.

Cette boucle consistant à agir, observer le résultat et adapter la consigne suivante reprend le schéma décrit dans la publication ReAct pour les agents raisonnants ; un promptware s'en distingue principalement par le fait que la révision est inscrite dans un fichier persistant au-delà de la session. Cette quatrième étape permet aux instructions de se bonifier avec le temps au lieu de régresser. C'est également l'étape qui exige le plus de vigilance humaine, comme le détaille la section sur les risques.

Les promptwares intégrés

Ivy Tendril est fourni avec sept promptwares, un pour chaque étape du cycle de vie présenté dans du ticket GitHub à la pull request. Chacun possède son propre programme, sa mémoire, ses permissions et ses journaux.

CreatePlan convertit une idée, une issue GitHub ou un rapport de bug en un projet de plan : objectif, périmètre, fichiers impactés et étapes de vérification.
ExpandPlan enrichit un ébauche manquant de précision pour être exécuté, en clarifiant par exemple les critères d'acceptation ou les choix d'architecture en suspens.
UpdatePlan réécrit une ébauche de plan pour intégrer les annotations insérées par le développeur.
SplitPlan scinde un plan dont l'envergure est devenue trop large en plusieurs sous-plans indépendants exécutables en parallèle.
ExecutePlan met en œuvre le plan validé avec l'agent de code sélectionné (Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode ou tout autre agent en ligne de commande) au sein d'un git worktree isolé. Le guide d'Anthropic sur les bonnes pratiques pour Claude Code défend avec les mêmes arguments la tenue de fichiers d'instructions versionnés que cette section pour Program.md.
CreatePr soumet la pull request une fois que le diff a validé les tests automatisés et la revue humaine.
CreateIssue génère une issue GitHub à partir d'une recommandation ou d'un constat établi pendant l'exécution.

Chaque unité étant cloisonnée, la mémoire de CreatePlan (par exemple : « l'équipe souhaite que les plans mentionnent explicitement les fichiers de test modifiés ») n'est pas transmise à ExecutePlan, et la permission accordée à ExecutePlan de lancer des commandes shell n'est pas attribuée à CreatePlan. La documentation des promptwares détaille le contenu par défaut de chaque unité.

Instructions versionnées et les deux risques

Pourquoi les fichiers versionnés surclassent les prompts ad hoc

Un prompt saisi à la volée dans une interface de chat n'existe qu'une fois, pour une seule personne, et disparaît avec la session. Un fichier Program.md validé dans le dépôt offre quatre atouts majeurs qu'un simple prompt ne possède pas :

Revue. Toute modification du programme se traduit par un diff dans une pull request. Un développeur senior peut bloquer une instruction indésirable telle que « sauter les tests si la modification est mineure » avant qu'elle n'influence de futurs runs.
Diff. Si la qualité des résultats fluctue, la commande git log sur le dossier du promptware montre clairement quelle consigne a changé et à quelle date.
Rollback. Un ajustement inopportun s'annule d'un simple commit de réversion.
Partage. Chaque ingénieur de l'équipe et chaque exécution d'agent s'appuient sur les mêmes règles. Une convention découverte lors d'un run le lundi bénéficie à toute l'équipe dès le mardi.

C'est exactement la même logique qui a guidé le passage de l'infrastructure configurée à la main vers le code sous contrôle de version, et le même principe qui préconise d'isoler la configuration du code dans The Twelve-Factor App ; la pertinence reste rigoureusement identique. D'autres structures d'orchestration d'agents et leur comparaison avec le promptware sont abordées dans les modèles d'orchestration pour agents de développement.

Risque 1 : la dérive d'instructions (instruction drift)

Un agent capable de modifier son propre programme peut aussi le dégrader. Un cycle qui échoue à cause d'un test intermittent (flaky) pourrait insérer une règle du type « relancer les tests en échec jusqu'à trois fois », masquant ainsi une véritable régression lors du run suivant. Deux mécanismes contrent ce risque. D'abord, le programme est un fichier versionné : la modification est un diff visible qu'un réviseur peut inspecter et rejeter. Ensuite, Logs/ conserve le cycle précis qui a suscité cette modification, permettant au relecteur de vérifier la solidité du raisonnement avant de l'approuver.

Risque 2 : l'enflure de la mémoire (memory bloat)

Une mémoire qui ne fait qu'enfler devient un coût sans contrepartie utile. Un fichier accumulant 400 entrées, dont la moitié est périmée, surconsomme des tokens à chaque exécution et noie les informations capitales. Deux réflexes permettent de la garder opérationnelle : dater et circonscrire chaque note, comme dans l'exemple ci-dessus, pour identifier sans peine les éléments caducs ; élaguer lors des revues : lorsqu'un plan touche un composant donné, le réviseur parcourt les notes de mémoire associées et supprime ce qui ne correspond plus à la réalité du code. Le suivi des coûts et des tokens par plan et par tâche met en lumière cette expansion, car une unité à la mémoire saturée enregistre une inflation de tokens sans accroissement du volume du plan — raison pour laquelle la mesure du débit des agents de développement évalue le coût par pull request fusionnée plutôt que par exécution unitaire.

Comment démarrer

Installez Ivy Tendril, ouvrez un dépôt et initialisez un plan. Les sept promptwares de base sont opérationnels dès le premier run.

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

Sous Windows, lancez irm https://cdn.ivy.app/install-tendril.ps1 | iex. Parcourez les fichiers Program.md avant de lancer une exécution, puis examinez les premières entrées de mémoire et révisions de programme avec le même soin que pour une revue de code. Après une dizaine de plans, la mémoire reflétera fidèlement les zones du code où l'agent a rencontré des frictions, qui correspondent le plus souvent à celles qui intrigueraient un développeur humain. La documentation des promptwares vous en dira plus sur les unités natives.

Foire aux questions

L'agent modifie-t-il Program.md sans préavis ?

L'agent ajuste son programme à l'issue d'un cycle. Program.md étant un fichier versionné, la révision forme un diff que vous pouvez consulter, approuver ou annuler, et le journal du cycle ayant provoqué la mise à jour est archivé juste à côté.

Peut-on concevoir ses propres promptwares ?

Les sept unités natives couvrent l'intégralité du cycle de vie. Leurs programmes, mémoires et permissions d'outils sont de simples fichiers texte : vous pouvez donc les adapter librement aux conventions de votre organisation. Consultez la documentation pour connaître les possibilités actuelles d'extension.

Où sont enregistrés la mémoire et les journaux ?

En local, sur la machine qui héberge Tendril. Rien n'est téléversé chez Ivy. Les seules requêtes réseau qu'effectue Tendril s'adressent à l'API du LLM que vous avez configurée et à GitHub.

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.

Promptware : des agents qui conservent et améliorent leurs propres instructions