Quelle application Kiro devrais-je choisir?

Kiro n'est plus une seule chose. En juillet 2025, nous avons lancé Kiro comme un IDE d'IA. Depuis, c'est devenu beaucoup plus. Kiro est un agent de génie logiciel disponible en tant qu'IDE, une CLI, une application web, une application mobile, et Kiro Crew. Si vous avez été près du projet dernièrement, la question que vous vous êtes probablement posée (ou que vous avez voulu poser) est désarmante de simplicité : laquelle devrais-je choisir?

La réponse honnête est « ça dépend », mais restez avec moi, parce qu'il y a un véritable cadre derrière cette échappatoire, et une fois que vous le comprenez, le choix devient beaucoup plus facile. Encore mieux, vous réaliserez que vous posiez une question légèrement erronée. Ce n'est rarement laquelle, et presque toujours laquelle pour ceci.

Avant d'y arriver, et pour le contexte, soulignons rapidement ce qui a changé récemment et qui a modifié la discussion.

Sous le capot, Kiro converge vers un harnais d'agent unique. Kiro est devenu un seul agent qui se trouve derrière chaque surface. Ce harnais est le produit : l'endroit canonique où résident les capacités. Tout ce que vous touchez réellement, incluant l'IDE, la CLI et l'application web, est une application : une façon de consommer ce produit. Les deux sont intentionnellement découplés. Le harnais définit ce que Kiro peut faire; les applications définissent comment vous en faites l'expérience.

Ce n'a pas toujours été aussi ordonné. Plus tôt cette année, chaque application avait son propre agent : celui de l'IDE écrit en TypeScript, celui de la CLI en Rust, et celui du web en Python. C'étaient trois cerveaux distincts qui stockaient les sessions différemment, parlaient des langages de permission incompatibles, et forçaient chaque nouvelle fonctionnalité à être construite trois fois. Cela a depuis été consolidé en un seul harnais d'agent qui s'exécute comme un processus autonome à côté de votre code et communique avec chaque application par l'entremise d'un protocole bien défini (ACP, l'Agent Client Protocol). Un cerveau, plusieurs visages. Le gain pour vous est triple : les capacités de base ajoutées au harnais apparaissent sur toutes les surfaces à la fois, le comportement reste cohérent quelle que soit l'application où vous êtes, et — voici la partie intéressante — une session peut commencer sur votre portable, continuer à s'exécuter dans le nuage, et être vérifiée depuis votre téléphone, parce qu'il s'agit du même agent tout au long. Les applications individuelles peuvent tout de même développer des capacités qui n'ont de sens que sur leur propre surface, mais l'expérience de base vous suit.

Et ce n'est pas seulement ce que l'agent peut faire qui vous suit : votre configuration vous suit aussi. Les Skills, les fichiers Steering, les agents personnalisés, les préférences que vous avez ajustées : vous les configurez autour du harnais plutôt qu'à l'intérieur d'une seule application, alors changer de surface ne signifie pas reconstruire votre environnement à partir de zéro. Aujourd'hui, cela tient pour des combinaisons d'applications spécifiques; la trajectoire est que cela tienne pour n'importe laquelle d'entre elles, alors où que vous travailliez, votre Kiro vous accompagne.

Si vous voulez l'histoire détaillée derrière cette consolidation et les choix que nous avons faits (pourquoi un processus autonome, pourquoi nous nous sommes appuyés sur ACP comme protocole, et ce que nous avons dû démêler en cours de route), l'équipe d'ingénierie de Kiro l'a rédigée dans One agent, every surface. Le détour en vaut vraiment la peine.

Cela ressemble à un détail d'architecture, mais c'est toute la raison pour laquelle la question « quelle application » a une réponse sensée. Parce que toutes les applications puisent dans le même moteur, en choisir une n'est pas un pari que vous pouvez perdre. Vous ne choisissez pas un jardin clos. Vous choisissez une porte d'entrée.

Nous n'avons construit aucune de ces applications pour remplacer les autres. Chaque application répond à un besoin distinct, et ensemble elles couvrent plus de terrain qu'aucune d'entre elles ne pourrait le faire seule. Elles convergent vers le bas vers le moteur partagé, pas sur les côtés les unes vers les autres. Le chevauchement entre elles n'est pas un bogue que nous nous précipitons à éliminer; c'est la forme attendue d'une couche d'expérience plurielle assise sur une seule fondation. L'IDE et l'application web pourraient toutes deux vous permettre d'orchestrer des agents. Bien. Elles pourraient le faire pour des personnes différentes, à des moments différents, dans des endroits différents, avec une mémoire musculaire ou des préférences différentes.

Avant d'approfondir le portefeuille d'applications, explorons les principes qui guident notre exécution. Il y en a quelques-uns sur lesquels nous nous appuyons chaque fois que nous décidons quelles applications construire, et ils valent la peine d'être gardés en tête avant d'arriver aux applications elles-mêmes.

D'abord, Kiro sert le cycle de vie de la livraison logicielle. Nous construisons des applications pour les gens qui livrent des logiciels : les développeurs d'abord, mais aussi les rôles qui les entourent directement : gestionnaires de produit, chefs de projet, architectes, responsables de l'assurance qualité, concepteurs UX, les gens des opérations et du DevOps qui font en sorte que tout fonctionne. Et il ne s'agit pas seulement de qui vous êtes, mais de ce que vous faites : un développeur qui trie Slack, qui vide sa boîte de courriels, ou qui gère un calendrier fait tout de même le travail de livrer un logiciel, alors une application qui aide dans ces moments compte aussi. Ce que nous ne construisons délibérément pas est un « assistant d'IA générique pour tout le monde ». Mais cette frontière est grise, et intentionnellement ainsi : le test n'est pas « cette personne est-elle une développeuse? » ou « cette tâche consiste-t-elle à écrire du code? », c'est « cela sert-il l'acte de livrer un logiciel? »

Ensuite, nous rencontrons les bâtisseurs là où ils sont, et nous essayons ensuite de les aider à progresser. Certains d'entre vous vivent dans les fichiers et les fonctions (« code d'abord »); d'autres orchestrent des agents et traitent le code comme un sous-produit (« agent d'abord »). La majeure partie de l'industrie est encore dans la première catégorie, et c'est là que se trouvent l'échelle et la plupart des sièges d'entreprise; la foule « agent d'abord », plus petite aujourd'hui, est là où l'industrie se dirige et où nous obtenons notre signal le plus clair. Nous construisons donc pour le monde « agent d'abord », mais nous établissons des rampes d'accès simples et contextuelles entre les deux, afin que les gens puissent passer de l'un à l'autre à leur propre rythme.

Voilà le modèle mental. Nous essayons d'être rigoureux dans le respect de notre architecture convergée, mais nous voulons aussi être pragmatiques dans un espace qui évolue à la vitesse de la lumière si nous voyons une occasion. Passons maintenant aux applications elles-mêmes, là où la question « laquelle » trouve vraiment sa réponse.

L'IDE est celui à qui la plupart des gens font référence lorsqu'ils disent « Kiro ». C'est l'éditeur basé sur Code OSS, il est en disponibilité générale, et c'est la surface principale où la plupart du code est écrit. Si vous êtes une développeuse ou un développeur grand public dans une équipe d'entreprise, c'est votre base d'attache.

L'ajout récent intéressant est le mode Agent Focus, que nous avons lancé comme fonctionnalité expérimentale il y a quelques semaines. L'IDE vous permet maintenant de basculer entre Code Focus (familier, guidé, édition centrée sur le code) et Agent Focus (orchestrer plusieurs sessions en parallèle, gérer les sessions, observer un flux de travail se dérouler), tout cela sans jamais quitter votre éditeur. L'expérience entre les deux vues est aujourd'hui faiblement couplée, et nous avons hâte d'avoir vos commentaires là-dessus, car nous voulons toujours améliorer et répondre à vos préférences. Nous considérons le mode Agent Focus comme une rampe d'accès vers le deuxième principe ci-dessus : vous avez un aperçu du monde « agent d'abord » depuis la sécurité de l'environnement que vous connaissez déjà, et vous pouvez revenir à vos fichiers et fonctions dès que vous le souhaitez.

Aussi en disponibilité générale. La CLI sert deux publics très différents qui, par coïncidence, veulent exactement la même interface.

Le premier est celui des développeuses et développeurs qui préfèrent le terminal : des gens qui vivent dans un shell, pensent en indicateurs et en tubes, et vivent une surface graphique comme une friction plutôt qu'une aide. Il n'est pas rare de voir ces développeurs utiliser de 4 à 6 de ces sessions en parallèle. Ils jettent souvent (ou occasionnellement) un coup d'œil au code, mais ils ne révisent habituellement pas chaque ligne et comptent (fortement) sur les tests. Le deuxième est l'automatisation, où il n'y a aucun humain dans la boucle du tout : Kiro enveloppé dans des scripts shell, intégré comme étape dans un pipeline CI/CD sur GitHub ou GitLab, s'exécutant comme un travail plutôt que comme une conversation sur le portable de quelqu'un. Ce deuxième cas n'est possible que parce que le moteur est découplé de l'expérience : c'est Kiro sans aucune interface utilisateur.

La CLI nous a aussi appris quelque chose que je n'attendais pas : tout le monde n'essaie pas de « graduer » vers une application plus riche. Nous encadrons habituellement tout cela comme un mouvement vers l'avant : des bâtisseurs qui passent d'outils plus simples à des outils plus sophistiqués. Mais après avoir lancé une TUI (Terminal User Interface) complète, nous avons dû ajouter un mode léger, parce que pour une véritable portion d'utilisatrices et utilisateurs, la TUI était déjà trop. Certaines personnes se replient intentionnellement et veulent moins de surface, pas plus. Cela vaut la peine de se rappeler que plus de surface ne signifie pas toujours plus d'utilité.

Kiro sur le web est, à ce jour, en préversion. C'est une surface axée sur le nuage : un endroit pour collaborer, lancer du travail, et garder un œil sur des agents en arrière-plan qui avancent sans que vous ayez à les surveiller. Et de plus en plus, c'est son véritable rôle : le plan de contrôle pour vos sessions dans le nuage. Maintenant que vous pouvez lancer un agent dans le nuage directement depuis l'IDE ou la CLI, la question n'est plus comment vous en démarrez un, mais où vous les observez et les dirigez tous une fois qu'ils sont en cours d'exécution; Web devient rapidement cet endroit unique, quel que soit l'endroit où chaque session a commencé. Son public naturel est constitué des développeurs de pointe, des équipes, et des personnes dans des rôles adjacents, comme les gestionnaires de produit et les responsables, qui veulent participer à la livraison de logiciels sans vivre dans un éditeur toute la journée.

Kiro sur le web rend aussi le découplage concret plutôt que théorique. Parce qu'il repose sur le harnais convergé, les capacités cessent d'être piégées dans l'application où elles sont nées, et Web est l'endroit où vous voyez d'abord ce gain se concrétiser. Le développement piloté par les Specs en est l'exemple le plus clair : il était réservé à l'IDE, mais une fois que le flux de travail des Specs a été déplacé dans le harnais, il est apparu dans Web sans reconstruction sur mesure. C'est le vrai dividende de construire une capacité une seule fois, dans le moteur : ce que vous pouvez faire voyage à travers les surfaces au lieu d'être épinglé à l'éditeur où vous avez commencé.

Kiro Mobile est aussi en préversion. Honnêtement, celle-ci n'est pas un débat, c'est un incontournable. Tout outil sérieux pour développeurs avec exécution d'agents dans le nuage a besoin d'une surface pour téléphone. Aujourd'hui, elle excelle dans les tâches à distance : surveiller les agents en arrière-plan, examiner les résultats, approuver des actions, relancer une tâche de longue durée. Bref, tout ce qui ne nécessite pas d'être à votre bureau. Atteindre vos sessions locales sur votre portable depuis votre téléphone est la partie plus difficile, encore ouverte; nous commençons là où la voie est claire et nous résolvons le reste au fur et à mesure.

Kiro Crew regroupe des choses comme la mémoire persistante, les tâches planifiées, et les agents asynchrones en arrière-plan : des capacités qui vont au-delà de « exécuter l'agent » et vers « exécuter tout un Crew d'agents, selon un horaire, pendant que je dors ». Et c'est notre première application à code source ouvert. Nous continuons de la tenir à la barre de qualité et de soutien que vous attendriez d'un produit en disponibilité générale.

Alors, qu'est-ce que ça fait réellement? C'est là où vous déléguez plutôt que de conduire. Confiez-lui une file de billets et il fait le tri et distribue; pointez-le vers un incident réparti sur plusieurs dépôts et il enquête pendant que vous vous concentrez sur le correctif; lancez une migration et il traverse les points de contrôle et les reprises pendant que vous êtes en réunion ou que vous dormez. Il garde plusieurs agents en mouvement à la fois, retient vos préférences et vos corrections passées d'une session à l'autre pour ne pas repartir à froid, et vous pouvez accéder au même travail depuis l'application de bureau, le tableau de bord web, une TUI, ou via Slack.

Si l'IDE est là où vous écrivez du code et la CLI là où vous le scriptez, Crew est là où tout un crew d'agents garde les choses en mouvement pendant que vous vous êtes éloigné, ce qui explique pourquoi son public naturel est constitué d'utilisateurs avancés et de développeurs de pointe qui préféreraient pointer une flotte d'agents vers un problème plutôt que d'en piloter un seul à la main. Un peu d'histoire : Kiro Crew n'a pas commencé sa vie sous ce nom. Pendant des mois, il a vécu à l'intérieur d'Amazon sous le nom de MeshClaw, et cette période d'utilisation intensive au quotidien au sein de l'équipe est exactement la raison pour laquelle il a pu être lancé directement en accès libre. En moins de six mois, il avait été adopté par plus de 39 000 bâtisseurs Amazon, avec près de 500 d'entre eux qui y ont contribué (597 mises à jour à un rythme d'environ 143 commits par semaine). À ce moment-là, il avait cessé d'être une expérience pour devenir quelque chose sur quoi beaucoup de gens comptaient pour accomplir leur travail.

Ce qui m'amène à la note architecturale honnête. Appeler Kiro Crew une « application » est un peu réducteur. C'est une extension de système complète construite autour du moteur Kiro, et elle est livrée avec ses propres applications : web, Slack, et une application de bureau. Une bonne partie de ce qui rend Crew utile (l'automatisation toujours active, l'orchestration multi-agents, et la mémoire qui persiste entre les sessions) réside dans Crew lui-même plutôt que dans le harnais partagé, et une partie de cela chevauche des choses que le harnais fait déjà à sa propre façon. Ce n'est pas comme cela que se déroule la version ordonnée de l'histoire. Lorsque le moment de lancer est venu, nous avons fait le choix intentionnel de déroger aux principes architecturaux pour accélérer l'exécution, plutôt que de passer des mois à décomposer tout sur le harnais avant que quiconque puisse y toucher. Cela dit, nous prévoyons réconcilier Kiro Crew avec l'architecture partagée.

Bon. C'est pour cela que vous êtes ici. Voici l'aide-mémoire, selon ce que vous essayez réellement de faire :

Mais remarquez ce qui vient de se passer. Chacune de ces réponses est une tâche, pas une identité. Et c'est le vrai point : bien que nous sachions que les gens gravitent vers des outils précis qu'ils choisissent, vous n'avez pas nécessairement à en choisir un seul. Même moteur en dessous, rappelez-vous? Utilisez l'IDE à votre bureau, la CLI dans votre pipeline, Mobile dans le train, et Crew pour les choses toujours actives. Vous pouvez les utiliser tous à la fois, tous puisant dans le même harnais. La bonne question n'a jamais été « quelle application, pour toujours? » C'est « quelle application pour ceci : cette tâche, ce moment, cette humeur? »

Et si vous êtes une personne visuelle comme moi, j'ai essayé de capturer ces concepts dans un diagramme, au cas où ce serait plus facile à saisir :

Alors si vous êtes venu chercher l'unique vraie application, désolé : ce n'est pas le monde que nous construisons. Nous construisons une famille de portes d'entrée vers un moteur de plus en plus capable, chacune façonnée pour une personne différente et un moment différent, aucune n'essayant de dévorer les autres. (Kiro Crew est moins une porte qu'une maison entière, mais elle s'ouvre tout de même sur le même moteur.) Choisissez la porte qui correspond à ce que vous faites aujourd'hui. Demain, vous pourriez franchir une porte différente, et c'est justement toute l'idée.

Des moments excitants, assurément.