Survol, Cursor, Kiro, Claude Code : deux étages différents

Commençons par le dire franchement : on utilise ces outils tous les jours. Survol lui-même est développé avec un agent de code, dans un éditeur, avec la complétion, le refactoring multi-fichiers et tout ce que cette génération d'outils a apporté. Cursor, Claude Code, Kiro, Copilot, Windsurf : ils ont rendu possible une manière de travailler qui n'existait pas il y a deux ans. Cet article ne cherche pas à les départager, et encore moins à leur trouver des défauts.

Il cherche à répondre à une question de placement. Quand quelqu'un nous demande « en quoi c'est différent de Cursor ? », la question sous-jacente est presque toujours : « est-ce que ça remplace ce que j'ai déjà ? ». La réponse est non. Survol se branche au-dessus.

Un assistant de code répond à « comment j'écris ce code ? ». Survol répond à « qu'est-ce qu'on construit, où en est-on, et qui a décidé quoi ? ».

Deux étages, pas deux camps

La manière la plus simple de se représenter la chose, c'est un empilement. En bas, le modèle. Au-dessus, l'outil qui met le modèle dans votre code. Au-dessus encore, la couche qui pilote le produit et l'équipe.

# L'empilement, tel qu'on le voit

  ← Survol
produit & équipe  spec vivante · décisions · versions · coûts

  ← Cursor, Kiro, Claude Code, Copilot…
code & session    édition · complétion · refactoring · exécution de tâches

  ← substituable
modèle            génération, raisonnement

Cette lecture n'est pas une invention marketing : c'est celle que défend l'Institut Montaigne quand il explique que la dépendance ne se joue pas sur les modèles mais sur la couche d'orchestration. Le modèle est substituable ; l'étage du dessus, beaucoup moins. Voici, concrètement, ce qui change d'un étage à l'autre.

1. L'unité de travail : le fichier ou la fonctionnalité

Dans un éditeur augmenté, l'unité naturelle est le fichier, la sélection, le diff. C'est la bonne granularité pour écrire du code : on veut voir précisément ce qui change.

Dans Survol, l'unité est la fonctionnalité et sa version. « Codes promo v2.0 » est un objet : elle a une spec, un statut dans le cycle de vie, une branche, une demande de fusion, une préview, un coût en tokens, un cahier de tests et un historique de décisions. On ne raisonne pas en lignes modifiées mais en incréments livrables. C'est la granularité à laquelle un product manager, un dirigeant ou un client raisonnent déjà.

2. L'interface : le prompt, la spec de tâche, ou la spec de produit

C'est la nuance la plus intéressante, et celle où il faut être précis - parce que le paysage a bougé vite.

Il y a un an, la comparaison aurait été « prompt contre spec ». Elle ne tient plus : l'industrie entière converge vers le spec-driven development. Kiro en est l'exemple le plus abouti : il produit des documents d'exigences, de conception et de tâches avant d'écrire la moindre ligne. GitHub fait de même avec Spec Kit. Nous ne pouvons que nous en réjouir - c'est notre conviction fondatrice depuis le premier jour.

La différence est ailleurs, et Thoughtworks l'a formulée mieux que nous : la plupart des approches sont spec-first (on écrit une bonne spec pour démarrer une tâche), rarement spec-anchored (la spec survit à la tâche et évolue avec la fonctionnalité). Comme l'écrit Birgitta Böckeler, « ce que doit être la stratégie de maintenance de la spec dans le temps est souvent laissé vague ».

3. Qui s'installe le produit : le développeur ou toute l'équipe

Un assistant de code s'installe sur la machine de celui qui écrit du code. C'est logique : c'est là qu'il sert. La conséquence, c'est que la personne qui décide du produit - la PM, la dirigeante, la fondatrice non technique - reste à l'extérieur de l'outil, et récupère l'information par des captures d'écran et des réunions.

Survol est web d'abord, et c'est un choix assumé : un PM ne doit rien installer. Seul le composant qui pilote l'agent vit sur la machine du développeur. Tout le monde regarde la même carte du produit, avec des droits et des rôles - éditeur, lecteur, admin - et une matrice de droits par fonctionnalité. La collaboration n'est pas une fonctionnalité annexe : c'est le point de départ.

4. La mémoire : la session ou la carte du produit

Une session d'agent a une mémoire remarquable… pendant qu'elle dure. Les outils récents la prolongent avec des fichiers de contexte dans le dépôt, et c'est une vraie avancée.

Survol part d'un besoin différent : répondre, six mois plus tard, à « pourquoi a-t-on tranché comme ça ? ». Les décisions produit y ont un cycle de vie complet - ouverte, acceptée ou refusée, puis implémentée - avec leurs dates, leurs votants et la version qui embarque la modification. Le raisonnement de l'équipe est archivé au même endroit que la spec qu'il a produite. C'est ce que Simon Rimbert appelle un coffre : non pas un tas de notes, mais un contexte structuré qui donne une forme à ce qu'on sait.

5. Les règles : le fichier de config ou la gouvernance

Tous les bons outils agentiques ont leur mécanisme de règles persistantes : CLAUDE.md, constitution.md, steering files, skills. Le principe est excellent et nous l'appliquons.

Là où Survol ajoute quelque chose, c'est en traitant ces règles comme une infrastructure d'organisation plutôt que comme un fichier par dépôt. Nos contraintes techniques ont trois niveaux d'autorité :

• Impérative - jamais contournée ;
• Forte - l'agent peut la contester avec arguments, ce qui ouvre une décision produit qu'un humain tranche ;
• Préférence - appliquée par défaut, sans drame si le contexte justifie de s'en écarter.

Elles se cascadent de l'organisation au produit puis à la fonctionnalité, sont injectées au début de chaque session, et chaque application - comme chaque contestation - est journalisée. Une règle de sécurité définie une fois s'applique à tous les produits de la société, sans dépendre de la discipline de chacun à recopier le bon fichier.

6. Le coût : par siège ou par fonctionnalité livrée

Les outils de l'étage du dessous facturent et mesurent naturellement par utilisateur : c'est la bonne maille pour un poste de travail. Beaucoup offrent d'ailleurs d'excellents tableaux de bord de consommation individuelle.

Survol suit la dépense par session, par version et par fonctionnalité. C'est la maille qui permet de répondre à la question que le COO d'Uber reconnaissait ne pas savoir traiter : tracer une ligne entre les tokens consommés et ce qui a réellement été livré aux utilisateurs. Une fonctionnalité qui brûle du budget sans avancer se repère du premier coup d'œil - et déclenche la bonne conversation.

Corollaire assumé sur notre modèle : nous ne revendons pas de tokens. Votre abonnement IA reste le vôtre. En mode clés en main, les tokens sont refacturés au prix public, marge zéro. Nous facturons l'outil de pilotage, pas l'IA.

7. Le cycle de vie : du commit à la production

Un assistant de code vous amène jusqu'au commit, souvent jusqu'à la demande de fusion. C'est déjà beaucoup.

Survol prend le relais après : environnements de test, préview et production, promotion d'un clic, retour arrière d'un clic, cahiers de tests d'acceptation déroulés par un humain sur un environnement identifié, revues d'experts humains à la demande dont chaque constat devient une tâche pour l'agent. Le statut d'une fonctionnalité - à discuter, spécifiée, en développement, en test, en préview, en production - est dérivé de ce qui est réellement déployé, pas déclaré à la main.

Ce que Survol ne fait pas

Cette section compte autant que les précédentes, et nous préférons l'écrire nous-mêmes.

• Survol n'est pas un éditeur de code. Pas de complétion inline, pas de navigation dans le code, pas de terminal intégré. Votre IDE reste votre IDE.
• Survol n'écrit pas le code lui-même. Il compose le contexte et pilote un agent - le vôtre, avec votre abonnement, sur votre machine. La qualité du code reste celle du modèle que vous branchez.
• Survol n'a d'intérêt qu'à partir d'un vrai produit. Pour un script jetable ou un week-end de prototypage, ouvrez directement votre éditeur : la couche de gouvernance serait un coût sans contrepartie.
• Survol ne remplace pas votre CI, votre hébergeur ni votre forge. Il s'y raccorde. Nous supervisons, nous ne possédons rien.

Comment ça cohabite, en pratique

Le scénario le plus courant chez nos utilisateurs pilotes ressemble à ceci. La PM décrit une fonctionnalité dans Survol et la fait valider par l'équipe. La spec validée part comme instruction à l'agent, avec les décisions déjà tranchées et les contraintes de la société. Pendant ce temps, un développeur reprend une partie du travail à la main dans son éditeur favori, sur la même branche.

Et c'est là que se joue notre principe le plus important : réconciliation, pas surveillance. Les branches, commits et demandes de fusion créés en dehors de Survol sont détectés par les webhooks, et l'outil propose de les rattacher à la bonne fonctionnalité. Dans notre modèle de domaine, l'origine d'une version est neutre - agent, manuelle ou mixte - et une version écrite à la main suit exactement le même cycle de vie qu'une version d'agent. Jamais de ton délateur : on relie le travail, on ne fliquera personne.

Ce qu'on en retient

1. Ce ne sont pas des concurrents mais des étages : l'éditeur augmenté travaille sur le code, Survol travaille sur le produit et l'équipe.
2. La spec est devenue le terrain commun de toute l'industrie. La question qui reste ouverte est celle de sa maintenance dans le temps - c'est là que nous nous situons.
3. Trois choses ne se règlent pas dans un éditeur : la décision collective, la gouvernance à l'échelle d'une organisation, et le lien entre la dépense et ce qui est livré.
4. Votre IDE reste le vôtre, votre agent aussi, votre code également. Survol se branche au-dessus - et se débranche sans rien vous prendre.

Si vous nous demandez lequel choisir, la réponse est probablement « les deux ». Gardez l'outil qui vous rend heureux dans l'éditeur ; il fait un travail que nous ne cherchons pas à faire. La question à laquelle nous répondons commence quand vous fermez l'éditeur : au fond, qu'est-ce qui est fait, dans quelle version, et pourquoi a-t-on décidé ça ?