Bot de veille IA :
de l'idée à la prod

Comptes X/Twitter ─┐
                   ├─► twitterapi.io ─► API Claude (résumé FR) ─┬─► Telegram (push quotidien)
RSS (feeds.txt) ───┘                                            └─► feed.json ─► site (archive)
                          ⏰ déclenché chaque matin par GitHub Actions

1. Le déclic / le besoin de départ

Je voulais suivre l'actualité IA (labos, modèles, outils, recherche) sans y passer du temps ni me noyer dans le hype. Avec un angle qui m'est propre : couvrir l'IA globale et surtout l'IA utile aux marchands / dirigeants — le concret pour une boîte.

Un cas réel m'avait déjà mis sur la piste : un LLM me rédige chaque matin une revue de presse hi-fi à partir d'une trentaine de sources. La veille IA, c'est la généralisation de cette mécanique.

Double finalité dès le départ :

• un canal Telegram (t.me/VeilleIA_HL) — push quotidien, éphémère ;
• une archive publique sur le site (page « Veille IA ») — permanente, optimisée SEO/GEO, citable par les IA.

2. L'idée → le cadrage (décisions, alternatives écartées)

• Deux repos séparés (veille-ia = moteur, knowledge-hub = site) — pour isoler les secrets (clés API, token bot) du site public. Écarté : tout mettre dans le repo du site, secrets exposés.
• Bot = moteur de données / Site = affichage, reliés par un seul feed.json — séparation des responsabilités. Écarté : le site qui collecte/résume lui-même.
• Lecture de feed.json au runtime (fetch navigateur), pas au build — un push de feed.json se reflète sans redéploiement. Écarté : régénérer le site à chaque màj.
• Page archive ≠ Telegram — l'archive est permanente, Telegram est éphémère. Écarté : compter sur le seul historique Telegram.
• Renommage « Flux IA » → « Veille IA » + URL /veille-ia/ (redirection depuis /flux-ia/) — terme métier plus juste, meilleur ancrage SEO/GEO. Écarté : « Flux IA », « Radar IA ».
• Média des tweets : embed X officiel + repli automatique vignette+lien — les embeds X sont fragiles, l'utilisateur n'est jamais bloqué. Écarté : l'embed seul (casse souvent).
• Résumés FR transformatifs, jamais le tweet recopié — règle copyright dure. Écarté : recopier le tweet (interdit).

3. Le « vibe coding » : comment ça s'est construit, étape par étape

Le projet s'est fait en deux temps : un cadrage en chat (les décisions ci-dessus, formalisées dans des MD de handoff), puis la construction réelle du code avec Claude Code dans le repo veille-ia.

Le pipeline construit (veille/) :

1. twitter.py — récupère les tweets récents par compte via twitterapi.io (+ advanced_search pour le backfill).
2. Filtrage — retire le bruit (retweets, réponses, hors fenêtre).
3. feed.py — Claude (rôle « rédac-chef neutre, anti-hype ») sélectionne les sujets marquants et produit des entrées structurées via JSON Schema imposé. Les champs factuels (URL, date, média, auteur) ne sont pas confiés à Claude : ils sont relus depuis le tweet source par son index [n].
4. digest.py — rédige le digest Telegram.
5. telegram.py — publie (avec découpage des messages > 4096 caractères).
6. main.py — orchestre les deux sorties depuis la même collecte.
7. backfill.py — génère le feed.json initial (mai 2026), borné en budget.

Le tout tourne sans serveur : deux workflows GitHub Actions (veille.yml quotidien à 05:00 UTC ≈ 7h Paris, et backfill.yml manuel).

4. La stack + les outils

• twitterapi.io — collecte des tweets (Twitter ayant fermé ses accès gratuits). Facturé à l'usage, quelques centimes/jour. Clé <TWITTERAPI_IO_KEY>.
• RSS (feeds.txt) — sources complémentaires hors X.
• API Claude (Anthropic) — sélection éditoriale + résumés FR neutres. Modèle claude-opus-4-8 (réglable sur claude-sonnet-4-6 pour réduire le coût). Clé <ANTHROPIC_API_KEY>.
• Telegram Bot API — push du digest. Token <TELEGRAM_BOT_TOKEN>, canal t.me/VeilleIA_HL.
• GitHub Actions — le planificateur (1 run/jour) qui orchestre collecte → résumé → 2 sorties.
• GitHub (veille-ia) — moteur + secrets. GitHub Pages (knowledge-hub) — le site.
• feed.json — le contrat de données entre les deux repos (cumulatif). seen.json — la mémoire de déduplication.
• Bridge cross-repo — en fin de job, veille-ia committe/pousse feed.json dans knowledge-hub via un PAT dédié <KH_REPO_TOKEN>.

5. Les galères (ce qui a cassé et comment on a réglé)

Reconstruites fidèlement depuis le code + l'historique Git du repo.

• Le bridge cross-repo qui se battait avec lui-même. Premier réflexe : rebase avant de pousser feed.json. Résultat → conflits add/add. → Notre feed.json étant la source de vérité, on écrase la version du site : git reset --hard origin/main puis copie + push, avec 3 tentatives de resync. (commits 7cf2157 → ec80ca4)
• Telegram qui bloquait tout. Bot non-admin du canal (403 "bot is not a member") ou pépin réseau → toute la livraison tombait, y compris le feed.json. → Envoi Telegram non-bloquant (try/except) et optionnel : pas de Telegram configuré → on saute, mais on produit quand même le feed. (commits 500a8ce, e9717d1)
• Le nom de secret qui ne collait pas. Le code attendait TELEGRAM_CHAT_ID, le secret s'appelait TELEGRAM_CHANNEL_ID. → Alias accepté des deux côtés. (commit e9717d1)
• Workflow GitHub Actions invalide. Un secrets.* dans un if: d'étape — interdit par GitHub. → Le garde-fou « token absent → on saute » déplacé dans le script ([ -z "$KH_REPO_TOKEN" ]). (commit ba581b3)
• Backfill déséquilibré. Sans quota, quelques comptes bavards mangeaient tout le budget. → Quota par compte (collecte équitable sur ~45 comptes) + garde-fou global strict sur le total. (commit 00afa3f)

6. Temps passé (réel) et tokens / coût

Temps. Cadrage (archi 2 repos, contrat feed.json, stack, garde-fous) étalé sur plusieurs courts échanges, formalisé dans deux MD de handoff. Mise en route le 31 mai 2026 (comptes + secrets), d'après l'horodatage de mes captures : ~15h14–15h19 (compte twitterapi.io + 1ᵉʳ secret), ~18h44–18h50 (bot Telegram via BotFather + 3 secrets), ~23h42–23h43 (4ᵉ secret + écran « pas encore de workflow »). Amplitude ~8h30 sur la soirée — mais ce sont des écarts d'horloge entre captures, pas du temps de travail effectif. Le travail réel bout à bout (créer les comptes, coller les 4 secrets, brancher le workflow) se compte en dizaines de minutes, pas en heures.

Coût (contrairement au site, ici on paie à l'usage) :

• twitterapi.io : 100 € en prépayé « pour voir » — alors que Claude me conseillait de démarrer à zéro. C'est un plafond de confort, pas une dépense : la conso réelle pour ~45 comptes reste de l'ordre de quelques centimes/jour, donc ces 100 € durent très longtemps.
• API Claude : un digest quotidien = une poignée de centimes. claude-opus-4-8 par défaut ; claude-sonnet-4-6 pour réduire encore.
• GitHub Actions : gratuit dans la limite des dépôts publics.
• Garde-fous budget : 1 run/jour, caps RSS/tweets, solde prépayé bas, backfill borné (pas de boucle sur advanced_search, plafond strict ~1500 tweets). Voir aussi Combien coûte l'IA.

7. Ce que ça illustre

• Un agent utile tient en ~300 lignes et 0 serveur. Collecte → résumé par l'API Claude → double publication, orchestré par un cron GitHub Actions gratuit. Pas d'infra à gérer. (C'est quoi un agent ? → le guide.)
• La bonne architecture évite les galères. Séparer moteur et affichage, isoler les secrets, figer un contrat de données : la plupart des bugs restants ont été des détails d'intégration, pas des trous de conception.
• On garde l'humain (et le LLM) honnêtes. Champs factuels relus depuis la source ; copyright respecté (résumé FR, jamais de recopie) ; ligne éditoriale neutre et anti-hype, même quand l'info n'est pas flatteuse pour Anthropic.

À venir / la suite

• Documenter le projet Telegram / veille IA (guide pas-à-pas « Mon agent de veille IA »).
• Post épinglé d'accueil sur le canal Telegram.
• Page Guides filtrable par tag côté site.
• Com LinkedIn : annoncer le projet et le suivre dans la durée — deux bons cas d'usage concrets, chiffrés en temps et en coût.