Singularity vs Kiro : specs pilotées par l’IA ou tickets Kanban ?

Kiro est l’environnement de développement agentique construit et exploité par AWS. Il s’est fait connaître par son approche spec-driven : avant d’écrire du code, l’agent rédige exigences, conception et liste de tâches que vous validez. Kiro existe aujourd’hui en IDE, en CLI, sur le Web avec un mode autonome, sur mobile en préversion et sous la forme de Kiro Crew.

Singularity encadre lui aussi le travail des agents, mais par un autre objet : le ticket sur un board Kanban, exécuté dans un worktree Git puis relu avant intégration. La décision porte donc sur l’endroit où vit la structure (specs Markdown ou tickets avec dépendances), sur le lieu d’exécution (votre poste ou un sandbox cloud) et sur le modèle économique (crédits Kiro ou vos propres abonnements aux fournisseurs).

Comparatif vérifié le 10 octobre 2026 à partir de la documentation officielle de Kiro et de celle de Singularity. Il compare des workflows, sans benchmark de vitesse ni de qualité du code généré. Tarifs publics en USD/EUR tels qu’affichés, hors taxes et consommation ; ils peuvent évoluer.

En bref

• Kiro structure une demande en trois documents (exigences, conception, tâches), enrichis par des fichiers de steering et des hooks, puis exécute les tâches indépendantes en parallèle.
• Singularity structure le travail en tickets sur un board : chaque exécution reçoit son worktree, rend compte de son activité et passe par un onglet Revue avant l’intégration par rebase.
• Kiro exécute son agent en local (IDE, CLI) ou dans un sandbox cloud (Web, sessions cloud) qui ouvre des pull requests ; Singularity lance les CLI des fournisseurs sur votre poste.
• Kiro facture des crédits, de 0 $ (50 crédits) à 200 $ par mois ; Singularity est gratuit, n’inclut aucun modèle et propose une licence à 24 € par mois et par poste pour ses plugins payants.

Présentation de Kiro

Selon sa page d’accueil, Kiro est « Built and operated by AWS », sans qu’un compte AWS soit nécessaire. D’après la FAQ, l’IDE est basé sur Code OSS et la connexion passe par GitHub, Google, AWS Builder ID ou IAM Identity Center ; les extensions viennent du registre Open VSX (migration depuis VS Code). L’IDE 1.0 a ajouté un système de permissions, des hooks structurés et un mode expérimental Agent Focus avec sessions parallèles (nouveautés de la 1.0).

Un seul harness d’agent alimente l’IDE, le CLI, le Web et le mobile via le protocole ouvert ACP (comment Kiro fonctionne). Il tourne en local dans l’IDE et le CLI, et dans un sandbox cloud pour le Web, le mobile et les sessions cloud, jusqu’à dix en parallèle, qui renvoient leurs changements en pull ou merge request.

Les specs produisent requirements.md (ou bugfix.md), design.md et tasks.md ; les exigences utilisent la notation EARS (feature specs), et les tâches indépendantes s’exécutent par vagues concurrentes. Le steering apporte un contexte durable (product.md, tech.md, structure.md, AGENTS.md) et les hooks déclenchent une commande ou un prompt sur des événements comme l’enregistrement d’un fichier. Sur le Web, le mode autonome planifie, délègue à des sous-agents et ouvre des pull requests. S’y ajoutent les Powers, paquets de skills et de configurations MCP, et Kiro Crew, un agent personnel open source.

Singularity en quelques mots

Singularity est un ADE (Agentic Development Environment) de bureau édité par Meteor Factory : un éditeur avec serveurs de langage, un terminal natif, un client Git (graphe, diffs, remises, worktrees), des espaces de travail multi-projets et un board Kanban qui sert de surface d’exécution aux agents. Un ticket porte la description, la priorité, les dépendances et la configuration de l’agent ; il conserve ensuite le compte rendu, les blocages et une résolution courte. Avec les worktrees activés, chaque exécution travaille dans sa propre copie Git, puis ses commits reviennent sur la branche de base par rebase, automatiquement ou après la revue. L’orchestration pilote les CLI de sept fournisseurs (Claude Code, Codex, Copilot, Cursor, Gemini, Mistral, Ollama) avec vos propres comptes. L’application est gratuite ; la licence ne débloque que les plugins payants du Marketplace, comme Pipelines.

Tableau comparatif

Spec ou ticket : deux façons de cadrer une demande

La spec Kiro est un document de conception versionné avec le code. Elle oblige à expliciter comportement attendu, architecture et découpage avant l’implémentation : pour une fonctionnalité floue, vous relisez des exigences plutôt qu’un long diff. Une « Quick Spec » sans étapes d’approbation existe pour les demandes déjà claires.

Le ticket Singularity est une unité d’exécution. Sa description sert de cahier des charges, mais sa force tient à ce qui l’entoure : priorité, type, dépendances, sous-tickets, planification récurrente, choix du fournisseur et du modèle, compte rendu. Singularity n’impose pas de format de spécification : à vous d’écrire une description précise. Notre exemple de ticket complet et vérifiable fournit un modèle copiable avec critères observables et commandes de vérification, sans imposer la syntaxe des specs Kiro.

Une même fonctionnalité dans les deux outils

Prenons une demande courante : ajouter un export CSV des factures, avec un endpoint côté API et un bouton côté interface.

Avec Kiro

Vous lancez une spec de fonctionnalité. Kiro rédige les exigences (« quand l’utilisateur clique sur Exporter, le système doit produire un CSV des factures filtrées »), la conception et une liste de tâches. Vous ajustez chaque document, puis lancez toutes les tâches : les indépendantes démarrent ensemble, les autres suivent par vagues. Un hook peut lancer le linter à chaque enregistrement. Dans l’IDE, vous relisez les diffs et pouvez revenir à un checkpoint ; sur le Web, l’agent ouvre une pull request que vous commentez.

Avec Singularity

Vous créez deux tickets, « Endpoint d’export CSV » et « Bouton d’export », le second bloqué par le premier. Le planificateur lance le ticket API ; l’agent travaille dans son worktree, publie sa phase sur la carte et termine par un compte rendu. Si la fusion automatique est désactivée, le résultat attend dans l’onglet Revue : vous approuvez fichier par fichier, annotez ou renvoyez l’exécution avec vos remarques. Après le rebase, le ticket UI démarre sur une base qui contient l’endpoint.

Kiro fait valider la réflexion en amont ; Singularity fait valider le résultat en aval. Dans les deux cas, les tests restent indispensables.

Local, cloud et parallélisme

Kiro couvre les deux mondes : en local, l’IDE et le CLI utilisent votre shell et votre chaîne d’outils ; en cloud, le même harness tourne dans un sandbox isolé, sans téléverser votre copie locale, et continue quand vous fermez votre ordinateur. Le parallélisme passe par les vagues de tâches, les sous-agents, le mode Agent Focus et les sessions cloud.

Singularity reste local : chaque agent tourne sur votre poste dans son worktree, le nombre d’agents simultanés est réglable et le planificateur respecte priorités et dépendances. Une exécution interrompue par la fermeture de l’application est rattachée ou placée dans un état explicite au redémarrage. Pas d’exécution cloud intégrée, mais un contrôle direct de l’environnement et des outils locaux.

Git, pull requests et intégration

Dans l’IDE, Kiro affiche les diffs de l’agent et des checkpoints pour revenir en arrière. Côté cloud, l’agent crée une branche, commite, ouvre une pull ou merge request sur GitHub ou GitLab, puis répond aux commentaires avec /kiro all ou /kiro fix (travailler avec l’agent web). La revue se fait là où l’équipe relit déjà le code.

Singularity intègre en local, sans forge : l’onglet Revue permet d’approuver chaque fichier, d’éditer dans le worktree, de fusionner seulement les fichiers approuvés ou de relancer avec le retour. L’intégration se fait par rebase, et une file de commits sérialise les intégrations concurrentes d’un projet. Les tests restent nécessaires après un rebase : deux tickets peuvent introduire des règles incompatibles sans conflit Git.

Modèles, crédits et structure de coût

Kiro facture l’usage en crédits partagés entre IDE, CLI et Web (tarifs) : Free à 0 $ avec 50 crédits, Pro à 20 $ (1 000 crédits), Pro+ à 40 $ (2 000), Pro Max à 100 $ (5 000) et Power à 200 $ (10 000) par utilisateur et par mois, plus 0,04 $ par crédit supplémentaire ; Enterprise est sur devis. La liste des modèles associe à chacun un multiplicateur de crédits : routeur Auto, Claude Sonnet et Opus, GPT expérimentaux et modèles open weight moins coûteux.

Singularity sépare l’outil et l’inférence : l’application est gratuite, sans limite d’agents, de projets ni de worktrees, et la licence à 24 € par mois et par poste (14 jours d’essai) ne concerne que les plugins payants. Le coût des modèles dépend des abonnements que vous avez déjà chez chaque fournisseur : pas de second compteur de consommation.

Données et confidentialité

D’après la page protection des données, le contenu des utilisateurs gratuits et des abonnés individuels peut servir à améliorer le service, sauf désactivation dans les réglages, et il est stocké dans la région AWS US East (Virginie du Nord) ; en Enterprise, il n’est pas utilisé à cette fin.

Singularity ne téléverse pas votre code de lui-même : seuls les CLI configurés communiquent avec leurs services, selon leurs politiques. Avec Ollama en local, l’inférence reste sur le poste ; les données de l’application vivent dans une base SQLite locale.

Où Kiro est plus fort

• Méthode de spécification : exigences EARS, conception et tâches versionnées, avec un flux dédié aux corrections de bugs.
• Exécution cloud : sessions dans un sandbox géré, qui continuent sans votre machine et reviennent en pull request.
• Automatisation par événements : hooks sur l’enregistrement de fichiers ou l’appel d’outils, steering conditionnel par motif de fichier.
• Écosystème : extensions Open VSX, Powers de partenaires, ACP pour utiliser Kiro depuis JetBrains ou Zed.
• Cadre entreprise AWS : IAM Identity Center, régions, GovCloud et facturation via AWS.

Où Singularity se distingue

• Un board pour tout le travail : tickets de natures différentes, priorités, dépendances, sous-tickets et planification récurrente sur une seule vue.
• Isolation par exécution : chaque agent travaille dans son worktree local, sans toucher à vos fichiers non commités.
• Intégration encadrée en local : revue fichier par fichier, fusion partielle, rebase linéaire et file de commits, sans dépendre d’une forge.
• Choix du fournisseur : sept fournisseurs, dont des modèles locaux via Ollama, avec vos comptes existants et sans crédits intermédiaires.
• Application gratuite : toutes les fonctions sans abonnement ; seule l’extension par plugins payants est facturée.

Peut-on utiliser les deux ?

Oui, sur le même dépôt. Les specs Kiro sont des fichiers Markdown : vous pouvez rédiger la spec dans Kiro, puis créer des tickets Singularity qui renvoient à tasks.md pour que Claude Code, Codex ou Copilot les exécutent dans des worktrees, que l’IDE Kiro peut aussi ouvrir.

Deux limites : Singularity ne pilote pas Kiro comme fournisseur, et les hooks Kiro ne s’exécutent que lorsque c’est le harness de Kiro qui travaille ; les hooks Git du dépôt, eux, s’appliquent des deux côtés. Voir aussi Singularity vs Antigravity et, pour la délégation dans le cloud, Singularity vs Devin.

Quel outil choisir ?

• Équipe qui veut formaliser les exigences avant de coder : Kiro, pour ses specs et son flux exigences, conception, tâches.
• Organisation déjà outillée par AWS : Kiro, pour l’identité, la facturation et la gouvernance AWS.
• Personne qui veut lancer des tâches depuis son téléphone ou laisser tourner un agent la nuit dans le cloud : Kiro Web et ses sessions cloud.
• Petite équipe qui gère un backlog varié : Singularity, pour le board, les dépendances et la revue avant intégration.
• Développeur déjà abonné à Claude, ChatGPT ou Copilot, ou qui veut des modèles locaux : Singularity, qui réutilise ces comptes ou Ollama.

Protocole d’essai

1. Choisissez une fonctionnalité réelle qui touche une API et une interface, avec des critères d’acceptation écrits.
2. Dans Kiro, créez une spec, relisez les trois documents, lancez toutes les tâches et notez le temps passé à corriger la spec puis le code.
3. Dans Singularity, découpez la même demande en deux tickets dépendants, désactivez la fusion automatique et relisez chaque exécution dans l’onglet Revue.
4. Exécutez la même suite de tests sur les deux résultats et comparez l’historique Git produit.
5. Relevez les crédits Kiro consommés et la consommation chez le fournisseur utilisé par Singularity.

Questions fréquentes

Faut-il un compte AWS pour utiliser Kiro ?

Non. Kiro indique qu’aucun compte AWS n’est nécessaire : la connexion se fait avec GitHub, Google, AWS Builder ID ou, en entreprise, IAM Identity Center.

Singularity sait-il lire une spec Kiro ?

Singularity n’a pas d’intégration dédiée, mais les specs sont des fichiers Markdown du dépôt. Un agent lancé depuis un ticket peut les lire dans son worktree si la description du ticket les cite.

Lequel est le moins cher ?

Cela dépend de votre usage. Singularity est gratuit, mais vous payez vos fournisseurs IA ; Kiro inclut l’inférence dans ses crédits, de 50 crédits gratuits à 10 000 crédits pour 200 $ par mois. Comparez sur une semaine de travail réelle.

Pour aller plus loin, consultez tous les comparatifs Singularity, le guide de démarrage, ou téléchargez Singularity pour tester le board sur votre propre dépôt.