AI File Sorter : trier et renommer des fichiers avec un LLM local
Cross-platform desktop application for content-aware file organization and renaming. Supports local and remote LLMs, preview-based workflows, and fully user-controlled changes.
En bref
- De quoi s’agit-il ?
- Application de bureau en C++ sous licence AGPL-3.0 qui analyse images, documents et métadonnées multimédias pour proposer des catégories et des noms de fichiers. Tout passe par une table de revue avant application, et les modèles locaux évitent l'envoi de données.
- À qui s’adresse-t-il ?
- AI File Sorter convient à qui veut ranger des dossiers hétérogènes sans script maison et sans envoyer ses données à un service tiers, à condition d'accepter la revue manuelle et le coût d'un modèle local. À éviter si vous cherchez une règle de tri déterministe et reproductible, ou si votre parc de machines n'a pas de GPU exploitable.
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions strictes. AGPL-3.0 est une licence à copyleft réseau : si des personnes utilisent une version modifiée via un réseau, par exemple comme service hébergé, vous devez leur proposer son code source sous la même licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement C++, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : des dossiers que personne n'ose ranger
Le README cible explicitement trois gisements : Downloads, disques externes et stockage NAS. Ce sont des dossiers où les noms de fichiers ne portent presque aucune information exploitable. IMG_2048.jpg, un PDF scanné sans titre, une piste audio nommée avec des underscores et des numéros de piste. Une règle fixe de tri ne peut pas traiter ce cas, parce que la décision dépend du contenu : ce qui est dans l'image, ce qui est écrit dans le document, ce que contiennent les balises du fichier multimédia.
L'application s'adresse donc à des utilisateurs individuels ou à de petites équipes qui veulent retrouver un fichier plus tard, pas à un pipeline d'ingestion automatisé. Le README insiste sur un point de conception : l'IA propose, l'utilisateur approuve. Aucun déplacement ni renommage n'a lieu avant validation dans la table de revue. C'est un choix qui a un coût en temps, et il faut le mesurer avant d'adopter l'outil sur un volume important.
Une chaîne en quatre étapes, du dossier à la table de revue
Le fonctionnement décrit dans le README tient en quatre étapes. On pointe l'application sur un dossier ou un disque. Les fichiers sont analysés par le modèle choisi, local ou distant, avec analyse du contenu de l'image quand le type de fichier s'y prête. Des suggestions de catégorie et, pour les types pris en charge, de renommage sont générées. L'utilisateur relit et ajuste dans la table de revue avant que quoi que ce soit ne soit modifié.
La décision de classement ne repose pas uniquement sur le modèle. Le README indique que l'application combine les suggestions de l'IA avec des whitelists optionnelles, les résultats similaires récents et les décisions de revue déjà approuvées. Ce mélange est ce qui distingue l'outil d'un simple appel à une API de vision : le cache de catégorisation et les décisions passées servent à garder un classement cohérent d'une exécution à l'autre, au lieu de laisser le modèle réinventer une arborescence à chaque passage. Le revers est qu'un mauvais choix validé une fois peut peser sur les suivants, ce que le README ne détaille pas.
Une fois la revue confirmée, les dossiers nécessaires sont créés automatiquement et les fichiers sont rangés. L'opération est réversible via Edit -> Undo last run, ce qui suppose que l'application conserve de quoi reconstituer l'état précédent.
Trois moteurs d'analyse selon le type de fichier
Toutes les analyses ne passent pas par un LLM. Le README distingue trois chemins. Pour les images, l'application utilise des backends visuels intégrés et produit un nom lisible du type clouds_over_lake.jpg à partir de IMG_2048.jpg. Pour les documents, un LLM textuel lit le contenu et propose un nom plus clair. Pour l'audio et la vidéo, l'application n'appelle pas de modèle : elle exploite les métadonnées déjà présentes dans le fichier. Si les balises année, artiste, album et titre existent, elle peut composer une suggestion comme 2024_artist_album_title.mp3.
Cette séparation est le point le plus intéressant de l'architecture. Le renommage multimédia est une transformation déterministe de balises existantes, pas une inférence. Cela signifie qu'il fonctionne sans GPU, sans modèle téléchargé et sans réseau, et que son résultat est prévisible. Le tri par contenu, lui, dépend entièrement de la qualité du modèle choisi. Le README ne donne pas de taux d'erreur ni de mesure de qualité pour l'un ou l'autre chemin, et je ne peux pas en avancer.
Mise en route et fichiers de modèle attendus
Le README documente l'installation par plateforme, avec des sections dédiées à Linux, macOS et Windows, et renvoie vers SourceForge et le Microsoft Store comme canaux de distribution. Il mentionne aussi une section Technical reference et une section Testing, dont une partie optionnelle de tests headless avec un LLM en direct. Le contenu de ces sections n'est pas repris dans l'extrait fourni, donc je ne peux pas décrire les commandes exactes de compilation ou de test.
Ce qui est documenté, c'est la présence d'une section Required visual LLM files. Autrement dit, l'analyse d'images ne fonctionne pas sans fichiers de modèle installés au préalable. C'est une contrainte de déploiement réelle : sur un parc de machines, il faut prévoir la distribution de ces fichiers, pas seulement l'installation de l'application.
Le README décrit également une fenêtre de benchmark de compatibilité, visible dans les captures d'écran, qui sert à vérifier que la machine peut faire tourner le backend prévu. Les logos Vulkan, CUDA et Apple Metal en tête du dépôt indiquent les accélérations visées. Sur une machine sans GPU compatible, l'analyse d'images risque d'être lente ou indisponible, et le benchmark est là pour le dire avant l'analyse, pas après.
Côté configuration, le README documente des clés API pour OpenAI et Gemini, ainsi qu'un mode custom OpenAI-compatible API pour pointer vers un autre service. Il faut noter que l'analyse d'images par LLM distant et l'analyse locale n'ont pas les mêmes implications de confidentialité, même si l'interface les présente côte à côte.
Ce que la revue manuelle protège, et ce qu'elle coûte
Le garde-fou principal est la table de revue, complétée par la fonction Undo last run. Le README recommande explicitement une première exécution sur un dossier de test de 20 à 50 fichiers copiés depuis Downloads, captures d'écran, photos ou documents, avant de toucher à une archive complète. C'est un conseil de bon sens, et il indique aussi la limite de l'outil : il n'est pas conçu pour un traitement de masse non supervisé.
La conséquence pratique est un débit dépendant de l'utilisateur. Sur un disque externe de plusieurs milliers de fichiers, la relecture ligne par ligne devient le goulot d'étranglement, pas l'inférence. Le README ne décrit pas de mécanisme d'approbation par lot ni de règle d'auto-application, donc je considère que la revue reste individuelle tant que la documentation ne dit pas le contraire.
Deuxième limite : les formats. Le README annonce des formats pris en charge pour les documents et pour l'audio/vidéo, mais l'extrait fourni ne détaille pas ces listes. Un fichier hors périmètre ne recevra pas de suggestion de renommage fondée sur son contenu. Il faut vérifier les listes dans la documentation avant de compter sur l'outil pour un fonds documentaire particulier.
Troisième point, plus structurel : la cohérence du classement dépend du cache et des décisions passées. Le README mentionne une section Categorization cache and learned behavior, sans en exposer le fonctionnement dans l'extrait. On ne sait donc pas comment le cache est invalidé, ni ce qui se passe si l'on change de modèle en cours de route.
Face à un script de tri et à un gestionnaire de fichiers classique
L'alternative la plus directe n'est pas un autre logiciel d'IA, c'est un script. Un script Python ou shell qui lit les balises EXIF et ID3, applique des règles de nommage et déplace les fichiers est déterministe, versionnable et gratuit. Sa faiblesse est exactement là où AI File Sorter place son argument : il ne sait rien faire d'un IMG_2048.jpg sans métadonnée utile, ni d'un PDF scanné dont le titre est illisible. Le LLM visuel et le LLM textuel couvrent ce trou, au prix de la non-déterminisme et de la dépendance à un modèle.
L'autre comparaison utile est celle des gestionnaires de fichiers à règles, du type de ceux qui appliquent des motifs sur le nom et l'extension. Eux aussi sont prévisibles, et eux aussi échouent sur le contenu. La différence d'approche d'AI File Sorter est de faire produire la décision par un modèle, puis de la faire valider par un humain, avec un cache pour amortir la répétition. C'est un compromis intermédiaire : moins fiable qu'une règle, plus capable qu'une règle.
Reste la question du modèle local contre le modèle distant. Le README présente le mode local comme privacy-first : fichiers, noms, images et métadonnées restent sur la machine, et aucune télémétrie n'est envoyée. Le mode distant, via une clé OpenAI ou Gemini ou une API compatible, envoie nécessairement le contenu analysé à un tiers. Les deux modes coexistent dans la même interface, ce qui rend le choix facile à faire par inadvertance.
Licence AGPL-3.0 et coût de maintenance
Le dépôt est publié sous AGPL-3.0. Pour un usage personnel sur son propre poste, la question ne se pose guère. Pour une intégration dans un produit ou un service exposé sur un réseau, la licence impose ses conditions de redistribution du code source, et ce point mérite un examen par un juriste avant toute décision. Je ne donne pas d'avis juridique ici, seulement le constat que le choix de licence est structurant pour un usage en entreprise.
Sur la maintenance, les éléments fournis indiquent un rythme de publication serré : v1.9.0 le 5 août 2026, v1.9.1 le 6 août, v1.9.2 le 14 août, et un dernier push sur main au 9 septembre 2026. Le dépôt n'est pas archivé. Ce rythme suggère des correctifs fréquents, ce qui est rassurant pour la correction de bugs mais implique de suivre les versions si l'on déploie sur plusieurs machines.
Le coût réel d'exploitation ne vient pas de l'application mais des modèles. Un modèle visuel local demande de l'espace disque et une accélération GPU correcte (Vulkan, CUDA ou Metal selon la plateforme). Un modèle distant demande une clé API et un budget à l'usage. Dans les deux cas, la partie installation de l'application n'est que la moitié du travail, et c'est la partie que le README traite le plus brièvement dans l'extrait disponible.
Conclusion éditoriale
AI File Sorter convient à qui veut ranger des dossiers hétérogènes sans script maison et sans envoyer ses données à un service tiers, à condition d'accepter la revue manuelle et le coût d'un modèle local. À éviter si vous cherchez une règle de tri déterministe et reproductible, ou si votre parc de machines n'a pas de GPU exploitable. Avant d'adopter, vérifiez le résultat du benchmark de compatibilité, la présence des fichiers de modèle visuel requis et le comportement de Edit -> Undo last run sur un dossier de test.
Notes de la communauté