La configuration guidée, c’est la façon dont SuperDevSpace comble ce manque. L’agent ouvre le site dans le navigateur intégré de l’application, fait les clics qu’il a le droit de faire, et vous passe la page, avec un repère et une phrase, exactement quand l’étape suivante vous revient.

Pourquoi « laisse l’agent tout faire » est la mauvaise réponse

La version facile de cette fonctionnalité donnerait tout le navigateur à l’agent : lire chaque champ, taper dans chaque case, appuyer sur chaque bouton. Ce serait rapide, et ce serait une mauvaise idée. Un parcours de configuration regorge de choses qu’un agent ne devrait jamais toucher :

• votre mot de passe et le code à usage unique reçu sur votre téléphone ;
• les numéros de carte, les coordonnées bancaires et les pièces d’identité ;
• les conditions que vous acceptez et le paiement que vous validez.

La conception part donc de l’autre bout. L’agent fait le travail de routine — naviguer, trouver la bonne page, saisir un nom de projet, cliquer sur Créer — et tout ce qui est personnel ou engageant reste entre vos mains.

Le déroulé d’une configuration guidée

La boucle est la même sur tous les sites, y compris ceux pour lesquels personne n’a écrit d’instructions.

Une fois fini, vous pouvez vérifier le résultat sans afficher de secret à l’écran :

$ grep -o '^PADDLE_[A-Z_]*=' .env
PADDLE_API_KEY=
PADDLE_CLIENT_TOKEN=
PADDLE_WEBHOOK_SECRET=
PADDLE_ENVIRONMENT=

Les règles que l’application impose

Ce sont des contrôles dans l’application, et l’agent ne peut pas les désactiver :

• Aucun secret n’entre, aucun secret ne sort. L’agent ne peut pas taper dans un champ de mot de passe, de carte, de CVC, d’IBAN, de code à usage unique ou d’identité. Quand il lit la page ou en prend un instantané, ces valeurs sont masquées, et elles sont retirées de tout texte qu’il lit.
• Les captures d’écran sont recouvertes. Les champs sensibles et chaque frame d’une autre origine — un widget de carte, un encart « Se connecter avec Google » — sont masqués avant qu’un agent ne voie une image.
• Pas de scripts sur les pages sensibles. Exécuter du JavaScript dans la page est refusé sur toute page qui affiche un tel champ.
• Le consentement et le paiement vous appartiennent. Cliquer sur une case de conditions ou sur un bouton « Payer » / « Commander » est refusé.
• Tout est visible. Ce que fait l’agent dans le panneau navigateur s’affiche dans le bandeau du panneau, au moment où cela se produit.
• Les secrets restent hors de la conversation. Une valeur lue comme secret est marquée sensible, et l’agent a pour consigne de ne jamais la répéter dans le chat, les rapports, les notes de tâche ou les notifications.

N’importe quel site, pas une liste d’intégrations

La configuration guidée est une boucle, pas une bibliothèque de scripts. Elle fonctionne sur un site pour lequel personne n’a écrit d’indications, parce que l’agent lit la page réellement affichée. Pour quelques services, nous fournissons de courts fichiers d’indications — par exemple pour le tableau de bord sandbox de Paddle et pour RevenueCat — qui disent à l’agent où se trouvent habituellement les réglages développeur. Les tableaux de bord déplacent sans cesse leurs menus, alors les indications le disent clairement : quand la page et l’indication se contredisent, c’est la page qui a raison.

C’est plus important qu’il n’y paraît. Le code d’intégration qu’écrit un agent n’est que la moitié d’une fonctionnalité ; l’autre moitié, c’est le compte, la clé et le webhook sur le site de quelqu’un d’autre. Avec la configuration guidée, les deux moitiés se font dans la même session, avec le même agent, et vous ne consacrez votre temps qu’aux étapes que vous seul pouvez faire.

Sa place dans l’ensemble

La configuration guidée fait partie du même espace de travail que tout le reste de SuperDevSpace : l’agent qui écrit votre intégration de paiement est celui qui vous accompagne pour créer ses clés, dans un panneau navigateur à côté de son terminal. Si vous découvrez SuperDevSpace, pourquoi nous l’avons créé présente le reste de l’équipe autour.

L’essayer

L’essai dure 14 jours en Premium, sans carte. Téléchargez SuperDevSpace, demandez à un agent de configurer un prestataire de paiement ou d’analytique pour votre projet, et laissez-le vous passer la page quand c’est votre tour.

SuperDevSpace fait travailler un manager et plusieurs workers sur un même dépôt en même temps. Cet article explique le mécanisme qui les sépare — les git worktrees — et les règles précises que l’application applique autour d’eux.

Qu’est-ce qu’un git worktree

Un dépôt git a normalement un seul répertoire de travail. git worktree permet à un même dépôt d’en avoir plusieurs, chacun sur sa propre branche, tous partageant la même base d’objets. Pas de deuxième clone, pas de deuxième copie de l’historique : un nouveau worktree coûte les fichiers d’un checkout, rien de plus.

Vous pouvez l’essayer à la main dans n’importe quel dépôt. Les commandes sont les mêmes partout ; seul le shell change :

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Chaque worktree a son propre HEAD, son propre index et ses propres fichiers. Deux processus peuvent modifier, compiler et tester dans deux worktrees à la fois sans voir les changements à moitié faits de l’autre. C’est exactement la propriété dont une équipe d’agents a besoin.

Comment SuperDevSpace les utilise

Les règles sont simples, et les mêmes pour toutes les organisations :

• Le manager travaille dans votre checkout principal. Il planifie, relit et fusionne ; c’est le seul endroit où les branches se rejoignent.
• Chaque worker reçoit son propre worktree sur sa propre branche. Quand le manager recrute un worker, l’application exécute git worktree add -b <branche> <chemin> pour lui. La branche s’appelle agent/<nom-du-worker>-<horodatage>, sauf si vous lui avez donné un nom.
• Les worktrees vivent dans le dossier de données de l’application, sous worktrees/<organisation>/<worker>, jamais dans votre dépôt. Votre dossier de projet ne se remplit pas de répertoires d’agents.
• Chaque tour est commité. Quand un worker termine un tour, l’application commite tout ce qui a changé dans son worktree (agent(<nom>): turn). Rien de ce qu’a fait un worker n’existe seulement dans un répertoire de travail non commité.
• La fusion est un squash merge. Quand le manager accepte le rapport d’un worker, la branche est fusionnée dans votre ligne avec git merge --squash, en un seul commit. En cas de conflit, l’application abandonne la fusion et laisse le dépôt propre pour l’opération suivante, au lieu de vous laisser au milieu d’un merge en conflit.
• Une seule opération git à la fois par dépôt. Les répertoires de worktree isolent les fichiers ; une file par dépôt sérialise les commandes git elles-mêmes, si bien que deux workers qui terminent au même instant ne se disputent jamais les métadonnées de git.

Sur le tableau, cela se traduit par plusieurs tâches en cours en même temps, chacune confiée à un worker différent, chacune avec sa propre branche en dessous.

Ce qui rend la chose praticable

Un worktree neuf ne contient que ce que git suit. Cela ne suffit généralement pas à faire tourner un projet : node_modules, un .env local, des fichiers générés. Deux détails règlent la question.

Un script d’installation par dépôt

Si votre dépôt contient .super/scripts/setup-worktree.sh, l’application l’exécute dans chaque nouveau worktree avant le démarrage du worker, avec SUPERDEV_MAIN_REPO pointant vers votre checkout principal. Sa sortie s’affiche en direct — une longue installation n’est pas une attente à l’aveugle — et vous pouvez l’annuler.

#!/usr/bin/env bash
set -euo pipefail
# Copier les fichiers purement locaux depuis le checkout principal
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Installer les dépendances (pnpm crée des liens depuis un store partagé, c’est rapide)
pnpm install --frozen-lockfile

Les submodules

git worktree add laisse les submodules vides. Si le nouveau worktree contient un fichier .gitmodules, l’application y lance git submodule update --init --recursive, pour qu’aucun worker ne compile contre une dépendance discrètement absente.

Faire le ménage sans perdre de travail

Les worktrees s’accumulent. L’application les récupère, mais avec prudence :

Un worktree avec des modifications non commitées, ou dont la branche contient du travail pas encore dans votre ligne, reste où il est. Un dossier supprimé se recrée ; un travail perdu, non. La même prudence s’applique aux branches : l’application garde la trace des branches qu’elle a créées et ne touche qu’à celles-là.

Ce que cela change pour vous

Avec chaque worker sur sa propre branche, « lancer quatre agents à la fois » n’est plus un pari. Vous pouvez :

• donner au manager une directive qui se découpe en tâches indépendantes et laisser les workers tourner en parallèle ;
• lire le diff de n’importe quel worker isolément, à côté de la conversation qui l’a produit ;
• rejeter la modification d’un worker sans déranger les autres ;
• continuer à utiliser votre checkout principal pendant que l’équipe travaille.

C’est la même discipline qu’une équipe humaine, appliquée à des agents qui ne peuvent pas vous prévenir qu’ils sont sur le point de se marcher dessus. Si vous vous demandez pourquoi nous avons construit toute une application autour de cela, le premier article raconte l’histoire.

L’essayer

L’essai de 14 jours est en Premium, sans carte. Téléchargez SuperDevSpace, associez une nouvelle organisation à un dépôt et regardez les worktrees apparaître à mesure que le manager recrute ses premiers workers.

C’est pour combler ce manque que nous avons créé SuperDevSpace. Une application de bureau qui transforme la CLI que vous avez déjà en une petite équipe : un manager qui planifie le travail et des workers qui l’exécutent, chacun dans son propre terminal et son propre git worktree.

Le problème d’un agent dans un terminal

Travailler avec un seul agent de code, c’est formidable pour une seule tâche. Tout se dérègle dès que vous avez trois choses à faire dans le même dépôt :

• Vous pouvez ouvrir un deuxième terminal, mais les deux agents modifient alors le même checkout. L’un lance la suite de tests pendant que l’autre est au milieu d’un refactoring.
• Vous devenez chef de projet. C’est vous qui découpez le travail, qui retenez quel terminal avait quelle tâche, qui recopiez le contexte d’une session à l’autre.
• Personne ne note ce qui s’est passé. Au retour de la pause déjeuner, le seul historique est le scrollback du terminal.

Rien de tout cela n’est un problème de modèle. C’est un problème d’organisation — et l’organisation, c’est justement ce que le logiciel fait bien.

Ce que fait réellement SuperDevSpace

Dans SuperDevSpace, chaque dépôt est une organisation. Chaque organisation a un manager : une vraie session de CLI d’agent, dans un vrai terminal que vous voyez et dans lequel vous pouvez taper. Vous donnez au manager une directive en langage courant — au clavier ou en la dictant avec la saisie vocale.

Le manager fait alors ce que ferait un lead :

Vous pouvez intervenir à tout moment. Chaque agent a une vue de chat et son vrai terminal — une seule session, deux façons de la regarder — et chaque modification apparaît sous forme de diff à côté de la conversation qui l’a produite : vous relisez avant que quoi que ce soit n’arrive sur votre ligne principale.

Votre abonnement, votre machine, votre code

La décision de conception la plus importante est aussi la plus simple : SuperDevSpace pilote une CLI que vous payez déjà. Nous ne revendons jamais d’accès aux modèles ; rien de ce que vous exécutez n’apparaît sur une facture de notre part, hormis l’abonnement SuperDevSpace lui-même.

Cette décision a des conséquences qui nous plaisent :

• Les agents tournent en processus locaux sur votre machine, sur vos dépôts locaux. Votre code source, vos prompts, la sortie de vos terminaux et vos chemins de fichiers ne sont jamais envoyés à nos serveurs. Notre service de compte stocke un compte, un état d’abonnement et une liste d’appareils.
• Vous choisissez la CLI par organisation. Claude Code, OpenAI Codex, Gemini CLI, Aider, Qwen Code, Cursor CLI et OpenCode sont tous sélectionnables. Claude Code est celle que l’application parle couramment aujourd’hui — hooks, reprise de session, outils MCP, réponses aux permissions. Les six autres démarrent et tournent ; l’application les marque comme expérimentales et vous dit quels compléments ne sont pas encore branchés au lieu d’échouer en silence.
• Rien n’est enfermé dans notre cloud, puisqu’aucun cloud ne fait le travail.

Avant la première directive, mieux vaut vérifier que la CLI et le dépôt sont bien là où vous les attendez :

$ claude --version
$ cd ~/code/votre-projet
$ git status

Ce qui entoure l’équipe

Une équipe a besoin de plus que des terminaux. Quelques éléments inclus dans chaque offre :

• Un tableau qui dit la vérité. Sprints, tâches, briefs et rapports. Un rapport dit ce qui a échoué, pas seulement ce qui a réussi.
• Inspector. Cliquez sur un élément de votre page web en cours d’exécution et envoyez-le à un agent avec le composant, le fichier et la ligne. Fonctionne avec Vite, Next.js et les sites statiques.
• Des validations depuis votre téléphone. Quand un agent a besoin d’une décision, il vous la demande. L’application mobile affiche le tableau, les agents et les validations en attente : vous répondez à une demande de permission loin de votre bureau.
• Un tableau blanc par organisation (Excalidraw), que les agents peuvent lire et sur lequel ils peuvent dessiner.

Premium ajoute ce qui va plus loin : un mode design basé sur Penpot avec un agent Designer qui dessine dans le fichier, des planifications qui lancent des directives selon un calendrier, et un lien entre pairs qui permet à un manager sur votre Mac de confier du travail à un manager sur votre PC Windows. La page des tarifs présente la comparaison complète.

Ce que nous ne promettons pas

Une équipe d’agents a toujours besoin d’un patron : c’est vous qui décidez de ce qui se construit et qui approuvez ce qui arrive sur votre branche principale.

L’essayer

L’essai dure 14 jours en Premium, sans carte. Votre abonnement CLI reste le vôtre, votre code aussi. Pour voir l’équipe au travail sur votre propre dépôt, téléchargez SuperDevSpace et donnez au manager sa première directive.