Pipeline de scoring de signaux : triage déterministe des connaissances

La plupart de la gestion des connaissances repose sur l’intuition. Vous enregistrez une note parce qu’elle « semble importante ». Six mois plus tard, vous avez 7 000 notes et aucune idée de celles qui comptent vraiment. J’ai construit un pipeline de scoring déterministe qui me le dit.

Le système fait 733 lignes de Python. Il évalue chaque signal entrant selon quatre dimensions pondérées, calcule un score composite et route le signal vers l’un des 12 dossiers thématiques, une boîte de réception pour revue manuelle, ou le néant. Pas d’étiquetage manuel. Pas de « à revoir plus tard » qui n’arrive jamais. L’algorithme décide.

TL;DR

Un score composite pondéré (pertinence 35 %, actionnabilité 30 %, profondeur 20 %, autorité 15 %) produit une note de 0,0 à 1,0 pour chaque signal. Le routage utilise trois seuils : >= 0,55 écrit automatiquement dans un dossier thématique, >= 0,30 met en file d’attente pour revue manuelle, < 0,30 ignore silencieusement. Plus de 7 700 notes traitées sur 14 mois, avec Development (2 837) et Design (1 709) dominant la distribution. La faille la plus intéressante : la dimension de profondeur mesure la richesse des métadonnées, pas la qualité du contenu — un tweet bien étiqueté montrant une photo de fleur obtient 0,85.

Le problème de l’intuition

J’utilise Obsidian comme base de connaissances. Les signaux arrivent par des flux RSS, des favoris Twitter, des étoiles GitHub, des newsletters et de la capture manuelle. Avant le pipeline, chaque signal allait dans un unique dossier de réception. Une boîte de réception de plus de 400 notes non traitées s’est accumulée en deux mois.

Le conseil classique (« faites une revue hebdomadaire, étiquetez au fil de l’eau, utilisez un système de dossiers ») suppose que la revue a lieu. Ce n’est pas le cas. Les boîtes de réception deviennent en écriture seule : les éléments y entrent mais n’en sortent jamais. Les connaissances que vous avez capturées sont fonctionnellement identiques aux connaissances que vous n’avez jamais capturées. Clay Shirky a formulé le problème avec précision : « Ce n’est pas une surcharge informationnelle. C’est une défaillance du filtrage. »⁸

J’avais besoin d’un système capable d’évaluer plus de 7 700 notes plus vite que je ne peux les lire, en utilisant des critères que je définis une fois et que j’applique uniformément. Pas un moteur de recommandation. Un algorithme de scoring.

Le score composite

La formule de scoring est une combinaison linéaire pondérée de quatre dimensions, une approche standard en analyse décisionnelle multicritère (MCDA) :⁹

composite = (
    relevance     * 0.35 +
    actionability * 0.30 +
    depth         * 0.20 +
    authority     * 0.15
)

Chaque dimension produit un nombre à virgule flottante entre 0,0 et 1,0. La formule arrondit le composite à trois décimales. Les pondérations reflètent un ordre de priorité délibéré : ce qui m’importe (pertinence) l’emporte sur ce que je peux utiliser (actionnabilité), qui l’emporte sur la richesse des métadonnées (profondeur), qui l’emporte sur la fiabilité de la source (autorité).¹

Les quatre dimensions

Pertinence (35 %) : correspondance avec les centres d’intérêt

La pertinence utilise un dictionnaire de mots-clés curé manuellement avec plus de 40 entrées, chacune notée de 0,15 (nft) à 1,0 (claude code, swiftui). Le scoring combine la meilleure correspondance avec la moyenne de toutes les correspondances :

# 60% best match, 40% average of all matches
return min(1.0, best_score * 0.6 + avg_score * 0.4)

Les éléments sans correspondance reçoivent un plancher de 0,25, pas 0,0. Le système pénalise moins sévèrement un sujet inconnu qu’un sujet non pertinent. Ce plancher est le paramètre le plus fréquemment ajusté : trop haut et le contenu non pertinent inonde la boîte de réception, trop bas et les centres d’intérêt véritablement nouveaux sont filtrés avant que je ne les voie.²

Actionnabilité (30 %) : potentiel d’apprentissage

L’actionnabilité compare le signal à 22 mots-clés orientés action : tutorial, guide, how-to, build, github.com. Les URL reçoivent un traitement spécial :

if "github.com" in url:
    hits += 2  # Repositories are inherently actionable
if "/docs" in url or "/tutorial" in url:
    hits += 1

Le scoring repose sur une fonction en escalier, pas linéaire : 0 correspondance → 0,10, 1 correspondance → 0,40, 2 correspondances → 0,60, 3+ correspondances → min(1.0, 0.70 + hits * 0.05). La fonction en escalier récompense la présence de signaux d’actionnabilité plus que leur quantité. Un seul lien vers un tutoriel vaut plus que la différence entre trois et quatre mots-clés.³

Profondeur (20 %) : richesse des métadonnées

La profondeur est purement structurelle. Elle mesure la présence et la longueur des champs, pas la qualité du contenu :

La profondeur est la dimension à laquelle je fais le moins confiance. Un tweet montrant une photo de némophile avec une description complète et quatre tags obtient un score de profondeur de 0,85. Des métadonnées riches, un contenu non pertinent : une jolie photo de fleurs. La profondeur sert de proxy pour « la source a fourni des données structurées », ce qui corrèle avec la qualité sans la garantir.⁴

Autorité (15 %) : crédibilité de la source

L’autorité démarre avec un plancher de 0,40 et s’ajuste selon le type de source :

if source in ("twitter", "x"):        score = 0.50
elif source in ("blog", "newsletter"): score = 0.60
elif source in ("github", "docs"):     score = 0.70

Une liste blanche de domaines ajuste le score à la hausse (jamais à la baisse) : github.com, anthropic.com, apple.com, arxiv.org, docs.python.org, entre autres, fixent l’autorité à au moins 0,75. Cette liste encode le jugement que ces sources méritent une confiance plus élevée par défaut.

Routage par seuils

Trois catégories de routage déterminent le sort de chaque signal évalué :

THRESHOLD_AUTO_WRITE = 0.55   # → domain folder
THRESHOLD_INBOX      = 0.30   # → 00-Inbox (manual review)
# Below 0.30 → silently skipped

Le pipeline écrit les signaux scorant >= 0,55 directement dans l’un des 12 dossiers thématiques, inférés par correspondance de tags et de titres. Les signaux intermédiaires (0,30-0,55) vont dans une boîte de réception pour revue manuelle. Tout ce qui est en dessous de 0,30 n’atteint jamais le coffre-fort.

La plage 0,30-0,55 est la « zone ambiguë » où le système est le moins confiant. Un drapeau optionnel --llm-triage envoie ces signaux à Claude pour évaluation, ce qui peut ajuster le score composite de ±0,20, déplaçant potentiellement un signal au-delà du seuil d’écriture automatique. Claude ne voit que les signaux ambigus, jamais ceux à score élevé ou faible. Dépenser des tokens API sur des signaux que le scoreur déterministe a déjà traités serait du gaspillage.⁵

L’inférence de domaine utilise un système de vote. Chaque tag correspond à un domaine, chaque mot-clé dans le titre ajoute un vote. Le domaine avec le plus de votes l’emporte. Les égalités sont départagées par l’ordre du dictionnaire (effectivement arbitraire). Domaine par défaut : « Inspiration ».

Les résultats

Après plus de 7 700 notes traitées sur 14 mois :

La distribution reflète la réalité. Je consomme plus de contenu sur le développement et le design que sur tout autre sujet. Les éléments en boîte de réception (420) représentent la zone ambiguë — des signaux que l’algorithme n’a pas pu router automatiquement avec confiance.⁶

Ce que l’algorithme a mal évalué

Le piège de la profondeur

Un tweet montrant une photo de némophile a obtenu composite 0,36, pertinence 0,25, actionnabilité 0,10, profondeur 0,85, autorité 0,50. Il a été routé vers la boîte de réception parce que la profondeur (0,85) et l’autorité (0,50) ont compensé une pertinence et une actionnabilité quasi nulles. Des métadonnées riches, un contenu non pertinent : une jolie photo de fleurs.

Cet exemple illustre la limitation fondamentale du scoring par proxy de métadonnées. La profondeur mesure « la source a fourni des données structurées », pas « le contenu a de la valeur ». Twitter fournit des descriptions complètes et des tags pour chaque tweet. Un tweet bien étiqueté sur le petit-déjeuner obtient un score de profondeur de 0,85. La recherche en extraction d’information appelle la tension sous-jacente le compromis précision/rappel : optimiser le rappel (capturer tout ce qui est pertinent) admet inévitablement des faux positifs.¹⁰

La correction que j’ai envisagée puis rejetée : Réduire la pondération de la profondeur de 0,20 à 0,10 réduirait les faux positifs provenant de contenu non pertinent bien étiqueté, mais pénaliserait aussi le contenu véritablement riche provenant de sources aux métadonnées éparses. La pondération actuelle est un compromis.

Le problème du plancher de pertinence

Un plancher de 0,25 pour une pertinence sans correspondance signifie que tout signal bien structuré provenant d’une source raisonnable obtient au moins 0,30 et atterrit dans la boîte de réception. Ce plancher crée un seuil de faux positifs : la boîte de réception accumule des signaux bien étiquetés et provenant de sources raisonnables, mais qui n’ont rien à voir avec mes centres d’intérêt.

La correction effective : Une revue périodique de la boîte de réception reste nécessaire. Le pipeline réduit la surface de revue de 7 700 éléments à 420 (soit une réduction d’environ 95 %), mais il ne peut pas éliminer la revue manuelle pour la zone ambiguë.

Notes d’implémentation

Le pipeline s’exécute comme un outil CLI. L’entrée est un tableau JSON de signaux (provenant de RSS, de l’API Twitter ou d’une saisie manuelle). La sortie est constituée de fichiers markdown compatibles Obsidian écrits dans les dossiers thématiques.

python triage.py --input signals.json --vault ~/obsidian-signals/
python triage.py --input signals.json --vault ~/obsidian-signals/ --llm-triage
python triage.py --input signals.json --min-score 0.60  # Stricter routing

Un pré-filtrage s’exécute avant le scoring : dédoublonnage d’URL par rapport aux notes existantes du coffre-fort, filtrage du contenu vide et liste noire de sources bruyantes. Les notes en doublon et les sources de spam n’atteignent jamais l’étape de scoring.

Les fonctions de scoring sont pures : pas d’effets de bord, pas d’appels API, pas d’accès au système de fichiers. Chaque fonction prend un dictionnaire de signal et renvoie un dictionnaire de scores. Cette approche pure les rend testables en isolation et composables avec l’étape de triage LLM, qui ne s’exécute que sur le sous-ensemble ambigu.⁷

Points clés à retenir

Pour les ingénieurs construisant des systèmes de triage :

• Le scoring déterministe surpasse la curation manuelle à grande échelle. 7 700 notes en 14 mois. Le triage manuel aurait nécessité plus de 50 heures de revue. Le pipeline les a traitées en quelques minutes avec un taux de routage d’environ 95 % (seuls 5,5 % ont nécessité une revue manuelle).

• Les proxies de métadonnées ont des modes de défaillance connus. La profondeur mesure la structure, pas la qualité. L’autorité mesure la source, pas l’exactitude. Ces deux proxies fonctionnent à l’échelle agrégée mais produisent des faux positifs prévisibles au niveau du signal individuel. Reconnaître les modes de défaillance est plus honnête que de prétendre que l’algorithme « fonctionne ».

Pour les praticiens de la gestion des connaissances :

• Les composites pondérés révèlent vos priorités réelles. Des pondérations de 35/30/20/15 ne sont pas arbitraires. Elles encodent un jugement spécifique : la pertinence compte plus que l’actionnabilité, qui compte plus que la richesse des métadonnées, qui compte plus que la crédibilité de la source. Rendre les pondérations explicites et ajustables fait la différence entre un système et une habitude.

• La zone ambiguë est irréductible. Les signaux entre 0,30 et 0,55 sont véritablement ambigus : le scoreur déterministe ne peut pas les résoudre. Le triage par LLM aide mais n’élimine pas la zone. La revue manuelle du sous-ensemble ambigu reste nécessaire.

J’ai formulé cet article comme un problème d’ingénierie, pas comme un conseil de productivité. Le scoring composite s’applique à tout domaine où des éléments nécessitent un routage déterministe : tickets de support, modération de contenu, qualification de prospects, détection d’anomalies. Mes pondérations et seuils spécifiques encodent des priorités personnelles, mais l’architecture est générale. Pour en savoir plus sur la façon dont les connaissances accumulées créent une valeur non linéaire, consultez Les intérêts composés mentaux. La boucle OODA pour le prompt engineering explore un schéma connexe : l’observation structurée comme alternative à l’intuition. Chaque composant du pipeline (scoring, routage, triage) est utile indépendamment et se compose avec les autres, suivant le schéma d’ingénierie composée.