MetaScreener : un ensemble de LLM open source pour le tri des résumés en revue systématique
AI-powered tool for efficient abstract and PDF screening in systematic reviews.
En bref
- De quoi s’agit-il ?
- MetaScreener automatise la phase de sélection des revues systématiques en faisant voter plusieurs LLM open source via OpenRouter, puis en routant les cas incertains vers un relecteur humain. Le dépôt documente une architecture en quatre couches, des presets de modèles et des coûts annoncés par article.
- À qui s’adresse-t-il ?
- MetaScreener convient aux équipes de revue systématique qui veulent un screening reproductible et chiffré, pas un remplacement du jugement humain. Il ne convient pas à celles qui refusent de dépendre d'OpenRouter ou qui attendent une version stable, le dépôt n'ayant pas dépassé le stade 2.0.0a4.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 96 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : trier des milliers de références sans y perdre la reproductibilité
Une revue systématique commence par une recherche bibliographique qui ramène souvent plusieurs milliers de titres et résumés. Deux relecteurs doivent ensuite décider, référence par référence, si le document mérite une lecture en texte intégral. Ce travail est long, et sa reproductibilité est fragile : deux personnes n'appliquent pas toujours les mêmes critères PICO de la même façon, et le désaccord se règle par discussion, sans trace quantifiée.
MetaScreener vise cette phase précise. Le dépôt le décrit comme un outil qui lit chaque titre et résumé, renvoie une décision d'inclusion ou d'exclusion avec un score de confiance, et route les cas incertains vers une relecture humaine. Le public visé est donc l'équipe qui conduit la revue, pas le développeur qui veut intégrer un modèle dans son propre pipeline. Le README insiste sur la reproductibilité : température fixée à 0.0, graine à 42, et une piste d'audit attachée à chaque décision.
Ce positionnement a une conséquence directe. L'outil ne cherche pas à remplacer le relecteur, il cherche à réduire le nombre de décisions qui exigent son attention. C'est une distinction que le vocabulaire du README rend explicite avec la notion de tiers.
Quatre couches, du vote des modèles au routage par palier
L'architecture documentée s'appelle Hierarchical Consensus Network et se lit comme une chaîne de traitement en quatre étages.
La première couche est l'inférence. Quatre modèles ou plus tournent en parallèle via des API, et le README cite DeepSeek, Qwen, Llama et Kimi. L'entrée accepte des fichiers .ris, .bib, .csv ou .xlsx, ce qui correspond aux exports classiques de PubMed ou Scopus. Rien dans le matériel fourni ne décrit un pré-traitement local du texte avant l'appel d'API.
La deuxième couche est un moteur de règles. Les critères PICO, PEO ou SPIDER alimentent deux types de règles : des règles dures qui excluent automatiquement, et des règles souples qui appliquent des pénalités de score. C'est ici que se joue la partie déterministe du système, celle qui ne dépend pas du jugement d'un modèle.
La troisième couche agrège. Le README nomme deux mécanismes : Calibrated Confidence Aggregation et Element Consensus Scoring. Le premier applique une calibration a posteriori, Platt ou Isotonic, pour transformer les scores bruts en probabilités. Le second mesure l'accord entre modèles élément par élément, sur les composantes P, I, C et O.
La quatrième couche route la décision. Le Tier 0 correspond à une exclusion par règle dure. Le Tier 1 est une décision automatique à haute confiance. Le Tier 2 est une décision automatique modérée. Le Tier 3 part en relecture humaine. Cette séparation en paliers est ce qui rend l'outil utilisable en pratique : sans elle, un score de confiance unique obligerait à choisir un seuil binaire, et tout le bénéfice de l'ensemble disparaîtrait.
Installation : pip, Docker ou source, et une clé OpenRouter obligatoire
Les trois voies d'installation sont documentées explicitement.
La plus courte passe par pip, avec Python 3.11 ou plus récent :
pip install metascreener python -m metascreener
Le serveur écoute ensuite sur http://localhost:8000.
La voie Docker évite d'installer Python :
docker pull chaokunhong/metascreener:latest docker run -p 8000:8000 -e OPENROUTER_API_KEY="sk-or-v1-your-key-here" chaokunhong/metascreener
La voie source s'adresse aux développeurs et demande uv ainsi que Node.js 18 ou plus récent :
git clone https://github.com/ChaokunHong/MetaScreener.git cd MetaScreener uv sync --extra dev python run.py
Dans ce dernier cas, le backend écoute sur le port 8000 et le frontend Vite sur le port 5173.
La configuration de la clé se fait soit par la page Settings de l'interface web, soit par la variable d'environnement OPENROUTER_API_KEY. Cette dépendance est structurelle : les quinze modèles listés passent par OpenRouter. Le dépôt ne décrit aucune voie d'exécution locale, ce qui exclut de fait les environnements sans accès sortant vers ce service.
Le README mentionne aussi une interface Vue 3 organisée en étapes numérotées, de la génération des critères à l'historique des sessions, en passant par le screening titre/résumé, le screening texte intégral avec découpage, l'extraction de données et l'évaluation du risque de biais selon RoB 2, ROBINS-I ou QUADAS-2.
Ce que coûtent les presets, et ce qu'ils ne garantissent pas
Le dépôt annonce trois presets. Balanced combine quatre modèles pour environ 0,005 dollar par article. Precision associe deux modèles de raisonnement et deux grands modèles, pour environ 0,009 dollar. Budget prend un modèle d'ancrage et trois modèles rapides, pour environ 0,003 dollar.
Ces chiffres proviennent du README et n'ont pas été reproduits ici. Ils dépendent entièrement des tarifs d'OpenRouter au moment de l'exécution, et le dépôt ne décrit pas de plafond de dépense ni de mécanisme d'arrêt automatique en cas de dépassement. Sur une revue de dix mille références au preset Balanced, la projection tourne autour de cinquante dollars, mais rien dans le matériel fourni ne permet de vérifier comment les tokens sont comptés, ni si un PDF long consomme davantage qu'un résumé.
Le classement des modèles en trois niveaux, Flagship, Strong et Lightweight, est une hiérarchie de capacité revendiquée, pas un résultat mesuré dans le dépôt. Le README attribue aux modèles Flagship, dont DeepSeek V3, Qwen 3 et Kimi K2.5, une meilleure exactitude et de meilleures connaissances médicales, sans citer d'évaluation. C'est une affirmation de conception, à traiter comme telle.
Le protocole d'audit des faux positifs et la question de la version
Le dépôt a publié une étiquette de version intitulée fp-audit-protocol-v1.0 en mai 2026, décrite comme un verrouillage de protocole d'audit des faux positifs. C'est un signal intéressant : dans une revue systématique, l'erreur qui coûte cher n'est pas symétrique. Exclure à tort un article pertinent fausse la synthèse et ne se voit pas, alors qu'inclure à tort un article non pertinent se corrige à l'étape suivante. Un protocole dédié aux faux positifs suggère que l'équipe a identifié ce déséquilibre.
Le matériel fourni ne détaille pas le contenu de ce protocole, ni la façon dont il s'articule avec les paliers de décision. Il faut donc le lire dans le dépôt avant de s'appuyer dessus.
Le second point est le statut des versions. La plus récente version publiée est 2.0.0a4, datée de février 2026, précédée de 2.0.0a3 la veille. Le suffixe alpha est explicite. Une équipe qui doit geler une méthode pour une revue publiée prend un risque en s'appuyant sur une branche dont le numéro de version annonce encore des changements d'API. Le README décrit par ailleurs un mécanisme d'apprentissage actif où le retour humain recalibre les poids des modèles en temps réel : un tel mécanisme implique que deux sessions avec des retours différents ne produisent pas les mêmes décisions, ce qui complique la revendication de reproductibilité totale. Le dépôt ne montre pas comment ces deux objectifs coexistent.
Face à un tri par règles ou à un relecteur unique assisté
L'alternative la plus directe n'est pas un autre outil d'IA, c'est le tri par règles déterministes dans un gestionnaire de références, du type Rayyan ou un script sur les métadonnées. La différence d'approche est nette : une règle sur l'année, la revue ou la présence d'un terme dans le résumé produit une décision explicable ligne par ligne, sans appel réseau ni coût par article. Elle échoue sur tout ce qui demande de comprendre un texte, par exemple juger si une population correspond à un critère PICO formulé en langage naturel.
MetaScreener prend le parti inverse. Il accepte le coût par article et la dépendance à un fournisseur pour gagner en couverture sémantique, puis tente de récupérer l'explicabilité par la calibration et le vote. Le prix de ce choix est visible dans l'architecture : trois des quatre couches servent à contrôler l'incertitude produite par la première.
Une seconde alternative consiste à confier le tri à un seul grand modèle avec un prompt soigné. C'est moins cher et plus simple à auditer, puisque la décision vient d'une source unique. Le README répond à cela en invoquant l'absence de point de défaillance unique, mais cette réponse a une limite : si les quatre modèles partagent des données d'entraînement et des biais similaires, leur accord mesure surtout une corrélation, pas une vérité. Le score de consensus élément par élément ne distingue pas ces deux situations.
Licence et coût de maintenance
Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et d'état des modifications, et avec une clause de brevets. Le matériel fourni ne mentionne aucune restriction additionnelle, ni sur les modèles utilisés, ni sur les données. Il ne dit rien non plus sur les conditions d'OpenRouter, qui régissent l'usage réel du service. Ce point mérite une lecture séparée, notamment si les résumés ou les PDF soumis contiennent des données de patients.
Le coût de maintenance se répartit en deux postes. Le premier est le suivi des modèles : le dépôt liste quinze modèles organisés par capacité, et ce genre de liste se périme vite, entre renommages, dépréciations et changements de tarifs chez le fournisseur. Le second est le suivi des dépendances Python et Node, puisque la voie source demande uv et Node.js 18 ou plus récent. Une équipe qui installe via Docker s'épargne le second poste, pas le premier. Rien dans le matériel fourni n'indique une cadence de publication régulière ni un engagement de support.
Conclusion éditoriale
MetaScreener convient aux équipes de revue systématique qui veulent un screening reproductible et chiffré, pas un remplacement du jugement humain. Il ne convient pas à celles qui refusent de dépendre d'OpenRouter ou qui attendent une version stable, le dépôt n'ayant pas dépassé le stade 2.0.0a4. Avant tout usage réel, vérifiez que la licence Apache-2.0 couvre bien votre cas, que le protocole d'audit des faux positifs publié en mai 2026 correspond à vos critères, et que les PDF que vous soumettez peuvent sortir de votre infrastructure vers les fournisseurs de modèles.
Notes de la communauté