AutomatisationIntégrations
Tech Radar : extraire le signal du fil d’une communauté de développeurs
- De quoi il s’agissait
- Mon propre service : il collecte les messages d’une communauté professionnelle, filtre le bruit à l’aide de règles explicables et compose un digest. Il tourne sur mon serveur.
- Mon rôle
- Cadrage, architecture, développement, exploitation — seul
- Période
- 2026, en cours
- Résultat
- 7 627 messages de 581 auteurs archivés ; le service tourne sans surveillance.
Contexte et problème initial
Une communauté de développeurs qui discute de nouvelles bibliothèques, d’outils et de tarifs d’API. La valeur est réelle, mais dispersée dans des centaines de messages par jour, et tout lire à la main n’est pas envisageable.
Enjeu business
Ne rien manquer d’utile sans tout lire. Recevoir un court résumé quotidien au lieu d’un fil, et pouvoir expliquer pourquoi un message a été retenu.
Contraintes et inconnues
- Un seul serveur, 2 CPU / 4 Go, sans GPU
- Les messages appartiennent à d’autres : l’archive reste privée, seuls des liens et des extraits ressortent
- Le service doit tourner sans surveillance — je suis occupé par d’autres travaux
- Aucune API payante
Ma responsabilité
Tout : collecte via Telethon, schéma de la base de données, règles de sélection, digest, unité systemd, tests et exploitation.
Décisions clés et compromis
- L’archive brute est intouchable : le traitement ne supprime jamais rien dans items, et chaque verdict dérivé est stocké à part dans item_analysis. Les règles peuvent être réécrites et rejouées sur tout l’historique.
- D’abord des règles déterministes, un LLM seulement ensuite. Les règles sont peu coûteuses, reproductibles et justifient leurs décisions par une liste de raisons ; un modèle sur deux cœurs sans GPU est lent et n’en est pas capable.
- Le LLM se trouve derrière une interface ItemAnalyzer plutôt que dans le code de traitement. Ajouter un modèle local revient à écrire une autre implémentation du même protocole, pas à tout réécrire.
- Collecte incrémentale par curseur : un redémarrage ne relit pas l’historique.
- Observabilité dès le premier jour — chaque exécution du collecteur est enregistrée avec son statut, y compris en cas d’arrêt anormal.
Ce qui a changé
- 7 627 messages de 581 auteurs collectés entre mars et août 2026
- Dédoublonnage par texte normalisé et par liens canonicalisés, paramètres de suivi supprimés
- Le digest indique un score, une catégorie et la liste des raisons pour lesquelles un message a été sélectionné
- Le service tourne sous systemd et survit à un redémarrage du serveur sans aucune intervention manuelle
- 1 148 lignes de mon propre code, quatre dépendances externes, trois suites de tests
Limites de divulgation et de résultats
Prochaine étape pour une tâche similaire
Une tâche similaire : extraire le signal d’un flux de messages, d’e-mails ou de demandes entrantes. Nous commencerions par définir ce qui compte comme signal.