Kiro Starter Kit pour une web agency — Partie 2 : workflow, audits et bonnes pratiques

Kiro Starter Kit : structurer le développement agentique pour une web agency

Dans la première partie, nous avons posé les bases : le paradigme AI-DLC, la plateforme Kiro (IDE, CLI, Web), et la construction d'un starter kit complet avec steering, agents, hooks, skills, powers et MCP servers. Cette seconde partie aborde le workflow quotidien : comment utiliser efficacement ces outils au jour le jour.

Le workflow Spec au centre

Le mode Spec est le cœur du développement structuré avec Kiro. Il formalise le passage d'une idée à une implémentation en quatre phases distinctes.

Workflow Spec-Driven : de l'idée à la PR

Une spec par fonctionnalité

La bonne organisation : une spec par fonctionnalité. Pas une spec monolithique pour tout le sprint, pas une spec par fichier. Une fonctionnalité cohérente, avec ses requirements, son design, et ses tâches.

.kiro/specs/
├── auth-system/
│   ├── requirements.md
│   ├── design.md
│   └── tasks.md
├── payment-flow/
│   ├── requirements.md
│   ├── design.md
│   └── tasks.md
└── user-dashboard/
    ├── requirements.md
    ├── design.md
    └── tasks.md

Les requirements sont rédigés en langage naturel avec des critères d'acceptation clairs. Le design décrit l'architecture technique, les flux de données, les endpoints API. Les tâches sont séquencées avec leurs dépendances et leurs critères de validation.

Quand utiliser quel mode

Vibe Session : questions rapides, exploration, prototypage, debug ponctuel. Pas de structure formelle, conversation libre. Idéal pour « comment faire X ? » ou « corrige ce bug ».
Spec Session : features complètes, refactoring structuré, nouvelles fonctionnalités. Le workflow requirements → design → tasks garantit la traçabilité et la reproductibilité.
Web Autonome : tâches longues qu'on veut déléguer entièrement. L'agent planifie, implémente, et ouvre une PR. Idéal pour les migrations, les refactorings cross-repo, ou les implémentations bien spécifiées.

La règle empirique : si la tâche nécessite plus de 30 minutes de travail humain et peut être décrite précisément, elle est candidate au mode Spec ou Web Autonome.

L'idéation libérée par les agents

L'un des changements les plus profonds apportés par l'AI-DLC concerne la phase d'idéation. Traditionnellement, les idées sont filtrées très tôt par la faisabilité technique perçue. « On ne peut pas faire ça, c'est trop complexe » est un réflexe courant qui tue l'innovation.

Avec des agents capables d'implémenter rapidement des prototypes, la barrière technique s'abaisse considérablement. L'équipe peut explorer des pistes plus ambitieuses, tester des hypothèses en quelques heures au lieu de quelques jours, et itérer sur des concepts sans le coût prohibitif d'un développement manuel.

L'humain guide, les agents exécutent. Le product owner décrit une vision, l'agent produit un prototype fonctionnel. Le designer propose une interaction, l'agent l'implémente pour validation. L'architecte esquisse un pattern, l'agent le concrétise avec les tests associés.

Ce n'est pas de la magie — c'est de la redistribution. Le temps gagné sur l'implémentation mécanique est réinvesti dans la réflexion, la validation, et l'itération sur le produit.

Utiliser l'IA pour définir le starter kit lui-même

Un point souvent négligé : Kiro peut aider à construire sa propre configuration. Les fichiers de steering, les définitions d'agents, les hooks — tout cela est du texte structuré que l'agent peut générer et affiner.

La démarche recommandée :

Décrire les pratiques en langage naturel dans une session Vibe : « Notre équipe utilise Next.js 16, TypeScript strict, Vitest pour les tests, Terraform pour l'infra AWS... »
Demander à l'agent de générer les fichiers de steering correspondants
Itérer : relire, ajuster, compléter avec les cas particuliers
Demander à l'agent de proposer des agents spécialisés adaptés aux rôles de l'équipe
Tester en conditions réelles et affiner

L'agent connaît les formats attendus (frontmatter YAML, structure des hooks JSON, conventions de nommage). Il produit des configurations valides dès la première itération dans la majorité des cas.

Le mode agent-to-agent de la CLI

La CLI Kiro supporte un mode de composition où plusieurs agents s'enchaînent. Le principe : la sortie d'un agent alimente l'entrée du suivant, créant un pipeline de traitement.

# Pipeline : analyse → correction → validation
kiro-cli chat --no-interactive --agent security-auditor --trust-all-tools \
  "Audite le module auth" | \
kiro-cli chat --no-interactive --agent backend-dev --trust-all-tools \
  "Corrige les vulnérabilités identifiées" | \
kiro-cli chat --no-interactive --agent qa-expert --trust-all-tools \
  "Écris les tests de non-régression"

Ce pattern « player-coach » (décrit par Ricardo Sueiras) permet de créer des boucles de feedback automatisées : un agent produit, un autre review, le premier corrige. Le résultat est un code qui a déjà traversé plusieurs niveaux de validation avant même la review humaine.

Le mode headless de la CLI (disponible depuis la version 2.0) permet d'intégrer ces pipelines dans GitHub Actions. Un workflow de CI peut déclencher un agent pour analyser une PR, produire un rapport, et poster un commentaire — le tout sans intervention humaine.

Gestion des prompts et ressources Kiro

Comprendre comment Kiro charge ses ressources dans le contexte est essentiel pour optimiser la consommation de tokens et maximiser la pertinence des réponses.

Chargement automatique

Steering (always) : injecté systématiquement. C'est le socle de connaissances permanent. Garder ces fichiers concis — chaque token compte.
Steering (fileMatch) : activé conditionnellement. Quand l'agent lit un fichier .tf, le steering terraform.md se charge automatiquement.
Skills (auto-match) : activé quand la requête correspond à la description du skill. Le frontmatter description est la clé.
Powers (keyword match) : activé quand un mot-clé de la power apparaît dans le prompt. Transparent pour l'utilisateur.

Invocation manuelle

Steering (manual) : via #NomDuSteering dans le chat.
Skills (slash command) : via /nom-du-skill dans l'input.
Agents (explicit) : via instruction dans le prompt ou sélection automatique par description.
Fichiers & Dossiers : via #File ou #Folder pour injecter du contexte spécifique.

Principe d'économie

La règle d'or : charger le minimum nécessaire. Préférer des fichiers courts et ciblés, utiliser le mode fileMatch pour les connaissances contextuelles, et réserver le mode always aux informations véritablement universelles (stack, conventions de base, commandes essentielles).

Intégration MCP avec Jira et Confluence

L'intégration MCP avec les outils de gestion de projet transforme le workflow quotidien. Quelques exemples concrets :

Daily standup assisté : l'agent consulte les tickets Jira en cours, les PR ouvertes, les commits récents, et produit un résumé orienté sur les blocages et les décisions à prendre. Le daily passe de 15 minutes de reporting mécanique à 5 minutes de discussion sur les vrais problèmes.

Synchronisation specs ↔ tickets : quand une spec Kiro est validée, l'agent peut créer automatiquement les sous-tâches Jira correspondantes, avec les critères d'acceptation extraits des requirements.

Documentation vivante : après l'implémentation d'une feature, l'agent met à jour la page Confluence associée avec les décisions techniques prises, les endpoints créés, et les patterns utilisés.

Contexte enrichi : quand un développeur travaille sur un ticket, l'agent peut consulter Confluence pour récupérer le contexte métier, les décisions architecturales passées, et les contraintes documentées.

Audits réguliers par agents spécialisés

Une bonne pratique souvent négligée : les audits réguliers. Plutôt que d'attendre qu'un problème soit signalé en production, on programme des audits périodiques par les agents spécialisés.

Cycle d'audits continus par agents spécialisés

Mise en place

Chaque agent d'audit est un custom agent avec un prompt orienté analyse et reporting. On les déclenche soit manuellement (hook userTriggered), soit dans un pipeline CI (CLI headless), soit en début de sprint.

Les audits recommandés :

QA : couverture de tests, cas limites non couverts, tests fragiles
SEO : meta tags manquants, structured data invalide, performance dégradée
Sécurité : dépendances vulnérables, secrets exposés, headers manquants
UX/UI : violations d'accessibilité, incohérences responsive, contrastes insuffisants
Architecture : couplage excessif, dette technique, patterns obsolètes
Performance : bundle size, lazy loading manquant, requêtes N+1

Chaque audit produit un rapport actionnable : pas un listing exhaustif de warnings, mais une liste priorisée de corrections avec leur impact estimé.

Fréquence et coût

La bonne pratique : un audit SEO et sécurité à chaque PR (via CI), un audit architecture et performance en début de sprint, un audit UX/UI avant chaque release. Le coût est marginal comparé au temps humain équivalent, et la couverture est systématique.

Bonnes pratiques pour les hooks

Les hooks sont puissants mais peuvent devenir coûteux si mal configurés. Quelques règles :

Préférer runCommand à askAgent quand c'est possible. Un pnpm lint ne coûte rien en tokens.
Cibler les patterns précisément. Si le hook n'est pertinent que pour les composants, cibler components/**/*.tsx.
Éviter les hooks en cascade. Un hook qui modifie un fichier peut déclencher un autre hook fileEdited.
Réserver preToolUse aux vérifications critiques (sécurité, secrets dans le code).
Documenter chaque hook — le champ description permet à l'équipe de comprendre pourquoi ce hook existe.

Trouver des ressources

L'écosystème Kiro s'enrichit rapidement. Quelques sources pour trouver des skills, agents, et configurations :

kiro.dev/powers — Le catalogue officiel de powers
KiroHub — Agents, skills et powers communautaires
SkillHub — Marketplace de skills pour agents de code
GitHub awsdataarchitect/kiro-best-practices — Template de bonnes pratiques Kiro
kiro.dev/docs — Documentation officielle complète

Transformer le starter kit en Power privée

Le starter kit qu'on vient de construire — steering, agents, hooks, MCP — peut aller plus loin. Plutôt que de dupliquer le répertoire .kiro/ dans chaque projet de l'agence, on peut le packager en une Kiro Power privée distribuée à toute l'équipe depuis un repository centralisé.

Structurer la Power

Une Power nécessite au minimum un fichier POWER.md à la racine. On y ajoute un mcp.json pour les serveurs MCP et un répertoire steering/ pour les guides de workflow :

power-webagency/
├── POWER.md              # Métadonnées + onboarding + mapping steering
├── mcp.json              # Jira, Confluence, GitHub, AWS docs
└── steering/
    ├── tech.md           # Stack Next.js/React/TypeScript/Tailwind
    ├── conventions.md    # Nommage, imports, Git, TypeScript strict
    ├── testing.md        # Vitest, Playwright, structure tests
    ├── deployment.md     # Terraform, GitHub Actions, AWS serverless
    ├── seo.md            # Structured data, meta, performance
    └── architecture.md   # Patterns Lambda, DynamoDB, API Gateway

Le POWER.md contient un frontmatter avec les mots-clés d'activation, une section d'onboarding, et un mapping qui indique quel fichier de steering charger selon le contexte :

---
name: "webagency-starter"
displayName: "Web Agency Starter Kit"
description: "Stack complète pour web agency : Next.js 16, TypeScript, AWS serverless, Terraform, GitHub Actions, Vitest, Playwright."
keywords: ["nextjs", "react", "typescript", "aws", "lambda", "terraform", "serverless", "vitest", "playwright"]
author: "NomDeLAgence"
---

# Onboarding

## Step 1: Vérifier les prérequis
- Node.js 22+ (`node --version`)
- pnpm (`pnpm --version`)
- Terraform CLI (`terraform --version`)
- AWS CLI configuré (`aws sts get-caller-identity`)

# When to Load Steering Files
- Composants React/Next.js → `tech.md`
- Nommage, imports, Git → `conventions.md`
- Tests → `testing.md`
- Déploiement, CI/CD → `deployment.md`
- Architecture serverless → `architecture.md`

Installer la Power en privé

L'installation se fait depuis le panneau Powers de l'IDE (l'icône 👻⚡ dans la barre latérale). Deux options pour les powers privées :

Add power from GitHub : entrer l'URL d'un repository GitHub privé (les développeurs doivent avoir accès au repo). Kiro clone et installe automatiquement.
Add power from Local Path : sélectionner un dossier local contenant le POWER.md. Utile quand la power est clonée manuellement ou incluse comme git submodule.

Une fois installée, la Power est active. Kiro charge automatiquement les steering files pertinents quand les mots-clés sont détectés. Les MCP servers déclarés dans mcp.json sont enregistrés dans ~/.kiro/settings/mcp.json.

L'approche combinée

La configuration optimale : la Power porte le socle commun (conventions, stack, patterns d'architecture, MCP partagés) et chaque projet conserve son propre .kiro/ pour les spécificités (specs de features, hooks métier, steering additionnel).

Quand la Power est mise à jour dans le repo central, chaque développeur peut la rafraîchir via Check for updates dans le panneau Powers. Tous les projets bénéficient immédiatement des améliorations.

Se concentrer sur la valeur ajoutée

Le changement de posture est fondamental. Dans un workflow AI-DLC avec Kiro, le développeur ne se demande plus « comment implémenter cette feature ? » mais « quelle feature apporte le plus de valeur ? ». Le « comment » est délégué aux agents.

Cela ne signifie pas que la compétence technique devient inutile. Au contraire : il faut être capable de valider que l'implémentation proposée par l'agent est correcte, performante, et maintenable. Mais le temps passé à écrire du code mécanique — CRUD, code répétitif, configuration, tests de base — est drastiquement réduit.

Le daily standup évolue aussi. Avec l'intégration MCP Jira/Confluence et les rapports d'agents, le standup du matin peut se concentrer sur :

Les décisions architecturales à prendre (pas les statuts de tickets)
Les blocages réels (pas les « j'ai avancé sur le ticket X »)
Les validations nécessaires (review de specs, approbation de design)

L'agent prépare le terrain. L'humain prend les décisions.

Conclusion

Construire un starter kit Kiro pour une web agency n'est pas un exercice purement technique. C'est un exercice d'organisation qui force à expliciter ce qui est souvent implicite : les conventions, les processus, les critères de qualité, les rôles et responsabilités.

Le résultat est un repository qui porte en lui la connaissance collective de l'équipe. Chaque nouveau développeur, chaque nouvel agent, hérite immédiatement de cette connaissance. Les pratiques sont appliquées systématiquement, pas par discipline individuelle mais par design du système.

L'investissement initial — quelques heures pour rédiger les steerings, définir les agents, configurer les hooks et les MCP — se rentabilise dès les premières semaines. Moins de temps perdu en onboarding, moins d'erreurs de convention, moins de dette technique accumulée par méconnaissance des patterns établis.

Le développement agentique n'est pas une mode passagère. C'est une évolution structurelle de la façon dont les équipes produisent du logiciel. Les équipes qui formalisent leurs pratiques aujourd'hui — via des outils comme Kiro — seront celles qui tireront le plus de valeur de cette évolution demain.