iASSET — cadrer les agents avant le premier diff

Introduction

Les agents de code (Cursor, Claude Code, OpenCode, pipelines CI) accélèrent la livraison — mais sans cadre, ils improvisent : specs floues, frontières d’architecture contournées, exigences sécurité oubliées ^[1]. iASSET répond par un dossier versionné iasset/ dans le repo : la source de vérité du contrat projet, lisible par les humains, les IDE et la CI.

Le package npm zot-iasset (licence MIT) expose la commande iasset. Le contenu généré sous iasset/ reste la propriété du projet client ^{[1, 2]}.

1. Pourquoi iASSET — sans cadre, l’agent improvise

Un agent libre code vite. Il peut aussi livrer un login sans behavior formalisé, casser les couches hexagonales, ou ignorer OWASP ASVS. iASSET impose un contrat visible avant le premier diff : même intention de prompt, mais le chemin passe par iasset/ (spec · arch · sécu · tests · eval) avant l’implémentation bornée.

Principe directeur : séparer le cadre invariant (dossier + gates) des adaptateurs locaux (`.cursor/`, `CLAUDE.md`, `AGENTS.md`). Si une règle n’existe que dans un plugin IDE, ce n’est pas iASSET — c’est un export dérivé ^{[1, 3]}.

2. Le bundle — cinq lettres, un dossier versionné

iasset init crée le bundle. Agents et CI lisent les mêmes artefacts YAML / Markdown.

• A — Architecture — presets (hexagonal, 3-layer, MVC, clean…), boundaries.yaml, conventions may / must_not.
• S — Specification — behaviors YAML / Gherkin, clés externes (Linear, Jira…).
• S — Security — niveau (baseline → critical), frameworks (OWASP Top 10, ASVS, ISO 27001…), tracking des gaps.
• E — Evaluation — modes pre-merge / release, templates commit & PR.
• T — Tests — politique de fineness / coverage, générateurs unit & scenario depuis une spec.

3. Boucle de changement — spécifier avant d’écrire

Le skill iasset-change orchestre l’ordre recommandé : trouver ou créer le behavior → planifier dans les frontières d’architecture → mapper les exigences sécurité → générer les plans de tests → implémenter uniquement dans AGENT_MAY → rédiger commit / PR via les templates d’évaluation ^[1].

4. CLI & workflow opérationnel

Install rapide :

npm i -g zot-iasset
iasset --help
# ou
npx zot-iasset --help

Session type (smoke du dépôt) :

iasset init --name demo --architecture hexagonal
iasset spec add --id auth.login.form --linear ENG-142
iasset tests generate --from-spec auth.login.form --kind unit
iasset tests generate --from-spec auth.login.form --kind scenario
iasset sync --target cursor
iasset validate --gate all
iasset agent run security-auditor
iasset eval commit-message --behavior auth.login.form

5. Un cadre, plusieurs surfaces

iasset sync projette le framing vers les surfaces d’exécution : .cursor/skills, .claude/CLAUDE.md, AGENTS.md / .opencode/skills, et les jobs CI qui appellent validate + agents. Les exports restent dérivés : la source de vérité est toujours iasset/ ^{[1, 3]}.

• Auditable — behaviors, frontières et exigences reviewables comme du code.
• Déterministe en CI — exit codes friendly pour bloquer un merge non conforme.
• IDE-agnostique — le contrat ne vit pas dans un seul éditeur.

Conclusion

iASSET transforme l’IA agentique en pipeline capitalisable : pas du vibe coding, un cadre versionné de la spec à la gate humaine. Chez JST6, c’est la méthode derrière l’atelier AEP — « Still master, not be mastered. »

Prochaines étapes : installer zot-iasset, initialiser un repo, synchroniser votre IDE, brancher iasset validate --gate all en CI, puis parcourir le deck A4 pour présenter le cadre à l’équipe.