13 points par hongyeon 2025-12-08 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Bonjour. J’ai étudié l’archéologie à l’université, mais je suis devenu ingénieur développeur pour essayer de résoudre un travail manuel sans fin — littéralement du terrassement et du labeur répétitif.

Après une longue réflexion, je partage en open source un moteur d’automatisation de newsletter (LLM Newsletter Kit) que j’ai conçu avant tout pour mon propre usage.

Aujourd’hui, ce moteur constitue le cœur de ma newsletter sur le patrimoine culturel, « Research Radar ». Il est optimisé pour maintenir un taux de clics (CTR) de 15 %, tout en gardant le coût d’API LLM à environ 0,20 $ par envoi.

Ce n’est pas un simple agrégateur de liens, mais un pipeline dans lequel le LLM analyse et résume des connaissances d’un domaine spécialisé afin de fournir des insights.

Contexte de développement et retour honnête

Comme il est basé sur du code, je pense qu’il pourrait ne pas être largement adopté par le grand public en raison d’une barrière à l’entrée plus élevée que les outils no-code. Dès le départ, mon objectif n’était pas tant de créer quelque chose de massivement utilisé que de répondre à un besoin très concret que j’avais moi-même.

Au début, c’était une « newsletter spécialisée patrimoine culturel » que j’avais créée uniquement pour moi. Ensuite, j’ai ouvert le service pour que tout le monde puisse s’y abonner.

En le développant, j’ai constaté que le code source et la logique métier propre au domaine du patrimoine culturel étaient trop fortement couplés. Pour résoudre ce problème, je les ai abstraits avec une structure de DI (injection de dépendances) afin de les séparer en une bibliothèque utilisable par tous.

npm i @llm-newsletter-kit/core

Aujourd’hui, mon propre service a lui aussi abandonné l’ancien code legacy fortement couplé et fonctionne après migration sur ce cœur open source.

Philosophie de conception : "Logic in code, reasoning in AI"

Si j’ai choisi le code plutôt que les outils no-code, c’est à cause de ma philosophie de conception : « la logique dans le code, le raisonnement dans l’IA, les connexions dans l’architecture (Logic in code, reasoning in AI, connections in architecture). »

Les outils no-code sont pratiques, mais leurs limites devenaient évidentes dès qu’il s’agissait d’implémenter une logique complexe. J’ai donc gardé le contrôle des workflows décisifs dans un code type-safe (TypeScript), tout en ne confiant au LLM que l’analyse intelligente, ce qui m’a permis d’implémenter des logiques sophistiquées comme l’auto-réflexion (self-reflection) ou la vérification en plusieurs étapes.

Principales caractéristiques

Conception Type-First & DI : écrit en TypeScript, avec toutes les étapes — crawling, analyse, génération, etc. — fondées sur des interfaces Provider, ce qui permet de remplacer les composants comme on changerait des pièces.

Bring Your Own Scraper : aucun verrouillage à une bibliothèque spécifique. Vous pouvez injecter de façon asynchrone ce que vous voulez, comme Puppeteer, Cheerio ou même un parseur basé sur l’IA.

Production Ready : conçu pour une exploitation réelle, avec logique de retry, options de chaînage et 100 % de couverture de tests.

Liens

Merci. Les retours sont toujours les bienvenus !

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.