Cinq flux de travail que l'équipe Okou fait tourner chaque semaine. Chacun montre la mise en place, le prompt, le livrable que Okou produit et le temps qu'il rapporte.
Le but n'est pas de les copier tels quels, mais de voir la forme d'un flux Okou complet et de l'adapter à votre propre travail.
1. Briefing du matin
La douleur. Chaque matin commence par un rattrapage : ouvrir Slack, parcourir les @mentions, vérifier l'agenda, jeter un œil aux PR ouvertes. Vingt minutes avant la première vraie tâche.
Mise en place. Une planification, en semaine à 8 h. Connecteurs : Slack, GitHub, Google Agenda.
Prompt.
« Chaque jour ouvré à 8 h heure de Pékin, envoie-moi un DM avec quatre sections :
- Les @mentions Slack non lues des dernières 24 heures, avec des résumés d'une ligne
- Les issues GitHub qui me sont assignées, triées par ancienneté, avec statut et dernier commentaire
- L'agenda du jour — titres des réunions, horaires, et le document Notion pertinent s'il est lié
- Une proposition de priorité pour la journée, d'après ce qui est en retard ou bloque les autres »
Ce que vous recevez. Un DM Slack à 8 h, en général 200 à 350 mots. Chaque section est courte, les chiffres sont concrets, les liens sont intégrés. La « priorité proposée » varie — parfois c'est une PR évidente, parfois une préparation de réunion qui demande plus d'attention que la journée n'en offre.
Ce que ça rapporte. Environ 20 minutes par jour, plus le coût cognitif de jongler entre quatre outils dès le réveil.
Variantes. Ajoutez une cinquième section pour les nouvelles inscriptions clients, ou pour les erreurs de production remontées par Sentry. Remplacez le DM Slack par un e-mail si vous préférez des matins sans notifications.
2. Veille concurrentielle hebdomadaire
La douleur. Savoir ce que les concurrents ont livré la semaine passée est utile. Vérifier à la main trois comptes X, trois changelogs, trois pages de tarifs et une liste de blogs est une corvée qui saute discrètement.
Mise en place. Un flux de travail (competitor-scan) plus une automatisation planifiée le lundi matin. Connecteurs : X et Notion. La recherche web ne demande rien à connecter — c'est un service géré.
Prompt.
« Passe en revue @competitor1, @competitor2, @competitor3 sur X et leurs changelogs depuis lundi dernier. Recoupe avec leurs pages de tarifs et leurs éventuels articles de blog. Compare avec la base de la semaine dernière (page Notion "Competitor State"). Publie un digest dans
#competitor-intelen mettant en avant : nouvelles fonctionnalités, changements de prix, signaux de recrutement, et tout ce qui est notable dans le ton ou le discours. »
Ce que vous recevez. Un fil Slack le lundi matin. Message principal : une synthèse en cinq points. Réponses : une section par concurrent avec les mises à jour citées et les liens. La page Notion de référence est mise à jour automatiquement, pour que la comparaison de la semaine suivante reparte d'une base fraîche.
Ce que ça rapporte. Environ 90 minutes par semaine, plus la charge mentale diffuse du « il faudrait que je regarde où en est Acme ».
Variantes. Ajoutez Reddit et Hacker News pour le ressenti de la communauté. Ajoutez une rétrospective trimestrielle qui condense les écarts de l'année en une diapositive prête pour le conseil.
3. Tri des bugs
La douleur. Quelqu'un dépose une capture ou une description vague dans #bug-report. Il faut en faire une vraie issue GitHub avec des étapes de reproduction, une sévérité, un label et une équipe. Cette étape de formalisation est petite mais permanente.
Mise en place. Un flux de travail (triage-bug-report), lancé à la main par Okou dans #bug-report. Connecteurs : Slack, GitHub.
Prompt (dans le canal) :
« Okou trie ça — extrais les étapes de reproduction des captures et du fil, cherche des issues GitHub liées, classe la sévérité (P0–P3), attribue à l'équipe la plus probable d'après les chemins de fichiers ou les symptômes, et ouvre une nouvelle issue si ce n'est pas un doublon. Réponds dans ce fil avec le lien. »
Ce que vous recevez. Une réponse en fil en une minute environ : un lien d'issue GitHub, la sévérité retenue avec une justification d'une ligne, une liste de 2 à 3 issues liées pour le contexte, et l'équipe attribuée. Si Okou estime que c'est un doublon, il publie le lien de l'issue d'origine au lieu d'en créer une nouvelle.
Ce que ça rapporte. Sur une semaine chargée, c'est la différence entre un suivi d'issues propre et une pile de captures Slack non triées.
Variantes. Ajoutez une étiquette « visible client » selon que la personne qui signale vient ou non de l'extérieur. Alertez automatiquement l'astreinte pour les P0.
4. Brouillon de réponse client
La douleur. Un e-mail client demande une réponse utile, fidèle à la marque et ancrée dans la documentation. Cinq minutes par e-mail × 30 e-mails par semaine, c'est un vrai coût.
Mise en place. Un flux de travail (customer-reply-draft), lancé à la main en transférant un e-mail à Okou ou en le collant dans le chat. Connecteurs : Gmail, Notion (ou votre centre d'aide), Stripe (pour la facturation), Linear (pour les problèmes connus).
Prompt.
« Le client a écrit cet e-mail [coller]. Lis ses trois derniers tickets, cherche la section pertinente dans notre documentation, vérifie dans Linear s'il existe des problèmes connus correspondant à son signalement, et regarde dans Stripe le contexte de facturation. Rédige une réponse dans sa langue. Cite la section de doc. Reste sous 150 mots. Reprends le ton de notre dernière réponse de support à cette personne. »
Ce que vous recevez. Un brouillon de réponse avec les sources liées en bas — en général deux ou trois liens de doc, plus un avertissement du style « Linear ENG-4422 est un problème connu là-dessus ; échéance la semaine prochaine. » Vous parcourez, ajustez une ligne, envoyez.
Ce que ça rapporte. Environ 3 à 4 minutes par e-mail. Sur une semaine de support, cela fait des heures.
Variantes. Détectez automatiquement le niveau du client via Stripe et faites relire les réponses VIP par une personne désignée. L'e-mail arrive toujours en brouillon dans votre compte pour qu'un humain l'envoie : c'est à l'étape de relecture que vous décidez du niveau d'examen selon le palier.
5. Production de contenu hebdomadaire
La douleur. Le marketing veut un article de blog, trois publications LinkedIn et un jeu de cartes sociales chaque semaine. Chaque pièce a besoin de contexte issu de la recherche et du contenu existant. Coordonner tout ça entre les outils demande plus de travail que l'écriture.
Mise en place. Un flux à plusieurs étapes (weekly-content) sur une automatisation planifiée le vendredi après-midi. Connecteurs : Notion (recherche), Plausible (analytics), Fal (génération d'images), Loops (e-mail).
Prompt.
« Chaque vendredi à 14 h, fais ceci :
- Lis les nouveaux documents Notion de la semaine dans la base "Marketing Inputs"
- Recoupe avec les sujets de blog de la semaine dernière pour éviter les redites
- Rédige un article de blog de 800 mots sur le sujet le plus opportun ; enregistre-le dans Notion sous "Blog Drafts"
- Rédige trois variantes LinkedIn de la même idée — un essai, une liste, une histoire personnelle
- Génère trois cartes sociales carrées dans notre style de marque
- Publie l'ensemble dans
#marketingpour relecture »
Ce que vous recevez. Un seul message Slack le vendredi après-midi contenant les six livrables intégrés. Le brouillon de blog pointe vers une page Notion déjà mise en forme. Les brouillons LinkedIn sont prêts à copier-coller. Les cartes sociales sont téléchargées et prêtes à joindre.
Ce que ça rapporte. Environ une demi-journée de coordination hebdomadaire. Les éditeurs relisent et publient ; ils ne rédigent pas.
Variantes. Ajoutez un test A/B où Okou génère deux titres et les teste auprès d'un petit public via Loops. Ajoutez une vérification Plausible des sujets les plus performants de la semaine passée pour orienter le choix du sujet.
Chacun de ces flux a demandé 10 à 30 minutes de mise en place. Ensuite, ils rapportent chaque jour ou chaque semaine. Le coût correspond à peu près aux crédits consommés par chaque exécution — visibles sur la page Facturation. Voir Crédits et facturation pour le calcul.
Pour construire votre propre version, copiez l'un de ces prompts, remplacez les noms de vos outils et de vos canaux, et essayez. Itérez à partir du résultat.
Pour un ensemble plus large, la bibliothèque de flux publique liste chaque exemple avec les connecteurs qu'il demande, le prompt qui le lance et les étapes que Okou exécute.