Faire d'abord écrire par l'IA ce qui est voulu, puis la laisser coder : la spécification transforme la devinette en mise en œuvre.

Écrire du code avec un modèle bute sur un problème incontournable : plus la demande est vague, plus les suppositions partent loin. Demandez un système de commentaires pour un blog et vous recevrez peut-être trois implémentations de styles entièrement différents, et le temps de les réviser toutes, plus personne ne se souvient de ce qui était voulu au départ. Kiro inverse l'ordre : coucher d'abord l'exigence dans une spécification que vous pouvez relire, puis laisser l'agent construire dessus.

Kiro est développé et exploité par AWS, lancé en juillet 2025 et depuis passé en disponibilité générale. Il résume la chose en une phrase : passer du codage assisté par IA à l'agentic engineering. Ce n'est pas un outil de complétion bavard mais un flux qui enchaîne exigence, conception, tâches et implémentation.

Piloté par spécification : une phrase devient trois documents

Le cœur est le développement piloté par spécification. Vous fournissez une seule description en langage naturel et trois documents apparaissent dans l'ordre. Le fichier d'exigences découpe le besoin en récits utilisateurs avec critères d'acceptation. Le fichier de conception expose l'architecture, les choix technologiques et la conception du système. Le fichier de tâches est une liste ordonnée par dépendances. Par défaut, tout cela vit dans un répertoire de spécifications du projet, et la recommandation officielle est de le committer avec le code.

La manière d'écrire les exigences mérite un mot. Les critères d'acceptation suivent la syntaxe EARS, dont la forme est à peu près : lorsqu'une condition est remplie, le système doit faire telle chose. La notation vient des systèmes de sécurité aéronautique, et son intérêt est de forcer une description floue à devenir une assertion vérifiable, si bien que les cas limites se perdent moins.

Chacun des trois documents marque un arrêt pour votre validation. On peut réécrire une exigence, rejeter une approche technique, réordonner les tâches, et seulement ensuite faire exécuter le tout par l'agent, une par une. Tout apparaît en diff, acceptable en bloc ou ligne par ligne.

Avant le code, vérifier que les exigences ne se contredisent pas

Un geste est inhabituel : avant qu'une ligne ne soit écrite, un raisonnement automatisé cherche les conflits et les manques dans vos exigences. La justification officielle est directe : que tous les tests passent ne signifie pas que le code correspond à votre intention, donc on vérifie d'abord l'intention elle-même.

Après l'implémentation vient une autre couche de vérification, avec des tests par propriétés, cousins du test aléatoire. Les tests unitaires ordinaires vérifient quelques cas concrets ; les tests par propriétés affirment des règles qui doivent tenir pour toute entrée, ce qui les rend meilleurs pour attraper le cas limite qui passe les tests unitaires et casse en production.

Steering et hooks : figer les règles du projet

Répéter dans chaque nouvelle conversation qu'on type strictement et que les tests vivent à côté du code use la patience. Les fichiers steering existent pour cela : des documents Markdown rangés dans un répertoire dédié, porteurs d'un savoir durable comme les décisions d'architecture, les normes de code et les conventions de nommage, que Kiro consulte automatiquement en générant du code ou en relisant des changements. Ils se chargent de trois façons, en permanence, selon une condition de fichier, ou sur référence manuelle, et les conventions courantes comme AGENTS.md sont aussi respectées.

Les hooks d'agent transforment les habitudes à prendre en exécution automatique. On définit un événement, enregistrement, création ou suppression de fichier, et l'agent lance une tâche préparée : ajouter le fichier de test dès qu'un composant est enregistré, mettre la documentation à jour dès qu'un point d'API change, chercher des identifiants fuités avant un commit. La comparaison officielle est une intégration continue qui tourne en local, à la différence près que la logique s'écrit en langage naturel plutôt que dans un dialecte de configuration.

Quatre formes, un seul jeu de réglages

Kiro existe comme IDE, comme outil en ligne de commande, en version web, en application mobile et comme espace de travail persistant nommé Kiro Crew. L'IDE repose sur une base d'éditeur open source et importe vos réglages, thèmes et extensions existants, si bien que la migration n'est pas douloureuse. La ligne de commande prend en charge bash, zsh et fish ainsi que plus de cinq cents outils CLI courants, et tourne sans interface dans une chaîne pour relire des pull requests ou corriger des bugs.

Les sessions web tournent dans un bac à sable cloud isolé, continuent après la fermeture du portable et coordonnent les changements entre dépôts. Kiro Crew est un projet open source sous licence Apache, tourne sur votre propre machine, conserve le contexte d'une session à l'autre et penche vers l'espace de travail de long terme.

Le modèle, ce n'est pas vous qui le choisissez

Le réglage Auto par défaut aiguille selon la complexité de la tâche, en pesant qualité du modèle, latence et coût. On peut aussi nommer un modèle explicitement, notamment dans la lignée Claude Sonnet, ou utiliser sur l'offre gratuite des modèles à poids ouverts comme Qwen3 Coder Next. Les paliers payants ouvrent des modèles plus avancés.

L'unité de facturation est le crédit, consommé par prompt et suivi à deux décimales, si bien qu'une requête simple peut ne pas en utiliser un entier. L'IDE affiche en temps réel ce qu'a coûté chaque prompt, de quoi éviter les factures surprises.

Prix et premiers pas

L'offre gratuite est permanente, avec cinquante crédits par mois, sans carte bancaire, et donne tout de même accès aux principaux modèles, assez pour dérouler une fois le flux de spécification. Les paliers payants coûtent vingt dollars par mois pour mille crédits, quarante pour deux mille, cent pour cinq mille et deux cents pour dix mille. Des crédits supplémentaires s'achètent à quatre cents pièce. Les offres équipe et entreprise ajoutent facturation centralisée, authentification unique, tableaux d'usage et gouvernance des droits.

La connexion accepte GitHub, Google, AWS Builder ID ou AWS IAM Identity Center, et aucun compte AWS n'est requis, un point souvent mal compris. La version de bureau couvre Windows, macOS et Linux.

Kiro ne cherche pas à faire écrire du code plus vite par l'IA, mais à garantir que le code écrit est celui que vous vouliez. Fixer d'abord l'exigence comme une spécification relisible qui vit dans la gestion de versions, puis laisser l'agent l'implémenter, et les cycles de reprise et de discussion baissent nettement. Pour un projet à maintenir pendant des années, cette discipline vaut son prix.