Banana Slides : générer un PPTX modifiable à partir d'une phrase, sans maquette

Le problème : le rendu final doit rester modifiable

La plupart des outils qui produisent des diapositives à partir d'un texte livrent soit des images, soit un format propriétaire. Dans les deux cas, la retouche après coup est pénible : on régénère, on recommence, on perd la mise en page obtenue. Banana Slides prend le problème par l'autre bout. Le dépôt annonce un export vers un PPTX modifiable, ce qui suppose de reconstruire une structure de diapositives plutôt que de coller une image plein cadre. Le projet vise donc un public précis : des personnes qui doivent présenter quelque chose rapidement mais qui savent qu'elles devront intervenir sur le fichier ensuite, ne serait-ce que pour corriger un chiffre ou déplacer un bloc. Le README cite aussi un export vidéo, ce qui déplace l'outil hors du seul cadre bureautique. Le slogan du dépôt, « Vibe PPT », résume la promesse : décrire plutôt que mettre en forme.

Ce que le dépôt expose réellement comme entrées

Le README énumère plusieurs chemins d'entrée : une phrase, un plan, une description page par page, des documents, des images et des modèles personnalisés. Il mentionne également une analyse automatique des éléments fournis. La fonction de modèles mérite qu'on s'y arrête, car c'est la partie la plus structurée du projet. Une note de version datée du 23 juin 2026 décrit deux modes : un modèle unique pour tout le jeu de diapositives, ou un modèle distinct par page. Les modèles peuvent être construits à partir d'images ou de PDF, l'outil en extrait un style, puis propose une correspondance page par page, avec possibilité de lier manuellement chaque page. Les deux modes sont présentés comme interchangeables à tout moment. C'est une conception qui a du sens : la cohérence visuelle est le premier point de friction quand on génère des pages indépendamment les unes des autres.

Architecture : un orchestrateur au-dessus de fournisseurs interchangeables

Le dépôt est en TypeScript et se déploie via Docker. Le README renvoie à des sections Architecture, API et Deploy, sans en détailler le contenu dans l'extrait fourni. Ce qui ressort des notes de version, en revanche, c'est une couche d'abstraction sur les fournisseurs. La version 0.9.0-rc.4 corrige l'indisponibilité des fournisseurs en ligne LazyLLM dans le paquet de bureau, et une note du 31 juillet 2026 indique que onze fournisseurs sont enregistrés : qwen, doubao, deepseek, glm, kimi, minimax, sensenova, siliconflow, ppio, aiping et openai. Le modèle d'image reste distinct du modèle de texte, comme le montre la correction de la rc.7, où le modèle d'appel principal passe de gpt-5.4 à gpt-5.6-terra tandis que le modèle d'image reste gpt-image-2. Cette séparation texte/image est le vrai centre de gravité du projet : la qualité du rendu dépend d'un modèle d'image, la structure dépend d'un modèle de texte, et les deux ne se règlent pas au même endroit.

Mise en route : Docker, .env, et une clé d'API

Le README renvoie à un guide Quick Start et à un déploiement Docker local, sans fournir la commande exacte dans l'extrait disponible. Je ne peux donc pas donner ici de commande que je n'ai pas vue. Ce qui est confirmé, c'est l'existence d'un fichier .env avec au moins une clé documentée : PUBLIC_DEMO_ADMIN_PASSWORD, qui protège l'accès à /admin/history sur une instance de démonstration publique. Le dépôt signale aussi une page de paramètres où les tests de chaque service peuvent être lancés simultanément, chacun affichant son résultat séparément. C'est un détail utile : quand on empile plusieurs fournisseurs, diagnostiquer lequel répond mal devient vite le principal temps passé. La démonstration publique impose des modèles fixes (Inferera, APIMart, 火山 Agent Plan) avec des clés isolées par visiteur, et ne conserve pas d'historique, d'où la recommandation de sauvegarder le lien de la page de prévisualisation.

Le point faible : une dépendance externe non négociable

Banana Slides n'est pas un moteur de mise en page. C'est un client autour de modèles de génération d'images. Sans clé d'API valide et sans accès réseau vers un fournisseur, l'outil ne produit rien. Le README mentionne d'ailleurs des correctifs récurrents sur ce point : erreurs de credentials MinerU, risque SSRF sur les images distantes d'un document de référence, dépendance SOCKS manquante dans le paquet de bureau. Autant de symptômes d'une architecture qui parle à l'extérieur en permanence. Deuxième limite : la maturité. Les versions publiées entre le 29 août et le 5 septembre 2026 sont toutes des candidates 0.9.0-rc.5, rc.6 et rc.7. Une rc reste une rc. Troisième limite, plus discrète : les notes de version corrigent des régressions d'interface à répétition (bouton retour disparu puis restauré, tiroir de propriétés qui masque une fenêtre d'export). Cela indique un projet qui bouge vite, ce qui est un compliment sur l'activité et un avertissement sur la stabilité.

Face à une chaîne classique de gabarits

L'alternative évidente reste une bibliothèque de composants de présentation couplée à un modèle de langage, par exemple python-pptx ou PptxGenJS pilotés par un LLM. La différence d'approche est nette. Dans cette seconde voie, le modèle de langage remplit un gabarit que vous contrôlez : chaque bloc a une position définie, le résultat est reproductible, et une même entrée donne une même sortie. Banana Slides fait l'inverse : il génère d'abord une image de page, puis reconstruit du contenu éditable. Le rendu visuel est plus libre, la variabilité est plus forte, et le coût par présentation dépend directement du prix du modèle d'image. Un gabarit classique ne demandera jamais de clé d'API d'image, ne dépendra pas d'un fournisseur, et ne vous facturera rien à la génération. Il produira en revanche des diapositives visiblement standardisées, ce qui est précisément ce que Banana Slides cherche à éviter.

Licence et coût de maintenance

Le projet est publié sous AGPL-3.0. Cette licence impose, lorsqu'une version modifiée est mise à disposition via un service réseau, de rendre le code source correspondant accessible aux utilisateurs de ce service. Pour un usage interne ou une exécution locale, la contrainte est faible. Pour quelqu'un qui voudrait héberger Banana Slides comme service public avec des modifications maison, elle change la donne. Je ne donne pas d'avis juridique : faites lire le texte de la licence si ce scénario vous concerne. Sur la maintenance, le rythme des publications est soutenu et le projet n'est pas archivé. La contrepartie est un coût de suivi réel : chaque version candidate corrige des points de configuration chez les fournisseurs, et une instance laissée sans mise à jour pendant plusieurs mois risque de rencontrer des erreurs d'authentification ou de format d'appel. La note du 15 juillet 2026 sur la réparation automatique des caches de navigateur corrompus montre aussi que l'état local du client fait partie de la surface à maintenir.

Conclusion éditoriale

Banana Slides convient à un usage individuel ou à une petite équipe capable de gérer un fichier .env, un déploiement Docker et une clé d'API d'image, et qui veut garder la main sur le rendu final au format PPTX. Il ne convient pas à qui cherche une chaîne déterministe sans modèle externe, ni à une organisation qui refuse l'AGPL-3.0 pour un service exposé à des tiers. Avant d'adopter, vérifiez deux choses concrètes : que votre fournisseur d'images accepte le volume de génération prévu, et que la version que vous installez est bien une version stable et non l'un des candidats v0.9.0-rc.x publiés entre août et septembre 2026.

Sources officielles

1. Anionex/banana-slides on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases