Système de Nouvelles IA Autonome Sans Contrôle Manuel

Système de nouvelles IA autonome : Comment remplacer sept workflows par une architecture unifiée

Au bout d'un mois et demi, une chaîne de traitement des nouvelles fragmentée en sept workflows n8n s'est transformée en un système stable avec 160 sources, 11 workers et 5 agents IA. Désormais, le traitement de 7127 enregistrements dans la base de données se fait sans intervention manuelle, et un LLM local sur un mini-PC remplace les API cloud. Nous décomposons l'architecture qui élimine les points de défaillance et assure un fonctionnement 24/7.

De sept points de défaillance à un système unique

Initialement, la chaîne de traitement des nouvelles se composait de sept workflows n8n indépendants : collecte de données, filtrage, traduction, génération d'images et publication. Chaque étape fonctionnait de manière isolée, créant des pannes en cascade. Un problème typique : un workflow marquait une tâche comme « terminée », mais la sortie était vide. Comme les étapes manquaient d'un système de surveillance unifié, les diagnostics prenaient des heures. La vulnérabilité critique était l'absence d'un statut unique pour chaque article. Si un workflow se bloquait, les autres continuaient le traitement, générant des données incohérentes.

La solution est venue après une analyse avec Perplexity et des expériences avec Claude Code. Au lieu de réécrire manuellement la logique en Python, l'assistant IA a reçu les workflows sources et les exigences architecturales. En une heure, il a généré une application conteneurisée avec une séparation claire des responsabilités. Changement clé : passage de workflows basés sur des déclencheurs à une chaîne orientée état, où chaque article passe par des étapes strictement définies avec un statut fixé dans la base de données.

Traitement local : Pourquoi Qwen 3.5 sur un mini-PC

Traduire les nouvelles via des API cloud s'est avéré économiquement non viable : 160 sources mises à jour toutes les 15 minutes nécessiteraient des dizaines de milliers de requêtes par jour. La solution : déployer un LLM local sur un mini-PC domestique avec Ubuntu et optimiser pour Vulkan via llama.cpp. Le modèle Qwen 3.5 (qwen3.5-9b-q5_k_m.gguf) a été choisi pour son équilibre vitesse/qualité pour la langue russe.

La configuration incluait :

• Fine-tuning pour l'architecture CPU via Cursor
• Calibrage du nombre de threads pour minimiser la latence
• Configuration du cache des résultats intermédiaires

Le système gère jusqu'à 50 requêtes par minute sans surcharger le CPU. Les données ne quittent jamais le réseau local, ce qui est crucial pour les sources avec restrictions de clés API. Pour comparaison : la traduction cloud coûterait ~120 $/mois au volume actuel, local — 0 $ après configuration initiale.

Architecture de la chaîne : Comment fonctionnent les 11 workers

Construite sur le principe « un processus — une tâche ». Chaque worker est isolé, éliminant les pannes en cascade. Flux de traitement :

collector → scraper → deduplicator → ai_filter → translator
    → llm_editor → image_worker → publisher

collector s'exécute toutes les 15 minutes, parse RSS/API de 160 sources (y compris Arxiv, TechCrunch, GitHub). scraper extrait le texte complet via une instance locale Jina Reader — cela a éliminé les limites des services cloud. deduplicator utilise une comparaison sémantique basée sur des embeddings, pas un appariement exact de texte. ai_filter attribue un relevance_score (0-100), filtrant les éléments en dessous de 75 points.

Attention particulière à l'étape llm_editor. Là, MiniMax M2.7 formate le texte au style du canal : ajoute des emojis aux titres, structure le contenu, ajoute l'attribution. Le modèle est entraîné sur des données historiques du canal, assurant une mise en forme cohérente. Tous les workers interagissent via une file de messages avec garantie de livraison, permettant la reprise après pannes depuis le dernier point de contrôle.

Gestion via agents IA : Des commandes Telegram aux actions

Le coordinateur basé sur OpenClaw remplace la gestion manuelle. Il s'exécute sur le même mini-PC et a accès aux outils via API. Le système utilise 5 agents spécialisés :

• AgentLLMEditor : corrige le texte toutes les 20 minutes
• AgentPipelineManager : distribue les posts vers les slots 4 fois par jour
• AgentSourceAuditor : désactive les sources non fonctionnelles hebdomadairement
• AgentAnalyst : génère les analyses à 21:05
• Coordinator : gère les autres agents

Une commande Telegram comme « Coordinator, réduis la limite de publication à 8 par jour » se transforme en appel API vers le gestionnaire de chaîne. L'agent vérifie les paramètres actuels, effectue les changements et confirme l'exécution. Cela élimine le besoin d'accès SSH et de connaissance de la syntaxe des fichiers de config. Pour les opérations critiques (ex. : désactivation d'une source), le système exige une confirmation via un worker human-in-the-loop (hitl).

Tableau de bord : Surveillance en temps réel

L'interface combine 9 onglets : aperçu, agents, sources, file, workers, slots, publiés, paramètres, GitHub Discovery. Métriques clés :

• Taux de passage par sources : Anthropic News (100 %) vs iXBT.com (14 %)
• Temps de traitement par étape : traduction (4 min) vs filtrage (2 min)
• Statut des workers : processus actifs/inactifs

En cas d'anomalies détectées (ex. : file de traduction bloquée), le tableau de bord crée automatiquement une tâche dans le groupe de travail Telegram. L'intégration avec GitHub Discovery suit les repos avec forte croissance d'étoiles — ces données s'affichent sur un onglet dédié avec graphique d'activité. Le système alerte sur les problèmes avant qu'ils n'affectent les publications : ex., si le taux de passage d'une source tombe sous 10 % pendant une semaine.

Économies par sélection : De 1000 articles à 8 posts par jour

Le système ne publie pas tout. ~1000 éléments traités par semaine, mais seulement 56 posts publiés (8 par jour). Critères de sélection :

• relevance_score ≥ 80 (ai_filter)
• Approuvé par l'éditeur LLM (statut approved)
• Correspond à un slot horaire

Planning lié aux fuseaux horaires :

• Matin (08:00–11:00) : 2 posts
• Jour (12:00–16:00) : 2 posts
• Soir (18:00–22:00) : 2 posts
• Nuit (00:00–06:00) : 2 posts

Précédemment 28 posts par jour, mais les analyses montraient que les utilisateurs ne lisaient que les 1-2 derniers. Désormais, la réduction du volume a augmenté la rétention de 37 % — les lecteurs voient toutes les publications du slot. Les taux de passage des sources permettent d'ajuster la liste hebdomadaire : 20 flux RSS peu efficaces déjà désactivés.

Ce qui compte

• Système d'état unifié remplace les workflows isolés : chaque nouvelle a un statut clair, accélérant les diagnostics de pannes par 5.
• LLM locaux économisent jusqu'à 120 $/mois sur traduction et édition, avec une latence ne dépassant pas 4 minutes pour 50 tâches parallèles.
• Agents IA éliminent la gestion manuelle : les commandes Telegram deviennent des appels API sans intervention de l'opérateur.
• Sélection stricte du contenu (8 posts/jour au lieu de 28) a boosté la rétention d'audience de 37 % en réduisant le bruit.

— Editorial Team