Pipeline de veille automatisée avec Claude API : guide étape par étape

Le piège d’une veille automatisée, c’est d’envoyer tous les articles au modèle. La version qui tient dans la durée fait l’inverse : un filtre de code classique élimine environ 80 % du bruit, Claude API ne trie que le reste, et vous recevez un seul email par semaine avec 5 à 10 entrées justifiées. Le modèle n’est que la troisième étape d’un pipeline qui en compte cinq.

Voici l’architecture que je recommande, les décisions techniques qui évitent les mauvaises surprises, et un dimensionnement chiffré sur un cas de veille réglementaire pour un chauffeur de taxi.

Pourquoi la plupart des veilles IA échouent en trois semaines

L’idée reçue : une bonne veille automatisée demande un modèle puissant qui lit tout. Dans ma pratique, c’est l’inverse. Les veilles que j’ai vues abandonnées échouent pour trois raisons très concrètes :

• Trop de bruit en sortie. Le modèle résume tout, le digest fait 40 lignes, personne ne le lit après la deuxième semaine.
• Des doublons. Le même communiqué apparaît dans 6 flux, et le digest le présente 6 fois.
• Aucune justification. Une ligne « article intéressant » ne dit pas pourquoi. Vous devez rouvrir la source pour vérifier, donc le gain de temps disparaît.

Le remède n’est pas un meilleur prompt. C’est un meilleur découpage : tout ce qui peut se faire sans modèle se fait sans modèle.

Les cinq étapes du pipeline

1. Collecter. Une liste de flux RSS ou Atom, un fichier JSON dans le dépôt avec l’URL et une étiquette par source. Pas besoin de scraper : la plupart des sites d’information, des blogs d’éditeurs et des institutions publient un flux. C’est plus stable qu’un scraping HTML qui casse au premier changement de gabarit.

2. Dédoublonner. On garde l’URL canonique et une empreinte du titre normalisé (minuscules, sans accents, sans ponctuation). Tout article déjà vu est écarté. Cette étape se fait en quelques lignes de TypeScript et supprime déjà une part importante des entrées.

3. Filtrer par règles. Une liste de mots-clés obligatoires et une liste d’exclusions. C’est bête et efficace : un article qui ne contient aucun de vos termes n’a aucune chance d’être pertinent. Je garde ces listes dans le même fichier de configuration que les flux, pour qu’un non-développeur puisse les modifier.

4. Trier avec Claude API. Seuls les articles qui ont survécu aux étapes 2 et 3 passent par le modèle. Je lui demande, pour chacun, un score de pertinence de 0 à 3, une phrase de justification et une catégorie parmi une liste fermée.

5. Livrer. Un digest par email ou par message, classé par score, avec le titre, le lien d’origine et la justification. Rien d’autre.

Le prompt de tri : liste fermée, score, justification

Le modèle ne doit pas « résumer », il doit décider. Je lui donne une description de votre activité en trois phrases, la liste des catégories autorisées et un barème explicite :

• 3 : action requise de votre part ou décision à prendre dans le mois
• 2 : à lire cette semaine
• 1 : bon à savoir
• 0 : hors sujet

Pour que la sortie soit exploitable, j’utilise les sorties structurées d’Anthropic, qui contraignent la réponse à un schéma JSON, et je double avec une validation Zod côté code. Si un champ manque, l’article est mis de côté pour le prochain passage au lieu de produire une ligne vide dans le digest.

Deux règles qui changent la qualité :

1. Demander la justification avant le score dans le schéma. Le modèle formule son raisonnement en une phrase, puis note. Les scores sont plus cohérents d’un jour à l’autre.
2. Ne jamais laisser le modèle inventer une catégorie. Une liste fermée de 5 à 8 valeurs, point. Une catégorie hors liste est une erreur de validation.

Où faire tourner le pipeline : une fonction Netlify planifiée

Pour un périmètre de quelques dizaines de flux, pas besoin de serveur. Mes projets sont déjà sur Netlify, donc j’utilise une fonction planifiée. La documentation Netlify donne les contraintes qui comptent :

• l’expression cron s’exécute en UTC uniquement, donc un envoi « le lundi à 8 h » à Marseille demande de raisonner en heure d’été et d’hiver ;
• la durée maximale d’exécution est de 30 secondes ;
• la fonction ne tourne que sur le déploiement publié, pas sur les aperçus de branche, et elle ne peut pas être appelée par une URL.

La limite de 30 secondes est celle qui dicte l’architecture. Collecter 40 flux, dédoublonner puis appeler un modèle dans le même passage, c’est risqué. Je sépare donc en deux fonctions : une première qui collecte, dédoublonne et filtre, puis écrit les candidats dans un stockage (Netlify Blobs ou un simple fichier JSON versionné), une seconde, plus tard, qui trie et envoie. Si le tri dépasse la fenêtre, une fonction en arrière-plan prend le relais.

Lots ou appels directs : quand l’API Batch devient utile

La veille ne demande aucune réponse immédiate. C’est exactement le cas d’usage de la Message Batches API : Anthropic indique une réduction de 50 % du coût, avec la plupart des lots terminés en moins d’une heure. Le principe : vous envoyez tous les articles candidats en un lot, vous récupérez les résultats ensuite.

Mon arbitrage, pour un digest hebdomadaire :

Situation	Mode que je choisis
Moins de 20 articles candidats par passage	Appels directs, plus simple à déboguer
Plusieurs centaines d’articles par semaine	Lots, pour la remise de 50 %
Alerte « action requise » à envoyer dans l’heure	Appels directs, limités aux sources prioritaires

Le point à ne pas rater : un lot est asynchrone, donc votre pipeline doit gérer un état « en attente » entre l’envoi et la récupération. C’est une complication réelle. Sous 20 articles par passage, elle ne vaut pas la remise.

Un dimensionnement sur un cas de taxi en PACA

Je prends comme cadre taxijulien.com, le site métier de transport sur lequel je travaille. Ce qui suit est une simulation de dimensionnement, pas une mesure relevée sur ce projet : les chiffres sont des hypothèses à remplacer par les vôtres. Je suis immatriculé à Marseille, donc je prends un chauffeur de taxi en région PACA qui veut suivre la réglementation de son métier et les annonces de sa plateforme de réservation.

Hypothèses :

• 25 flux suivis (préfecture, fédération professionnelle, presse locale, éditeurs d’outils) ;
• 200 nouveaux articles par semaine en moyenne ;
• le dédoublonnage et le filtre par mots-clés éliminent 85 % des entrées ;
• le reste est trié par le modèle, puis 6 entrées arrivent dans le digest.

Étape	Articles restants	Qui traite
Collecte	200	Code
Après dédoublonnage	150	Code
Après filtre par mots-clés	30	Code
Après tri par le modèle	6	Claude API
Lecture dans le digest	6	Vous, environ 10 min

Dans cette simulation, la lecture brute des 200 articles prendrait, à 2 minutes par titre ouvert pour en écarter la plupart, plus de 6 heures. Le digest en demande 10 minutes de lecture plus 5 minutes de vérification des liens. À un TJM de 400 euros pour 7 heures, soit environ 57 euros de l’heure, c’est un temps libéré de l’ordre de 5 heures par semaine, donc autour de 285 euros. C’est un ordre de grandeur et il dépend entièrement de ce que votre temps vaut vraiment : un chauffeur qui ne facture pas ses heures de veille n’en tire pas le même calcul.

Surtout, le modèle ne traite que 30 articles sur 200. C’est cette étape qui rend le coût d’appel marginal, pas le choix du modèle.

Les limites que j’annonce avant de livrer

Trois garde-fous que je mets dans chaque pipeline de veille :

• Le lien d’origine est toujours dans le digest. Le résumé du modèle sert à décider quoi ouvrir. Il ne remplace jamais la source, surtout pour une règle ou une échéance.
• Un journal des articles écartés. Chaque semaine, je garde la liste de ce qui a été éliminé par le filtre et par le modèle. Si vous découvrez qu’une information importante vous a échappé, vous retrouvez à quelle étape elle a été jetée et vous ajustez la règle.
• Un usage interne. Je conserve titre, lien et une note courte. Je ne republie pas le texte des articles. Dès que le digest est diffusé à des tiers, il faut regarder les conditions d’utilisation des sources.

Côté données personnelles, une veille sur des sources publiques en contient très peu. Mais si votre digest part vers plusieurs destinataires, les adresses email relèvent du RGPD : une liste de diffusion tenue proprement et un lien de désinscription suffisent pour ce périmètre.

Quand je déconseille ce pipeline

Si vous suivez moins de 5 sources, un lecteur RSS gratuit suffit et le pipeline est du sur-équipement. Si votre veille porte sur des documents non publics, ou si une décision juridique dépend de l’information, une lecture humaine intégrale reste obligatoire : le tri par modèle peut rater un texte pertinent, et j’ai vu des scores de 1 sur des articles qui méritaient 3. C’est pour ça que le journal des écartés existe.

À partir de 15 à 20 sources et d’un domaine où un retard d’information coûte de l’argent, le gain devient net. C’est mon seuil, et il est volontairement bas pour vous éviter un projet inutile.

Ce qu’il faut retenir

Une veille automatisée efficace avec Claude API est un pipeline en cinq étapes où le modèle n’intervient qu’à la quatrième : collecte par flux RSS, dédoublonnage et filtre par mots-clés en code classique, tri par le modèle avec score et justification, puis digest hebdomadaire. Une fonction Netlify planifiée suffit, à condition de respecter la limite de 30 secondes et le fuseau UTC. L’API Batch réduit le coût de 50 % quand le volume le justifie. Sous 5 sources, un lecteur RSS gratuit suffit.

Les points clés

• Éliminez le bruit avec du code classique avant tout appel à Claude API : c’est ce qui rend le coût marginal.
• Faites décider le modèle avec un barème de 0 à 3, une justification et une liste fermée de catégories, validées par un schéma Zod.
• Découpez le travail en deux fonctions Netlify pour tenir la limite de 30 secondes d’exécution.
• Réservez l’API Batch aux volumes de plusieurs centaines d’articles : la remise de 50 % ne compense pas la complexité sous 20 articles.
• Gardez toujours le lien d’origine dans le digest et un journal des articles écartés.
• Restez en usage interne : titre, lien et note courte, sans republier le contenu des sources.