Pour les équipes déjà outillées
« On a déjà Agent HQ, Kiro, Cursor. » Bonne nouvelle.
Ces outils font très bien ce qu'ils font, et Survol ne fait rien de ce qu'ils font. Cette page dit exactement ce qu'il ajoute - et à quoi vous reconnaîtrez que vous n'en avez pas besoin.
Ils gouvernent l'agent. Nous gouvernons le produit.
Un orchestrateur sait quel agent a le droit de toucher quel dépôt, avec quel budget, sur quelle branche. Aucun ne sait ce que fait votre application, dans quelle version, pour quel objectif, et si ça a marché.
Une réponse d'une minute par outil
Ce qu'ils font, ce qui reste ouvert
« On a GitHub Agent HQ. »Mission control multi-agents, permissions par branche, gouvernance d'entreprise.
Agent HQ orchestre des agents sur des dépôts : qui lance quoi, où, avec quelles permissions. C'est excellent, et Survol ne le refait pas. Ce qu'il ne porte pas : la notion de fonctionnalité, son cycle de vie jusqu'à la production, la version écrite à la main par un humain, les décisions produit tracées, et ce qu'une livraison a coûté rapporté à ce qu'elle devait produire. Son centre de gravité est le dépôt - le dépôt dit comment c'est fait, pas ce que c'est.
✅ Vous gardez Agent HQ. Survol s'installe au-dessus : il décrit le produit, Agent HQ exécute.
« On fait du spec-driven avec Kiro / Spec Kit. »Exigences, conception et tâches écrites avant le code, versionnées dans le dépôt.
C'est la bonne pratique, et nous ne cherchons pas à vous en détourner - le débat sur « faut-il partir d'une spécification » est gagné, et pas par nous. La limite est ailleurs : ces spécifications sont des fichiers dans une branche. Elles décrivent une intention à un instant donné, une fonctionnalité à la fois, sans statut, sans historique de version fonctionnelle, sans décision votée, sans coût, et sans personne pour les relire trois mois plus tard. Demandez à votre équipe ce que fait exactement l'application aujourd'hui : la réponse ne se trouve pas dans ces fichiers.
✅ Vous gardez vos specs. Survol leur donne une durée de vie, un statut et un propriétaire.
« Cursor Organizations nous suffit pour le budget. »Consolidation de la dépense, budgets par équipe, alertes de seuil.
Pour piloter une dépense, oui, franchement. Ces outils vous disent combien a été consommé, par qui, sur quel modèle, dans quelle équipe. Ils ne peuvent pas vous dire pour livrer quoi - parce qu'ils ne savent pas ce qu'est une fonctionnalité de votre produit. La question du dirigeant n'est pas « combien avons-nous dépensé » : c'est « qu'est-ce que ça a produit, et sur quoi avons-nous dépensé pour rien ». C'est une question de gouvernance produit, pas de FinOps.
✅ Vous gardez vos plafonds. Survol ajoute le dénominateur qui manque au chiffre.
« On a Jira, et on peut déjà assigner un ticket à un agent. »Agents in Jira, Rovo Dev, Linear + Cursor.
Le pont est réel et il progresse vite. Mais un ticket décrit du travail, pas un produit : il naît, il est fermé, il disparaît. Il ne porte pas de version fonctionnelle, pas de cycle de vie jusqu'à la production, pas de coût rattaché, et il ne dit rien de ce que la fonctionnalité est devenue. Fermer un ticket ne prouve rien ; une version en production qui a tenu sa promesse, si.
✅ Vous gardez Jira. Vos équipes n'en changeront pas, et nous ne vous le demanderons pas.
« Et si GitHub ou l'éditeur de notre agent sort la même chose ? »La question honnête, celle qu'on se pose aussi.
Ils le sortiraient pour leur propre écosystème - or une entreprise qui a deux dépôts et deux agents ne peut pas être gouvernée par l'un de ses fournisseurs. Et surtout : leur intérêt économique est que vous consommiez plus. Le nôtre est que vous consommiez moins, puisque nous ne prenons aucune marge sur l'IA. Ces deux produits ne peuvent pas être écrits par la même entreprise. Si ça arrive quand même, cela validera au moins que le problème était réel.
✅ Ce qui reste à vous : spécifications, objectifs, décisions, historique. Cet actif survit au changement d'agent, de modèle ou de fournisseur.
Le partage, ligne par ligne
Ce que chacun couvre
Un tableau ne convainc personne - c'est la démonstration qui convainc. Celui-ci sert seulement à vérifier qu'on parle bien de la même chose.
| Capacité | Orchestrateurs Agent HQ, Devin, Factory | IDE à spécification Kiro, Spec Kit | Suivi de projet Jira, Linear | Survol |
|---|---|---|---|---|
| Orchestrer plusieurs agents | ✓ | partiel | partiel | ✓ |
| Spécification préalable structurée | partiel | ✓ | partiel | ✓ |
| Spécification vivante, hors du dépôt, versionnée | ✗ | ✗ | partiel | ✓ |
| Arbre de fonctionnalités + cycle de vie produit | ✗ | ✗ | ✗ | ✓ |
| Version manuelle et version d'agent, même cycle | ✗ | ✗ | ✗ | ✓ |
| Objectifs, promesses et verdicts | ✗ | ✗ | ✗ | ✓ |
| Coût rattaché à une fonctionnalité livrée | ✗ | ✗ | ✗ | ✓ |
| Quotas et suivi de dépense IA | ✓ | ✓ | ✗ | ✓ |
| Environnements et gates de promotion | ✗ | ✗ | ✗ | ✓ |
| Utilisable par quelqu'un qui n'ouvre pas d'éditeur | ✗ | ✗ | ✓ | ✓ |
| Indépendance vis-à-vis du fournisseur | ✗ | variable | partiel | ✓ |
Honnêtement
Trois cas où Survol ne vous servira à rien
Un éditeur qui prétend servir à tout le monde ne sert à personne. Voici les situations où nous vous conseillons de ne pas nous appeler.
Vous développez seul
Sans équipe, la carte du produit tient dans votre tête et elle est à jour. Survol résout un problème de mémoire collective - vous n'en avez pas.
Vous livrez un projet, pas un produit
Une prestation qu'on livre et qu'on ne reprendra plus n'a pas de cycle de vie à gouverner. Votre outil de suivi suffit.
Personne ne relira jamais un verdict
Si votre direction ne demandera jamais ce que l'IA a produit, la moitié de la valeur de Survol ne sera jamais consommée. Attendez que la question se pose.
La seule démonstration qui compte
Ouvrez votre dépôt et demandez à votre équipe : « qu'est-ce que fait notre produit aujourd'hui, dans quelle version, et qu'est-ce que la dernière fonctionnalité livrée a rapporté ? » Si la réponse arrive en trente secondes, vous n'avez pas besoin de nous.