figures4papers : un dépôt de scripts Python pour les figures de publications, doublé d'une compétence pour agents de codage

Ce que le dépôt contient réellement

figures4papers n'est pas une bibliothèque de tracé. C'est un dépôt personnel qui regroupe les scripts Python ayant servi à produire les figures de plusieurs articles signés par Chen Liu, présenté dans le README comme doctorant en informatique à Yale. Les figures citées sont parues dans Nature Machine Intelligence, ICML, NeurIPS et ECCV, entre autres. Le dépôt est organisé en dossiers de la forme figure_*, un par projet ou par article, auxquels s'ajoutent un dossier assets/ pour les figures de démonstration et un dossier scientific-figure-making/ pour la partie destinée aux agents.

Le public visé est étroit : quelqu'un qui doit rendre une figure pour un article et qui cherche un point de départ stylistique plutôt qu'une API à importer. Le README liste les catégories couvertes : diagrammes en barres pour comparaison quantitative, diagrammes en barres pour décomposition de composition, sphères 3D, diagrammes radar, courbes, figures de concept et figures de tendance. Chaque catégorie est illustrée par un PNG hébergé dans un dossier figure_* précis, par exemple figure_ImmunoStruct/figures/bars_comparison_IEDB.png ou figure_ophthal_review/figures/trend_by_month.png.

Une section du README mérite attention : elle s'intitule Miscellaneous et regroupe des figures que l'auteur indique ne pas avoir réalisées de bout en bout en Python. Il les inclut, écrit-il, pour reconnaître le temps passé dessus. Autrement dit, une partie des visuels présentés en vitrine n'est pas reproductible à partir du code du dépôt. C'est une honnêteté appréciable, mais cela veut aussi dire que la galerie en tête de README ne doit pas être lue comme la liste des scripts exécutables.

Le dossier scientific-figure-making et son découpage

La partie la plus structurée du dépôt est scientific-figure-making/. Le README en donne l'arborescence : un fichier SKILL.md à la racine, puis un dossier references/ contenant api.md, common-patterns.md, demos.md, design-theory.md et tutorials.md.

La répartition des rôles est explicite dans les commentaires du README. SKILL.md sert de référence rapide : métadonnées, cas d'usage, motifs, liens. api.md décrit l'API et les conventions à implémenter, à savoir la palette, les helpers et l'export. common-patterns.md rassemble des motifs de figures réutilisables. demos.md pointe vers les projets figure_* réels avec leurs URL. design-theory.md expose la logique de style et les principes de conception. tutorials.md propose des guides pas à pas.

Ce découpage a une conséquence pratique : le contenu normatif n'est pas dans SKILL.md mais dans references/. Un agent qui ne lit que SKILL.md obtient un index, pas les règles de style. Le README demande d'ailleurs explicitement, dans le modèle de prompt fourni, de citer à la fois SKILL.md et references/design-theory.md, et de consulter references/api.md pour la palette, les helpers et l'export. Les helpers nommés sont apply_publication_style, les fonctions make_* et finalize_figure. Le dépôt ne publie pas de documentation en ligne de ces fonctions : la seule source est ce dossier references/.

Deux façons de s'en servir, dont une sans installation

Le README documente deux modes d'utilisation pour un agent de codage. Le premier ne demande aucune installation : on ouvre le dépôt dans l'agent (Cursor, Claude Code) et on référence la compétence par son chemin dans le prompt. L'agent lit alors scientific-figure-making/SKILL.md et les fichiers de references/ directement depuis le dépôt, sans lien symbolique ni greffon.

Le second mode installe la compétence par lien symbolique. Depuis la racine du dépôt, pour Cursor : mkdir -p ~/.cursor/skills puis ln -s "$(pwd)/scientific-figure-making" ~/.cursor/skills/scientific-figure-making. Pour Claude Code, le chemin cible est ~/.claude/skills/scientific-figure-making. Pour Codex, ~/.codex/skills/scientific-figure-making. Le README précise qu'il faut redémarrer l'agent ou rafraîchir sa liste de compétences après la création du lien, et qu'on peut ensuite invoquer la compétence par son nom.

Le modèle de prompt fourni demande de créer un script de figure à un chemin cible, de suivre les conventions de SKILL.md, design-theory.md et api.md, d'implémenter ou d'adapter les motifs apply_publication_style, make_* et finalize_figure, puis d'exporter deux fichiers, un .png et un .pdf. Le script produit doit rester cohérent avec le style du dépôt. Aucun exemple de sortie n'est fourni dans le matériel dont je dispose, donc je ne peux pas décrire le rendu obtenu.

Le point faible : pas de release, pas de paquetage, pas de licence claire

Le dépôt ne publie aucune release. Le matériel indique également une licence NOASSERTION, ce qui signifie que GitHub n'a pas su classer le fichier de licence et qu'aucun identifiant SPDX standard n'est associé au projet. Ce n'est pas un détail : sans licence explicite, la réutilisation des scripts dans un article ou un produit n'est pas encadrée par un texte connu à l'avance. La question se pose concrètement pour la palette et les helpers de scientific-figure-making/references/api.md, qui sont du code destiné à être copié dans d'autres projets. Je ne peux pas trancher ce point à partir du matériel fourni, et je n'ai pas à le faire : il faut le vérifier auprès de l'auteur avant de reprendre du code.

Deuxième limite, structurelle : il n'y a pas de fichier de paquetage mentionné, donc pas de pip install, pas de versionnage, pas de dépendances déclarées dans le matériel. Les scripts des dossiers figure_* sont des scripts de projet, pas des modules. Les réutiliser suppose de lire le script concerné et d'en extraire ce qui vous intéresse.

Troisième limite : le dépôt est mono-auteur et lié à des articles précis. Le README indique que la dernière poussée date du 6 septembre 2026, mais rien ne décrit une politique de maintenance, un cycle de mise à jour ou une prise en charge des versions de matplotlib. Un dépôt de scripts personnels n'a pas à en avoir, mais cela change le calcul pour qui envisage de s'appuyer dessus.

Ce que cela remplace, et ce que cela ne remplace pas

L'alternative évidente est une bibliothèque de tracé scientifique généraliste, du type de celles qui proposent des styles prêts à l'emploi et une API stable. La différence d'approche est nette. Une bibliothèque de style fournit un thème et des valeurs par défaut, que vous appliquez à vos propres appels de tracé. figures4papers fournit l'inverse : des scripts complets, écrits pour des figures précises, avec une théorie de conception rédigée à côté. Vous partez du script fini et vous adaptez, au lieu de partir d'un thème et de tout écrire.

Cette différence a un coût. Un thème s'installe et se met à jour par un gestionnaire de paquets. Ici, la mise à jour consiste à relire le dépôt et à comparer avec votre copie. L'avantage, en revanche, est que les scripts montrent des figures complètes, y compris des compositions que les thèmes généralistes traitent mal, comme les diagrammes radar ou les sphères 3D illustrées par figure_Dispersion/figures/illustration.png.

Ce dépôt ne remplace pas non plus un outil de dessin vectoriel. Le README le dit lui-même en séparant les figures faites de bout en bout en Python de celles qui ne le sont que partiellement. Si votre figure est un schéma d'architecture avec des flèches et des encadrés, les scripts de tracé ne vous aideront pas beaucoup.

À qui cela sert, et à quel moment

Le cas d'usage le plus net est celui d'un auteur qui doit produire une figure de comparaison ou de tendance pour un article et qui veut éviter de réinventer les conventions de style. Le dépôt donne des scripts de référence par type de figure, et le dossier references/ donne la logique derrière ces choix. Pour un doctorant ou un chercheur qui publie régulièrement, c'est un gain de temps réel, à condition d'accepter de lire du code plutôt que de la documentation d'API.

Le second cas est celui d'un utilisateur d'agent de codage qui veut que l'agent produise des figures cohérentes entre elles. Le mode par lien symbolique est là pour cela, et le modèle de prompt fourni cadre la demande. C'est probablement l'apport le plus original du dépôt par rapport à un simple dépôt de scripts.

Le mauvais cas est celui d'une équipe qui cherche une dépendance à maintenir dans un pipeline automatisé. Pas de release, pas de paquetage, pas de licence identifiée : trois raisons de regarder ailleurs. De même, si vous avez besoin de figures interactives ou de rendu web, rien dans le matériel ne l'indique.

Conclusion éditoriale

À adopter si vous produisez des figures pour un article et voulez des scripts de référence couvrant barres, radars, courbes, nuages 3D et figures de concept, avec une convention de style documentée dans scientific-figure-making/references/design-theory.md. À éviter si vous attendez une bibliothèque installable : il n'y a ni release, ni fichier de paquetage, ni licence explicite, et le README précise que certaines figures n'ont pas été produites entièrement en Python. Avant tout usage, lisez scientific-figure-making/references/api.md pour vérifier la présence des helpers apply_publication_style, make_* et finalize_figure, et clarifiez le statut de licence auprès de l'auteur.

Sources officielles

1. ChenLiu-1996/figures4papers on GitHub
2. Issues
3. Project website
4. README