Soumis, en attente, en ligne : pourquoi les états comptent

Toutes les feuilles de calcul de soumissions aux annuaires commencent pareil : une colonne « statut », trois valeurs — à faire, fait, éventuellement « en attente » — et un total en bas qui monte chaque fois que quelqu’un clique sur soumettre. Deux semaines plus tard, le total affiche 40, le nombre de fiches qu’un inconnu peut réellement trouver est de 6, et personne ne sait expliquer la différence sans rouvrir chaque compte.

La différence ne vient pas de la paresse. Elle vient de ce qu’on a demandé à « fait » de répondre à cinq questions à la fois. Cet article parle de ces questions, de la raison pour laquelle le suivi de LaunchRepo donne à chacune son propre état, et de deux exemples tirés de notre propre campagne seomap.dev où un simple « fait » aurait été faux.

Une colonne, cinq questions

Quand vous soumettez un produit à un annuaire, les personnes que le résultat intéresse veulent savoir des choses différentes :

• Le travail est-il fait de mon côté ? Ai-je tout rempli et appuyé sur le bouton ?
• La plateforme l’a-t-elle reçu ? Une page de remerciement, un e-mail, une entrée dans le compte.
• Est-ce que cela attend quelque chose ? Une modération, une place dans une file, une validation, une date.
• Le public peut-il le voir ? Une URL qui s’ouvre pour quelqu’un qui n’est pas connecté et qui ne porte pas de mention d’attente.
• Ai-je quelque chose à faire ? Un CAPTCHA, une double authentification, un badge sur mon site, une décision sur une voie payante.

« Fait » répond à la première question et prétend silencieusement répondre à la quatrième. C’est ainsi qu’un total de 40 devient un total de 6.

Les états, et la question à laquelle chacun répond

Le suivi LaunchRepo (record.py qui écrit submissions.csv, et les mêmes règles dans le tableau de bord local) utilise onze états. Chacun est lié à une observation minimale — ce que vous devez avoir réellement vu avant de l’enregistrer. Regroupés par la question à laquelle ils répondent :

Le travail de votre côté

• draft — la préparation existe, la soumission finale n’a pas été confirmée. Un formulaire enregistré est un brouillon.
• prepared_needs_human — quelque chose de précis bloque le travail préparé et seule une personne peut le lever : CAPTCHA, 2FA, état de compte incertain. La note dit exactement quoi.

La plateforme l’a reçu

• submitted_pending_review — la plateforme a explicitement accusé réception et la modération est encore ouverte.
• queued — la plateforme a confirmé une position dans une file ou un statut de liste d’attente. Différent de la modération en cours : il y a une file, et vous y êtes.
• scheduled — la plateforme a confirmé une date de lancement égale ou postérieure à votre date de lancement au plus tôt. S’il reste une validation en suspens, cela va dans la note ; l’état reste scheduled.

Le public peut le voir

• live — une fiche publique a été vérifiée, sans mention d’attente. Exige l’URL publique et un indicateur de confirmation explicite au moment de l’enregistrement.
• already_listed — une fiche publique existante a été trouvée et vérifiée avant toute soumission de votre part. Même exigence d’URL et de confirmation.

Cela s’est arrêté, pour une raison que vous pouvez nommer

• blocked — éligibilité, capacité du compte ou un fait obligatoire dont vous ne disposez pas.
• deferred_paid — la seule voie utilisable coûte de l’argent ; rien n’a été acheté.
• not_a_fit — le produit ne répond pas à l’audience ou aux critères de l’annuaire.
• unavailable — la voie ou la plateforme n’a pas pu être utilisée ; la note consigne ce qui a été observé.

Onze, cela paraît beaucoup. En pratique, chacun existe parce que le fondre dans son voisin a produit au moins une fois un rapport faux.

Exemple 1 : SaaSHub — public, mais en attente

La soumission SaaSHub, documentée dans le guide de terrain SaaSHub public, a produit une page produit accessible publiquement. N’importe qui avec le lien pouvait l’ouvrir. Elle portait aussi une mention visible : « Pending approval ».

Un suivi à une seule colonne enregistre cela comme fait, voire comme en ligne — après tout, la page s’affiche. La règle LaunchRepo est l’inverse : l’accessibilité publique seule ne prouve pas l’acceptation. La fiche reste submitted_pending_review tant que la page annonce une attente, et ne passe à live qu’après que quelqu’un l’a rouverte, n’y a vu aucune mention d’attente et a enregistré l’URL avec l’indicateur de confirmation. Dans le cas de SaaSHub, cela signifiait que le compteur « en ligne » n’a pas bougé le jour de la soumission, et que le fichier de relance a reçu une date de vérification.

Le détail supplémentaire qu’ajoute le guide : sur SaaSHub, la vérification de propriété du domaine est une demande distincte de la connexion au compte. C’est une deuxième chose qui peut être en attente indépendamment, et une note sur la ligne est le bon endroit pour le dire.

Exemple 2 : TinyLaunch — programmé, validation en suspens

TinyLaunch, documenté dans le guide de terrain TinyLaunch, proposait un créneau de lancement hebdomadaire à venir. Le parcours observé est passé par un lancement Standard, une étape de services optionnels réglée sur aucun, une confirmation de programmation et une seconde fenêtre d’upgrade avec une option « continue with free launch » avant l’apparition de la page de succès. Le tableau de bord a ensuite affiché la date confirmée — et, juste à côté, « Waiting for approval ».

Deux mauvaises façons d’enregistrer cela : live, parce qu’il y a une date sur un calendrier ; ou submitted_pending_review, parce que la validation est en suspens. Le suivi enregistre scheduled avec la date confirmée transmise explicitement, et garde la validation en attente dans la note. Les deux faits survivent : une date existe, et elle peut ne pas tenir. L’article sur le lancement à budget zéro traite la partie upsell de ce même parcours.

C’est aussi là que la date de lancement au plus tôt compte. product.json porte un earliest_launch_date ; le suivi refuse d’enregistrer scheduled avec une date antérieure à celle-là. Un développeur solo qui a fixé ce plancher à « après la mise en ligne de la page tarifs » ne peut pas programmer par accident un lancement pour demain simplement parce qu’un annuaire a proposé le créneau.

Trois règles qui découlent des états

Un écran de remerciement n’est pas une fiche en ligne. C’est au mieux submitted_pending_review. La plupart des annuaires qui relisent manuellement les soumissions mettent des jours à des semaines ; plusieurs offres gratuites de notre campagne ont mis plus longtemps encore. Le guide de suivi des états dit explicitement qu’une estimation de délai de modération n’est ni une échéance ni une garantie.

Une soumission, une ligne. Certains annuaires proposent une case « diffuser aussi sur nos sites partenaires ». La cocher ne crée pas de seconde soumission tant que la seconde plateforme n’a pas accusé réception de son côté. Le suivi garde une ligne courante par plateforme et exige un remplacement explicite pour la changer : une case partenaire ne peut donc pas gonfler discrètement le total.

Un relais humain est un état, pas un échec. Quand un agent tombe sur un CAPTCHA ou une double authentification, il enregistre prepared_needs_human avec l’action suivante exacte et s’arrête. Le tableau de bord regroupe ces lignes sous « vous attend ». Les marquer autrement — réessayer, « en attente », passer — revient soit à contourner un contrôle de la plateforme, soit à masquer du travail qu’il vous reste à faire.

Pourquoi un agent en a plus besoin que vous

Si vous soumettez à cinq annuaires à la main, vous vous souvenez lequel est en modération et lequel a montré un calendrier. Un agent IA qui déroule une session, la ferme et redémarre demain — peut-être un autre agent, sur une autre machine — non. Il lit d’abord le suivi et décide quoi faire à partir de l’état :

• Les lignes prepared_needs_human et les lancements scheduled à vérifier passent en premier.
• Les lignes submitted_pending_review dont la fenêtre de modération est écoulée sont revérifiées — l’enregistrement existant, pas une nouvelle soumission pour doubler la file.
• Les lignes live ne sont pas touchées.

Chacune de ces décisions est fausse si l’état est faux. Enregistrer live pour la page SaaSHub aurait voulu dire que personne n’a jamais vérifié si elle était approuvée. Enregistrer TinyLaunch comme simplement soumis aurait voulu dire que personne n’a vérifié le lancement à la date confirmée. Les états sont la mémoire de l’agent, et le pas à pas avec Claude Code montre comment une exécution les lit au début de chaque session.

À quoi ressemble un bon rapport

Au lieu de « 40 faits », le tableau de bord affiche quelque chose comme : 6 en ligne avec URL publique, 21 en modération avec dates de relance, 4 programmés avec dates confirmées, 3 qui vous attendent, 2 reportés parce que la voie gratuite n’existait pas, 4 hors cible. Le total fait toujours 40. Chaque nombre peut être défendu, et chaque groupe a une action suivante évidente.

C’est tout ce à quoi sert un suivi. Pas à faire impression — à dire à la personne suivante, ou à l’agent suivant, ce qui est vrai et ce qu’il faut faire.

Si vous mettez en place votre propre campagne, comment ça marche montre où le suivi s’insère dans le déroulé, la page fondateurs de SaaS couvre la configuration d’un produit avec un vrai calendrier de lancement, et la page tarifs porte la licence à paiement unique du dépôt dans lequel le suivi est livré.

Sources : RUNBOOK.md et AGENTS.md du dépôt LaunchRepo (tableau des états et observations minimales), les guides de terrain publics SaaSHub et TinyLaunch (observés le 2026-09-13) et le guide de suivi des états de soumission. Les nombres du rapport de la dernière section sont illustratifs, pas mesurés.