BLOG

Date de lancement au plus tôt : quand publier les fiches ?

Pourquoi LaunchRepo demande une date de lancement au plus tôt avant toute soumission, pourquoi les annuaires gratuits publient tard, et comment planifier.

Par Publié le 8 min de lecture

La première question que l’onboarding du kit pose sur le calendrier n’est pas « quand voulez-vous lancer ? » mais « y a-t-il une date avant laquelle rien ne doit être public ? ». Ce sont deux questions différentes, et cette différence est le sujet de cet article. La version courte : les soumissions aux annuaires ne sont pas mises en ligne quand vous les soumettez, elles le sont quand l’annuaire s’en occupe, et si vous voulez une semaine de lancement plutôt qu’un lancement étalé, il vous faut un plancher, pas une cible.

La fonctionnalité, en un paragraphe

Depuis la version du 15 septembre 2026, product.json a un champ nommé earliest_launch_date. Vide signifie pas de plancher. S’il contient une date, le record.py du suivi refuse de marquer une plateforme comme scheduled avec une date de lancement antérieure, et refuse scheduled sans --launch-date tout court. L’onboarding demande la valeur d’emblée, et le tableau de bord local affiche le plancher à côté de l’état programmé. C’est toute la fonctionnalité : un champ, un refus, une question posée avant que quoi que ce soit soit soumis. Le changelog contient la note de version.

Elle est petite à dessein. Elle ne retarde pas les soumissions, parce qu’elle ne le peut pas ; l’agent ne décide pas quand un annuaire publie. Ce qu’elle fait, c’est empêcher la seule chose que vous contrôlez de mal tourner : un agent qui confirme une date de lancement sur une plateforme proposant un calendrier, pour une semaine que vous ne vouliez pas.

Pourquoi les annuaires gratuits publient plus tard que vous ne le pensez

Si vous n’avez jamais soumis un produit à un annuaire par sa voie gratuite, les délais surprennent. D’après les guides de terrain publics de ce site, tous observés en septembre 2026 :

  • SaaSHub a produit une page accessible publiquement juste après la soumission, marquée Pending approval. Accessible n’est pas accepté ; le suivi garde submitted_pending_review tant que la mention n’a pas disparu.
  • PitchWall a accepté la soumission en Under Review avec un délai de relecture estimé à plus de 30 jours.
  • TinyLaunch a proposé un créneau hebdomadaire à venir sur sa voie standard, puis a laissé la validation en suspens une fois la date choisie : scheduled, avec une réserve.
  • Uneed n’autorisait qu’un lancement en attente par compte sur la voie gratuite observée ; un second produit attend donc que le premier soit passé.
  • Product Hunt a confirmé une date de lancement et un fuseau horaire ; cela confirme une date, pas une place en page d’accueil.

Rien de tout cela n’est une plainte. Les offres gratuites sont modérées par des personnes qui ont une file, et la file est longue parce que l’offre est gratuite. Le runbook demande à l’agent de vous prévenir clairement que beaucoup d’annuaires gratuits prennent des semaines, pas des jours, et de ne jamais inventer le délai de modération d’une plateforme quand celle-ci n’en indique pas. L’article sur les états de soumission décrit ce que le suivi enregistre dans chacune de ces situations ; cet article porte sur ce que vous faites de cette connaissance avant de commencer.

Dates cibles et planchers

Une date cible est le moment où vous aimeriez que les choses se produisent. Un plancher est le moment le plus tôt où quoi que ce soit a le droit de se produire. Les annuaires rendent les cibles peu fiables et les planchers bon marché, pour une raison : vous contrôlez quand vous soumettez et quand vous programmez, et rien d’autre.

Voyez ce qui arrive avec une cible seule. Vous voulez des fiches en ligne la semaine du 12 octobre. Votre agent commence le 20 septembre, parce que les modérations prennent des semaines. La plupart des annuaires gratuits publient alors quand ils publient : certains en un jour, certains fin octobre, certains jamais. Mais les plateformes qui vous laissent choisir une date — les tableaux de lancement à créneaux hebdomadaires, Product Hunt avec son calendrier — accepteront volontiers le 28 septembre si c’est le premier créneau libre que l’agent voit, et voilà votre meilleure plateforme de lancement partie avant que votre page produit, votre changelog et votre annonce soient prêts.

Avec un plancher au 12 octobre, le second problème disparaît. L’agent peut toujours soumettre tôt aux annuaires modérés, parce que soumettre n’est pas publier et que le plancher ne s’y applique pas. Il ne peut rien programmer avant le 12 octobre, parce que le suivi refuse. La file d’attente joue en votre faveur : les soumissions déposées fin septembre commencent à sortir la semaine cible ou après, jamais avant.

Planifier une semaine de lancement coordonnée

Voici le plan pour lequel le plancher est conçu. Les dates sont des exemples.

Semaine −4 : fixer le plancher et faire l’onboarding. Décidez de la date la plus tôt à laquelle quelque chose peut devenir public. Inscrivez-la dans product.json pendant l’onboarding. Terminez les faits produit et le briefing de représentation pour que l’agent dispose d’un texte approuvé avant de toucher un formulaire ; une fiche mise en ligne avec la mauvaise bio du fondateur est pire qu’une fiche en retard.

Semaines −4 à −2 : soumettre aux annuaires modérés. Ceux sans calendrier : files de modération, pages « pending approval », estimations « under review ». Soumettez-les en premier parce qu’ils sont les plus lents et que vous ne pouvez pas les piloter. Consignez chaque résultat. Attendez-vous à submitted_pending_review et queued, et attendez-vous à ce que certains y restent au-delà de la semaine de lancement ; c’est normal, le plancher n’a jamais été pour eux.

Semaines −2 à −1 : programmer les plateformes qui prennent une date. Tableaux de lancement à créneaux, Product Hunt, tout ce qui confirme une date et un fuseau horaire. Donnez à l’agent le plancher et un jour préféré ; il enregistre scheduled avec la date confirmée par la plateforme, et le suivi refusera tout ce qui précède le plancher. Là où un créneau est confirmé mais la validation encore en suspens, la note le dit.

Semaine de lancement : vérifier, puis publier. Le jour même, l’agent ouvre chaque fiche programmée avant d’enregistrer live ; une date sur un calendrier n’est pas la preuve d’une page publique. Les communautés — Hacker News, Indie Hackers, Peerlist et consorts — sont des posts que vous écrivez, pas des formulaires, et leur place est ici, quand les fiches vers lesquelles ils pointent existent.

Semaines +1 à +4 : relancer la file. Les soumissions en attente dont la fenêtre de modération annoncée est écoulée sont revérifiées, jamais resoumises pour doubler la file. Les fiches qui arrivent tard comptent quand même ; elles arrivent après le plancher, et c’est la seule chose que le plancher promettait.

Ce que le plancher ne fait pas

Il ne fait pas publier un annuaire plus vite. Il ne s’applique pas aux états submitted_pending_review et queued, parce que ceux-là suivent l’horloge de la plateforme. Il n’empêche pas un annuaire de publier tôt une fiche modérée si vous l’avez soumise tôt ; si une plateforme est connue pour publier immédiatement sur la voie gratuite, soumettez-la dans la fenêtre de lancement, pas avant. Et il n’existe pas pour les produits déjà lancés : un plancher vide est la valeur par défaut, et l’article sur le lancement à budget zéro décrit l’approche au fil de l’eau qui convient à un produit déjà sur le marché.

Il ne remplace pas non plus le jugement sur l’opportunité de soumettre. Quelles plateformes méritent l’effort est une question à part, tranchée produit par produit avec la méthode de preuves du fichier de priorité, pas par une date.

Fixer le plancher en pratique

Si vous lancez le prompt de démarrage, l’agent pose la question pendant l’onboarding ; répondez par une date ou dites « pas de plancher ». Pour le changer plus tard, modifiez earliest_launch_date dans le product.json du produit et prévenez l’agent, ou changez-le dans la vue produit du tableau de bord local. Les lignes scheduled existantes ne sont pas réécrites ; le refus s’applique aux nouveaux enregistrements. Si vous repoussez donc le plancher après un créneau déjà confirmé, relisez le suivi avant la prochaine session de l’agent et décidez s’il faut reprogrammer sur la plateforme.

Deux habitudes font marcher tout cela. Confirmez le fuseau horaire chaque fois qu’une plateforme confirme une date ; le guide de terrain Product Hunt existe en partie pour cette raison. Et traitez un écran de remerciement pour ce qu’il est : ni live, ni scheduled, juste la fin d’un formulaire.

LaunchRepo livre cela dans la licence à paiement unique : l’onboarding qui pose la question, le suivi qui fait respecter la réponse, et 346 playbooks qui savent quelles plateformes prennent une date et lesquelles prennent simplement leur temps.

Sources : ONBOARDING.md, RUNBOOK.md, DASHBOARD.md et CHANGELOG.md dans le dépôt LaunchRepo (version du 15 septembre 2026) ; les guides de terrain publics de ce site, observés le 13 septembre 2026.

  • launch
  • tracker
  • planning

Donnez toute la liste à votre agent

LaunchRepo est le dépôt que votre agent de code IA exécute : 346 playbooks d’annuaires, un modèle de produit et un tracker. Payez une fois au prix de lancement de 99,98 € et utilisez-le pour chaque produit que vous créez.

Voir le prix