Kiro IDE : retour d’expérience et test de l’IDE IA d’AWS

Cet article, rédigé à l'aide de l'IA, est issu d’un talk filmé, donné par Léo RICHARD, développeur et responsable du pôle DevOps & Cybersec chez KAIZEN Solutions.

Il explore Kiro IDE, un nouvel environnement de développement propulsé par AWS et enrichi par des agents IA.
L’objectif : comprendre ce que vaut réellement cet outil qui promet de passer du prototype à la production en automatisant l’intégralité du cycle de développement, de la rédaction des spécifications au code livré.

Kiro IDE vs Cursor : quelles différences ?

La comparaison avec Cursor est naturelle. Cursor, fork de VS Code, avait séduit en permettant d’intégrer le LLM de votre choix directement dans l’IDE, avec la possibilité de sélectionner un bloc de code pour en demander une explication, générer des complétions ou même modifier le code inline, le tout accompagné de diffs bien présentés.

Kiro IDE reprend ce principe, mais en le poussant beaucoup plus loin. L’agent IA qui le propulse (Claude Code) peut se connecter à un terminal, interagir avec un navigateur, lire ou modifier des fichiers, et en théorie, manipuler n’importe quel outil exposant une API : de curl à Excel, en passant par un agenda Google ou une boîte Gmail. L’idée n’est plus de confiner l’assistant dans l’IDE, mais de lui permettre d’agir sur l’environnement complet du développeur.

Qu’est-ce que Kiro IDE ?

AWS présente Kiro comme un IDE “du prototype à la production”. Sa promesse est d’accompagner le développeur sur tout le cycle, avec une logique claire : ne pas commencer par coder, mais d’abord cadrer le besoin.

Dans la communication AWS, l’outil est presque présenté comme un remplaçant des analystes fonctionnels, chefs de projets et développeurs : il collecte le besoin, le transforme en architecture, planifie les tâches et les exécute, jusqu’à obtenir une application fonctionnelle.

Mais derrière cette image, la réalité technique impose des limites. Lors de son ouverture publique (bêta gratuite), Kiro a rapidement dû fermer les inscriptions. La raison : le coût d’exécution des modèles. Chaque utilisateur sollicitait lourdement le modèle Claude utilisé par Kiro, et l’infrastructure n’était pas prête à absorber la charge. Résultat : on ne peut plus télécharger librement l’IDE depuis leur site, seuls ceux qui l’avaient déjà installé peuvent continuer à l’utiliser.

Autre point clé : Kiro impose son propre agent Claude hébergé chez lui. Il n’est pas possible de brancher son propre modèle (Claude, GPT, Gemini, ou local) comme sur Cursor. En version gratuite, toutes les données saisies peuvent servir à l’entraînement futur des modèles, et il faudra attendre la version payante pour espérer un traitement des données plus privé. Cela limite les possibilités de personnalisation et peut poser des questions de confidentialité selon le contexte d’utilisation.

Comment fonctionne Kiro IDE?

Un workflow en 4 étapes

L’une des originalités de Kiro est d’imposer un cycle en quatre étapes, chacune correspondant à un fichier Markdown versionnable.

1. Le premier est un document de spécifications rédigé au format RFC 2119, avec des formulations précises qui utilisent les mots-clés MUST, SHOULD, MAY. Il sert à formaliser les besoins fonctionnels à partir de simples mots-clés fournis par l’utilisateur.
2. Le deuxième document est le design technique : architecture logicielle, endpoints, conventions de nommage, schémas Mermaid, découpage entre backend et frontend. Kiro y précise même les conventions à respecter selon le langage. Ce design peut intégrer des schémas et servir de référence commune à l’équipe.
3. La troisième étape est la liste de tâches, un plan d’actions concret dérivé des specs et du design, que l’IA pourra dérouler automatiquement. Elle est censée être exploitable directement : on choisit une tâche et Kiro la déroule, en éditant les fichiers, lançant des commandes, effectuant des commits.
4. Enfin, la dernière et 4ème étape est l’exécution. Elle vise à ce que ces tâches soient déroulées (codées) en se basant sur les spécifications.
   

Ce pipeline a l’avantage de tout formaliser, mais il souffre déjà d’une limite : si le contexte initial est incomplet ou imprécis, les erreurs se propagent dans tout le reste du processus.

Retour d’expérience : Kiro IDE testé en conditions réelles

Intégration dans un projet existant : résultat mitigé

La première mise à l’épreuve a consisté à intégrer Kiro dans un projet existant sans lui donner d’explication particulière. L’outil a correctement détecté l’architecture générale ( un backend en FastAPI, un frontend Angular, une base de données et un déploiement orchestré ), mais a échoué à reconstituer le fonctionnel à partir du code seul. Les spécifications produites étaient vagues, souvent hors sujet, et la liste de tâches contenait des actions déjà réalisées dans le projet. En clair, Kiro essayait de remplir son pipeline, quitte à inventer des besoins.

Lors d’un deuxième test, le même projet lui a été présenté avec un briefing détaillé. Cette fois, le design technique généré était précis et fidèle à la réalité. Les spécifications étaient plus pertinentes, mais le problème de la création compulsive de tâches persistait : même avec un contexte clair, Kiro continue à produire des items inutiles, simplement parce que son pipeline l’exige.

Un troisième test a consisté à reprendre les spécifications produites par Kiro, les enrichir, supprimer les redondances et préciser les besoins, puis à lui demander de régénérer la liste des tâches. Le résultat était plus structuré, mais encore trop volumineux. Certaines tâches restaient déjà implémentées, et l’agent, en les déroulant, se rendait parfois compte en cours de route qu’elles étaient inutiles… tout en poursuivant quand même, installant par exemple des dépendances en doublon ou choisissant des versions obsolètes.

Ajout de fonctionnalités ciblées : intégration d’une authentification Google

Parmi les tâches demandées, l’intégration d’une authentification Google côté frontend et la sécurisation des routes côté backend ont servi de bon test. Kiro a été capable de modifier le design et la liste des tâches pour y intégrer cette fonctionnalité, mais plusieurs problèmes sont apparus : il a remplacé des bibliothèques récentes par des versions datées, a réécrit des blocs déjà corrects, et a généré des diffs Git disproportionnés par rapport aux changements réels.

Cette tendance à “refactorer” tout un fichier pour une modification mineure complique la relecture et la gestion du code. Elle révèle aussi un comportement typique des LLMs actuels : ils privilégient la cohérence interne du fichier généré à la minimisation de l’impact dans un projet existant.

Création d’un projet from scratch : quand l’IA sur-produit

Le cinquième test a été réalisé sur un projet vide, avec pour objectif de créer une application Next.js intégrant React et Chart.js. L’agent a compris la demande, mais a produit des spécifications disproportionnées pour un simple proof-of-concept, générant plusieurs pages non demandées, ajoutant des formulaires et du texte inutile, et installant des bibliothèques qui n’étaient pas prévues.

Le code produit était très défensif, avec des vérifications partout, même là où elles n’étaient pas nécessaires dans le contexte du projet. Ce comportement reflète probablement l’entraînement sur des librairies open source, où le code doit être robuste pour des usages variés, mais devient inutilement lourd dans des projets dont le périmètre est maîtrisé.

Kiro IDE : limites pour les développeurs

Plusieurs limites sont apparues de manière récurrente:

• Kiro a tendance à choisir des dépendances obsolètes, parfois même non maintenues depuis des années.
• Lorsqu’il modifie un fichier, il ne se limite pas à la section concernée, ce qui génère des diffs difficiles à relire.
• Le contexte de travail se sature vite : les fichiers de specs et de design peuvent atteindre plusieurs centaines de lignes, et l’agent oublie alors des instructions données précédemment.
• Il ne lance pas systématiquement les tests ou le build, sauf demande explicite, et ne s’intègre pas encore dans un pipeline CI/CD complet.
• Enfin, la création de tâches artificielles est un problème constant, surtout sur des projets existants.

Bonnes pratiques pour utiliser Kiro IDE efficacement

L’expérience montre que Kiro ne peut pas être utilisé “en roue libre”.

• Il faut le briefer comme un développeur humain, avec des objectifs clairs, un contexte précis et des contraintes explicites.
• Les tâches doivent être découpées en unités simples pour éviter que le contexte ne déborde.
• Il vaut mieux éviter de lui confier l’installation des dépendances et privilégier le mode “by coding” pour les ajustements ciblés.
• Et dans tous les cas, il faut relire soigneusement chaque livrable – spécifications, design, code – avant de valider.
  

L’analogie qui résume le mieux l’outil est celle qui a émergé pendant le lunch : Kiro, c’est un stagiaire avec un doctorat. Il sait produire des choses impressionnantes, mais il faut le cadrer, vérifier son travail et lui donner des instructions précises.

Perspectives : l’apport potentiel du MCP

L’une des pistes évoquées pour améliorer Kiro est l’intégration du Model Context Protocol (MCP). Cela permettrait à l’agent de :

• charger dynamiquement la documentation la plus récente des outils qu’il utilise,
• rester à jour sur les API et les commandes,
• s’intégrer plus facilement dans un pipeline complet avec CI/CD et QA renforcée.

Si cette intégration est réussie, Kiro pourrait devenir un véritable assistant full-stack, capable non seulement de produire du code mais aussi de le tester et de le valider pour un déploiement direct.

Conclusion

En quatre heures de manipulation, Kiro a montré un vrai potentiel. Utilisé avec méthode, il peut accélérer et structurer un développement. Utilisé sans cadrage, il devient contre-productif. Ce n’est pas encore un remplaçant pour un pipeline complet, mais c’est un laboratoire précieux pour comprendre comment collaborer efficacement avec une IA outillée.

Pour l’instant, Kiro reste un outil pour développeurs curieux, capables d’exercer un contrôle serré et de lui fournir un cadre précis. Mais avec les évolutions rapides des agents IA et l’arrivée de standards comme MCP, il pourrait bien devenir, dans quelques mois, un partenaire fiable du quotidien.

Retour aux articles