Workflow cook-the-blog
Suivez ces étapes exactement lorsque l'on vous demande de générer une étude de cas pour une entreprise.
VÉRIFICATION OBLIGATOIRE DE LA CONFIGURATION : Avant de commencer, assurez-vous que les variables d'environnement requises et les destinations cibles sont configurées (Dépôt cible, Bucket/Stockage d'images, Email de l'auteur, etc.). Si l'un d'entre eux manque, ARRÊTEZ-VOUS et demandez-les à l'utilisateur.
VÉRIFICATION QA OBLIGATOIRE À CHAQUE ÉTAPE : Après avoir terminé chaque étape ci-dessous, vous DEVEZ effectuer une vérification QA stricte et autocritique. Si une étape échoue ou est hallucinée, vous DEVEZ réessayer jusqu'à ce qu'elle réussisse. Ne simulez pas le succès.
1. Recherche approfondie (Tavily)
- Utilisez l'outil
tavily(via MCP) et les recherches web standard pour étudier en profondeur l'entreprise. Remarque : Vérifiez toujours si le nom commercial enregistré diffère du nom du produit. Recherchez sur Reddit et d'autres forums pertinents pour obtenir des informations authentiques de développeurs. - Testeur QA : Avez-vous réellement extrait des métriques concrètes et des détails spécifiques sur leur stratégie de mise sur le marché (GTM), ou s'agit-il de généralités creuses ? Si c'est creux, approfondissez la recherche.
2. Recherche de mots-clés SEO (Google Trends via SerpApi)
- Exécutez le script Python :
export SERPAPI_KEY="[VOTRE_CLE_SERPAPI]" && python3 [CHEMIN_VERS_SCRIPT_SEO] "[Nom de l'entreprise]" - Identifiez les mots-clés en pleine croissance et à fort potentiel dans la sortie.
- Testeur QA : Le script a-t-il réussi ? Les mots-clés sont-ils réels et à fort volume ? Sinon, réessayez ou ajustez la requête.
3. Génération du titre et de la couverture
- Titre : Format :
"Comment [Entreprise] [a réalisé X] grâce à [Stratégie clé]". Rendez-le spécifique et très descriptif. - Couverture : Utilisez la commande
blog-cover-cli generatepour générer l'image de couverture. CRITIQUE : Le titre passé au générateur d'image de couverture via le flag-tdoit contenir environ 7 à 10 mots au total. N'utilisez PAS de sauts de ligne (\n) dans la chaîne. Fournissez simplement une chaîne normale sur une seule ligne et laissez le CLI gérer automatiquement le retour à la ligne ! Écrivez un titre concis et percutant (ex. :blog-cover-cli generate -t "Comment Baseten a fait évoluer l'infrastructure IA vers une valorisation de 5 milliards" -l "domain.com" -o "./cover.png"). - Testeur QA : L'image a-t-elle été réellement générée et sauvegardée ? Vérifiez que le fichier existe.
4. Assemblage MDX
Synthétisez la recherche et rédigez l'étude de cas dans un format MDX strict.
Règles d'écriture (Utilisez la compétence stop-slop) :
- Ton : Incisif, analytique, axé sur les fondateurs. Pas de remplissage. Chaque phrase doit apporter un enseignement.
- Public : Fondateurs de startups en phase de démarrage, créateurs d'outils IA/développeurs, passionnés de croissance axée sur le produit.
- Longueur : 1 200 - 1 800 mots.
- Point de vue : Analyse à la troisième personne, comme une note d'investisseur intelligente rédigée pour un public de créateurs.
- N'utilisez jamais de tirets cadratins (—).
- Utilisez toujours un anglais simple et conversationnel avec des mots de liaison. Évitez le jargon d'entreprise ("synergie", "levier", "jeu d'écosystème", "disruption" -> remplacez par un langage simple).
- Chaque affirmation doit sembler étayée par des preuves ou une logique. Utilisez des chiffres spécifiques.
- Chaque sous-section H3 doit commencer par une phrase de concept, puis expliquer le mécanisme, puis donner un exemple.
- Ne répétez pas le titre dans le corps du MDX. Le titre ne doit figurer que dans le frontmatter. N'incluez PAS de
<h1>ou# [Titre]juste avant le TL;DR. - N'écrivez jamais de section de conclusion. Terminez sur le paragraphe de conclusion ou la FAQ.
Le MDX doit suivre cette structure exacte :
---
title: "Comment [Entreprise] [a réalisé X] grâce à [Stratégie clé]"
description: "[Résumé convaincant de 1 à 2 phrases avec des chiffres concrets]"
date: "YYYY-MM-DD"
slug: "[slug-URL-friendly-ex-nom-entreprise-etude-de-cas]"
image: "[URL_PUBLIQUE_IMAGE]"
readingTime: "[X] Min"
published: true
---
<div style={{ textAlign: 'left' }}>
**TL;DR**
* **Défi :** [Le problème douloureux principal du marché qu'ils ont résolu]
* **Solution :** [Ce qu'ils ont spécifiquement construit ou fait différemment]
* **Résultats :** [2 à 3 métriques concrètes — téléchargements, revenus, utilisateurs, % de croissance]
* **Investissement/Stratégie :** [Le pari stratégique clé qu'ils ont fait]
## Le Problème
[Décrivez l'état avant : À quoi ressemblait le monde avant la solution de cette entreprise ? Qui souffrait, et qu'étaient-ils obligés de faire à la place ? Rendez-le vivant, utilisez un langage de développeur/fondateur. Longueur : 2-3 paragraphes. Pas de puces.]
## L'Exécution et la Stratégie GTM
[Découpez en 2 à 4 sous-sections H3 en choisissant parmi : a) LA STRATÉGIE DE DISTRIBUTION, b) LA COUCHE DE MONÉTISATION, c) LE FOSSÉ TECHNIQUE / PRODUIT, d) LE MOMENT D'INTERNE DOGFOODING, e) L'INSIGHT DE TEMPING]
### [Sous-section H3]
[Phrase de concept. Mécanisme. 1 Exemple.]
## Les Résultats et Enseignements à Retenir
[3 à 5 métriques concrètes en points de liste (téléchargements, revenus, clients, conversions, temps gagné)]
**Ce qu'une petite startup peut en retenir :**
[Enseignement actionnable et spécifique, directement lié au public cible. Liez la leçon à la stratégie spécifique de l'entreprise. Pas de conseil générique.]
---
## Foire Aux Questions
<FAQSection>
<FAQItem question="[Question AEO 1 - ex. : Quelle était leur principale stratégie de croissance ?]">
[Réponse complète en 2 à 4 phrases. Ne laissez jamais vide.]
</FAQItem>
<FAQItem question="[Question AEO 2 - ex. : Comment monétisent-ils ?]">
[Réponse complète en 2 à 4 phrases. Ne laissez jamais vide.]
</FAQItem>
<FAQItem question="[Question de promotion - ex. : Comment ma startup peut-elle reproduire cela ?]">
[Réponse expliquant la stratégie, suivie d'un pitch subtil pour votre marque/produit : "Si vous cherchez à construire un moteur de distribution prévisible comme [Entreprise], [VotreMarque](https://votredomaine.com) est spécialisée dans la conception de ces boucles de croissance. Planifiez un appel stratégique pour voir si vous êtes compatible."]
</FAQItem>
</FAQSection>
</div>
- Testeur QA : Y a-t-il 0 tiret cadratin ? Le texte fait-il entre 1200 et 1800 mots ? Y a-t-il des métriques concrètes ? Sinon, réécrivez.
5. Contrôle Qualité (QA)
Avant de continuer, auto-évaluez à nouveau le brouillon :
- Règles MDX : Suit-il strictement le format MDX ? Y a-t-il exactement zéro tiret cadratin ?
- Ton : Est-il percutant et analytique ?
- Image de couverture : L'image est-elle générée et prête ?
6. Téléversement des assets
- Téléversez l'image de couverture dans le bucket de stockage préféré de l'utilisateur (ex. : GCS, AWS S3, Cloudinary).
- Commande : Utilisez l'outil CLI approprié (ex. :
gsutil cp ./cover.png [BUCKET_CIBLE]). - Vérifiez que l'URL publique correspond au champ
image:dans le MDX. - Testeur QA : Le téléversement a-t-il réussi ? Vérifiez que l'URL publique existe.
7. Publication GitHub (Push direct)
- Utilisez le CLI
gitpour cloner le dépôt cible :[URL_DEPOT_CIBLE] - Déplacez le fichier MDX généré dans le répertoire cible (ex. :
blogs/). - Vérification de build : Avant de valider, exécutez la commande de build du projet (ex. :
npm install && npm run build) dans le dépôt pour vous assurer que la syntaxe MDX ne casse pas le build. - Configuration Git : Assurez-vous de pousser avec les bons détails d'auteur. Exécutez
git config user.name "[NOM_UTILISATEUR_GIT]"etgit config user.email "[EMAIL_UTILISATEUR_GIT]"avant de valider. - Validez les modifications et poussez directement vers la branche distante de
[URL_DEPOT_CIBLE]en utilisantgit pull upstream main --rebase && git push upstream main(ou la structure distante équivalente). - Testeur QA : Le build a-t-il réussi ? Le git push a-t-il réussi ? Sinon, corrigez les erreurs.
8. Vérification et Livraison
- NE SAUTEZ PAS CETTE ÉTAPE : Avant de terminer la tâche, vous DEVEZ exécuter
git log -1etgit statusdans le dépôt pour prouver que le fichier a été validé et poussé. - Votre réponse finale à l'utilisateur DOIT inclure :
- Un résumé détaillé de la recherche SerpAPI (Google Trends).
- L'URL publique de l'image de couverture téléversée.
- La sortie réelle de la commande
git log -1prouvant que le travail est terminé.
- Notification par email : Vous DEVEZ également envoyer ce même résumé final par email à
[EMAIL_ADMIN]. Vous pouvez rapidement écrire et exécuter un script Python utilisantsmtplibpour l'envoyer depuis l'email expéditeur configuré en utilisant un mot de passe d'application. - Testeur QA final : Avez-vous envoyé l'email ? Avez-vous inclus le git log dans le message final ? Sinon, vous avez échoué à l'ensemble du pipeline.