Les assistants de programmation basés sur l’IA ont considérablement facilité la génération de code. En théorie, il suffit de décrire une fonction, de demander une correction ou de réclamer un test pour obtenir une réponse utile en quelques secondes.

Cette façon de travailler convient bien aux tâches isolées. Elle devient toutefois moins fiable lorsqu’il faut développer une fonctionnalité complète, coordonner plusieurs services et prendre des décisions qui devront encore être comprises six mois plus tard.

À mesure que les échanges s’allongent, le contexte commence à se perdre. Les exigences évoluent sans être consignées formellement. Les décisions d’architecture restent dans la tête du développeur. Le code peut fonctionner, mais le raisonnement qui l’a façonné se retrouve éparpillé entre des conversations, des billets et une documentation qui n’est peut-être déjà plus à jour.

Kiro aborde le problème autrement. Conçu par AWS, cet environnement de développement agentique repose sur des spécifications structurées. Plutôt que de réagir à un prompt à la fois, Kiro peut planifier, implémenter et vérifier le travail dans l’ensemble d’une base de code à partir d’exigences, d’un design technique et d’une séquence de tâches.

Chez Unicorne, Kiro est devenu l’un de nos éditeurs de référence, aux côtés de VS Code, parce que son fonctionnement correspond à notre façon de livrer des solutions : clarifier l’intention, rendre l’architecture explicite et tenir compte des réalités de la production dès le départ.

Passer d’un prompt à une véritable spécification

Pour une fonctionnalité complexe, Kiro n’a pas besoin de commencer immédiatement à modifier les fichiers sources. Il peut d’abord organiser le travail autour de trois artéfacts versionnés.

Les exigences définissent ce que la fonctionnalité doit accomplir à l’aide de récits utilisateurs, de comportements attendus et de critères d’acceptation. Le design décrit son fonctionnement technique, notamment l’architecture, les interfaces, les flux de données et les éléments à prendre en compte pendant l’implémentation. Les tâches transforment ensuite ce design en une série d’étapes concrètes que Kiro peut exécuter individuellement sous la supervision d’un développeur.

Le développeur reste impliqué tout au long du processus. Les exigences peuvent être précisées avant de passer au design. Les choix d’architecture peuvent être remis en question avant d’être traduits en code. Les tâches peuvent être modifiées, réorganisées ou confiées à l’agent de façon sélective.

La relation avec l’agent change alors complètement. Le code n’arrive plus avant le raisonnement.

La spécification demeure également dans le dépôt, à côté de l’implémentation. Elle conserve une trace de ce que l’équipe voulait construire, de la manière dont la fonctionnalité devait fonctionner et des étapes suivies pour la réaliser.

Cette trace devient particulièrement utile lorsqu’un autre développeur révise la fonctionnalité, y revient plusieurs mois plus tard ou doit expliquer une décision d’architecture.

La spécification n’est donc pas une documentation reconstruite une fois le travail terminé. Elle sert de contrat de travail pendant toute l’implémentation.

Intégrer les contrôles de qualité au travail quotidien

La plupart des équipes disposent déjà de linters, de tests, d’analyses de sécurité et de normes de revue de code. La difficulté tient souvent au moment où ces contrôles sont appliqués.

Les Agent Hooks de Kiro peuvent déclencher un prompt destiné à l’agent ou une commande shell lorsqu’un événement précis survient. Ils peuvent notamment s’exécuter lorsqu’un fichier est enregistré, créé ou supprimé, lorsqu’un prompt est envoyé, lorsqu’un tour de l’agent se termine ou avant et après l’exécution d’une tâche liée à une spécification.

Un hook peut lancer un linter après l’enregistrement d’un fichier TypeScript. Il peut exécuter une suite de tests lorsqu’une portion de code est modifiée. Il peut analyser les fichiers touchés afin de repérer des identifiants, des secrets ou d’autres problèmes de sécurité avant que le travail se poursuive.

Il peut aussi mettre à jour la documentation ou appliquer une étape de validation propre au projet, sans dépendre de la mémoire du développeur.

Les outils de gestion du code source de Kiro peuvent également proposer un message de commit à partir des changements préparés. Le développeur peut ensuite le réviser et le modifier avant de valider le commit.

Ces automatisations ne remplacent ni les pipelines CI/CD ni la revue par les pairs. Elles permettent simplement d’obtenir une rétroaction plus tôt, au moment où les problèmes sont généralement plus simples à corriger.

Transmettre les standards de l’équipe à l’agent

Dans bien des équipes, les standards de développement ne sont pas tous documentés. Une partie importante du savoir pratique se transmet encore de façon informelle, souvent par les développeurs les plus expérimentés.

Les Steering Files de Kiro fournissent à l’agent un contexte persistant sur le projet. Ils peuvent décrire l’objectif du produit, la pile technologique, la structure du projet, les conventions de nommage, les exigences de sécurité, les pratiques de test, les bibliothèques privilégiées et les contraintes d’architecture.

Kiro peut générer des fichiers de base portant sur le produit, la pile technologique et la structure du projet. L’équipe peut ensuite ajouter ses propres fichiers pour préciser, par exemple, les normes d’API, les modèles d’infrastructure, les règles de gestion des données ou les procédures de déploiement.

Ces instructions peuvent s’appliquer globalement, à l’échelle d’un espace de travail ou seulement à certains types de fichiers et de tâches.

Il devient ainsi inutile de répéter les mêmes consignes dans chaque prompt. Tous les développeurs qui travaillent sur le projet disposent du même cadre de référence.

Un développeur junior et un architecte principal peuvent demander des choses très différentes à Kiro. L’agent, lui, continuera de travailler à partir des mêmes technologies approuvées, des mêmes conventions et des mêmes contraintes.

Ce qui dépendait autrefois de connaissances transmises oralement peut maintenant faire partie intégrante de l’environnement de développement.

Relier l’agent aux véritables systèmes grâce à MCP

Un agent ne peut raisonner qu’à partir du contexte auquel il a accès.

Kiro prend en charge le Model Context Protocol, ou MCP, qui lui permet de se connecter à des outils externes, à de la documentation, à des API, à des bases de données et à d’autres services.

Au lieu de dépendre uniquement des connaissances du modèle, Kiro peut aller chercher de l’information dans les systèmes réellement utilisés par l’équipe.

Il peut, par exemple, consulter la version actuelle d’une documentation d’API, examiner le schéma d’une base de données, récupérer de l’information dans une plateforme interne ou utiliser un outil spécialisé pour valider du code d’infrastructure.

Pour le développement sur AWS, les serveurs MCP officiels peuvent fournir un accès à la documentation AWS, à des recommandations en matière d’infrastructure as code, à la validation de modèles CloudFormation, à des exemples CDK, à des outils de dépannage de déploiement et à de l’information sur la tarification AWS.

AWS Labs offre également des options d’installation simplifiée pour Kiro et d’autres environnements de développement compatibles.

Les Kiro Powers regroupent des outils MCP, des instructions de pilotage et, lorsque cela est pertinent, des hooks. Les Powers utiles sont chargés en fonction de la tâche plutôt que d’ajouter tous les outils disponibles au contexte de l’agent.

Ces accès doivent évidemment être encadrés. Les serveurs MCP peuvent interagir avec des systèmes sensibles, des identifiants et du code source. Les équipes doivent donc utiliser des serveurs de confiance, limiter les autorisations au strict nécessaire et vérifier ce que chaque intégration peut consulter ou modifier.

Kiro offre également des contrôles d’entreprise permettant de limiter l’utilisation de MCP à une liste de serveurs approuvés.

L’objectif n’est pas de donner carte blanche à l’agent. Il s’agit de lui fournir le bon contexte par l’intermédiaire de connexions contrôlées et vérifiables.

Un environnement bien adapté au développement sur AWS

Kiro repose sur Amazon Bedrock et utilise plusieurs modèles de fondation selon les tâches de développement à accomplir.

Les organisations peuvent gérer les accès à l’aide d’AWS IAM Identity Center. Les développeurs individuels peuvent également utiliser les méthodes de connexion personnelle prises en charge.

Pour une équipe spécialisée dans AWS comme Unicorne, l’avantage est concret : Kiro peut travailler à proximité des services et des outils de livraison déjà utilisés dans nos projets.

Selon la charge de travail, il peut notamment générer ou modifier du code AWS CDK, développer des fonctions Lambda, travailler avec des services conteneurisés sur Amazon ECS, valider des modèles CloudFormation ou consulter la documentation AWS actuelle grâce à MCP.

Les développeurs peuvent réviser les modifications proposées, approuver l’utilisation des outils et conserver le contrôle sur ce qui sera réellement déployé.

On obtient ainsi un parcours plus cohérent entre l’architecture et l’implémentation.

La spécification définit ce qui doit être construit. Les Steering Files précisent la façon dont l’équipe souhaite le construire. MCP donne accès au contexte technique nécessaire. Les hooks vérifient le travail au fur et à mesure.

La place de Kiro dans le cycle AI-DLC d’Unicorne

Chez Unicorne, Kiro n’est pas un simple outil de productivité utilisé en parallèle. Il s’intègre à notre AI Development Life Cycle, ou AI-DLC, qui structure nos mandats autour de trois phases : Inception, Construction et Operation.

Pendant la phase d’Inception, nous définissons l’objectif d’affaires, les besoins des utilisateurs, les limites techniques, les considérations de sécurité et les mesures de succès.

Le but est de confirmer que l’équipe s’attaque au bon problème avant de commencer l’implémentation.

Kiro est particulièrement utile pendant la phase de Construction. Une fois l’intention validée, les exigences approuvées peuvent être transformées en designs techniques et en tâches d’implémentation.

Les agents peuvent contribuer à la production du code applicatif et du code d’infrastructure pendant que les développeurs révisent les décisions, testent les comportements et tranchent les compromis techniques. Des contrôles automatisés veillent au respect des normes de programmation, de test et de sécurité tout au long du travail.

Pendant la phase d’Operation, ce même contexte structuré facilite la maintenance, le dépannage et les améliorations futures.

L’équipe ne dispose pas seulement d’un ensemble de fichiers sources. Elle conserve aussi les exigences, les choix de design et le plan d’implémentation qui ont mené au résultat.

Le développement piloté par les spécifications fait donc le lien entre l’intention définie pendant l’Inception et le logiciel livré pendant la Construction.

Le principe est simple : les humains définissent l’intention, les contraintes et les compromis. Les agents exécutent des tâches bien délimitées et accélèrent les boucles de rétroaction.

La vitesse ne suffit pas

Le principal risque associé au code généré par l’IA n’est pas une mauvaise syntaxe. C’est généralement l’un des problèmes les plus faciles à détecter.

Le risque plus important est de produire un logiciel qui fonctionne aujourd’hui, mais dont personne ne pourra réellement expliquer la construction plus tard.

Lorsqu’une équipe ne peut pas relier une exigence à une décision de design, à une tâche d’implémentation et au code qui en découle, la revue devient plus difficile et la maintenance plus coûteuse.

Kiro n’élimine pas ce risque à lui seul. Une mauvaise spécification peut toujours mener à une mauvaise implémentation, et le code généré doit toujours être révisé par des développeurs expérimentés.

Kiro fournit toutefois une meilleure structure pour effectuer cette revue.

Il rend les hypothèses visibles avant qu’elles se répandent dans la base de code. Il donne aux développeurs des moments précis pour remettre en question les exigences et l’architecture. Il préserve aussi un lien plus clair entre ce que l’entreprise a demandé et ce que l’équipe de développement a finalement livré.

Passer du prototype à la production sans perdre le raisonnement

L’IA a déjà changé la vitesse à laquelle les équipes peuvent produire du logiciel. Le prochain défi consiste à profiter de cette rapidité sans perdre le contrôle de la qualité, de la sécurité et de la maintenabilité.

En plaçant les spécifications au centre du processus, Kiro donne au développement agentique une structure adaptée au travail de production.

C’est là que réside sa valeur pour Unicorne. Kiro nous aide à accélérer le développement sur AWS tout en maintenant un lien clair entre l’intention, l’architecture et l’implémentation, de la première exigence jusqu’à la solution déployée.

Foire aux questions

Kiro convient-il mieux aux nouveaux projets ou aux applications existantes?

Kiro peut être utilisé dans les deux cas, mais la façon de l’intégrer diffère.

Dans un nouveau projet, l’équipe peut définir les exigences, l’architecture et les standards de développement avant que la base de code prenne de l’ampleur. Les spécifications peuvent ainsi servir de fondation au projet dès le départ.

Pour une application existante, Kiro doit d’abord disposer d’assez de contexte pour intervenir sans compromettre ce qui est déjà en place. Les Steering Files peuvent documenter l’architecture, les conventions et les contraintes de la base de code. La première spécification devrait quant à elle porter sur une fonctionnalité ou une modification bien délimitée, plutôt que de tenter de couvrir l’ensemble de l’application.

Il est généralement plus réaliste d’introduire Kiro graduellement que d’essayer de restructurer en une seule fois plusieurs années de développement.

Quand une équipe devrait-elle créer une spécification plutôt que d’utiliser un simple prompt?

Un simple prompt peut suffire pour une tâche ciblée, comme expliquer une fonction, corriger une erreur mineure ou générer un test de base.

Une spécification devient plus utile lorsque le travail touche plusieurs fichiers, services ou équipes, ou lorsqu’il implique des décisions d’architecture, de sécurité ou d’affaires qui devront rester compréhensibles une fois le code écrit.

Une bonne façon de trancher consiste à se demander combien d’explications seraient nécessaires pendant la revue de code. Si la personne qui révise doit comprendre non seulement ce qui a changé, mais aussi pourquoi la solution a été conçue de cette façon, le travail mérite probablement une spécification.

Quel niveau de détail une spécification Kiro devrait-elle contenir?

Une spécification doit fournir assez d’information pour éliminer les ambiguïtés importantes, sans chercher à dicter chaque ligne de code.

Elle devrait préciser le comportement attendu, le principal besoin de l’utilisateur ou de l’entreprise, les contraintes techniques pertinentes, les interfaces importantes ainsi que les critères qui permettront de déterminer si le travail est terminé.

Le design devrait également faire ressortir les décisions susceptibles d’avoir une incidence sur la sécurité, l’évolutivité, la gestion des données ou l’intégration avec d’autres systèmes.

L’objectif n’est pas de produire un document parfait avant de commencer le développement. La spécification est un artéfact de travail que les développeurs peuvent réviser et préciser à mesure que les hypothèses sont validées et que de nouveaux renseignements deviennent disponibles.

Comment éviter qu’une mauvaise spécification produise plus rapidement le mauvais code?

La spécification devrait être révisée avec autant de rigueur que le code qui en découle.

Avant de commencer l’implémentation, les développeurs doivent vérifier que les exigences sont suffisamment complètes, remettre en question les hypothèses du design proposé et confirmer que les critères d’acceptation peuvent réellement être testés.

Le fait de diviser l’implémentation en petites tâches permet également de valider régulièrement que le travail avance toujours dans la bonne direction.

Les tests automatisés, les linters, les contrôles de sécurité et les Agent Hooks peuvent détecter des problèmes techniques. Ils ne peuvent toutefois pas déterminer si l’équipe a mal compris le besoin d’affaires. Cette validation repose encore sur le jugement humain.

Kiro peut accélérer l’exécution, mais il ne dispense pas l’équipe de vérifier ce qu’elle lui demande d’exécuter.

Comment intégrer Kiro à un processus de développement et de revue de code déjà établi?

Une équipe n’a pas besoin d’abandonner ses pratiques actuelles pour utiliser Kiro.

Une approche concrète consiste à commencer par une fonctionnalité ou un chantier bien défini, tout en conservant la structure du dépôt, la stratégie de branches, les demandes de fusion, la revue par les pairs et les pipelines CI/CD déjà en place.

Les artéfacts de spécification peuvent être conservés dans le dépôt, à côté du code. Les Steering Files servent alors à consigner les standards que l’agent doit respecter.

Les développeurs peuvent ensuite comparer cette façon de travailler à leur processus habituel et ajuster l’utilisation des spécifications, des tâches et des contrôles automatisés en fonction des résultats.

Kiro peut ainsi être évalué à l’intérieur des mécanismes de contrôle existants, plutôt que d’être traité comme un outil destiné à les remplacer.

Comment mesurer la valeur réelle d’un IDE agentique?

Le nombre de lignes de code générées n’est pas un indicateur de réussite particulièrement utile.

Une équipe devrait plutôt vérifier si Kiro réduit le temps nécessaire pour passer d’une exigence approuvée à une implémentation révisée.

D’autres indicateurs peuvent être suivis, notamment la quantité de travail à reprendre, le temps consacré à clarifier les exigences pendant le développement, le nombre de problèmes relevés pendant la revue ainsi que l’effort nécessaire pour qu’un autre développeur comprenne ou maintienne la fonctionnalité.

L’organisation peut aussi évaluer si les spécifications améliorent la traçabilité des décisions et facilitent l’intégration d’un développeur qui connaît moins bien une partie de la base de code.

L’approche la plus fiable consiste à commencer par un projet pilote limité, à établir un point de comparaison à partir de travaux similaires réalisés auparavant, puis à comparer les résultats.

Le but n’est pas seulement de produire du code plus rapidement. Il est de raccourcir les délais de livraison sans augmenter le nombre de défauts, l’effort de revue ou les coûts de maintenance.