Kiro après la hype : ce que les IDE IA ont vraiment changé

Huit mois après que Kiro a atteint la disponibilité générale, l'idée durable s'avère être la spec, et la partie la moins durable s'avère être l'IDE. Kiro s'est lancé comme un IDE agentique dont le pari était de travailler au niveau de la spécification et de laisser l'agent implémenter. Ce qui a tenu, c'est l'artefact : une déclaration écrite d'intention qu'un humain relit avant que le code n'existe. Ce qui a discrètement perdu, c'est l'hypothèse selon laquelle l'éditeur est l'endroit où ça se passe. Kiro a livré une CLI à la GA, ajouté un mode headless, et c'est le terminal où l'usage intéressant s'est déplacé.

J'ai écrit sur la GA de Kiro fin d'année dernière dans AWS Monthly (Dec '25): The Kiro Era Begins, avec plus d'enthousiasme que de recul. Huit mois, c'est assez de temps pour dire quelles parties de ce texte ont tenu.

Ce qui a réellement été livré

Kiro est entré en préversion en juillet 2025 et a atteint la GA le 17 novembre 2025. La GA n'était pas une release de stabilité, c'était une release de périmètre : des tests basés sur des propriétés qui dérivent des cas de test des critères d'acceptation d'une spec, du checkpointing pour que les changements d'un agent puissent être annulés, la prise en charge des espaces de travail multi-racines, des plans d'équipe gérés de façon centralisée via AWS IAM Identity Center, et Kiro CLI, qui a mis l'agent dans le terminal.

Depuis, la trajectoire a été cohérente et peu spectaculaire. Kiro CLI a reçu un mode headless en avril 2026, si bien que l'agent tourne dans des pipelines plutôt qu'à côté d'un humain. Les sorties CLI de janvier 2026 portaient sur des allowlists et blocklists pour les URL qu'un agent peut récupérer, des raccourcis clavier pour les agents personnalisés, de meilleurs diffs. Ce n'est pas une roadmap qui court après une démo. C'est un outil qu'on ajuste pour la production, et la forme de cet ajustement vous dit ce que les gens font réellement avec.

La spec était la bonne idée

La véritable contribution de Kiro, c'est d'avoir fait de la spécification un fichier. Exigences, conception et tâches, dans le repo, versionnées, relisibles, diffables. Ça sonne comme un petit détail à côté de « l'IA écrit votre code », et c'est la seule partie que je défendrais sans réserve.

La raison, c'est là où ça déplace la relecture. Le codage agentique non gouverné produit un gros diff et demande à un humain de l'évaluer après coup, ce qui est le pire moment possible : le travail est fait, l'auteur est une machine sans mémoire de son raisonnement, et le rejeter revient à jeter quelque chose qui a l'air fini. Relire une spec inverse ça. Vous lisez une intention, au moment où la changer coûte une phrase. L'économie du « non, pas comme ça » est complètement différente avant et après l'implémentation.

Cette propriété n'a rien à voir avec l'IA, ce qui explique précisément pourquoi elle a survécu. C'est de la revue de conception avec une boucle de rétroaction plus courte, et ça tient que l'implémenteur soit un agent, un prestataire, ou vous-même mardi prochain.

Où ça n'a pas tenu

Trois échecs honnêtes, et ils étaient tous visibles tôt pour quiconque l'a utilisé sur du travail réel.

Les specs dérivent

Les exigences et la conception sont générées en amont et ne se mettent pas à jour toutes seules quand l'implémentation révèle que la conception était fausse. Les équipes rapportent exactement la dynamique qu'on prédirait : le code bouge, la spec non, et en quelques semaines la spec est un document décrivant un système qui n'existe plus. Ce n'est pas un échec de l'IA, c'est le plus vieil échec de la documentation logicielle, réintroduit par un outil qui a rendu le document bon marché à produire et pas moins cher à maintenir. Bon marché à écrire et coûteux à garder vrai, c'est précisément la combinaison qui génère des artefacts périmés.

L'overhead ne convient pas au petit travail

La version brute, de gens qui l'ont essayé sur un petit correctif de bug, c'est que le workflow de spec est un marteau-pilon pour une noisette. Exigences, conception et découpage en tâches pour changer une règle de validation, c'est pire que de simplement changer la règle de validation. La cérémonie est proportionnelle à rien, et la majeure partie du travail d'ingénierie est petite.

La rigidité est réelle

Le spec-first suppose que vous savez ce que vous voulez avant de commencer. Une bonne partie du logiciel s'écrit par des gens qui découvrent ce qu'ils veulent en l'écrivant. Pour le travail exploratoire, mettre la spécification en amont n'est pas de la discipline, c'est une hypothèse formalisée en document qui a désormais une autorité qu'elle n'a pas méritée. La critique selon laquelle le développement piloté par spec réimporte des dynamiques waterfall n'est pas totalement injuste, mais elle n'est pas totalement fausse non plus, et la différence dépend de si votre équipe traite la spec comme un contrat ou comme un brouillon.

Alors, pour qui

Le motif qui a émergé est plus étroit que le discours commercial et plus défendable. Les specs rentabilisent leur overhead quand les exigences sont ambiguës, quand les personnes impliquées sont assez dispersées pour qu'une compréhension partagée ne puisse pas être supposée, ou quand la traçabilité est une obligation plutôt qu'un agrément. Dans un contexte réglementé, « voici la spec relue, voici le diff qui l'implémente » n'est pas de l'overhead. C'est l'artefact d'audit que vous auriez dû construire de toute façon, produit comme sous-produit.

Pour une petite équipe sur une base de code bien comprise, l'overhead est surtout un coût. Ce n'est pas une critique de Kiro. C'est une affirmation de périmètre que le marketing n'allait jamais faire.

Ce que les IDE IA ont réellement changé

Voici l'affirmation rétrospective, et je la tiens avec des pincettes.

Le changement n'est pas que l'IA écrit le code. C'est arrivé, c'est réellement utile, et c'est maintenant assez banal pour que discuter du sujet soit ennuyeux. Le changement, c'est que l'unité de relecture humaine s'est déplacée en amont, du diff vers l'intention. Les specs de Kiro en sont une implémentation. AGENTS.md et les fichiers de steering en sont une autre. Le motif est le même : les humains rédigent des contraintes et relisent l'intention, les agents produisent des implémentations, et l'artefact sur lequel les humains se disputent cesse d'être le code.

Le second changement, c'est que l'IDE s'est révélé ne pas être le bon conteneur. La propre CLI de Kiro et son mode headless font le point mieux qu'aucun critique ne pourrait. Si un humain ne lit pas chaque changement à mesure qu'il arrive, l'éditeur est une UI pour quelque chose qui n'en a plus besoin, et l'agent appartient là où vit le reste de votre automatisation. L'IDE était la bretelle d'accès, pas la destination.

Ce qu'il faut retenir

Huit mois après la GA, la contribution durable de Kiro est la spécification comme fichier relisible et versionné, qui a déplacé le jugement humain vers le point où il coûte le moins cher à appliquer. Les coûts sont réels et précis : les specs dérivent parce que les générer est bon marché et les maintenir ne l'est pas, et la cérémonie ne convient pas au travail petit ou exploratoire. Utilisez-le là où l'ambiguïté ou la traçabilité justifient l'overhead, et passez outre là où ce n'est pas le cas. Et remarquez que la sortie la plus utile de l'IDE agentique fut une CLI, ce qui est l'industrie vous disant où ça va.