Contexte
N'importe qui — créateur, marketeur, journaliste, investisseur, ou simplement curieux d'un sujet de niche — suit aujourd'hui 30+ sources réparties sur YouTube, TikTok, Instagram, Twitter/X, Telegram, Substack, podcasts, RSS. La promesse "rester à jour" devient mathématiquement intenable. Les agrégateurs classiques (Feedly, Inoreader) listent des liens. ALLIN va plus loin : il résume, priorise, et personnalise.
J'aime ce projet parce qu'il touche à beaucoup de couches : modélisation de données, scraping multi-plateforme, LLMs en parallèle, edge computing, billing, transactionnel, delivery email. Un projet "couteau suisse" — exactement le type de problème où je suis à l'aise.
Le challenge métier
Construire un produit qui scale techniquement (chaque utilisateur = une matrice unique de sources × préférences) sans exploser le coût marginal LLM. La réponse architecturale : déduplication agressive en amont, résumés réutilisables, personnalisation au moment du delivery.
Le flow — du sign-up au briefing du matin
Deux flows imbriqués : un parcours utilisateur côté front (inscription + sélection des sources + billing) et un pipeline opérationnel automatisé qui tourne chaque nuit pour livrer le briefing à 7h.
- 1. Inscription — l'utilisateur arrive sur une des 5 landing Astro A/B testées et crée son compte.
- 2. Sélection de sources — il choisit les comptes/podcasts/feeds qu'il suit parmi 9 plateformes (YouTube, TikTok, Instagram, X, Telegram, Substack, podcasts, RSS).
- 3. Billing — Lemon Squeezy gère le paiement (freemium ou premium) et déclenche l'activation via webhook.
- 4. Pipeline nocturne — scraping — un cron VPS pull les nouveaux contenus de toutes les sources suivies via les 9 scrapers.
- 5. Transcription — Whisper (Workers AI) transforme l'audio des podcasts et vidéos en texte.
- 6. Résumé LLM — 4 LLMs en parallèle (GPT-4, Claude, Grok, Gemini) génèrent un résumé brut par contenu. Le résultat est mis en cache KV — un même contenu suivi par 100 users n'est résumé qu'une fois.
- 7. Assemblage personnalisé — au moment du delivery, le Worker compose le briefing en piochant uniquement les résumés des sources de l'utilisateur.
- 8. Podcast custom — TTS xAI génère une version audio personnalisée (stockée sur R2, lifecycle 7 jours).
- 9. Email 7h — Resend délivre le briefing HTML + lien podcast dans la boîte de l'utilisateur.
landing Astro A/B"] U1 --> U2["2. Sélection sources
9 plateformes possibles"] U2 --> U3["3. Billing Lemon Squeezy
freemium / premium"] end subgraph P["Pipeline nocturne (cron VPS)"] P1["4. Scraping
9 scrapers multi-plateforme"] P1 --> P2["5. Transcription Whisper
audio → texte"] P2 --> P3["6. Résumé LLM
4 modèles en parallèle"] P3 --> P4["Cache KV
résumés mutualisés"] end subgraph D["Delivery 7h"] D1["7. Assemblage personnalisé
Worker compose le briefing"] D1 --> D2["8. Podcast TTS xAI
R2 lifecycle 7j"] D2 --> D3["9. Email Resend
briefing + lien podcast"] end U3 -.active user.-> P1 P4 --> D1
Stack technique
- Cloudflare Workers (Hono + TypeScript)
- D1 SQL (SQLite distribué)
- KV namespace (cache résumés)
- R2 bucket (rapports + MP3, lifecycle 7j)
- Workers AI (Whisper + embeddings BGE)
- YouTube RSS · TikTok · Instagram
- Twitter/X · Telegram Bot (MTProto)
- Substack · Podcast RSS
- Puppeteer + gstack headless
- GPT-4 / Claude / Grok / Gemini
- Triple moteur recherche : Brave + Serper + Grok
- Transcription Whisper (Workers AI)
- TTS xAI pour podcast personnalisé
- Astro + Alpine.js + Tailwind
- 5 landing pages A/B testées (lp1-5)
- Lemon Squeezy (paiement + webhooks)
- Resend (email transactionnel + digest)
3 décisions d'architecture clés
1. Edge computing pour le delivery, VPS pour le scraping
Les Workers Cloudflare sont parfaits pour servir des requêtes à faible latence et faire la composition finale
des briefings. Mais ils ne sont pas faits pour des jobs longs (10 minutes de scraping vidéo). J'ai donc
migré les crons vers un VPS daemon, en gardant le Worker comme façade API exposée
/api/run-pipeline avec ADMIN_TOKEN. Découplage propre.
2. Résumés mutualisés en KV, briefings personnalisés au delivery
Le même YouTube vidéo regardé par 100 utilisateurs n'a pas besoin d'être résumé 100 fois. Le résumé brut
(LLM) est mis en cache KV avec une clé content_id.
Au moment du delivery, le Worker assemble un briefing personnalisé en piochant uniquement les
résumés des sources que cet utilisateur suit. Coût marginal LLM : O(content) plutôt que O(content × users).
3. Lifecycle automatique R2 — 7 jours puis suppression
Les briefings HTML et les podcasts MP3 personnalisés sont stockés sur R2 avec une règle de lifecycle "auto-delete > 7 jours". Aucun nettoyage manuel, aucun risque de bill surprise. C'est l'équivalent d'un trigger Apex "scheduled delete" mais géré au niveau infra.
Résultats
Lien direct avec Salesforce
ALLIN est une mini-org Salesforce multi-tenant. Voici la cartographie :
- Schéma users → creators → contents → briefings = Accounts → Contacts → Opportunities → Tasks Sales Cloud.
- Lemon Squeezy webhook → activation utilisateur → premier email = Flow déclenché sur Opportunity Closed Won.
- 9 scrapers externes = Salesforce Connector / MuleSoft / Platform Events ingérant des sources tierces.
- Résumés LLM personnalisés = Einstein GPT pour générer du texte custom par compte.
- 5 landings A/B = Experience Cloud pages variants avec analytics intégrées.
- Plan gratuit / payant via Lemon Squeezy = Profiles & Permission Sets avec gating sur des features.
Lessons learned
- Les Workers ne sont pas faits pour les jobs longs — découpler scraping (VPS) et delivery (Worker) m'a sauvé des time-outs récurrents.
- 4 LLMs n'est pas un luxe — Grok est meilleur sur la fraîcheur, Claude sur le résumé, GPT sur la rédaction, Gemini sur le multilingue. Choisir au cas par cas, pas au global.
- Le pricing freemium est un sujet métier, pas technique — j'ai itéré 4 fois sur le seuil gratuit avant de trouver un équilibre. La tech n'a pas changé d'une ligne.
- Le canal email reste sous-coté — un briefing à 7h dans la boîte mail bat tous les pushs notifications combinés en rétention.