Kiro Starter Kit pour une web agency — Partie 1 : plateforme et configuration

Les outils de développement assistés par IA se multiplient. Cursor, Claude Code... chacun apporte sa vision du développement assisté par l'IA. Mais entre un assistant qui complète du code et une plateforme qui structure un workflow de production complet, il y a un fossé. Kiro vous aide à structurer tout cela, avec une approche qui dépasse la simple génération de code pour embrasser l'ensemble du cycle de développement.

Cet article en deux parties propose un guide concret pour construire un starter kit Kiro destiné à une web agency. Dans cette première partie : le contexte AI-DLC, la plateforme Kiro, et la construction du kit. La seconde partie couvre le workflow quotidien, les audits, et les bonnes pratiques.

L'AI-DLC : un nouveau paradigme de développement

Du SDLC à l'AI-DLC

Le Software Development Life Cycle (SDLC) traditionnel — planification, conception, développement, tests, déploiement, maintenance — repose sur l'humain à chaque étape. L'AI-Driven Development Life Cycle (AI-DLC), formalisé par AWS en 2025, repositionne les rôles : l'IA devient l'exécutant principal sur les phases d'implémentation, de test et de déploiement, tandis que l'humain conserve la direction stratégique, la validation et la supervision.

Ce n'est pas une question de remplacer les développeurs. C'est une question de redistribution de l'effort cognitif. Dans un AI-DLC, un développeur passe moins de temps à écrire du code répétitif et plus de temps à définir ce que le logiciel doit accomplir, à valider que l'implémentation respecte les contraintes métier, et à prendre les décisions architecturales qui nécessitent du jugement humain.

Ce que Kiro apporte au-delà de Claude Code

Claude Code, développé par Anthropic, est un agent terminal puissant qui a posé les bases de nombreux concepts repris entre autre par Kiro. C'est Claude Code qui a introduit les skills (chargement progressif de documentation), le support natif de MCP, les custom agents et le steering sous forme de fichiers CLAUDE.md. Ces mécanismes fonctionnent et sont éprouvés en usage individuel.

Ce que Kiro ajoute, c'est une couche d'orchestration et de structure pensée pour les équipes et les projets de production :

Specs : un workflow structuré requirements → design → tasks — absent de Claude Code qui reste conversationnel
Hooks : des automatisations event-driven intégrées à l'IDE
Powers : des packages de connaissances spécialisées activés automatiquement par mots-clés
Mode Web autonome : délégation complète de tâches longues avec PR automatiques
Interface visuelle : gestion des specs, hooks, et agents dans un IDE dédié

Les fondations sont partagées (steering, skills, MCP, custom agents), mais Kiro les enveloppe dans un workflow structuré qui encode le « comment on travaille ici » directement dans le repository.

La plateforme Kiro : IDE, CLI, Web

Kiro n'est pas un outil unique mais une plateforme déclinée en trois interfaces complémentaires.

L'IDE : le quotidien du développeur

L'IDE Kiro est l'environnement de travail principal. C'est là que se déroulent les sessions Vibe (conversationnelles) et Spec (structurées). L'IDE offre l'accès complet aux hooks, au steering, aux skills, aux powers et aux MCP servers. Deux modes d'autonomie coexistent : Autopilot (l'agent travaille de bout en bout, le développeur review) et Supervised (l'agent s'arrête après chaque modification pour validation).

C'est l'interface à utiliser pour le développement actif : écriture de features, debugging, refactoring, itération rapide avec feedback visuel immédiat.

La CLI : automatisation et pipelines

La CLI Kiro apporte l'agent dans le terminal. Elle partage le même moteur que l'IDE — steering, skills, custom agents, MCP — mais s'intègre dans des workflows scriptés. Depuis la version 2.0, elle supporte un mode headless avec API key, ce qui permet de l'intégrer directement dans des pipelines CI/CD, des scripts de build, ou des workflows GitHub Actions.

Le cas d'usage principal : l'automatisation. Intégrer un agent dans un pipeline GitHub Actions pour analyser une PR et poster un commentaire, générer du code d'infrastructure à partir d'un ticket Jira, ou orchestrer des agents en pipeline via le mode agent-to-agent où la sortie d'un agent alimente l'entrée du suivant.

Le Web : délégation autonome

Kiro Web est la nouveauté majeure. Accessible depuis un navigateur, sans installation, il permet de connecter des repositories GitHub et de déléguer des tâches complètes à l'agent. Le mode autonome est le différenciateur : l'agent pose des questions de clarification en amont, construit un plan, délègue à des sous-agents spécialisés, et ouvre une pull request automatiquement.

C'est l'interface à utiliser quand on veut déléguer une tâche longue sans bloquer son IDE : refactoring cross-repo, implémentation d'une feature bien spécifiée, migration de code. On décrit le besoin, on laisse l'agent travailler, on review la PR résultante.

Point de vigilance : la consommation de crédits. En mode autonome, l'agent consomme des crédits en continu jusqu'à complétion. Deux précautions dans un contexte d'équipe :

Limiter les droits par profil : restreindre les abonnements autonomes (Pro+, Power) aux profils seniors qui savent cadrer une tâche
Cadrer précisément la tâche : une spec bien rédigée avec des critères d'acceptation clairs limite le périmètre d'exécution

L'autre atout du mode Web : il travaille quand vous ne travaillez pas. Lancer une tâche le vendredi soir — migration de code, refactoring d'un module, génération de tests — et retrouver une PR prête à review le lundi matin.

Quand passer de l'un à l'autre

IDE pour coder, CLI pour automatiser, Web pour déléguer.

Formaliser les pratiques de l'équipe

Avant de configurer Kiro, il faut cartographier les pratiques existantes. Voici la stack d'une web agency type, construite autour de TypeScript, React 19, Next.js 16, et Tailwind CSS 4, avec une infrastructure serverless AWS gérée par Terraform :

Domaine	Choix
Langages & Frameworks	TypeScript, React 19, Next.js 16, Tailwind CSS 4
Package manager	pnpm
Backend	AWS Lambda, API Gateway, DynamoDB
Hébergement frontend	S3 + CloudFront (site statique)
Infrastructure as Code	Terraform
CI/CD	GitHub Actions
Versioning	Git, Gitflow, Pull Requests
Tests	Vitest (unit/intégration), Playwright (E2E)
Ticketing	Jira
Documentation	Confluence

Côté backend : AWS Lambda pour le compute serverless, Amazon API Gateway pour les endpoints REST, Amazon DynamoDB pour la persistance NoSQL. Frontend sur Amazon S3 derrière Amazon CloudFront. Monitoring via Amazon CloudWatch et AWS X-Ray. Versioning Gitflow avec Git. Tests : Vitest et Playwright. Gestion de projet : Jira et Confluence. Package manager : pnpm.

Construire le Starter Kit Kiro

Le starter kit vit dans .kiro/ à la racine du projet, versionné avec le code. Chaque développeur qui clone le repo hérite de la configuration complète.

Steering : encoder les conventions

Fichiers markdown dans .kiro/steering/, injectés automatiquement dans le contexte :

.kiro/steering/
├── tech.md           # Stack, versions, commandes build/test/deploy
├── conventions.md    # Nommage, imports, TypeScript strict, Git
├── testing.md        # Framework, structure, commandes, mocks
├── deployment.md     # Pipeline, AWS resources, scripts
├── seo.md            # Structured data, meta, performance
├── security.md       # Headers, CSP, bonnes pratiques
└── architecture.md   # Patterns serverless, DynamoDB, Lambda

Un bon steering tient en 30-50 lignes. Trois modes d'inclusion : always (défaut), fileMatch (ex: *.tf → terraform.md), manual (via #NomDuSteering). Pour les gros documents (OpenAPI, GraphQL), utiliser #[[file:chemin/relatif]].

Agents personnalisés : un agent par métier

Les custom agents sont des fichiers markdown dans .kiro/agents/. Chaque agent a son propre prompt système, ses outils autorisés, et éventuellement ses MCP servers dédiés. Kiro sélectionne automatiquement l'agent approprié en fonction de la description, ou on peut l'invoquer explicitement.

Pour une web agency, on définit des agents alignés sur les rôles de l'équipe :

.kiro/agents/
├── frontend-dev.md      # Expert React/Next.js, composants, performance
├── backend-dev.md       # Expert Lambda, DynamoDB, API Gateway
├── devops.md            # Expert Terraform, GitHub Actions, AWS
├── qa-expert.md         # Expert tests, couverture, qualité
├── seo-auditor.md       # Expert SEO technique, structured data
├── ux-reviewer.md       # Expert accessibilité, responsive, UX
└── security-auditor.md  # Expert sécurité, vulnérabilités, compliance

Un agent bien défini contient : une description claire (pour la sélection automatique), un prompt système qui cadre son expertise et ses limites, la liste des outils auxquels il a accès, et optionnellement des MCP servers spécifiques.

Exemple de structure pour l'agent QA :

---
name: qa-expert
description: "Expert QA spécialisé en tests unitaires (Vitest), intégration et E2E (Playwright). Analyse la couverture, identifie les cas limites, et propose des stratégies de test."
model: auto
tools:
  - read
  - write
  - shell
---

Tu es un expert QA senior. Tu analyses le code pour identifier les cas de test manquants, tu écris des tests robustes et maintenables, et tu vérifies la couverture.

## Règles
- Framework : Vitest pour unit/intégration, Playwright pour E2E
- Structure : tests/unit/, tests/integration/, tests/e2e/
- Convention : describe('ComponentName') → test('should do X when Y')
- Toujours nettoyer les side effects dans afterEach
- Pas de dépendances entre tests

Hooks : automatiser sans gaspiller

Les hooks sont des automatisations event-driven. Ils se déclenchent sur des événements IDE et exécutent soit une commande shell (runCommand), soit une instruction à l'agent (askAgent).

La tentation est de tout automatiser. C'est une erreur : chaque hook askAgent consomme des tokens. La bonne pratique est de réserver les hooks à des actions qui apportent une valeur immédiate et évitent des erreurs coûteuses en aval.

.kiro/hooks/lint-on-save.kiro.hook :

{
  "name": "Lint on Save",
  "version": "1.0.0",
  "when": { "type": "fileEdited", "patterns": ["*.ts", "*.tsx"] },
  "then": { "type": "runCommand", "command": "pnpm lint --fix" }
}

.kiro/hooks/security-check.kiro.hook :

{
  "name": "Security Check on Write",
  "version": "1.0.0",
  "when": { "type": "preToolUse", "toolTypes": ["write"] },
  "then": {
    "type": "askAgent",
    "prompt": "Vérifie que ce fichier ne contient pas de secrets, tokens, ou credentials en clair."
  }
}

Les hooks runCommand sont gratuits en tokens — ils exécutent simplement une commande. Les hooks askAgent consomment du contexte. La règle : utiliser runCommand pour le linting, le formatting, les tests rapides ; réserver askAgent pour les vérifications qui nécessitent du jugement (sécurité, conformité aux conventions complexes).

Skills : connaissances à la demande

Les skills sont des fichiers markdown avec un frontmatter descriptif. Contrairement au steering (toujours chargé), les skills ne chargent que leurs métadonnées au démarrage. Le contenu complet est injecté uniquement quand l'agent détecte que la requête correspond à la description du skill.

C'est le mécanisme idéal pour les documentations volumineuses : patterns Next.js, conventions Terraform, guides de migration, procédures de déploiement.

L'installation de skills communautaires se fait via la CLI skills (agentskills.io) :

# Installer un skill depuis un repository GitHub
npx skills add hashicorp/terraform-skill

# Les skills sont installés dans .kiro/skills/ (partagés via Git)

Les skills installés au niveau projet (dans .kiro/skills/) sont versionnés et partagés avec toute l'équipe. Ceux installés au niveau utilisateur (~/.kiro/skills/) restent personnels.

Powers : expertise packagée

Les Kiro Powers vont plus loin que les skills. Une power package de la documentation, des workflows guidés (steering files), et optionnellement des MCP servers. Quand un mot-clé associé à une power est détecté dans le prompt, Kiro charge automatiquement le contexte spécialisé.

Le catalogue de powers s'enrichit régulièrement. Pour une web agency AWS, on installe typiquement les powers AWS CDK, Terraform, et les powers spécifiques aux frameworks utilisés. L'installation se fait depuis l'IDE via le panneau Powers ou depuis le site kiro.dev.

MCP Servers : connecter l'écosystème

Le Model Context Protocol (MCP) permet à Kiro d'interagir avec des outils externes. Pour une web agency, les connexions essentielles sont :

.kiro/settings/mcp.json :

{
  "mcpServers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-jira"],
      "env": { "JIRA_URL": "${JIRA_URL}", "JIRA_TOKEN": "${JIRA_TOKEN}" }
    },
    "confluence": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-confluence"],
      "env": { "CONFLUENCE_URL": "${CONFLUENCE_URL}", "CONFLUENCE_TOKEN": "${CONFLUENCE_TOKEN}" }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    }
  }
}

L'intégration Jira permet à l'agent de lire les tickets, mettre à jour les statuts, et créer des sous-tâches. L'intégration Confluence permet de consulter la documentation existante et de la mettre à jour. Ces connexions transforment le daily standup : l'agent peut produire un résumé de l'avancement basé sur les commits, les PR, et les tickets, orienté sur les vrais blocages plutôt que sur le reporting mécanique.

Dans la seconde partie : workflow Spec, audits par agents, mode agent-to-agent, gestion des tokens, et transformation du starter kit en Power privée.