Enregistrer les résultats : états, preuves et record.py

Chaque tentative sur un annuaire se termine par une commande. scripts/record.py écrit une seule ligne courante par plateforme dans submissions.json, dans le dossier du produit, et refuse les lignes que le kit considère comme non prouvées ou risquées. Ce refus est tout l’intérêt : le suivi est ce qui empêche « nous avons soumis à 40 annuaires » de vouloir dire « nous avons rempli 40 formulaires en croisant les doigts ». Ce guide couvre les états, la preuve que chacun exige, les options de la commande, et ce qui peut ou non figurer dans une note. C’est un résumé de RUNBOOK.md et des contrôles du script, pas un remplacement.

La commande

L’exemple du runbook, depuis le répertoire du kit avec un dossier de projet privé déjà créé :

Sous Windows, utilisez py -3 à la place de python3 dans les commandes ci-dessous (ou python si cette commande lance Python 3.10 ou plus récent). Gardez votre espace de travail dans un dossier local privé, hors de OneDrive et des autres dossiers synchronisés. Dans PowerShell, écrivez les exemples shell sur une seule ligne et retirez les caractères \ de fin de ligne.

python3 scripts/record.py --project ../private-product pitchwall draft \
  --note "Product import corrected; final form not sent" \
  --next-action "Check saved profile and review final form"

Deux arguments positionnels (identifiant de plateforme, état) et deux options obligatoires (--note, --next-action). Les options facultatives sont --public-url, --confirmed-public, --launch-date et --replace. L’identifiant de plateforme doit être un slug en minuscules, l’état doit être l’un des onze ci-dessous, et le suivi s’arrête avec une explication dès qu’une règle n’est pas respectée. Le formulaire d’enregistrement du tableau de bord local appelle la même fonction avec les mêmes règles.

Les onze états et leur preuve minimale

Le tableau du runbook, en bref :

État	Ce que vous devez avoir observé
draft	Travail préparé ; soumission finale non confirmée.
prepared_needs_human	Une action précise du propriétaire ou un défi (CAPTCHA, 2FA) bloque le travail préparé.
submitted_pending_review	La plateforme a explicitement reçu la soumission ; la modération reste à venir.
queued	La plateforme confirme une position dans une file ou un statut de liste d’attente.
scheduled	La plateforme confirme une date de lancement égale ou postérieure au plancher ; une validation en suspens reste dans la note.
live	Fiche publique vérifiée, sans mention d’attente ; URL publique et --confirmed-public obligatoires.
already_listed	Une fiche publique existante vérifiée ; mêmes exigences que live.
blocked	Éligibilité, capacité du compte ou un fait obligatoire manquant empêche d’avancer.
deferred_paid	La voie utilisable exige un paiement ; rien n’a été acheté.
not_a_fit	Le produit ne répond pas à l’audience ou aux critères de la fiche.
unavailable	La voie ou la plateforme ne peut pas être utilisée pour l’instant ; notez le problème.

Les distinctions qui comptent le plus sont brouillon vs soumis et en attente vs en ligne. Un écran de remerciement ne met pas une fiche en ligne. Une page accessible peut encore être en attente de validation. Une case « diffuser aussi chez notre partenaire » cochée ne signifie pas qu’une seconde plateforme a reçu quoi que ce soit. Le résultat de chaque plateforme reste indépendant pour que les totaux ne soient jamais gonflés.

Les règles que le script fait respecter

• Les états publics exigent une preuve. live et already_listed exigent --public-url avec une URL HTTPS relue — sans chaîne de requête, sans fragment, sans chemin de compte, de tableau de bord ou de connexion — et --confirmed-public, votre déclaration que vous avez regardé la page.
• Programmé exige une date. --launch-date YYYY-MM-DD est obligatoire et ne doit pas être antérieure à earliest_launch_date dans product.json ; le guide de la date de lancement au plus tôt explique pourquoi.
• Les notes restent propres. Les notes et les actions suivantes ne peuvent contenir ni liens, ni adresses e-mail, ni paires du type password=, ni préfixes de jetons connus. Le fichier de suivi est fait pour être partageable ; les preuves avec URL de compte vont dans un stockage privé.
• Une ligne par plateforme. Si la plateforme a déjà une ligne, la commande échoue sauf si vous passez --replace — après avoir inspecté la ligne existante et la plateforme. Remplacer est intentionnel, jamais un effet de bord.
• Pas de liens symboliques, écritures atomiques, un fichier de verrou. Détails ennuyeux, mais c’est grâce à eux que deux agents écrivant en même temps ne corrompent pas le suivi.

Reprendre sans doublons

Au début de la session suivante, lisez le suivi avant de toucher un formulaire. Priorisez les relais humains et les lancements programmés à vérifier, puis les soumissions en attente dont la fenêtre de modération annoncée est écoulée. Si une plateforme n’indique aucun délai de modération, convenez d’une date de relance avec le propriétaire au lieu d’en inventer une. Et ne resoumettez jamais pour avancer dans une file : revérifiez l’enregistrement existant. Le suivi stocke l’état courant, pas l’historique ; s’il vous faut une piste d’audit, archivez séparément des résumés d’exécution expurgés.

Pour des exemples concrets des états sur de vraies plateformes, lisez l’article sur les états de soumission et le guide plus ancien sur le suivi sans double comptage ; le vocabulaire lui-même est défini sous statut de fiche.