OpenScience : un poste de travail pour la recherche scientifique, du terminal au bureau

Un objectif en entrée, une chaîne de travail complète

La promesse tient en une phrase du README : donnez un objectif, l'outil lit la littérature, écrit et exécute du code, mène les expériences et rédige ce qu'il a trouvé. Le public visé n'est pas le développeur qui cherche un assistant de complétion, mais l'équipe de recherche qui manipule déjà des jeux de données, des scripts d'analyse et des articles. Le README cite la bioinformatics et le ML engineering parmi les sujets du dépôt, ce qui donne une idée du terrain. La tâche se formule en langage naturel dans l'interface, par exemple demander d'inspecter data/samples.csv pour repérer les valeurs manquantes et les libellés incohérents, sans modifier les données d'origine, puis de sauvegarder un rapport de qualité et un graphique dans results/ avec le code reproductible. La demande inclut donc la preuve, pas seulement le résultat. C'est le point qui distingue un workbench de recherche d'un chat généraliste : la sortie attendue est un artefact reproductible, pas une réponse en prose.

Ce que le dépôt laisse voir de l'architecture

Le projet est écrit en TypeScript, publié sur npm sous le nom @synsci/openscience, et se pilote depuis trois surfaces : une application de bureau pour macOS, Windows et Linux, un espace de travail dans le navigateur, et un terminal. Le README ne détaille pas l'architecture interne, et il faut le dire clairement : la façon dont les étapes d'agent sont orchestrées, la persistance des sessions ou le format des artefacts ne sont pas décrits dans les éléments fournis. Ce qui est documenté, c'est le mécanisme d'extension. Le workbench accepte des connexions MCP, des agents et commandes personnalisés, des plugins, et une intégration par SDK. Les skills décrivent des procédures, et le README précise qu'un skill ne signifie pas que chaque outil ou service référencé est installé. Autrement dit, la couche de capacités est déclarative et l'exécution dépend de ce qui est réellement présent sur la machine. Cette séparation est saine sur le plan du design, mais elle déplace la responsabilité de la vérification sur l'utilisateur, qui doit inspecter la disponibilité des outils avant une tâche lourde.

Installation et choix du fournisseur de modèles

L'installation passe par npm. La commande npm install -g @synsci/openscience installe la CLI, puis openscience la lance. Un lanceur en une étape existe aussi : npx synsci. Pour ouvrir un projet existant, la commande prend un chemin en argument, openscience ~/research/my-project. Le choix de l'accès aux modèles se fait dans l'interface, à l'endroit Customize puis Models, ou depuis le terminal avec openscience keys add pour ajouter une clé, et openscience models pour consulter les modèles disponibles. Un endpoint local s'ajoute avec openscience local add, et le README mentionne Ollama, LM Studio ou tout autre endpoint compatible. L'option Ace correspond à des modèles gérés : l'activation est une autorisation à 0 dollar, la facturation se fait à l'usage à partir du coût rapporté par le fournisseur, plus des frais de financement de 5,5 pour cent appliqués une fois par requête, sans autre marge, les frais de traitement de carte étant affichés séparément au paiement. Un détail à ne pas manquer : tant que les rechargements automatiques sont actifs, un solde de portefeuille inférieur à 5 dollars déclenche un rechargement de 20 dollars, et passer à votre propre fournisseur ne désactive pas ces rechargements. C'est un comportement de facturation à connaître avant de brancher une clé personnelle.

Exécuter une tâche, avec ou sans plan préalable

Deux modes coexistent. Le mode Research exécute la tâche, tandis que la commande /plan permet de s'accorder d'abord sur la méthode. Pour un tour unique en terminal, openscience run prend la demande en argument, par exemple pour demander une revue du plan d'analyse du projet, et openscience run --continue poursuit la conversation, ici pour suggérer des vérifications sur les hypothèses identifiées. Le README insiste sur un point qui vaut d'être répété : il faut examiner les sources, les hypothèses, le code et les sorties avant de s'appuyer sur une conclusion scientifique. La fonction de reproduction d'expérience est décrite de la même manière : convenir d'une affirmation, de prérequis et d'un budget, puis comparer les résultats mesurés. Le budget fait donc partie du contrat de la tâche, ce qui est cohérent avec un outil qui exécute du code et peut consommer des appels de modèles. Rien dans les éléments fournis ne permet de dire comment ce budget est appliqué ni ce qui se passe s'il est dépassé.

Skills, connecteurs et l'écart entre catalogue et réalité

Le workbench est livré avec des centaines de skills, et il est possible d'ajouter une procédure propre à un projet. Il existe aussi des connecteurs et des accès à des bases de données, ainsi qu'un SDK pour intégrer le tout ailleurs. La limite est énoncée par le projet lui-même : un skill décrit une procédure, il ne garantit pas que chaque outil ou service mentionné soit installé. La recommandation du README est de vérifier la disponibilité dans Customize avant une tâche substantielle. C'est la contrainte la plus concrète de l'outil. Un catalogue de plusieurs centaines d'entrées donne l'impression d'une couverture large, alors que la valeur réelle dépend de l'environnement local, des identifiants configurés et des services accessibles depuis la machine. Pour un lecteur qui évalue l'adoption, la question n'est pas de savoir combien de skills existent, mais lesquels fonctionnent dans son contexte. Le projet ne fournit pas, dans les éléments disponibles, de mécanisme décrit pour tester automatiquement cette disponibilité.

Quand OpenScience n'est pas le bon outil

Trois cas de figure se dessinent. Le premier est l'analyse exploratoire courte : si vous voulez charger un CSV et tracer deux courbes, un notebook classique comme Jupyter reste plus direct, sans couche d'agent ni consommation de modèles. Le deuxième est le contexte où l'exécution de code généré n'est pas acceptable, par exemple sur des données soumises à des contraintes réglementaires ou sur une machine sans isolation. L'outil écrit et exécute du code, et le README demande explicitement de réviser ce code avant de s'appuyer sur une conclusion. Le troisième cas est celui d'une équipe qui ne peut pas utiliser de modèles externes et ne dispose pas non plus de matériel pour un endpoint local. Le mode local existe, mais il dépend de votre matériel, et le README ne donne aucune indication sur les ressources nécessaires. Sur la question des performances, des benchmarks ou du nombre d'utilisateurs, les éléments fournis ne contiennent rien, et je n'avancerai donc aucun chiffre.

Maintenance, licence et rythme de publication

Le dépôt n'est pas archivé et la dernière poussée date du 9 septembre 2026. Les versions récentes s'enchaînent à un rythme serré : v2.0.87 le 9 septembre 2026 à 16h28, v2.0.86 le même jour à 06h56, v2.0.85 à 05h58. Trois publications en une journée sur une même branche main indiquent un cycle de correction rapide, ce qui a deux conséquences pour l'adoption. D'un côté, les correctifs arrivent vite. De l'autre, une équipe qui épingle une version devra prévoir une procédure de mise à jour régulière, et le numéro de patch qui avance aussi vite suggère que la surface fonctionnelle bouge encore. Le projet est sous licence Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et d'avis. Je ne donne pas de conseil juridique : si vous redistribuez une version modifiée, faites relire les conditions par une personne compétente. Le coût de maintenance ne se limite pas au logiciel. Il inclut la gestion des clés de fournisseurs, la surveillance du solde du portefeuille Ace et de ses rechargements automatiques, et la vérification périodique des outils que les skills supposent installés.

Conclusion éditoriale

OpenScience convient aux équipes de recherche qui veulent un poste unique pour la littérature, l'analyse de données et la reproduction d'expériences, et qui acceptent de vérifier sources, hypothèses et code avant de s'appuyer sur une conclusion. Passez votre chemin si vous cherchez un simple notebook ou si vous ne pouvez pas auditer ce que l'agent exécute. Avant d'adopter, lancez openscience models pour confirmer l'accès aux modèles, puis vérifiez dans Customize quels outils référencés par les skills sont réellement installés.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. synthetic-sciences/openscience on GitHub