Comment j’ai monté ma newsletter perso avec des agents IA

Je suis abonné à pas mal de newsletters.

Et souvent, j’ai la même réaction.

J’ouvre. Je scroll. Je vois une pile de liens. Je me dis “ok, je lirai ça plus tard”. Et évidemment, je ne le lis jamais.

Le problème n’est pas le sujet. Le problème, c’est le travail laissé au lecteur.

On appelle ça de la veille. En vrai, c’est souvent juste une liste.

Du coup, j’ai eu envie de construire un format différent. Pas une newsletter “plus smart”. Pas une newsletter “boostée à l’IA”. Juste une newsletter qui fait vraiment le boulot de tri, de condensation et de reformulation.

Et surtout, je voulais comprendre si ce système pouvait tourner proprement chaque semaine sans devenir une usine à gaz.

Le cahier des charges

Je voulais quelque chose d’assez simple :

• 3 à 4 actus max
• des sujets IA, mobile, produit, distribution
• des liens source propres
• une leçon claire derrière chaque actu
• un ton humain
• un email assez court pour être lu en une seule fois

Donc l’objectif n’était pas “faire une newsletter”. L’objectif, c’était plutôt :

construire une petite chaîne éditoriale qui transforme du bruit web en signal utile.

Le principe général

Le système repose sur une idée très simple :

1. un cron lance la routine
2. un agent cherche les actus des 7 derniers jours
3. il garde seulement 3 ou 4 signaux solides
4. il reformule chaque actu avec une leçon utile
5. il produit l’email HTML
6. il prépare au passage des idées de posts pour LinkedIn
7. puis la stack d’envoi expédie le digest

Dit comme ça, ça sonne un peu technique. En pratique, c’est surtout une checklist bien rangée.

La brique 1 : le cron

La routine tourne avec un cron hebdo.

Son rôle n’est pas de “penser”. Son rôle est juste de déclencher la bonne séquence au bon moment.

Concrètement, le cron charge un brief Markdown qui sert de source de vérité. Dans ce brief, je définis :

• le type d’actus à chercher
• la fenêtre temporelle
• le format attendu de l’email
• les garde-fous de voix
• le format des idées de posts à stocker
• la logique d’envoi

J’aime bien cette approche parce qu’elle reste lisible. Tu peux ouvrir le fichier et comprendre ce que le système est censé faire sans lire 300 lignes de code.

La brique 2 : la recherche web

Ensuite, l’agent part chercher les infos.

Là, je ne lui demande pas “trouve des news tech”. Je cadre beaucoup plus que ça.

Je lui demande de chercher des signaux pertinents pour quelqu’un qui build des apps :

• IA appliquée au build
• mobile
• App Store / Play Store
• monétisation
• outils utiles pour builders

Et surtout, je lui demande de revenir avec des sources datées et des URLs propres.

Ça paraît banal, mais c’est un point critique. Si tu ne forces pas cette discipline, tu obtiens vite un digest rempli de hype, de reprises molles, ou de trucs déjà vus 40 fois.

La brique 3 : le filtre éditorial

C’est là que le système devient intéressant.

Le vrai job n’est pas de trouver 4 liens. Le vrai job, c’est de répondre à ces questions :

• qu’est-ce que cette actu change pour quelqu’un qui build ?
• est-ce que ça parle de distribution ?
• de monétisation ?
• de velocity ?
• de mobile réel ?

Par exemple, dans un envoi récent, le système a retenu :

• Claude Sonnet 5
• Shipaton 2026 par RevenueCat
• le fonds Google Play pour les studios indés en Afrique
• le retour des paiements par carte Apple Account en Inde

Pris brut, ça ressemble à 4 news qui n’ont pas grand-chose à voir.

Mais quand tu les fais passer dans le bon filtre, tu obtiens autre chose :

• un signal sur le coding agentique
• un signal sur la distribution publique
• un signal sur l’ouverture de nouveaux écosystèmes
• un signal sur la friction paiement côté mobile

Là, tu n’as plus juste une veille. Tu as déjà une lecture du marché.

La brique 4 : la reformulation

Une fois les actus choisies, le système ne recrache pas juste un résumé. Il suit une petite structure stable :

• un titre court
• le fait en 1 ou 2 phrases
• une “leçon” actionnable
• le lien source

C’est volontairement simple.

Je ne cherche pas à faire un article académique. Je ne cherche pas non plus à faire du thread Twitter en email. Je veux juste un format lisible, utile, qui donne envie d’ouvrir les liens sans obliger le lecteur à tout reconstruire lui-même.

La brique 5 : les skills

Le mot peut faire peur, mais en vrai un skill ici, c’est juste une procédure réutilisable bien décrite.

En gros, au lieu de re-redire à l’agent à chaque run :

• comment chercher
• quoi éviter
• quel ton prendre
• quel format respecter

je stocke cette logique dans des briques réutilisables.

Pour cette newsletter, les skills servent surtout à trois choses :

1. Charger le bon contexte

Le système lit les fichiers utiles avant d’écrire :

• la voix
• le positionnement
• les preuves
• le pipeline de contenu

Comme ça, l’email reste aligné avec ma manière d’écrire.

2. Garder une structure stable

Le skill évite que chaque run réinvente :

• la forme du digest
• le niveau de détail
• les garde-fous
• les sorties attendues

3. Réutiliser l’effort ailleurs

Le même matériau source peut ensuite nourrir :

• la newsletter
• des idées de posts
• des articles
• parfois d’autres contenus plus longs

C’est ça que j’aime dans le système. Une fois la matière filtrée correctement, tu peux l’exposer sous plusieurs formes.

La brique 6 : les sorties concrètes

La routine ne sort pas qu’un email. Elle produit aussi des fichiers d’idées de posts.

Concrètement, pour chaque actu retenue, le système écrit un JSON dans le pipeline social avec :

• l’angle
• la source
• l’idée de post
• le statut

Donc une seule exécution alimente deux choses :

• le digest email
• le stock d’idées de contenu

Ça évite de faire deux fois le même travail de veille.

La brique 7 : l’envoi

Une fois l’email prêt, le système appelle la brique d’envoi.

Je n’ai pas voulu que l’agent gère toute la délivrabilité lui-même. Je préfère séparer :

• la partie éditoriale d’un côté
• la partie envoi de l’autre

Résultat :

• l’agent prépare le contenu
• la stack d’envoi se charge des abonnés, du sender name, du footer, etc.

C’est moins sexy qu’un “agent full stack autonome”. Mais c’est beaucoup plus propre.

Ce qui est réplicable si tu veux faire ta version

Si tu veux refaire ce genre de système à ta sauce, je pense qu’il faut retenir surtout ça :

1. Cadre mieux les inputs que les outputs

Le plus important, ce n’est pas de dire “écris-moi un bon email”. C’est de dire :

• quoi chercher
• sur quelle période
• dans quelles sources
• avec quel filtre éditorial

2. Force une structure simple

Si chaque item doit suivre la même mini-structure, le rendu devient plus robuste.

3. Sépare recherche, synthèse et envoi

Si tu mélanges tout, tu obtiens vite un système flou. Si tu sépares les rôles, c’est plus facile à comprendre, corriger et faire évoluer.

4. Stocke les procédures utiles dans des skills

Pas pour faire “tech”. Juste pour éviter de redire la même chose à chaque fois.

5. Ne laisse pas l’IA parler dans le vide

Exige :

• des sources
• des URLs
• une fenêtre de temps claire
• un nombre limité d’items

Sinon tu fabriques du bruit automatisé.

Ce que j’aime dans cette stack

Ce n’est pas le côté “wow, j’ai automatisé une newsletter”.

Ce que j’aime, c’est que le système fait disparaître la partie pénible :

• la recherche dispersée
• le tri
• le reformattage
• la régularité
• la transformation vers d’autres formats

Et moi, je garde la partie qui m’intéresse vraiment :

• choisir l’angle
• ajuster le niveau d’exigence
• décider ce qui mérite d’être poussé

En gros, l’IA fait l’assistant éditorial. Pas le cerveau.

La vraie leçon

Le plus intéressant dans cette histoire, ce n’est pas la newsletter elle-même.

C’est le pattern.

Quand tu prends un flux d’information un peu chaotique et que tu lui ajoutes :

• un déclencheur
• un cadre de recherche
• un filtre éditorial
• une structure de sortie
• des briques réutilisables

alors tu peux produire quelque chose de régulier sans te noyer dedans.

Et ça, pour moi, c’est probablement l’usage le plus sain des agents IA :

absorber la friction, sans dissoudre l’intention.

Pour finir

Je ne voulais pas juste une newsletter “cool”. Je voulais un système simple, réplicable, assez concret pour être utile, mais pas assez lourd pour devenir un projet à maintenir à plein temps.

Pour l’instant, c’est exactement ce que j’aime dans cette stack.

Elle ne remplace pas le goût. Elle ne remplace pas le jugement. Elle ne remplace pas la voix.

Mais elle enlève une grosse partie du travail répétitif qui empêche souvent ce genre de format d’exister dans la durée.

Si un jour je la fais évoluer, ce sera dans cette direction. Pas plus d’automatisation pour faire joli. Plus de clarté, plus de signal, plus de recyclage intelligent de la même matière source.

Si tu veux voir ce que ça donne en pratique, tu peux jeter un œil à la newsletter ici :

App World Weekly