Pourquoi BranchPy ne supprime pas les fichiers automatiquement

Tout outil capable de supprimer des fichiers est confronté à une question de conception qui semble simple mais ne l'est pas : dans quelle mesure doit-il agir seul, plutôt que de vous demander d'abord ?

Pour BranchPy, la réponse a été arrêtée tôt et n'a pas changé : l'outil ne supprime rien que vous n'ayez explicitement sélectionné et confirmé. Il n'y a pas de nettoyage automatique, pas de bouton « supprimer tout ce qui est inutilisé », pas de balayage en arrière-plan. Cette note explique pourquoi.

Le problème d'asymétrie

Quand un outil fait une erreur lors d'une opération de lecture — par exemple, il classe mal un fichier —, le coût est faible. Vous voyez la mauvaise étiquette, vous le remarquez, vous passez à autre chose. Rien n'est perdu.

Quand un outil fait une erreur lors d'une opération d'écriture ou de suppression, le coût peut être permanent. Les fichiers de projet supprimés peuvent être irrécupérables. Les assets originaux des artistes, les graphismes GUI personnalisés, les mixages audio soigneusement ajustés — ils ne sont pas toujours sous contrôle de version, et pas toujours sauvegardés. Pour beaucoup de développeurs indépendants travaillant sur un premier titre, il n'y a pas de filet de sécurité.

Cette asymétrie — où les erreurs dans un sens sont bon marché et dans l'autre catastrophiques — change la façon dont un outil doit se comporter par défaut. Le chemin agressif n'a besoin de se tromper qu'une seule fois.

Ce que la suppression automatique exigerait vraiment

Pour qu'une suppression en masse ou automatique soit sûre, plusieurs conditions devraient être vraies simultanément :

1. L'analyse des références du scanner devrait être complète — pas de références dynamiques, pas de chemins chargés par le moteur, pas d'assets utilisés par des extensions ou des écrans personnalisés que le scanner n'a pas vus.
2. La classification devrait être correcte pour chaque fichier de l'ensemble.
3. La structure du projet de l'utilisateur devrait correspondre aux attentes du scanner — pas de disposition de répertoires inhabituelle, pas de chargement conditionnel, pas d'assets référencés uniquement dans des modèles ou du code généré.
4. La copie de travail de l'utilisateur devrait être dans un état récupérable — sous contrôle de version, ou sauvegardée, ou au minimum tolérante à une perte permanente.

En pratique, aucune de ces conditions n'est garantie, et la dernière échappe entièrement au contrôle de l'outil. Un scanner qui supprime automatiquement parie que les quatre conditions sont vraies pour votre projet, maintenant, sans vous le demander.

Le cas particulier des projets Ren'Py

Les projets Ren'Py ajoutent une couche de complexité supplémentaire. Le moteur charge de nombreux assets via des mécanismes qui n'apparaissent pas du tout dans les fichiers de script — variables GUI, affectations config.*, définitions de polices et styles d'écrans intégrés. Un fichier peut être véritablement critique pour que votre jeu se lance correctement tout en semblant complètement non référencé pour un scanner de niveau script.

BranchPy maintient une couche de classification spécifiquement pour cela : les fichiers qui relèvent de chemins gérés par le moteur sont marqués PROTÉGÉS avant même que les résultats soient affichés. Ils ne peuvent pas être sélectionnés. Mais les règles de protection ne couvrent que ce que nous savons. Pour tout le reste dans l'ensemble des fichiers non référencés, la révision par l'utilisateur n'est pas une étape bureaucratique — c'est une réduction de risque réelle.

L'approche par étapes

Ce que BranchPy fait à la place de la suppression automatique, c'est un flux de travail par étapes :

1. Scanner — inventorier tous les fichiers médias dans l'arborescence du projet.
2. Classifier — attribuer à chaque fichier un statut : référencé, non référencé, manquant ou protégé.
3. Présenter — afficher les résultats classifiés dans une interface révisable, avec les raisons visibles par fichier.
4. Confirmer — exiger une sélection explicite et une étape de confirmation avant toute suppression.

Chaque étape est indépendante. Un problème dans la classification ne déclenche pas silencieusement une suppression. Un bug d'interface qui afficherait le mauvais fichier comme sélectionnable serait quand même intercepté par l'étape de confirmation. Les étapes forment une défense en profondeur pour une opération destructive.

Ce que cela coûte, et pourquoi ça vaut le coup

La réponse honnête est : exiger une révision prend du temps. Si vous avez 200 fichiers non référencés et que chacun d'eux est véritablement sans danger à supprimer, vous devez quand même regarder la liste et appuyer sur confirmer. C'est de la friction.

Mais considérez l'alternative. Un outil qui aurait raison 199 fois sur 200 et supprimerait silencieusement un fichier dont vous aviez besoin perdrait définitivement votre confiance — et aurait peut-être causé de vrais dommages au projet. La friction de la révision est la prime que vous payez pour la garantie que l'outil n'agit pas sans vous.

Cette garantie vaut davantage pour les projets où la récupération est difficile. Et pour beaucoup des développeurs solo et en petites équipes pour lesquels BranchPy est conçu, la récupération est difficile.

Résumé

• Les erreurs dans les opérations destructives coûtent bien plus cher que les erreurs dans les opérations de lecture.
• BranchPy ne peut garantir que sa classification est complète pour toutes les structures possibles de projets Ren'Py.
• La suppression automatique repose sur des hypothèses qui peuvent ne pas être vraies pour votre projet.
• Le flux de travail en étapes scanner → classifier → présenter → confirmer instaure une défense en profondeur contre les faux positifs.
• La friction de la confirmation est intentionnelle — l'outil n'agit pas sans vous.