Comparaison des environnements de développement piloté par les spécifications (SDD) : SpecKit vs Kiro

Introduction

Cet article compare deux approches représentatives pour mettre en œuvre le « développement piloté par les spécifications (SDD) », une méthodologie qui a récemment suscité une attention considérable.

• VSCode + GitHub Copilot + SpecKit : Ajout d'un toolkit SDD aux éditeurs existants
• Kiro IDE : Un IDE tout-en-un avec des fonctionnalités SDD intégrées

Qu'est-ce que le développement piloté par les spécifications (SDD) ?

Dans le développement traditionnel, le code est central et les spécifications sont secondaires. Le SDD inverse cela en traitant les spécifications comme des livrables exécutables.

Principaux avantages du SDD

• Clarification et documentation des exigences
• Instructions précises pour les agents IA
• Réduction des désalignements entre les équipes
• Support des processus d'amélioration itérative

Environnement 1 : VSCode + GitHub Copilot + SpecKit

Présentation

SpecKit est un toolkit open source pour implémenter le SDD dans les environnements de développement existants. Fourni par GitHub, il permet l'interaction avec les agents IA via des commandes slash.

Configuration

# Installer Specify CLI
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# Initialiser un nouveau projet
specify init my-project --ai copilot

# Ou dans un projet existant
specify init . --ai copilot

Flux de développement

1. Établir la constitution du projet

/speckit.constitution Create principles focused on code quality, 
testing standards, user experience consistency, and performance requirements

Cette commande génère .specify/memory/constitution.md, définissant les directives à l'échelle du projet.

2. Créer des spécifications

/speckit.specify Build an application that can help me organize my photos 
in separate photo albums. Albums are grouped by date and can be re-organized 
by dragging and dropping on the main page.

Fichiers générés :

• .specify/specs/001-feature-name/spec.md : Exigences de fonctionnalité et user stories

3. Créer un plan d'implémentation technique

/speckit.plan The application uses Vite with minimal number of libraries. 
Use vanilla HTML, CSS, and JavaScript as much as possible.

Fichiers générés :

• plan.md : Architecture technique
• data-model.md : Définition du modèle de données
• contracts/api-spec.json : Spécifications API
• research.md : Documentation de recherche technique

4. Décomposition des tâches

/speckit.tasks

Fichiers générés :

• tasks.md : Liste des tâches d'implémentation (avec dépendances et marqueurs d'exécution parallèle)

5. Exécuter l'implémentation

/speckit.implement

L'implémentation se déroule séquentiellement selon la liste des tâches.

Détails des fichiers de prompt SpecKit

SpecKit génère plusieurs fichiers de prompt dans le répertoire .github/prompts/.

speckit.constitution.prompt.md

Objectif : Définir les principes fondamentaux et les directives de développement pour le projet

Structure :

---
description: Create or update project governing principles
---

# Project Constitution

Create a comprehensive constitution document that includes:

1. **Code Quality Standards**
   - Naming conventions
   - Documentation requirements
   - Code review processes

2. **Testing Standards**
   - Unit test coverage requirements
   - Integration test strategies
   - Test documentation

3. **Architecture Principles**
   - Design patterns to follow
   - Technology stack constraints
   - Performance requirements

4. **User Experience Guidelines**
   - Accessibility standards
   - Responsive design requirements
   - Internationalization considerations

Caractéristiques :

• Les agents IA référencent ce document tout au long de toutes les phases suivantes
• Applique les meilleures pratiques spécifiques au projet
• Assure la cohérence entre les équipes

speckit.specify.prompt.md

Objectif : Structurer les exigences fonctionnelles au format user story

Structure :

---
description: Define requirements and user stories
---

# Specification Template

## User Stories

**As a** [user type]
**I want** [goal]
**So that** [benefit]

### Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

## Functional Requirements

### FR-001: [Requirement Name]
**Priority**: High/Medium/Low
**Description**: Detailed requirement description
**Dependencies**: [Other requirements]

Processus de génération :

1. Analyser la description en langage naturel de l'utilisateur
2. Convertir en user stories
3. Clarifier les critères d'acceptation
4. Attribuer des identifiants d'exigences fonctionnelles

speckit.plan.prompt.md

Objectif : Détailler les plans d'implémentation technique

Structure :

---
description: Create technical implementation plans
---

# Implementation Plan

## Technology Stack
- Frontend: [Framework/Library]
- Backend: [Framework]
- Database: [Type]
- Deployment: [Platform]

## Architecture Overview
[System architecture diagrams, component diagrams]

## Data Model
[Entity relationship diagrams, table definitions]

## API Specifications
[Endpoint definitions, request/response formats]

## Implementation Phases
1. Phase 1: [Core features]
2. Phase 2: [Advanced features]

## Technical Considerations
- Security requirements
- Performance optimization
- Scalability concerns

Caractéristiques :

• Respecte les principes de constitution.md
• Résout techniquement les exigences de spec.md
• Compare plusieurs choix technologiques

speckit.tasks.prompt.md

Objectif : Décomposer en tâches concrètes et implémentables

Structure :

---
description: Generate actionable task lists
---

# Task Breakdown

## User Story: [Story ID]

### Task 1: [Task Name]
**File**: `src/components/Feature.tsx`
**Type**: Implementation
**Dependencies**: None
**Parallel**: [P] (if parallelizable)
**Description**: Detailed task description
**Acceptance**: How to verify completion

### Task 2: [Task Name]
**File**: `tests/Feature.test.tsx`
**Type**: Testing
**Dependencies**: Task 1

Règles de génération :

• Gérer explicitement les dépendances
• Spécifier les chemins de fichiers concrètement
• Considérer l'ordre du développement piloté par les tests (TDD)
• Marquer les tâches pouvant être exécutées en parallèle

speckit.implement.prompt.md

Objectif : Exécuter l'implémentation selon la liste des tâches

Flux d'exécution :

---
description: Execute implementation plan
---

# Implementation Execution

1. **Validate Prerequisites**
   - Constitution exists
   - Spec is complete
   - Plan is approved
   - Tasks are defined

2. **Parse Tasks**
   - Read tasks.md
   - Build dependency graph
   - Identify parallel tasks

3. **Execute Tasks**
   For each task in order:
   - Create/modify specified files
   - Run tests (if TDD)
   - Validate against acceptance criteria
   - Update task status

4. **Progress Reporting**
   - Mark tasks as In Progress/Done
   - Report errors with context
   - Suggest next steps

speckit.clarify.prompt.md

Objectif : Clarifier les parties ambiguës de la spécification par des questions

Structure :

---
description: Clarify underspecified areas
---

# Clarification Questions

## Coverage Analysis
[Identify areas not covered in the specification]

## Sequential Questions
1. **Question**: [Specific question]
   **Context**: [Why this is important]
   **Options**: [Possible answers]

[Answers are added to Clarifications section when recorded]

Caractéristiques :

• Recommandé à exécuter avant la création du Plan
• Obtenir des réponses via des questions structurées
• Les réponses sont intégrées dans la spécification

Exemple de documents générés

Dans un projet réel, la structure de répertoire ressemble à ceci :

my-project/
├── .specify/
│   ├── memory/
│   │   └── constitution.md          # Principes du projet
│   ├── specs/
│   │   └── 001-photo-albums/
│   │       ├── spec.md               # Spécifications de fonctionnalité
│   │       ├── plan.md               # Plan d'implémentation
│   │       ├── tasks.md              # Liste des tâches
│   │       ├── data-model.md         # Modèle de données
│   │       ├── contracts/
│   │       │   └── api-spec.json    # Spécifications API
│   │       └── research.md           # Recherche technique
│   ├── scripts/
│   │   ├── create-new-feature.sh
│   │   └── setup-plan.sh
│   └── templates/
│       ├── spec-template.md
│       ├── plan-template.md
│       └── tasks-template.md
├── .github/
│   └── prompts/
│       ├── speckit.constitution.prompt.md
│       ├── speckit.specify.prompt.md
│       ├── speckit.plan.prompt.md
│       ├── speckit.tasks.prompt.md
│       ├── speckit.implement.prompt.md
│       ├── speckit.clarify.prompt.md
│       └── speckit.analyze.prompt.md
└── src/
    └── [Fichiers d'implémentation]

Avantages

✅ Open Source : Utilisation gratuite sous licence MIT
✅ Flexibilité : Supporte plusieurs agents IA (Claude, Gemini, Copilot, etc.)
✅ Adoption progressive : Peut être adopté progressivement en commençant par les fonctionnalités nécessaires

Inconvénients

❌ Configuration manuelle : La configuration initiale nécessite plusieurs étapes
❌ Complexité d'intégration : Besoin de combiner plusieurs outils
❌ Expérience UI : Centré sur la ligne de commande avec un retour visuel limité
❌ Courbe d'apprentissage : Besoin de comprendre le rôle et l'ordre de chaque commande

Environnement 2 : Kiro IDE

Présentation

Kiro est un IDE Agentique supportant du prototype à la production, avec des fonctionnalités SDD nativement intégrées.

Configuration

1. Téléchargez l'IDE depuis kiro.dev
2. Installez et lancez
3. Peut importer automatiquement les paramètres et plugins VS Code

Flux de développement

1. Générer des Steering Docs

Sélectionnez « Generate Steering Docs » dans le panneau Kiro pour générer les éléments suivants dans .kiro/steering/ :

• Informations sur la stack technologique du projet
• Conventions de codage
• Directives de workflow

2. Trois phases de création de spécifications

Phase des exigences

Décrivez les user stories et les critères d'acceptation au format EARS (Easy Approach to Requirements Syntax) :

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

Fichier généré : .kiro/specs/feature-name/requirements.md

Phase de conception

Documentez l'architecture technique et les diagrammes de séquence :

Fichier généré : .kiro/specs/feature-name/design.md

Phase des tâches

Plan détaillé pour les tâches d'implémentation :

Fichier généré : .kiro/specs/feature-name/tasks.md

3. Automatisation avec les Hooks

Automatisation pilotée par événements qui exécute automatiquement des tâches en réponse aux modifications de fichiers :

Exemple : « Lors de la sauvegarde d'un composant React, générer automatiquement des fichiers de test »

{
  "hooks": [
    {
      "trigger": "onFileSave",
      "pattern": "**/*.tsx",
      "action": "generateTests"
    }
  ]
}

Structure des documents Kiro

my-project/
├── .kiro/
│   ├── steering/
│   │   ├── tech-stack.md
│   │   ├── coding-standards.md
│   │   └── workflows.md
│   └── specs/
│       └── photo-albums/
│           ├── requirements.md    # Exigences au format EARS
│           ├── design.md          # Conception architecturale
│           └── tasks.md           # Tâches d'implémentation
└── src/
    └── [Fichiers d'implémentation]

Avantages

✅ Expérience intégrée : Toutes les fonctionnalités nativement intégrées dans l'IDE
✅ UI visuelle : Gestion visuelle des listes de specs et des statuts de tâches
✅ Automatisation : Exécution de tâches en arrière-plan avec les Hooks

Inconvénients

❌ IDE dédié requis : Besoin de migrer depuis les éditeurs existants
❌ Vendor lock-in : Dépendance aux fonctionnalités spécifiques à Kiro

Tableau de comparaison détaillé

Comparaison des documents générés

Constitution/Steering

SpecKit :

• .specify/memory/constitution.md : Fichier unique
• Décrit les principes globaux du projet
• Référencé par toutes les commandes

Kiro :

• .kiro/steering/ : Plusieurs fichiers
• Sépare la stack tech, les conventions de codage, les workflows
• Auto-généré + personnalisable

Spécification

SpecKit :

# spec.md

## User Stories
As a user, I want to...

## Functional Requirements
FR-001: Feature description

## Review Checklist
- [ ] Requirements are clear
- [ ] Acceptance criteria defined

Kiro :

# requirements.md (EARS format)

WHEN user clicks upload button
THE SYSTEM SHALL display file selection dialog

WHEN file size exceeds 10MB
THE SYSTEM SHALL display error message

Plan d'implémentation

SpecKit :

# plan.md

## Architecture
- Frontend: React
- Backend: Node.js

## Implementation Details
[Detailed implementation guide]

# data-model.md
[Database schema]

# contracts/api-spec.json
{OpenAPI specification}

Kiro :

# design.md

## Component Architecture
[System architecture diagram]

## Sequence Diagrams
[Flow diagrams]

## Technical Considerations
[Performance, security, etc.]

Tâches

SpecKit :

# tasks.md

## User Story: US-001

### Task 1: Setup database schema
File: src/db/schema.sql
Dependencies: None
[P] Parallel: Yes

### Task 2: Create API endpoint
File: src/api/upload.ts
Dependencies: Task 1

Kiro :

# tasks.md

## Phase 1: Core Implementation

- [ ] Task 1: Database setup
  Status: Not Started
  Assignee: [Auto]
  
- [ ] Task 2: API development
  Status: Not Started
  Dependencies: Task 1

Guide d'utilisation

Quand choisir SpecKit

1. Vous souhaitez conserver l'environnement VSCode existant

   • Utiliser les plugins et paramètres étendus tels quels
   • Éviter les coûts de migration d'éditeur

2. Toute l'équipe est nouvelle au SDD

   • Apprendre progressivement avec l'approche basée sur les commandes
   • Facile de partager des documents via Git

3. Vous souhaitez essayer plusieurs agents IA

   • Alterner entre Claude, Gemini, Copilot, etc.
   • Éviter le vendor lock-in

4. Priorité à l'open source

   • Développement piloté par la communauté
   • Liberté de personnalisation

Quand choisir Kiro

1. Maximiser la productivité

   • Travailler rapidement avec une UI intégrée
   • Automatiser les tâches répétitives avec les Hooks

2. Accent visuel

   • Gérer les specs et les tâches visuellement
   • Vérifier la progression sur le tableau de bord

3. Besoin d'automatisation avancée

   • Workflows pilotés par événements
   • Intégration avec des services externes via MCP

4. Nouveaux projets

   • Non lié à l'environnement existant
   • Essayer la dernière expérience SDD

Utilisation avancée avec les fichiers de prompt SpecKit

Créer des prompts personnalisés

Les fichiers de prompt SpecKit peuvent être librement personnalisés :

---
description: Custom quality checklist generator
---

# /speckit.custom-checklist

Generate a quality checklist for:

1. **Security Review**
   - Authentication check
   - Authorization verification
   - Input validation

2. **Performance Review**
   - Database query optimization
   - Caching strategy
   - Load testing results

[Output format: Markdown checklist in spec directory]

Gérer plusieurs specs

# Fonctionnalité 1
specify init . --ai copilot
/speckit.specify Build user authentication system

# Fonctionnalité 2 (sur une nouvelle branche)
git checkout -b feature/002-payment
/speckit.specify Integrate payment gateway

Exemples pratiques de workflow

Développement en équipe avec SpecKit

graph TD
    A[Product Manager] -->|Define requirements| B["speckit.specify"]
    B --> C["Generate spec.md"]
    C --> D[Tech Lead]
    D -->|Technology selection| E["speckit.plan"]
    E --> F["Generate plan.md, data-model.md"]
    F --> G[Developer]
    G -->|Review tasks| H["speckit.tasks"]
    H --> I["Generate tasks.md"]
    I --> J["speckit.implement"]
    J --> K["Generate code"]
    K --> L[Pull Request]
    L --> M[Code Review]
    M -->|Approve| N[Merge]

Flux de développement en équipe avec SpecKit : Différentes commandes pour différents rôles, partage de documents via Git

Développement solo avec Kiro

graph TD
    A[Idea] --> B[Spec Chat]
    B --> C[Generate Requirements]
    C --> D[Generate Design]
    D --> E[Generate Tasks]
    E --> F[Code with #spec reference]
    F --> G[Save file]
    G --> H[Trigger Hooks]
    H --> I[Auto-generate tests]
    I --> J[Run in background]

Flux de développement solo avec Kiro IDE : Cycle de développement efficace avec UI intégrée et automatisation via Hooks

Conclusion

SpecKit est idéal pour les équipes qui souhaitent adopter le SDD tout en tirant parti des environnements de développement existants. Il est open source, très flexible et permet une adoption progressive.

Kiro est adapté aux développeurs recherchant la dernière expérience d'IDE Agentique. Avec une UI intégrée, des fonctionnalités d'automatisation et un retour visuel, il maximise la productivité.

Les deux environnements visent à rompre avec le « vibe coding » traditionnel et à réaliser un processus de développement systématique centré sur les spécifications. Choisissez en fonction de la nature de votre projet, de la composition de l'équipe et de l'environnement de développement existant.

• Essayer SpecKit : Dépôt GitHub
• Essayer Kiro : Site officiel