Dix-sept mille signaux

Mon coffre-fort Obsidian contient 17 913 notes de signaux. Chacune correspond à un article de recherche, un billet de blog, un avis de sécurité ou une discussion communautaire que mon scanner a identifié comme potentiellement pertinent pour l’un des neuf sujets que je surveille : sécurité de l’IA, agents LLM, Claude/Anthropic, SwiftUI/iOS, systèmes de design, creative coding, recherche en ML, science et sécurité. C’est la couche opérationnelle de ce que j’appelle l’infrastructure du goût — l’idée que le jugement esthétique et éditorial doit être encodé dans des systèmes, et non appliqué de manière ad hoc.

Sur ces 17 913 signaux, j’en ai lu environ 200 en détail. 500 autres ont influencé une décision, un billet de blog ou un choix de design. Les 17 213 restants sont du bruit que j’ai analysé, noté et classé sans y donner suite.

Ce bruit n’est pas gaspillé. Le bruit est l’instrument.

Le problème de la notation

Chaque signal reçoit un score composite de 0 à 1, pondéré selon quatre dimensions : pertinence (correspond-il à mes sujets), actionnabilité (puis-je en faire quelque chose), profondeur (y a-t-il de la substance) et autorité (la source est-elle crédible). Les signaux dépassant 0,55 sont écrits dans les dossiers thématiques. Ceux entre 0,40 et 0,55 vont dans la boîte de réception. En dessous de 0,40, ils sont ignorés.

Les seuils sont calibrés, pas choisis arbitrairement. Ils ont émergé de mois d’analyse, d’examen de ce qui atterrissait dans chaque catégorie, et d’ajustements jusqu’à ce que le ratio signal/bruit paraisse juste. 0,55 était trop élevé au départ (des articles importants passaient à travers les mailles). 0,30 était trop bas (la boîte de réception se remplissait de déchets). Les seuils actuels produisent environ 15 à 30 écritures thématiques et 10 à 20 éléments en boîte de réception par analyse, tous sujets confondus.

Le système de notation comporte des biais que je comprends :

Les articles de recherche démarrent à 0,75 en autorité. Un article arXiv avec une catégorie et des mots-clés correspondants obtient 0,75 avant toute évaluation du contenu. C’est délibéré : la recherche évaluée par les pairs dans des domaines pertinents possède une crédibilité de base que les billets de blog et les discussions HN n’ont pas.

Les avis de sécurité démarrent à 0,95 en autorité. Un CVE du NVD ou un GHSA de GitHub obtient un score élevé quel que soit le contenu, car l’existence même d’un avis de vulnérabilité constitue le signal. Le contenu est secondaire par rapport au fait lui-même.

Les discussions HN démarrent à 0,55 en autorité. Les discussions communautaires sont précieuses pour le sentiment et la découverte, mais peu fiables pour les faits. Un article HN très voté sur un nouvel article de recherche est un mécanisme de découverte, pas une source. L’article lui-même est la source.

Ces lignes de base encodent mon jugement sur la fiabilité des sources. Une personne différente avec des priorités différentes fixerait des lignes de base différentes. Ces lignes de base ne sont pas une vérité objective. Elles sont une opinion codifiée sur l’origine de la confiance. La méthodologie complète de notation est documentée dans mon pipeline de notation des signaux.

Ce que le bruit enseigne

La plupart des analyses produisent 80 à 100 écritures thématiques et 20 à 40 éléments en boîte de réception. La majorité est du bruit : des articles que je ne lirai jamais, des avis pour des logiciels que je n’utilise pas, des discussions sur des sujets que je surveille sans y donner suite.

Le bruit enseigne trois choses :

La forme du domaine. Quand les analyses ai-safety renvoient systématiquement des articles sur l’interprétabilité mécaniste et le RLHF, cela m’indique où la communauté de recherche concentre ses efforts. Quand les analyses llm-agents produisent soudain cinq articles sur la revue de code agentique en une semaine, cela m’indique qu’une tendance se forme. Les articles individuels peuvent être du bruit. La distribution de fréquence est du signal.

La ligne de base de la surprise. Un article noté 0,65 dans le sujet ai-safety n’a rien de remarquable. Un article noté 0,91 est surprenant. La surprise n’est significative que parce que je dispose d’une ligne de base de ce à quoi ressemble un 0,65. Le bruit établit la ligne de base. Le signal est l’écart par rapport à cette ligne de base.

Les lacunes de ma couverture. Quand l’attaque sur la chaîne d’approvisionnement LiteLLM s’est produite, mon pipeline scan-intel l’a détectée via la correspondance de mots-clés HN. Le pipeline ne disposait pas à l’époque de sources d’avis de sécurité (NVD, OSV, GHSA). La lacune était invisible jusqu’à ce qu’un incident passe au travers. J’ai élargi le pipeline en ajoutant trois sources d’avis de sécurité la semaine suivante. Le bruit de ces nouvelles sources m’apprend à quoi ressemble le trafic normal des avis. La prochaine lacune sera visible plus tôt.

L’expansion

Le pipeline a démarré avec 6 sources. Il en compte désormais 12 :

Chaque source a ajouté du bruit. Chaque source a aussi capté quelque chose que les autres avaient manqué. La vulnérabilité de traversée de chemin LangChain est apparue dans GHSA mais pas sur HN. L’article Claudini sur l’autorecherche est apparu sur arXiv 12 heures avant d’apparaître sur HN. Le voleur d’identifiants LiteLLM est apparu dans OSV avec l’identifiant MAL-2026-2144 que le NVD ne portait pas encore.

Le système de déduplication par alias regroupe les doublons inter-sources. Le même CVE apparaissant dans NVD, OSV et GHSA produit une seule note de signal, pas trois. Lors de la première exécution en production, 6 des 85 signaux de sécurité ont été dédupliqués par alias. Le taux de déduplication augmentera à mesure que les sources gagneront en maturité.

La discipline du triage

Dix-sept mille signaux exigent une discipline de triage. La mienne est simple : parcourir la sortie, lire les scores élevés, classer le reste.

Une analyse typique prend 3 minutes à exécuter et 2 minutes à examiner. Je lis chaque signal au-dessus de 0,80 (généralement 2 à 5 par analyse). Je survole la plage 0,60-0,80 à la recherche de surprises. J’ignore tout ce qui est en dessous de 0,60, sauf si un mot-clé attire mon regard.

L’analyse est devenue une habitude. Analyse du matin, analyse du soir. Certains jours produisent plus de 100 écritures thématiques (quand un nouveau lot arXiv tombe). D’autres jours n’en produisent aucune (quand la fenêtre de 7 jours a été entièrement dédupliquée). La variance est normale. L’habitude est constante.

Les signaux qui comptent le plus sont ceux qui changent ce que je construis ou écris. L’article Claudini (0,83) est devenu un billet de blog. L’attaque sur la chaîne d’approvisionnement LiteLLM (0,67 depuis HN, puis confirmée via OSV à 0,62) est devenue un billet de blog et deux mises à jour de citations dans des articles existants. Le dataset LICA (trouvé manuellement, pas par scan-intel) est devenu un plan de moteur de goût en design. L’article SlopCodeBench (0,77) est devenu un candidat de citation pour l’article sur le contexte composé.

La plupart des signaux ne deviennent rien. Ils se classent silencieusement dans le coffre-fort, établissent la ligne de base et attendent le jour où un nouveau signal se connectera à un ancien pour produire un aperçu qu’aucun des deux ne contenait seul.

Le coffre-fort comme mémoire

Le coffre-fort n’est pas une liste de lecture. Je n’ai pas l’intention de lire les 17 213 signaux que je n’ai pas lus. Le coffre-fort est une mémoire interrogeable de ce que le domaine a produit pendant que je l’observais — une forme de topologie de la connaissance où la structure des connexions compte davantage que n’importe quel nœud individuel.

Quand j’écris un billet sur la sécurité de la chaîne d’approvisionnement, je peux chercher dans le coffre-fort chaque signal étiqueté « security » et « supply-chain » des 90 derniers jours. La recherche renvoie l’attaque LiteLLM, la compromission Trivy, le benchmark MCPTox, l’attaque Clinejection et une douzaine de CVE affectant des paquets d’infrastructure IA. Chacun est une citation potentielle, un point de données ou un contre-argument.

Quand je planifie une nouvelle fonctionnalité, je peux chercher des signaux liés au domaine. Le dataset LICA est apparu lors d’une exécution scan-intel comme un signal design-systems noté 0,72. Je ne l’aurais pas trouvé par une recherche ciblée, car je ne cherchais pas de datasets de design graphique. L’analyse l’a fait remonter parce que les mots-clés (« design systems », « typography ») correspondaient. Le coffre-fort a fait la connexion.

Les 17 213 signaux non lus ne sont pas un effort gaspillé. Ce sont du contexte indexé que je peux interroger quand j’en ai besoin. L’analyse est peu coûteuse. L’indexation est automatique. La valeur est latente jusqu’au moment où une question se connecte à une réponse classée il y a des mois. C’est le contexte composé en pratique : chaque signal déposé aujourd’hui peut devenir la pièce manquante d’une synthèse future.

FAQ

Quels outils utilisez-vous ?

Le scanner est un script Python personnalisé (scan_intel.py, environ 1 200 lignes) qui récupère depuis 12 sources, note avec un moteur de triage, déduplique sur trois couches (URL, identifiant d’article, alias d’avis) et écrit des notes en markdown dans un coffre-fort Obsidian. Le coffre-fort utilise Dataview pour les requêtes. La configuration est en JSON. L’état (identifiants vus) est en JSON avec un élagage à 90 jours.

Combien cela coûte-t-il ?

Zéro. Toutes les sources sont des API gratuites ou des flux RSS publics. arXiv, Semantic Scholar, OSV et l’API Algolia de HN ne nécessitent aucune authentification. Le NVD dispose d’un niveau gratuit avec des limites de débit (5 requêtes par 30 secondes). Les avis GitHub utilisent le CLI gh qui s’authentifie via votre session GitHub existante.

Comment évitez-vous la surcharge informationnelle ?

Par les seuils de notation et la discipline de triage. Je consacre 2 minutes par analyse à examiner la sortie. Les signaux en dessous de 0,60 sont classés sans lecture. Le coffre-fort grandit, mais mon attention ne croît pas avec lui. Le coffre-fort est une mémoire, pas un devoir de lecture.

Puis-je utiliser ce système ?

L’architecture est portable : récupérer depuis des API, noter avec des critères pondérés, dédupliquer, écrire dans une base de connaissances. Les sources, mots-clés et seuils spécifiques sont calibrés selon mes intérêts. Il vous faudrait définir vos propres sujets, mots-clés et lignes de base d’autorité. Le moteur de notation et la logique de déduplication sont agnostiques au domaine. Mon guide Obsidian couvre l’architecture du coffre-fort et les schémas de requêtes en détail, et mon article sur le récupérateur hybride explique comment je combine recherche par mots-clés et recherche sémantique sur ce corpus.