vendredi 24 avril 2026Connexion →
21 SOURCES ACTIVES+256 / 7J
Fellow
La veille de l'intelligence artificielle

À propos

Méthodologie

Fellow agrège, traduit et hiérarchise la production éditoriale des labs et des analystes IA. Cette page détaille exactement d'où viennent les données, comment elles sont transformées, et ce que Fellow ne fait pas.

Sources d'items

Le catalogue est défini dans src/lib/ingest/sources.ts et visible en temps réel sur /sources. Trois types d'adapters :

Flux RSS / Atom

API structurées

  • arXiv — endpoint officiel Atom pour les catégories cs.AI, cs.LG, cs.CL
  • Hacker News — hacker-news.firebaseio.com, top stories filtrées sur mots-clés IA

Pages index parsées par un agent

Pour les labs sans flux RSS exploitable, Fellow fetch la page index (max 512 Ko) et demande à Claude Sonnet 4.6 d'extraire la liste d'articles sous forme JSON structurée ({url, title, published_at?}). Chaque URL extraite est validée par rapport au domaine officiel du lab.

Pipeline d'ingestion

Un cron Vercel hit /api/ingest trois fois par jour (07:00, 13:00, 19:00 UTC). Pour chaque run :

  1. Fetch parallèle de toutes les sources avec timeout individuel de 20 s.
  2. Dédoublonnage par URL dans le batch, puis batch-query Supabase pour écarter les URLs déjà ingérées.
  3. Enrichissement concurrent (5 workers) via Claude Sonnet 4.6 — au plus 30 items par run, budget temps 240 s pour rester sous les 300 s max de Vercel.
  4. Extraction og:image en parallèle : fetch de la page article (max 256 Ko), extraction de og:image / twitter:image / image_src par regex. Taux de couverture observé : ~70 %.
  5. Upsert sur la table items(UUID stable dérivé de l'URL canonique).
  6. Invalidation des caches ISR des pages publiques si au moins un item écrit.

Fenêtre glissante : les queries publiques ne retournent que les items ingérés dans les 35 derniers jours. Les articles sauvegardés via l'étoile persistent au-delà de cette fenêtre dans ton localStorage.

Enrichissement éditorial

Chaque item passe par Claude Sonnet 4.6 avec un prompt système qui impose un ton neutre de desk de rédaction (pas de style personnel, pas de familiarité). Claude retourne un JSON strict :

  • title_fr, dek_fr, summary_fr — traduction fidèle et résumé dense en français.
  • classification parmi : recherche, marché, outils, opinion, policy, signal, safety.
  • tags — 2 à 5 étiquettes FR/EN tech.
  • signal_heat (0-100) — à quel point ça buzze (breaking = 85-100).
  • signal_relevance (0-100) — pertinence pour un créateur de contenu IA.
  • signal_novelty (0-100) — nouveauté technique ou stratégique.

Limite connue : la heatest une estimation subjective de Claude, pas un score agrégé de mentions cross-sources. L'ordre d'affichage du feed et du briefing est pour le moment purement chronologique (récence), pas par signal.

Briefing quotidien

Le chapeau qui apparaît en haut de la une (« {résumé} ») est généré à chaque revalidation ISR (toutes les 5 minutes max) par Claude Sonnet 4.6 à partir de :

  • Nombre d'items ingérés sur les 24 dernières heures.
  • Nombre de signaux forts (signal_heat ≥ 85).
  • Le top 3 par récence (titre + chapeau).

Contraintes : deux phrases max, 280 caractères, ton factuel, pas de tiret cadratin. Si l'API Claude est indisponible, un fallback template basé sur les compteurs prend le relais.

Profils d'entités

Chaque acteur listé dans /entities a un profil tiré intégralement de Wikidata. Une fonction SPARQL pointe vers l'identifiant Q-ID de l'entreprise et récupère :

  • P571 date de fondation · P159 siège · P17 pays · P1128 effectif (+ année) · P452 secteurs
  • P749 maison mère · P112 fondateurs · P169 CEO · P856 site officiel · P154 logo Wikimedia Commons
  • P2226 capitalisation boursière · P2139 revenus (convertis approximativement en EUR)

Le cron /api/refresh-profiles tourne une fois par mois (1er à 04:00 UTC) et rafraîchit les 9 Q-IDs mappés dans src/lib/wikidata/qids.ts. Les champs non renseignés côté Wikidata apparaissent comme « — » (typiquement la capitalisation pour les sociétés non cotées).

Le graphe de personnes de chaque entité est dessiné à partir du champ founders et ceode Wikidata. Pas de scraping LinkedIn, pas d'inférence.

Post LinkedIn

Le bouton POST LINKEDIN (admin) appelle Claude Opus 4.7 avec le guide de style Gabriel (fichiers skills/gabriel-writing-style/SKILL.md + references/style-guide.md) chargé en system prompt. Contraintes injectées : 800-1500 caractères, hook fort en ouverture, jamais de tiret cadratin ni de hashtag, clôture par une question ouverte.

Ce que Fellow ne fait PAS

  • Pas de scraping d'utilisateurs, de profils LinkedIn, ou de X/Twitter. Les mentions d'auteurs viennent exclusivement des flux RSS qu'ils publient eux-mêmes ou des crédits dans Wikidata.
  • Pas de tracking comportemental. Aucune analytics côté client. Seuls tes sauvegardes et préférences restent en localStorage sur ton appareil.
  • Pas de récupération de cap-table ou d'actionnariat détaillé. Ces données ne sont pas ouvertes pour les labs privés (OpenAI, Anthropic, xAI). Fellow affiche uniquement ce qui est public sur Wikidata.
  • Pas de décision humaine dans la boucle d'ingestion. Les traductions, résumés et scores sont produits à 100 % par Claude. Des erreurs sont inévitables (classification imparfaite, heat parfois sur-évaluée).

Stack technique

  • Next.js 16 (App Router, ISR 5 min sur les pages publiques) sur Vercel.
  • Supabase Postgres avec RLS — public read, admin write (magic-link sur email autorisé).
  • Vercel AI Gateway pour les appels Claude (cache + comptabilité).
  • Anthropic SDK— Sonnet 4.6 pour l'enrichissement, Opus 4.7 pour la génération de posts.
  • Wikidata SPARQL(endpoint public, pas d'auth) pour les profils d'entités.

Contact · desbouis.lgabriel@gmail.com