face aux tickets
Les tickets supposent que la réflexion est terminée
Linear et Jira ont été conçus pour orchestrer le travail entre humains. Le ticket dit à l'équipe quoi faire ; la spec permet de savoir que c'est la bonne chose à faire.
La vitesse est acquise. L'alignement, non.
Quand une équipe n'est pas alignée sur le périmètre, les priorités et les décisions, les agents de code n'y changent rien. Ils construisent la mauvaise chose, plus vite. Ajouter des fonctions IA aux tickets et aux documents ne suffira pas non plus : c'est le cycle de développement logiciel lui-même qu'il faut réinventer autour des agents. Kairo est conçu pour ce nouveau cycle.
Le seul produit dont l'objet central est la spec
Collaborative, ancrée dans la codebase, exécutable par les agents. Cette seule phrase distingue Kairo de ses trois voisins.
face aux documents
Les PRD figent un instant, puis dérivent
Un document est une prose statique qui ignore tout de votre codebase. Trois semaines après sa rédaction, un PRD ne correspond plus à ce qui se construit.
face aux fichiers de spec pour agents
Les fichiers pour agents s'écrivent entre développeurs
Fichiers d'instructions et modes plan sont écrits par des développeurs, pour des agents. Décider quoi construire implique des personnes qui n'ouvriront jamais un terminal.
Une seule source de vérité
Tous vos requirements, au même endroit
La fragmentation ne se compte pas en outils. Elle se compte en endroits où la vérité sur un requirement peut diverger. Aujourd'hui, la vérité d'une seule fonctionnalité s'étale sur un brouillon Notion, une epic Jira, quatre fils Slack et deux réunions. Dans Kairo, chaque change request a un seul document de requirements, et ce document est l'unique source de vérité, pour votre équipe comme pour vos agents.
Kairo face aux documents et aux tickets
| Critère | Docs et tickets aujourd'hui | L'approche Kairo |
|---|---|---|
| Unité de travail | Une prose statique et des tickets atomisés | Une spécification vivante, prête à exécuter |
| Connaissance de la codebase | Aucune : la vérité s'éloigne du dépôt | Ancrée dans le code réel, ses patterns et ses contraintes |
| Ambiguïté | Découverte en cours d'implémentation | Levée dans un dialogue mené par l'IA, avant la rédaction du document |
| Source de vérité | Éparpillée entre documents, tickets et fils de discussion | Un seul document de requirements, pour l'équipe et ses agents |
| Handoff aux agents | Des requirements collés à la main dans des prompts | Des specs servies à n'importe quel agent de code via MCP |
| Mode de travail | Séquentiel : écrire, puis traduire, puis clarifier | Multijoueur : produit, design et engineering dans une même spec |
Questions
Ce que les équipes nous demandent
À qui s'adresse Kairo ?
Aux équipes logicielles en pointe sur l'IA, typiquement de 5 à 50 personnes entre produit et engineering, où les agents de code accélèrent déjà l'implémentation et où définir la bonne chose à construire est devenu le goulot d'étranglement.
Où se situe Kairo par rapport aux outils que nous utilisons déjà ?
Notion et Confluence documentent le projet, de façon statique. Jira et Linear découpent le travail en tâches. Entre les deux, là où se décident réellement le quoi, le pourquoi et le comment, il n'y a souvent que des réunions, des commentaires et des fils Slack. Kairo est conçu pour cette couche, et il fonctionne de façon autonome : pas besoin d'un outil de tickets ou de documents à côté pour l'utiliser.
Kairo remplace-t-il Jira ou Linear ?
Il le peut. Kairo gère tout le flux à lui seul : les change requests avancent sur son tableau de Defining à Ready, Building puis Done, les agents lisent les specs via MCP, et des tâches légères couvrent ce qui reste aux humains. Les équipes pleinement agentiques constatent souvent qu'elles n'ont plus besoin d'un outil de tickets séparé. Rien n'oblige pour autant à tout remplacer dès le premier jour : vous pouvez garder Jira ou Linear aussi longtemps que cela vous est utile.
Nous avons construit notre propre système de specs dans Notion, avec des templates et des bases de données.
Alors vous ressentez déjà le problème que Kairo résout. Mais un template ne lève pas les ambiguïtés avant le handoff, et une base de données ne lit pas votre dépôt. Vous avez construit le process ; Kairo est le produit vers lequel il tend. Vous pouvez importer vos PRD existants comme contexte dès le premier jour.
Peut-on adapter l'IA de Kairo à notre façon de travailler ?
Oui. Kairo fournit des skills prédéfinis pour le travail récurrent, par exemple définir une change request, la planifier ou vérifier une implémentation au regard de ses critères d'acceptation. Vous pouvez aussi créer vos propres skills et assistants IA, et générer les documents de requirements à partir de votre propre template.
Avec quels agents de code Kairo fonctionne-t-il ?
Avec tout agent qui parle MCP. Le serveur MCP de Kairo expose la définition, le plan et les documents liés de chaque change request : Claude Code, Copilot, Codex, Cursor ou tout autre client MCP peuvent les lire directement.
À quoi Kairo se connecte-t-il ?
À GitHub et GitLab pour les dépôts, fichiers, branches, pull requests et issues. À Figma pour le contexte design, et à Slack pour le contexte des conversations qui s'y sont déjà tenues. Vous pouvez aussi importer vos documents existants, et les connecteurs Confluence, SharePoint, Notion et Microsoft Teams arrivent bientôt. Dans l'autre sens, le serveur MCP de Kairo donne aux agents de code externes l'accès à vos specs.
Où Kairo est-il hébergé, et que deviennent nos données ?
Kairo est conçu et hébergé en Europe, avec un traitement des données conforme au RGPD. Vos données ne servent jamais à entraîner un modèle d'IA, ni le nôtre ni celui d'un tiers. Les intégrations passent par OAuth sécurisé et des comptes de service, et humains comme assistants IA n'accèdent qu'aux projets dont ils sont membres.
Faites passer votre prochaine fonctionnalité par le workflow Kairo
Rejoignez le pilote et mesurez la différence entre un ticket et une spec qui connaît votre codebase.