Que fait beedle ?
Construisez des pages marketing que les moteurs de recherche et les crawlers IA peuvent lire, qu'un inconnu comprend en dix secondes, et qui ne revendiquent que ce qui peut être prouvé. Moins c'est plus : chaque section doit mériter sa place. Chaque tour se termine par une revue indépendante.
Leçons : avant l'étape 1, lisez le fichier design/LESSONS.md du projet s'il en existe un et suivez tout ce qui concerne son site marketing. Ce sont les corrections du propriétaire.
1. Lire le projet
Découvrez ce qui existe déjà avant de demander quoi que ce soit : la stack et l'hébergeur, tout site actuel, le vrai nom du produit, le dépôt, les fiches des magasins, les prix, les captures d'écran, les jetons de design ou le thème, les analytics, et docs/marketing/page-brief.md.
Construisez dans la stack que le projet utilise déjà. Pour un nouveau site, suivez reference/seo.md (« Choisir une stack »). Le contenu marketing n'est jamais du Flutter web ou du rendu côté client, car les crawlers risquent de ne jamais le voir.
Utilisez le thème du projet s'il en existe un (design/THEME.md, *.tokens.json). Sinon, portez les jetons de l'application. S'il n'y a pas non plus d'application à partir de laquelle porter, écrivez le seul petit fichier dans reference/small-theme.md, car une seule page n'a pas besoin d'un système de design. Utilisez la compétence ultrahand:theme uniquement lorsque l'utilisateur demande un thème, ou lorsque plusieurs sites ou une application devront le partager.
2. Choisir le type et l'état de lancement
Lisez reference/page-types.md. Choisissez un type et un état (pré-lancement ou en ligne), et notez les pages de support dont le site a besoin.
3. Rédiger le brief
Enregistrez docs/marketing/page-brief.md dans le projet, en utilisant ce modèle. C'est le contrat que le relecteur vérifiera par rapport à la page, et le point de départ de la prochaine session.
# Brief de la page
- Type et état :
- Public : (qui, et ce qu'ils savent déjà)
- L'unique mission de la page :
- Appel à l'action principal : (mots exacts et destination)
- Action secondaire : (une, plus légère, ou « aucune »)
- Expressions de recherche : (3 à 5 choses que ce public tape réellement)
- Objections : (les vraies raisons pour lesquelles quelqu'un partirait)
- Analytics et cookies : (ce qui se charge, ou « aucun »)
## Revendications
| Revendication sur la page | Preuve |
| --- | --- |
| <chaque chiffre, citation, comparaison, « premier », « le plus rapide », ...> | <fichier, lien ou mesure, avec date> |
| <une description simple de ce que c'est ou fait> | <fichier ou lien, ou `README uniquement` si c'est tout ce qu'il y a> |
## En attente d'une personne
- <qui : ce qu'il doit faire, ou « rien »>
Demandez à l'utilisateur uniquement ce que le projet ne peut pas répondre, généralement le public et la preuve. N'inventez jamais de preuve. Un témoignage manquant est une section manquante, pas un espace réservé à remplir. Utilisez des sentinelles qui échouent bruyamment, comme APP_STORE_ID_TODO, plutôt que des valeurs factices plausibles.
Lorsque vous n'avez que le README, vous pouvez quand même construire la page. Il peut dire simplement ce qu'est le produit et ce qu'il fait : marquez ces lignes README uniquement. Il ne peut pas prouver les chiffres, les dates, les versions, la licence, le prix, la sécurité, la confidentialité ou la disponibilité, alors cherchez une source principale pour chacun : le code, un fichier LICENSE, une page de version, une fiche de registre ou de magasin, une mesure, ou la parole datée du propriétaire. Citez cette source. S'il n'y en a pas, laissez la revendication hors de la page.
Tout ce que seule une personne peut fournir va sous En attente d'une personne dès que vous le savez : une vraie capture d'écran, un domaine, un prix à confirmer. Cela reste là jusqu'à ce qu'elle l'ait fait.
4. Écrire les mots d'abord
Suivez reference/message.md. Écrivez le texte avant toute mise en page. Commencez par les cinq blocs qui s'y trouvent. Ajoutez une section uniquement lorsque vous pouvez nommer l'objection à laquelle elle répond, et enregistrez cette objection dans le brief.
5. Construire
Suivez reference/seo.md pour ce qui va dans la page et à côté. Utilisez de vraies captures d'écran ou images du produit, et ne qualifiez jamais une reconstitution de capture d'écran. Une capture de la vraie application exécutant des données d'exemple est réelle : dites que c'est un exemple sur la page, et dites comment vous l'avez réalisée dans le tableau des revendications. Si vous n'avez rien de réel à montrer, laissez l'image de côté, ou laissez une sentinelle si le type de page en a besoin. Évitez les indicateurs de design listés dans la référence du message, car ils donnent l'impression qu'une page est générée avant même que quiconque ne l'ait lue.
6. Auto-vérification
Construisez le site et exécutez l'audit sur le résultat construit, puis corrigez chaque erreur que vous pouvez :
beedle audit --dir <site construit>
Ajoutez --exclude docs pour chaque section qui n'est pas marketing (répétable). Si beedle n'est pas dans le PATH, dites à l'utilisateur que l'audit n'a pas été exécuté et que INSTALL.md explique comment l'ajouter.
Une erreur que seule une personne peut résoudre reste, comme une sentinelle DOMAIN_TODO pour un domaine que personne n'a acheté. Ne remplacez jamais par une valeur factice pour obtenir une exécution propre. Assurez-vous qu'elle soit sous En attente d'une personne, puis passez à la revue.
7. Revue du tour
Chaque tour se termine par une revue par un nouveau relecteur dans sa propre session, avant de dire à l'utilisateur que la page est prête. Un tour est la première construction et chaque invite ultérieure qui modifie la page, donc même un changement d'une ligne de texte est aussi revu. Sautez-la uniquement lorsque l'utilisateur dit de la sauter pour ce tour, et dites que vous l'avez sautée.
Commencez-la vous-même, sans qu'on vous le demande. Vous ne pouvez pas revoir votre propre page de manière équitable : vous voyez ce que vous aviez l'intention de construire. Suivez review/round.md. En bref, rédigez le brief, exécutez beedle review --brief <brief> --add-dir <projet> en arrière-plan, puis agissez sur les résultats. Ne publiez pas, ne déployez pas et ne déclarez pas la page terminée avant cela.
8. Rapport
Dites ce que vous avez construit, le type et l'état, le verdict, et ce que la revue a trouvé, corrigé et laissé ouvert, avec son coût.
Si le verdict est Impossible de livrer tant qu'une personne n'a pas agi, commencez par cela : la page n'est pas prête, qui doit faire quoi, et ce que le prochain tour vérifiera une fois qu'elle l'aura fait. N'adoucissez jamais en « presque terminé ».
Listez toujours ce qui reste pour le propriétaire après le lancement : Search Console et vérification Bing Webmaster, et le test Rich Results sur la page déployée.
Ne déployez pas sauf si l'utilisateur le demande.
9. Apprendre
Lorsque le propriétaire corrige le résultat ou énonce une préférence durable, ajoutez une ligne au fichier design/LESSONS.md du projet (créez-le si nécessaire). Si la correction montre que ces règles sont erronées pour tous les projets, corrigez aussi la règle ici.