177 skills, 100 bases de données : ce qui manque vraiment à un scientifique augmenté par l'IA

Cette semaine, le cinquième repo du classement hebdomadaire des tendances GitHub n'était pas un modèle. C'était un annuaire de skills pour scientifiques : 177 d'entre eux, couvrant la biologie, la chimie, la médecine et la découverte de médicaments, branchés sur plus de 100 bases de données scientifiques. Le repo revendique 250 000 scientifiques utilisateurs. Ce chiffre vient du projet lui-même et doit se lire comme une allégation commerciale, mais le nombre d'étoiles — plus de 53 000 sur un dépôt créé en octobre 2025 — est public et vérifiable.

L'argument tient en une phrase : transformer n'importe quel agent IA en scientifique IA. Pourquoi cette phrase a besoin de 177 fichiers pour être vraie, c'est la partie que personne n'explique.

Parce que le goulot d'étranglement n'a jamais été le raisonnement

Demandez à un modèle de pointe d'expliquer une voie de repliement de protéine : il s'en sort honorablement. Demandez-lui d'aller chercher la structure réelle d'un ID Uniprot précis, de croiser les variants associés avec ClinVar, de les aligner sur un génome de référence, puis de tracer les scores de conservation — et il produira quelque chose qui ressemble à tout ça et qui est en partie inventé.

Ce qui manque n'est pas l'intelligence. C'est la plomberie. Le travail scientifique repose sur quelques centaines de bases de données et de formats de fichiers spécialisés, dont la plupart ont des API idiosyncratiques, et dont chacun est un endroit où un modèle de langage va halluciner un nom de colonne avec assurance.

Un skill, dans ce contexte, est un petit paquet qui connaît une de ces interfaces. Quels arguments prend un outil, à quoi ressemble la réponse, quels identifiants sont valides, quel défaut est raisonnable. C'est la différence entre dire à un agent « va chercher la protéine » et lui tendre une fonction qui échoue bruyamment quand l'ID est mal formé.

{{INLINE1}}

Ce qu'il y a vraiment dans les 177

La liste de topics du repo est la description la plus honnête disponible : bioinformatique, chimioinformatique, génomique, protéomique, métabolomique, recherche clinique, science des matériaux, découverte de médicaments, calcul scientifique, visualisation scientifique. À lire comme une carte des frictions, pas comme une liste de capacités.

La génomique illustre bien pourquoi la friction est élevée. Une seule analyse peut toucher un assemblage de référence, une base de variants, une piste d'annotation et un package statistique, chacun avec sa propre convention de coordonnées. En génomique, les erreurs off-by-one sont un genre de bug, pas un accident. Un skill qui encode « cette base est en base 1, celle-là en base 0 » évite toute une classe de réponses fausses qu'aucune capacité de modèle ne corrige.

La chimie a la même forme, avec plus de danger. Les chaînes SMILES, les clés InChI, les masses moléculaires et les seuils de test ressemblent tous à du texte brut, et aucun ne l'est. Un agent qui traite une chaîne SMILES comme de la prose produira une molécule qui n'existe pas, parfaitement formatée.

La proposition de valeur est donc peu glamour et bien réelle : ces skills sont une mémoire des détails d'interface, maintenue en un seul endroit, au lieu d'un préambule de prompt réécrit par chaque labo.

Le problème de distribution que personne ne résout

Il y a un problème plus discret à empaqueter 177 skills dans un seul repo. L'épinglage de version. Si un skill enveloppe une base de données dont l'API change à son propre rythme, le skill est une couche de compatibilité qui se dégrade. Un labo qui épingle la version 1.4 de la bibliothèque et obtient un pipeline qui marche en mars peut le retrouver cassé en septembre, et la panne ressemblera à un problème de modèle plutôt qu'à un problème de dépendance.

Le monde du logiciel a résolu ça avec des lockfiles et du versionnage sémantique, en une quinzaine d'années, et mal. Le logiciel scientifique n'a ni l'un ni l'autre, et il importe maintenant un graphe de dépendances qu'il n'a pas demandé.

« Validé » est le mot sur lequel il faut appuyer

Le repo décrit ses skills comme validés. C'est un mot fort pour une catégorie sans standard partagé, et il vaut la peine de demander en quoi consiste la validation. Testés contre des sorties connues ? Relus par un expert du domaine ? Ou simplement exécutés une fois sans planter ?

Les trois sont raisonnables, et ils veulent dire des choses très différentes. Pour un connecteur de base de données, « renvoie le bon enregistrement pour une requête connue » est un vrai test. Pour un skill d'analyse qui recommande une méthode statistique, aucun test ne tranche, parce que la bonne méthode dépend du plan expérimental.

C'est là que les skills de domaine diffèrent des skills de code qui remplissaient les tendances plus tôt cette année. Un skill qui formate un diff se vérifie mécaniquement. Un skill qui décide s'il faut un test t ou un modèle mixte, non. Et le livrer dans un paquet avec 176 frères « validés » suggère un niveau d'assurance qu'il n'a peut-être pas.

La liste de compatibilité, c'est la stratégie

Le repo dit fonctionner avec Cursor, Claude Code, Codex, Pi, Antigravity et le standard ouvert Agent Skills. Cette liste est plus intéressante que l'ensemble des fonctionnalités. Une bibliothèque de skills qui tourne sur un seul agent est une fonctionnalité de cet agent. Une bibliothèque qui tourne sur six est une infrastructure, et l'infrastructure est adoptée par ceux qui ne veulent pas parier sur l'agent qui va gagner.

Cela met aussi la bibliothèque dans une position inconfortable. Le standard ouvert Agent Skills est jeune, et chaque hôte l'implémente un peu différemment : où vivent les skills, comment ils sont découverts, quelles permissions ils reçoivent. Maintenir 177 skills sur six hôtes est une charge de support qui croît plus vite que le nombre de skills. C'est généralement là que ces projets soit se consolident, soit se réduisent discrètement à deux plateformes.

Pour un labo, pourtant, la portabilité est tout l'intérêt. Un postdoc qui écrit un skill pour un pipeline de spectrométrie de masse veut qu'il fonctionne dans l'outil que la bourse du PI paiera l'année prochaine.

Ce que ça change pour un chercheur qui travaille

Trois choses, par ordre de proximité.

D'abord, la victoire ennuyeuse : la recherche de littérature et de bases de données cesse d'être un endroit où le modèle invente des citations. Si un skill interroge le vrai index, la référence est réelle ou l'appel échoue. C'est une amélioration mesurable dans un flux qui coûte aujourd'hui des heures de vérification.

Ensuite, la reproductibilité gagne un nouvel artefact. Un pipeline assemblé à partir de skills nommés et de versions épinglées est plus reproductible qu'un journal de conversation, parce qu'il peut être relancé. Que quelqu'un épingle réellement les versions est une autre affaire, et les premières preuves venues des chaînes d'approvisionnement logicielles ne sont pas encourageantes.

Enfin, et c'est le plus lent : la division du travail change. Le métier du scientifique cesse d'être « opérer les outils » et devient « décider quelle question vaut ce calcul ». C'est la version de l'IA dans la science que tout le monde vend. Elle arrive, si elle arrive, par 177 fichiers d'interface sans éclat plutôt que par une percée.

Ce qu'il faut surveiller

Surveillez si le nombre de skills continue de croître ou commence à diminuer. Un annuaire qui ajoute des skills sans fin est une opération de content marketing. Un annuaire qui consolide, déprécie et publie ce qui a cassé est un outil dont les gens dépendent.

Et surveillez si l'un d'eux finit cité dans la section méthodes d'un article. C'est le moment où un skill cesse d'être une commodité et devient une partie du dossier scientifique, avec toutes les obligations de revue que cela implique. Personne n'a encore eu à résoudre ça. Quelqu'un le fera, probablement dans l'année.