LaunchRepoVoici le parcours que j’aurais aimé avoir avant mon propre lancement : ce qui se passe réellement, dans l’ordre, quand vous pointez Claude Code vers le dépôt LaunchRepo et lui demandez de lancer votre produit sur les annuaires. Il suit les documents du dépôt — START.md, ONBOARDING.md et BROWSER-SETUP.md — en langage simple, en signalant les moments où vous devez agir. Rien ici n’est propre à Claude Code au point de ne pas marcher avec Codex ou Cursor ; les pages agents détaillent les différences. Claude Code est simplement celui que j’utilise.
Deux attentes à poser. D’abord, ce n’est pas un lancement en un clic : l’agent fait le travail répétitif, mais vous connectez le navigateur, validez les textes, résolvez les CAPTCHA et confirmez ce qui est en ligne. Ensuite, aucune étape ci-dessous ne promet une fiche — chaque annuaire décide seul de ce qu’il publie, et beaucoup d’offres gratuites prennent des semaines.
Étape 0 : ce qu’il vous faut
- Le dépôt. Après l’achat, vous recevez une invitation à un dépôt GitHub privé. Clonez-le.
- Python 3.10 ou plus récent sur macOS ou Linux. Le suivi, le tableau de bord et les scripts sont du Python pur, sans dépendance à installer.
- Claude Code avec une intégration navigateur. Un terminal seul ne remplit pas de formulaires ; la configuration navigateur du dépôt utilise Chrome DevTools MCP, qui a besoin de Node.js pour
npx. - Chrome 144 ou plus récent, connecté à votre compte Google et à votre boîte mail — ceux que les annuaires doivent connaître.
- Les faits sur votre produit : nom, URL, une vraie description, les tarifs, le stade de lancement, de vraies captures et un logo. Pas des souhaits marketing ; ce qui existe aujourd’hui.
Étape 1 : le prompt de départ
Ouvrez le dossier cloné dans Claude Code et collez le prompt de START.md, tel quel :
Read AGENTS.md, then follow “Start the dashboard for the owner”. Create my private workspace if I do not have one yet, start the dashboard, and give me the link.
Le prompt est en anglais et le reste ; l’agent vous parlera dans votre langue une fois les instructions lues. La suite est déterministe : l’agent lit AGENTS.md, crée un espace de travail privé à côté du clone — vos produits et identifiants ne vivent jamais dans le dépôt livré —, démarre le tableau de bord local et répond avec un lien 127.0.0.1. Ouvrez-le. Tout le reste peut se faire dans cet onglet ou dans le chat ; les formulaires du tableau de bord écrivent les mêmes fichiers que lit l’agent.
Si vous préférez faire cette étape vous-même, le dépôt documente deux commandes : l’une initialise l’espace de travail à l’emplacement de votre choix, l’autre démarre le tableau de bord. Un drapeau --demo sert un espace jetable avec un produit fictif si vous voulez d’abord jeter un œil.
Étape 2 : l’entretien d’onboarding
ONBOARDING.md demande à l’agent de mener votre première session une phase à la fois et de lire les fichiers existants avant de poser deux fois la même question. En pratique, cela ressemble à un entretien.
Où nous en sommes. L’agent explique ce qu’est l’espace de travail et demande le nom, l’URL et le dossier local contenant le code ou les notes de votre premier produit. Il inspecte ces sources avant de poser d’autres questions, et détermine votre système, votre agent et les outils navigateur qu’il peut réellement appeler — il lui est explicitement interdit de prétendre disposer d’outils que la session n’a pas.
Un foyer privé. L’agent vous aide à créer votre propre dépôt distant privé pour l’espace de travail et explique, sans détour, que les identifiants réutilisables qui y sont stockés sont lisibles par toute personne ayant accès à ce dépôt, historique compris. Vous décidez si les identifiants vont dans l’espace de travail, dans un gestionnaire de secrets (références seulement) ou nulle part. Le fichier de l’espace de travail enregistre ce choix.
Le produit. Un script crée un dossier produit à partir d’un court identifiant ; puis l’agent remplit product.json avec vos réponses : audience, problème, différenciateur, fonctionnalités réelles, tarifs ou essai gratuit, stade de lancement, captures et logo. Un atelier de rédaction en tire copy.md avec des variantes pour différentes limites de champs. Les inconnues restent vides — l’agent a pour consigne de ne pas déduire des capacités à partir des concurrents ni de transformer des fonctionnalités prévues en fonctionnalités disponibles.
Cette phase fixe aussi la date de lancement au plus tôt. Beaucoup d’annuaires gratuits mettent les soumissions en file de modération ; la confirmation peut prendre des semaines. L’agent demande s’il existe une date avant laquelle rien ne doit être publié, l’écrit dans product.json, et le suivi refuse de marquer quoi que ce soit comme programmé avant cette date.
Identité. identity.json contient le nom public, l’adresse e-mail que les annuaires doivent utiliser, votre pseudonyme et les informations d’organisation que vous acceptez de publier. Suit une courte session de briefing RP, où vous corrigez la façon dont l’agent vous décrit avant que rien de tout cela n’atteigne une fiche publique.
Étape 3 : connecter Chrome et votre boîte mail
C’est l’étape que l’on saute avant de se demander pourquoi l’agent n’arrive pas à se connecter. L’agent a besoin d’un navigateur que vous pouvez voir et surveiller. BROWSER-SETUP.md propose deux voies.
Voie A : votre Chrome existant. Vérifiez chrome://version (144+), ouvrez chrome://inspect/#remote-debugging dans le Chrome que l’agent doit utiliser et activez-y le débogage à distance. Ajoutez ensuite Chrome DevTools MCP à la configuration MCP de Claude Code avec --autoConnect. Déclenchez une action navigateur anodine depuis l’agent et approuvez vous-même la demande de connexion de Chrome, dans la bonne fenêtre. Un processus MCP en cours ne prouve pas l’accès au navigateur ; un onglet visible qui bouge, si.
Voie B : un profil dédié. Lancez Chrome avec son propre répertoire de données dans l’espace de travail et un port local de débogage à distance, connectez-vous aux comptes nécessaires dans cette fenêtre, et pointez la configuration MCP vers --browserUrl au lieu de --autoConnect. Jamais les deux à la fois, jamais avec le port exposé au-delà de localhost.
Sur macOS, n’accordez que les autorisations Automatisation, Accessibilité ou Enregistrement d’écran dont votre intégration a réellement besoin ; une connexion DevTools pure n’en demande généralement aucune. La demande de connexion de Chrome peut revenir après une reconnexion — c’est un contrôle de sécurité, pas un bug, et le dépôt demande à l’agent de ne pas promettre de le faire disparaître.
Puis le test de fumée : l’agent ouvre un onglet vierge, va sur la page d’accueil publique d’un annuaire, lit son titre principal et vous dit quel onglet il a utilisé. Vous regardez la même fenêtre. Il se connecte ensuite à un annuaire cible et vérifie dans le menu du compte que l’identité est la bonne — terminer un OAuth ne prouve pas la connexion sur le site de destination. Enfin, il confirme l’accès à la boîte mail, car ce sont les e-mails de vérification qui finalisent les inscriptions. Le transfert manuel de codes est une solution de repli acceptée ; le suivi l’enregistre comme un relais humain, pas comme un accès automatisé.
Étape 4 : les autorisations, une fois par produit
Avant toute soumission, l’agent lit WEBSITE-AND-EMAIL.md et pose une poignée de questions qu’il ne reposera pas : où vit le code de votre site, comment il se déploie, quelle branche est la production, s’il peut ajouter au pied de page les badges exigés par certains annuaires et les pousser, et si les inscriptions gratuites, les soumissions finales gratuites et les actions précises sur les e-mails de vérification sont autorisées. Les réponses, la date et le périmètre exact vont dans authorizations.json. La dépense reste à zéro — l’agent a pour consigne de refuser chaque option payante.
Refuser les badges est acceptable ; cela écarte simplement les annuaires qui en exigent un. Ce qu’il ne faut pas faire, c’est étendre les autorisations d’un produit à un autre. Le fichier est par produit, à dessein.
Étape 5 : le premier résultat utile
L’agent exécute alors doctor.py, qui distingue la configuration manquante des autorisations refusées, et choisit dans l’index des playbooks et le catalogue trois à cinq annuaires adaptés à votre produit — il explique l’adéquation et les prérequis, et commence par une voie gratuite accessible. Pour chaque annuaire, le playbook impose la même boucle : chercher d’abord une fiche existante, vérifier qu’on est sur le bon site, préparer le texte dans les limites des champs, confirmer que rien ne coûte d’argent, ne soumettre que dans le cadre de votre autorisation, et consigner le résultat réel.
Attendez-vous à des relais. Un CAPTCHA, une double authentification, un état de compte incertain ou un badge obligatoire arrête l’exécution : l’agent enregistre prepared_needs_human, le tableau de bord place la plateforme sous « vous attend », et vous terminez cette étape dans votre propre navigateur. C’est voulu — le dépôt interdit le contournement et les modifications furtives.
Un bon premier résultat est souvent une soumission en attente de modération, pas une page en ligne. C’est normal.
Étape 6 : ce que signifient les états du suivi
Chaque résultat passe par record.py vers submissions.csv, et le tableau de bord affiche les mêmes onze états. Chacun est lié à une observation minimale, pour qu’un « terminé » ne puisse pas être gonflé. Avec mes mots :
- draft — le travail est préparé, mais la soumission finale n’a pas été confirmée.
- prepared_needs_human — quelque chose de précis bloque et vous seul pouvez agir : CAPTCHA, 2FA, compte incertain.
- submitted_pending_review — la plateforme a explicitement reçu la soumission et la modération est encore en cours.
- queued — la plateforme a confirmé une position dans une file ou un statut de liste d’attente.
- scheduled — la plateforme a confirmé une date de lancement égale ou postérieure à votre date au plus tôt ; toute validation en suspens reste dans la note.
- live — une fiche publique a été vérifiée sans mention « en attente ». Exige l’URL publique et votre confirmation.
- already_listed — une fiche publique existante a été trouvée et vérifiée ; même exigence d’URL et d’attestation que live.
- blocked — l’éligibilité, la capacité du compte ou un fait obligatoire manquant empêche d’avancer.
- deferred_paid — la seule voie utilisable exige un paiement ; rien n’a été acheté.
- not_a_fit — le produit ne répond pas aux critères d’audience ou de fiche.
- unavailable — la voie ou la plateforme est actuellement inutilisable ; le problème observé est noté.
Trois conséquences en découlent. Un écran de remerciement n’est pas live. Une case de distribution partenaire cochée sur un site ne compte pas comme seconde soumission tant que la seconde plateforme n’a pas confirmé. Et scheduled sur une offre gratuite peut encore mettre des semaines à paraître. Le guide de suivi des états explique comment garder tout cela distinct.
Étape 7 : laisser un espace de travail reprenable
En fin de session, l’agent ne coche la liste d’onboarding que pour ce qu’il a réellement observé, écrit les preuves non sensibles et les étapes ouvertes dans SESSION.md, met les prochaines dates dans FOLLOW-UP.md et lance une vérification de confidentialité git avant de pousser vers votre dépôt privé. La session suivante — la vôtre ou celle d’un autre agent — lit d’abord le suivi, priorise les relais et les lancements programmés à vérifier, puis les soumissions en attente dont la fenêtre de modération est écoulée. Elle revérifie les enregistrements existants au lieu de soumettre à nouveau pour remonter dans une file.
Cette reprise est tout l’intérêt. Votre deuxième produit réutilise la configuration navigateur, l’identité, le schéma d’autorisations et les playbooks ; seuls product.json et les textes sont nouveaux.
Pour aller plus loin
La page Claude Code réunit le même prompt de départ, la liste des relais et les notes navigateur sur un seul écran. Comment ça marche montre les six étapes avec la vidéo du fondateur. Le catalogue des annuaires vous permet de lire quelques playbooks publics avant de décider, et la page tarifs est là où le dépôt s’achète, une fois.
Sources : START.md, ONBOARDING.md, BROWSER-SETUP.md et RUNBOOK.md du dépôt LaunchRepo (notes de version dans le changelog) ; le prompt de départ est cité mot pour mot depuis prompts/start.md. Aucun chiffre de durée ou de résultat n’est donné, car aucun n’a été mesuré sur l’ensemble des clients.