Documentation
Tout ce qu’il faut pour passer de l’installation à une équipe d’agents qui travaille sur votre dépôt. L’application reprend les mêmes indications dans son panneau d’accueil ; cette page en est la version à lire avant d’installer.
Ce qu’il vous faut
SuperDevSpace pilote une CLI d’agent que vous avez déjà. Avant le premier lancement, préparez :
- macOS 13 Ventura ou plus récent sur Apple silicon, Windows 10 ou 11 en 64 bits, ou Linux 64 bits (Ubuntu 22.04+, Debian 12+, Fedora 38+).
- Git, et le dépôt sur lequel l’équipe doit travailler, cloné en local.
- Au moins une CLI d’agent installée et connectée — Claude Code, OpenAI Codex, Gemini CLI, Aider, Qwen Code, Cursor CLI ou OpenCode. L’application détecte celles qu’elle trouve et vous donne la commande d’installation des autres.
- Un abonnement ou une clé API pour cette CLI. Cela reste entre vous et son fournisseur ; SuperDevSpace ne le voit jamais et ne revend jamais d’accès aux modèles.
Installation et connexion
Récupérez le programme d’installation sur la page de téléchargement ; elle indique les versions disponibles. La version macOS (Apple silicon) est signée, notarisée et se met à jour toute seule. Le programme d’installation Windows démarre en bêta, sans signature de code pour l’instant, donc SmartScreen pose la question une fois (Informations complémentaires › Exécuter quand même). Sous Linux, prenez l’AppImage (elle se met à jour toute seule) ou le .deb / .rpm pour votre gestionnaire de paquets. Chaque fichier publié est listé avec son SHA-256, pour que vous puissiez le vérifier avant de l’ouvrir.
Au premier lancement, l’application vous demande de créer un compte ou de vous connecter (e-mail, Google, GitHub ou Apple). Un nouveau compte démarre un essai Premium de 14 jours, sans carte. Le compte contient votre abonnement et votre liste d’appareils — rien sur votre code.
Votre première organisation
Dans SuperDevSpace, chaque dépôt est une organisation : une équipe, un tableau et une mémoire qui lui sont propres. Le panneau d’accueil vous guide en trois étapes :
- Ajoutez une organisation : donnez-lui un nom et indiquez le dossier du dépôt.
- Composez l’équipe : choisissez les rôles (frontend, backend, QA, relecteur, designer et d’autres), donnez un nom à chaque agent et, si vous le souhaitez, des instructions supplémentaires. Vous pourrez en ajouter plus tard.
- Lancez le manager. Il s’ouvre comme une vraie session de CLI d’agent, dans un onglet de terminal que vous voyez et où vous pouvez écrire.
Donner une directive
Dites au manager ce que vous voulez en langage courant — tapez-le dans son terminal ou son chat, ou dictez-le. Le manager fait ce que ferait un lead :
- Il ouvre un sprint et découpe la directive en tâches sur le tableau, chacune avec un court brief.
- Il recrute un worker par tâche. Chaque worker est sa propre session CLI dans son propre onglet de terminal, avec son propre git worktree sur sa propre branche.
- Il relit le rapport de chaque worker, fait un squash-merge de la branche dans votre ligne de développement et demande des corrections quand quelque chose cloche.
- Il vous remet un rapport consolidé à la fin.
Vous pouvez intervenir à tout moment : chaque agent a une vue chat et son vrai terminal, et chaque changement apparaît sous forme de diff à côté de la conversation qui l’a produit.
Les worktrees et le script de setup
Les workers ne partagent jamais un checkout. Chacun reçoit un git worktree dans le dossier de données de l’application (pas dans votre dépôt), et chaque tour terminé est commité sur la branche du worker : rien ne vit uniquement dans un dossier non commité.
Un worktree neuf ne contient que ce que git suit. 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 qui pointe vers votre checkout principal. Les sous-modules sont initialisés pour vous.
#!/usr/bin/env bash
set -euo pipefail
# Copy local-only files from the main checkout
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Install dependencies
pnpm install --frozen-lockfile
Autorisations et questions
Quand un agent a besoin d’une décision — une demande d’autorisation, un choix entre deux approches —, il vous pose la question au lieu de deviner. La question apparaît en haut de l’espace de travail et y reste jusqu’à votre réponse.
Une application compagnon pour téléphone, qui affiche le même tableau, les mêmes agents et les questions en attente, arrive sur l’App Store ; aujourd’hui, c’est une bêta sur invitation.
Corriger une page web en la pointant du doigt
Ouvrez le serveur de développement de votre application dans le panneau navigateur et sélectionnez un élément. L’Inspector affiche la chaîne de composants sous le curseur, avec le fichier et la ligne de chacun, et envoie l’élément, une capture d’écran et votre note à un agent. Il fonctionne avec Vite, Next.js et les sites statiques.
Choisir la CLI
La CLI se choisit par organisation. Claude Code est celle que l’application maîtrise pleinement aujourd’hui — hooks, reprise de session, outils MCP et réponses aux demandes d’autorisation. Les six autres démarrent et fonctionnent ; l’application les marque comme expérimentales et vous dit quelles fonctions ne sont pas encore branchées, au lieu d’échouer sans rien dire.
Ce qui quitte votre machine
Les agents tournent en processus locaux sur vos dépôts locaux. Votre code source, vos prompts, la sortie du terminal et les chemins de fichiers ne sont jamais envoyés à nos serveurs. Le service de compte stocke un compte, un état d’abonnement et une liste d’appareils ; la politique de confidentialité détaille chaque champ.
Bloqué ?
Écrivez à [email protected] en précisant ce que vous avez essayé et ce que vous avez vu — une vraie personne vous lit. Les signalements de sécurité vont à [email protected].