paperbanana : générer des figures d'article à partir d'une description textuelle

Le problème : la figure de méthode reste un travail manuel

Un article d'apprentissage automatique contient presque toujours un schéma qui résume la pipeline : encodage, modules intermédiaires, flux de données, sortie. Le produire demande soit un outil de dessin vectoriel, soit du TikZ, soit un diagramme bricolé en fin de rédaction. paperbanana attaque ce point précis. Le README le formule comme un cadre agentique qui génère des diagrammes académiques et des graphiques statistiques de qualité publication à partir de descriptions textuelles, en s'appuyant sur le papier arXiv:2601.23265. Le public visé est nommé dans le slogan du projet : les chercheurs en IA qui écrivent eux-mêmes leur méthode et veulent une première version visuelle sans quitter leur terminal. Le projet se présente explicitement comme une implémentation non officielle, non affiliée aux auteurs originaux ni à Google Research, et précise que le résultat peut différer du système d'origine. C'est une mise au point utile : ce dépôt est une reconstruction à partir du papier public, pas une redistribution du code de recherche.

Deux phases, plusieurs agents, et un appel réseau à chaque étape

Le README décrit une pipeline multi-agents en deux phases avec raffinement itératif. Le mécanisme visible dans le matériel fourni reste volontairement haut niveau : un modèle de langage ou de vision traite la description textuelle, puis un modèle de génération d'images produit le rendu, et une couche d'optimisation d'entrée intervient en amont pour améliorer la qualité. Le projet cite quatre familles de fournisseurs : OpenAI (GPT-5.2 et GPT-Image-1.5 selon le README), Azure OpenAI / Foundry, Google Gemini et Atlas Cloud. Cette architecture implique une conséquence pratique que la documentation n'énonce pas comme un avertissement mais qui découle de la liste des fournisseurs : chaque exécution est un enchaînement d'appels réseau facturés ou limités en débit. Le mode auto-refine et la reprise d'exécution avec retour utilisateur ajoutent des cycles supplémentaires. Sur un texte de méthode long, le coût en appels n'est pas linéaire en une seule passe. Le README ne publie aucune mesure de latence ni de coût par figure, et je ne peux pas en avancer.

Installation et première génération en ligne de commande

L'installation tient en une commande : `pip install paperbanana`. Pour développer depuis les sources, le README donne `pip install -e ".[dev,openai,google]"`, ce qui indique des extras séparés par fournisseur. Le support des entrées PDF est conditionné à un extra distinct, `paperbanana[pdf]`, qui tire PyMuPDF, avec sélection page par page. Une image Docker est fournie : `docker build -t paperbanana .` puis une exécution qui monte l'entrée et le dossier de sortie dans `/work`. La configuration passe par un fichier `.env` obtenu avec `cp .env.example .env`, où l'on renseigne `OPENAI_API_KEY` ou `GOOGLE_API_KEY`. Pour Azure, la clé de configuration est `OPENAI_BASE_URL`, pointée vers l'endpoint de la ressource. Trois variables permettent de surcharger Gemini : `GOOGLE_BASE_URL`, `GOOGLE_VLM_MODEL` (l'exemple utilise `gemini-2.5-flash`) et `GOOGLE_IMAGE_MODEL` (l'exemple utilise `gemini-3-pro-image-preview`). Un assistant `paperbanana setup` existe pour Gemini. La commande de génération est `paperbanana generate --input ... --caption "..."`, et le README l'illustre sur `examples/sample_inputs/transformer_method.txt`. Le CLI est construit avec Typer et la validation avec Pydantic v2.

Batch, PDF et serveur MCP : ce que la CLI ajoute au-delà d'une figure

Trois extensions méritent l'attention parce qu'elles changent l'usage réel. D'abord la génération par lot depuis un manifeste YAML ou JSON, qui produit plusieurs diagrammes en une seule exécution. Ensuite `paperbanana plot-batch`, qui enchaîne plusieurs graphiques statistiques à partir d'un manifeste où chaque entrée pointe vers un CSV ou un JSON. C'est la partie la plus intéressante du projet pour un lecteur technique : générer un schéma conceptuel est un problème de rendu, mais tracer un graphique depuis des données brutes suppose une étape de lecture et de mise en forme que le manifeste rend explicite. Enfin le serveur MCP, déclaré sous le nom `io.github.llmsresearch/paperbanana`, expose l'outil à un IDE. Le dépôt fournit aussi des skills Claude Code pour `/generate-diagram`, `/generate-plot` et `/evaluate-diagram`, et une interface Gradio locale appelée PaperBanana Studio via `paperbanana studio`, qui couvre diagrammes, graphiques, évaluation, batch et navigation dans les exécutions. Cette accumulation de surfaces (CLI, API Python, MCP, Gradio) est cohérente avec un projet jeune qui cherche son point d'entrée principal.

Ce que le projet ne garantit pas

La limite la plus structurante est la dépendance aux fournisseurs. Sans clé OpenAI, Azure, Gemini ou Atlas Cloud, la bibliothèque n'a rien à exécuter : il n'existe pas de chemin local mentionné dans le matériel fourni. Cela exclut d'emblée les environnements hors ligne, les laboratoires qui interdisent l'envoi de contenu non publié vers une API tierce, et les cas où vous devez reproduire exactement la même figure des mois plus tard, puisque le rendu dépend d'un modèle distant qui peut changer de version. Le README ne documente ni mécanisme de cache des sorties, ni graine aléatoire, ni garantie de stabilité entre deux appels. Deuxième point : la documentation publique reste mince sur le fonctionnement interne des deux phases. Le README annonce une pipeline multi-agents et une couche d'optimisation d'entrée, mais ne détaille ni le nombre d'agents, ni les critères d'arrêt du raffinement, ni la façon dont les erreurs d'un agent sont propagées. Un lecteur qui veut auditer ou modifier la logique devra lire le code. Troisième point, plus prosaïque : c'est une implémentation non officielle, donc la conformité au système décrit dans le papier n'est pas vérifiable depuis le README seul.

Face à un pipeline TikZ ou à un rendu direct par modèle d'image

Deux approches occupent le même terrain. La première est un pipeline TikZ ou PGF/TikZ écrit à la main, éventuellement assisté par un LLM qui produit le code LaTeX : la différence n'est pas la qualité du rendu mais la nature de l'artefact. TikZ produit un fichier texte versionnable, diffable et recompilable à l'identique, ce que paperbanana ne produit pas, puisqu'il renvoie une image générée. La seconde est l'appel direct à un modèle de génération d'images avec un prompt soigné. La différence tient à ce que paperbanana ajoute autour de cet appel : la couche d'optimisation d'entrée, la séparation entre diagramme conceptuel et graphique statistique, le manifeste de lot, et l'étape d'évaluation exposée comme skill `/evaluate-diagram`. Si votre besoin se limite à une illustration unique, l'appel direct est plus simple et supprime une dépendance. Le projet prend sa valeur quand vous devez en produire plusieurs, de façon répétée, avec un format d'entrée normalisé.

Maintenance, licence et ce que MIT ne couvre pas

Le dépôt est actif : dernier push en septembre 2026, versions v0.2.0 et v0.3.0 publiées à un jour d'intervalle en juin 2026, plus un miroir de jeu de données nommé bench-data-v1. Cette cadence rapprochée sur deux versions successives suggère une API encore instable, et le README ne mentionne aucune politique de compatibilité ni de dépréciation. Concrètement, une montée de version peut casser un script d'appel à l'API Python sans préavis documenté. Le code est sous licence MIT, ce qui est permissif pour l'usage et la modification du code lui-même. Attention toutefois à ne pas confondre les deux niveaux : la licence MIT couvre le dépôt, pas les images que vous produisez. Les conditions d'utilisation d'OpenAI, de Google ou d'Atlas Cloud s'appliquent à leurs sorties respectives, et rien dans le README ne traite cette question. Je ne peux pas trancher ce point à votre place, et ce n'est pas un avis juridique. Le coût de maintenance réel se situe donc moins dans le code que dans le suivi des changements de modèles et de tarifs chez les fournisseurs.

Conclusion éditoriale

paperbanana convient à un chercheur ou une équipe qui rédige déjà en LaTeX et veut prototyper rapidement des schémas de méthode sans passer par un outil de dessin vectoriel, à condition d'accepter une dépendance totale à une clé API externe. Ce n'est pas l'outil adapté si vos figures doivent être reproductibles hors ligne, versionnées au pixel près, ou si vous ne pouvez pas envoyer le contenu de votre méthode à un fournisseur tiers. Avant d'adopter, vérifiez deux choses concrètes : lancez `paperbanana setup` puis `paperbanana generate --input examples/sample_inputs/transformer_method.txt --caption "..."` sur un texte de méthode court pour mesurer la qualité réelle du rendu, et lisez la section du README sur les fournisseurs pour confirmer lequel de OPENAI_API_KEY ou GOOGLE_API_KEY vous êtes en droit d'utiliser dans votre contexte institutionnel.

Sources officielles

1. Issues
2. License: MIT
3. llmsresearch/paperbanana on GitHub
4. README
5. Releases