Les assistants de développement basés sur l’IA se sont imposés très vite dans les pratiques quotidiennes. On a rapidement vu émerger les pratiques de vibe coding. En quelques mois, ils sont passés du statut de gadget prometteur à celui d’outil presque incontournable pour accélérer la production de code. Mais derrière cette promesse, une difficulté demeure : comment garder du contrôle, de la cohérence et un vrai cadre technique quand l’IA intervient partout ?
C’est ici qu’AWS positionne Kiro, un IDE basé sur VSCode et orienté spec-driven coding. Kiro propose une manière structurée de collaborer avec des agents d’IA. L’outil ne cherche pas seulement à générer du code plus vite. Il essaie surtout de le faire dans un cadre explicite, documenté et répétable.
Nous allons voir ce que propose Kiro, comment fonctionne son approche spec-driven, ce qu’il faut comprendre sur son modèle économique, et en quoi il se compare à des initiatives comme spec-kit.
Kiro est sorti en GA le 17 novembre 2025. Il se repose sur VSCode, mais il a été modifié par AWS pour intégrer nativement des fonctionnalités d’IA dédiées au développement. L’idée n’est pas de proposer un simple éditeur enrichi par un chat ou un assistant contextuel. Kiro veut aller plus loin en intégrant une méthode de travail complète autour des spécifications.
L’usage de l’IDE nécessite une souscription, gratuite ou payante. Ce choix place Kiro dans une logique de service plutôt que dans celle d’un outil local autonome. L’expérience repose en grande partie sur l’infrastructure cloud d’AWS, avec Bedrock comme socle d’exécution.
Sur le plan pratique, Kiro s’appuie sur plusieurs modèles de langage, que l’utilisateur peut laisser choisir automatiquement ou sélectionner lui-même. Parmi les fournisseurs annoncés, on retrouve notamment Claude, Deepseek, MiniMax et Qwen. Cette ouverture donne à l’outil une certaine flexibilité, tout en gardant une logique de centralisation chez AWS.
Comme souvent avec les outils d’IA intégrés dans les environnements de développement, la question des données est centrale. Elle se décompose en deux sujets distincts : la télémétrie de l’IDE et les données envoyées au moteur d’IA.
Côté télémétrie, Kiro propose plusieurs réglages permettant de mieux contrôler les données remontées. Le sujet est important, mais il reste relativement classique pour un produit moderne : l’utilisateur peut ajuster les paramètres en fonction de son niveau d’acceptation.
La partie la plus sensible concerne les données utilisées par l’IA. Il faut ici se référer à la documentation de protection des données publiée par Kiro, car les règles dépendent du type d’abonnement : si l’abonnement est individuel mais que l’utilisateur dispose d’un abonnement Amazon Q Developer Pro, alors les données ne sont pas utilisées pour l’apprentissage. C’est également le cas pour les utilisateurs qui ne sont pas dans un cadre d’abonnement individuel.
Ce point n’est pas anecdotique. Dans un contexte sensible, la question n’est pas seulement de savoir si l’outil fonctionne bien, mais aussi de comprendre dans quelles conditions les données transitent, sont conservées, ou peuvent être réutilisées.
Kiro adopte un modèle de facturation assez lisible, mais qu’il faut bien comprendre avant de l’adopter. Toute la facturation liée à l’utilisation des modèles est centralisée dans Kiro. Il n’est pas nécessaire de souscrire à des services supplémentaires, ce qui simplifie l’expérience, mais impose aussi de suivre sa consommation de crédits.
L’unité de base est le crédit qui cache en fait un consommation de tokens.
Les offres disponibles proposent toutes les mêmes fonctionnalités. La différence se joue uniquement sur le nombre de crédits mensuels. On trouve ainsi pour commencer une offre gratuite avec 50 crédits par mois et on peut aller jusqu'à une offre à 200 $ par mois avec 10 000 crédits. Sur toutes les offres il y aura la possibilité de dépasser le forfait à 0,04 $ par crédit.
Au moment de la création du compte, Kiro offre également 500 crédits gratuits à consommer dans le mois. Cela permet de tester l’outil sans engagement immédiat.
La consommation varie selon le modèle utilisé. AWS applique un facteur allant de 1,3x à 0,05x, selon le choix du LLM. En mode automatique, le facteur appliqué est de 1x, quel que soit le modèle retenu.
Le vrai intérêt de Kiro se trouve dans sa manière d’aborder le développement assisté par l’IA. L’objectif du spec-driven coding est d’obtenir un comportement plus cohérent des agents, en les inscrivant dans un cadre défini à l’avance.
L’idée de base est simple : si l’on veut que l’IA produise du code utile dans un projet réel, il ne suffit pas de lui donner une consigne ponctuelle. Il faut lui fournir un contexte stable, explicite et partagé. C’est ce rôle que joue le steering.
Le steering définit les principes de fonctionnement du projet. Il est intégré dans chaque prompt afin de conserver une ligne directrice constante. Pour être efficace, il doit être précis, factuel et suffisamment court pour ne pas alourdir inutilement les requêtes successives.
Dans Kiro, ce steering est matérialisé par des documents Markdown rédigés en langage naturel. Ils constituent en quelque sorte la mémoire du projet et le référentiel de l’agent. L’approche est intéressante, car elle reste lisible par les humains tout en étant exploitable par les modèles.
Le cadre spec-driven de Kiro s’appuie sur trois fichiers principaux.
Ce fichier décrit le but du produit. Il rassemble les objectifs, les fonctionnalités clés et les intentions fonctionnelles. C’est le document du pourquoi.
Il sert à répondre à des questions simples mais essentielles : quelle valeur apporte le produit, quelles sont les capacités attendues, quels sont les comportements importants à préserver ? Sans ce socle, l’IA risque rapidement de produire des réponses techniquement correctes mais déconnectées de l’objectif métier.
Le fichier tech.md décrit le comment. On y retrouve la stack technologique, les frameworks utilisés, les bibliothèques importantes et les commandes habituelles du projet.
Sur un projet applicatif, ce fichier peut contenir les commandes de lint, de build et de test. Sur un projet d’IaC, il peut aussi décrire les commandes liées à la gestion de la stack, aux vérifications ou au déploiement. En pratique, c’est un document très utile pour éviter que l’agent n’invente des conventions qui ne correspondent pas au projet.
Enfin, structure.md précise l’organisation du repository. Il décrit l’arborescence, les dossiers à utiliser, les conventions de nommage et la manière de structurer le contenu des fichiers.
Ce point est souvent sous-estimé, alors qu’il conditionne une grande partie de la cohérence du travail généré. Une IA peut produire du bon code, mais si elle le place au mauvais endroit ou adopte une organisation incohérente, la valeur devient limitée. Ce fichier sert précisément à éviter ce type de dérive.
Le spec-driven coding apporte une réponse à un problème bien connu : plus on utilise l’IA dans un projet, plus on risque de voir apparaître des écarts de style, de structure ou d’intention. Chaque prompt peut amener un nouveau contexte, une nouvelle interprétation, ou une nouvelle manière de produire le code.
En imposant un socle documentaire stable, Kiro cherche à réduire cette variabilité. L’agent n’agit pas à partir d’une consigne isolée, mais à partir d’un ensemble de règles partagées. Cela rend les réponses plus prévisibles et améliore la continuité du travail.
Cette approche a particulièrement du sens dans les projets où plusieurs personnes interviennent, ou lorsque le dépôt a déjà un niveau de structuration élevé. Elle facilite aussi l’onboarding de nouveaux contributeurs, puisque les documents de steering donnent immédiatement une vision plus claire des attentes.
Kiro et spec-kit sont souvent rapprochés, car ils poursuivent une idée commune : guider l’IA par la spécification plutôt que par des prompts isolés. En théorie, les deux approches sont donc très proches.
Dans les faits, leur implémentation est différente. Kiro propose un IDE complet et une ligne de commande intégrée. Spec-kit, lui, repose sur des plugins destinés à différents agents, dont Kiro peut faire partie. On est donc davantage sur une logique d’écosystème côté spec-kit, et sur une logique d’environnement intégré côté Kiro.
Le workflow reste similaire dans les grandes lignes :
Cette séquence est pertinente, car elle force à expliciter le raisonnement avant de passer à l’écriture. Elle réduit le risque d’obtenir une implémentation trop rapide, mais mal alignée avec le besoin.
Après test, la différence entre les deux approches se ressent assez vite. Avec spec-kit et Claude, le respect de la constitution semble un peu moins strict que le steering côté Kiro. En revanche, les retours pendant l’exécution des commandes sont plus présents, et le code produit est globalement plus pertinent.
Kiro, de son côté, paraît plus cadré. Le comportement des agents est plus stable, plus proche du cadre défini au départ, et l’outil semble mieux conserver la cohérence du projet. C’est un point important si l’objectif principal est la répétabilité et la maîtrise du contexte.
On peut donc voir Kiro comme une tentative sérieuse de rendre l’IA plus compatible avec les pratiques de développement structurées. Ce n’est pas seulement un assistant de plus, mais une proposition méthodologique autour du développement assisté par l’IA.
Kiro se distingue moins par la nouveauté brute de ses briques techniques que par sa volonté de cadrer l’usage de l’IA dans le développement. Son approche spec-driven, son steering en Markdown, sa gestion centralisée des crédits et son intégration à l’écosystème AWS en font un outil à part.
Pour des équipes qui veulent expérimenter l’IA sans perdre le contrôle du projet, Kiro mérite clairement d’être étudié.