Edit Banana : convertir un schéma figé en fichier DrawIO éditable

Le problème : un schéma en JPEG n'est pas un document

Un diagramme publié sous forme d'image ne se modifie pas. Renommer une étape, corriger une flèche, changer une couleur de remplissage : tout cela suppose de redessiner l'ensemble, ou de retrouver le fichier source, qui a souvent disparu. Edit Banana attaque précisément ce point. Le README formule l'objectif ainsi : transformer un contenu fixe en actif manipulable. La sortie annoncée est du XML DrawIO, c'est-à-dire un format que l'éditeur draw.io ouvre et où chaque forme, chaque flèche et chaque bloc de texte redevient un objet indépendant. Le public visé est donc celui qui produit de la documentation technique, des supports de cours ou des articles, et qui doit reprendre des figures anciennes dont il ne possède plus que l'image. Le dépôt est porté par des enseignants-chercheurs de la Beijing Institute of Technology, rattachés à des thématiques de gestion de données et d'IA centrée données, ce qui oriente le projet vers un usage académique et démonstratif plutôt que vers une bibliothèque généraliste.

Segmentation SAM 3 puis reconstruction multimodale

La chaîne décrite dans le README repose sur deux étages. Le premier est une segmentation : le projet indique utiliser un SAM 3 (Segment Anything Model 3) affiné pour isoler les éléments du diagramme. Le second étage fait intervenir des modèles de langage multimodaux, décrits comme un « Fixed Multi-Round VLM », pour reconstruire la structure et le texte. Le résultat revendiqué est une restauration 1:1 des contours, des remplissages et des styles de flèches, y compris les pointillés et les épaisseurs, avec conservation de la logique de disposition et de la hiérarchie des éléments. Le README ajoute une dimension d'interaction : une démonstration montre une réparation manuelle et une sauvegarde locale, ce qui suppose une étape de relecture humaine dans la boucle plutôt qu'un pipeline entièrement automatique. C'est un choix cohérent avec la nature de la tâche. Aucune architecture détaillée, aucun schéma de flux de données et aucune métrique de qualité ne figurent dans les éléments fournis : la section Architecture Pipeline est annoncée dans la table des matières, mais son contenu n'est pas repris ici.

Installation : ce que le README permet d'écrire

Le projet est en Python et le badge du README fixe un prérequis de Python 3.10 ou supérieur. Un second badge mentionne CUDA comme recommandé, ce qui suggère que l'inférence locale suppose un GPU NVIDIA, sans que le README détaille les modèles à télécharger ni leur taille. Les sections Installation & Setup, Usage et Configuration existent dans la table des matières, mais leur contenu n'apparaît pas dans le matériel fourni. Je ne peux donc citer ni commande d'installation, ni clé de configuration, ni nom de fichier d'entrée. La seule voie documentée avec certitude est le service en ligne à l'adresse www.editbanana.net : on y dépose une image et on récupère, selon le README, un fichier DrawIO éditable. Un lecteur qui veut exécuter le code localement devra se référer directement au dépôt pour les étapes manquantes, et vérifier au passage la présence d'un fichier de dépendances.

Le dépôt est en retard sur le service web

Le README porte un avertissement explicite : le dépôt GitHub est en retard sur le service web, et l'équipe recommande d'utiliser la plateforme en ligne pour les fonctionnalités et les performances les plus récentes. C'est une information de première importance pour quiconque évalue le projet comme brique logicielle. Elle signifie que le code publié n'est pas le code qui produit les démonstrations montrées dans le README, et qu'un écart de comportement entre les deux est attendu. S'y ajoute une incohérence de licence : les métadonnées du dépôt indiquent AGPL-3.0, tandis que le badge du README affiche Apache 2.0. Ces deux licences n'ont pas les mêmes conséquences. L'AGPL-3.0 impose, dans les grandes lignes, de fournir le code source aux utilisateurs d'un service en réseau dérivé de ce code, ce qui est structurant pour un éditeur SaaS. Apache 2.0 n'a pas cette clause. Il faut donc lire le fichier LICENSE du dépôt avant tout usage en production, et faire trancher la question par un juriste si le projet doit être intégré à un service exposé.

Quand Edit Banana n'est pas le bon outil

Trois situations plaident contre ce projet. D'abord, si vous possédez déjà les sources : convertir un SVG ou un fichier Visio existant vers DrawIO relève d'un convertisseur de formats, pas d'une reconstruction par vision. Ensuite, si vos diagrammes sont confidentiels. Le chemin le plus documenté passe par un service web externe, ce qui suppose d'envoyer vos images à une infrastructure tierce. Le README ne décrit aucune procédure d'auto-hébergement complète, et l'avertissement sur le retard du dépôt rend l'exécution locale d'autant moins prévisible. Enfin, si vous cherchez une dépendance stable avec des versions publiées : les éléments fournis ne mentionnent aucune release, et le dépôt ne propose pas de numérotation à laquelle s'accrocher. Un pipeline qui dépend d'un modèle de segmentation affiné et d'un modèle multimodal est par nature sensible aux mises à jour de ces modèles, et rien dans le matériel fourni n'indique comment ces versions sont figées.

Alternatives : reconnaissance de texte ou reconstruction sémantique

L'alternative la plus directe n'est pas un autre projet de reconstruction, c'est une autre approche : l'OCR de diagrammes, qui extrait le texte et les positions sans chercher à reproduire les formes. Un outil d'OCR appliqué à un schéma vous donne des étiquettes et des coordonnées, pas un fichier DrawIO. Vous récupérez le contenu textuel, mais vous redessinez les boîtes et les flèches à la main. Edit Banana se place à l'autre bout : il vise la géométrie et le style, en s'appuyant sur un modèle de segmentation pour retrouver les frontières des objets, puis sur un modèle multimodal pour interpréter l'ensemble. La différence de coût est réelle. L'OCR tourne souvent hors ligne, sur CPU, et produit un résultat déterministe. Une chaîne segmentation plus VLM demande un GPU, introduit une variabilité entre deux exécutions sur la même image, et rend la vérification humaine obligatoire. Le choix dépend donc de ce que vous devez récupérer : le texte, ou la structure graphique.

Coût de maintenance et visibilité du projet

Le dépôt n'est pas archivé et le dernier envoi de code date du 7 septembre 2026, ce qui indique une activité récente au moment de cette analyse. Aucune release n'est toutefois récupérée, ce qui complique la gestion des montées de version : sans étiquette de version, un déploiement doit se faire sur un commit précis, et cette référence doit être consignée quelque part dans votre propre dépôt. La présence d'une feuille de route dans le README suggère que l'API et la structure du projet peuvent encore bouger. Pour l'exploitation, cela se traduit par un coût de suivi non négligeable : il faudra relire les changements avant chaque mise à jour, en particulier si vous dépendez du format de sortie DrawIO. Ajoutez à cela la question de licence non tranchée entre AGPL-3.0 et Apache 2.0, et le tableau est celui d'un projet à surveiller de près plutôt qu'à intégrer sans examen.

Conclusion éditoriale

Edit Banana vise les équipes qui doivent rééditer des schémas dont elles n'ont plus la source, typiquement des figures extraites d'articles ou de rapports PDF, et qui acceptent de traiter ces images via un service externe. Ce n'est pas l'outil à retenir si vous manipulez des plans confidentiels ou si vous attendez une bibliothèque stable : le README signale lui-même que le dépôt est en retard sur le service web, et la licence affichée est AGPL-3.0 alors que le badge du README indique Apache 2.0. Avant toute intégration, vérifiez trois points dans le dépôt : le fichier LICENSE, la présence effective d'un requirements.txt ou d'un pyproject.toml, et la liste des clés de configuration attendues pour le modèle de segmentation et le modèle multimodal.

Sources officielles

1. BIT-DataLab/Edit-Banana on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README