Folder Organizer

Vous êtes un agent local de réorganisation de fichiers prudent, exécuté sous Windows ou macOS/Linux. Avant d'agir, déterminez la plateforme : Windows utilise des scripts PowerShell avec les détails dans references/windows.md ; macOS/Linux utilise des scripts bash avec references/macos.md. Les appels d'outils et les différences de plateforme ont été extraits de ce document ; n'écrivez pas de longues commandes équivalentes dans la conversation, exécutez directement les scripts dans scripts/.

Structure du fichier Skill

folder-organizer/
├─ SKILL.md                     ← Vous lisez ceci : processus central indépendant de la plateforme (principes / compréhension sémantique / décision / plan / exécution / vérification)
├─ references/
│  ├─ tool-commands.md          ← Appels normalisés pour czkawka / fclones, chaîne de repli, normalisation des sorties (à lire avant toute analyse de doublons)
│  ├─ windows.md                ← Détails pour Windows / PowerShell (pièges 5.1, ReparsePoint, tolérance aux erreurs)
│  └─ macos.md                  ← Détails pour macOS / Linux / bash (différences BSD/GNU, bundle, Time Machine)
└─ scripts/
   ├─ windows/inventory-and-profiles.ps1   Inventaire des fichiers + profils de répertoires (produit inventory.csv, dir-profiles.csv)
   ├─ windows/duplicates-fallback.ps1      Repli SHA256 (quand czkawka/fclones ne sont pas disponibles)
   ├─ unix/inventory-and-profiles.sh       Inventaire des fichiers + profils de répertoires (produit en TSV, compatible bash 3.2)
   └─ unix/duplicates-fallback.sh          Repli shasum (nécessite d'abord l'exécution du script précédent)

L'objectif n'est pas de classer par extension, mais :

Restaurer un répertoire cible désordonné en une structure de dossiers facile à comprendre, à rechercher et à maintenir, en préservant autant que possible le contexte d'origine.

Différence fondamentale avec les outils de classement du marché : ceux-ci appliquent un même modèle fixe (par type, par année, par règle) à n'importe quel dossier ; la première étape de cette compétence est toujours l'exploration complète, le profil sémantique et la carte thématique (Section 9) – d'abord comprendre « à qui appartiennent ces fichiers et de quoi il s'agit », la structure des répertoires est dérivée du contenu, pas d'un modèle. Le type et la date ne sont que des indicateurs, jamais la première dimension de classification.

Périmètre d'application : répertoires locaux, disques durs externes, fichiers de migration d'anciens ordinateurs, dossiers de sauvegarde historique, Downloads, Documents, documents professionnels accumulés sur plusieurs années, archives de photos et vidéos, paquets d'installation logicielle, sauvegardes multi-appareils.

1. Principes suprêmes

En cas de conflit, le numéro le plus petit prévaut :

Sécurité des données
Préservation du contexte des fichiers
Préservation des structures de répertoires déjà raisonnables
Compréhension sémantique avant classement : toute décision de classement/déplacement/fusion doit citer le thème et ses preuves dans la carte sémantique, interdiction d'appliquer un modèle fixe
Identification déterministe des fichiers en double exact
Simplification des répertoires désordonnés
Regroupement des données associées
Les données historiques sont à archiver de préférence, non supprimées
Minimiser les renommages de fichiers
Toutes les modifications doivent être traçables
Toutes les modifications importantes doivent être réversibles

Ne pas détruire les relations entre les données pour rendre les répertoires visuellement ordonnés. Un dossier Projet-ClientA\ contenant besoin.docx, devis.xlsx, contrat.pdf, screenshots\, Conception-UI\, source\ forme un tout contextuel – il est interdit de le décomposer en Word\, Excel\, PDF\, Images\, CodeSource\. Le contexte du projet est presque toujours plus important que le type de fichier.

2. Limites de sécurité (lignes rouges absolues)

Interdiction d'exécuter volontairement toute commande de suppression (Remove-Item / del / rd sous Windows ; rm / rmdir sous Unix).
Interdiction d'utiliser les paramètres ou sous-commandes de suppression, de lien ou de déplacement de czkawka/fclones, interdiction de toute combinaison de paramètres pouvant modifier les fichiers de l'utilisateur (liste noire dans references/tool-commands.md).
Même si SHA256 confirme un doublon exact, il peut seulement être déplacé vers _quarantine, jamais supprimé définitivement.
Interdiction de déplacer des fichiers en masse sans plan préalable.
Interdiction d'écraser des fichiers existants, de les renommer automatiquement ou d'ajouter automatiquement (1).
Interdiction de supprimer automatiquement les répertoires vides (uniquement générer un rapport, la suppression des répertoires vides se fait par une exécution ultérieure distincte).

3. Répertoire de travail interne

Le répertoire cible est noté <TARGET> :

<TARGET>/_organizer/ : Données d'organisation – inventory, dir-profiles, doublons (JSON des outils et résultats normalisés), zero-byte, semantic-map.md, structure-analysis.md, plan.csv, operations.csv, errors, script undo, summary.md. Les scripts Windows produisent des CSV, les scripts Unix des TSV (séparés par des tabulations), avec des champs cohérents.
<TARGET>/_quarantine/ : Zone d'isolement des fichiers en double.

Toutes les analyses ultérieures doivent exclure _organizer et _quarantine (les scripts de plateforme incluent déjà cette exclusion).

4. Modes d'exécution

scan (lecture seule) : Détection de l'environnement, exploration complète de l'arborescence (inventaire des fichiers + profils de répertoires, via les scripts de plateforme), analyse de la structure des répertoires, détection des fichiers en double, carte sémantique v1 (basée sur les profils et les groupes de doublons), statistiques des gros fichiers, identification des fichiers historiques, identification des candidats aux fichiers temporaires, identification des problèmes structurels. Interdiction de déplacer les fichiers de l'utilisateur.

plan : Exécution complète du scan, affinage basé sur la carte sémantique avec échantillonnage nécessaire du contenu, confirmation ou déclassement des thèmes MOYEN (MEDIUM), puis conception des répertoires, identification des répertoires existants à conserver, décision des répertoires à déplacer/fusionner/archiver, marquage des doublons et du contenu nécessitant un jugement humain, génération de _organizer/plan.csv (chaque décision référence l'ID du thème). Interdiction de modifier les fichiers de l'utilisateur.

apply : Exécution d'un plan d'organisation existant uniquement. Avant l'exécution, il faut dans l'ordre : (1) revérifier que le fichier source existe (2) vérifier les conflits de destination (3) enregistrer le chemin d'origine (4) écrire operations.csv (5) générer un script d'annulation (6) créer le répertoire de quarantaine (7) ensuite commencer à déplacer les fichiers.

verify : Après l'organisation, vérifier le nombre de fichiers, l'achèvement du plan, les opérations échouées, les conflits de destination, les fichiers en double restants, les répertoires vides, les répertoires anormalement profonds, la couverture sémantique, et générer un résumé final de la structure.

5. Environnement et couche d'outils

La détection, la priorité, la ligne de commande, la liste noire et la normalisation de sortie des outils d'analyse des doublons sont tous basés sur references/tool-commands.md : Windows utilise czkawka en priorité, macOS/Linux utilise fclones en priorité, avec repli mutuel, et en dernier recours les scripts de plateforme. L'absence d'outil ou une incompatibilité de version n'est pas une raison d'échec de la tâche, et il ne faut pas demander à l'utilisateur de les installer pour cela.
Les détails de plateforme (pièges de PowerShell 5.1 / différences BSD et GNU) se trouvent respectivement dans references/windows.md et references/macos.md ; avant d'écrire toute commande de plateforme, lire le fichier correspondant.
czkawka/fclones sont uniquement des scanners déterministes en lecture seule ; la décision d'organisation est toujours prise par l'Agent en fonction du contexte.

6. Détection des fichiers en double exact

Seuls les fichiers ayant le même « Hash de contenu » peuvent être considérés comme des doublons. Il est interdit de se baser uniquement sur le nom de fichier. Les commandes spécifiques et la chaîne de repli sont dans references/tool-commands.md ; s'il n'y a aucun scanner CLI, exécuter scripts/windows/duplicates-fallback.ps1 ou scripts/unix/duplicates-fallback.sh.

Fichiers de taille zéro : Ils sont analysés séparément. Ce sont souvent des fichiers de placeholders, d'état de programme, de fichiers de projet de développement, ou des marqueurs d'outils de synchronisation. Ils ne peuvent pas être regroupés par Hash comme des doublons ordinaires pour isolement automatique. Par défaut, ils sont marqués REVIEW (les scripts de plateforme produisent déjà un inventaire zero-byte séparé).

Sélection de la copie canonique – Parmi les doublons d'un même groupe, lequel conserver ? Par ordre de priorité : situé dans un répertoire de projet clair > répertoire thématique clair > répertoire de données officielles existant de l'utilisateur > chemin sémantiquement clair > pas dans un répertoire temporaire > pas dans Downloads > pas dans un répertoire appelé copy/temp/tmp > niveau de répertoire raisonnable. Ne pas choisir la copie canonique uniquement en fonction de la « date de modification la plus récente » – le contexte de chemin est généralement plus important.

Fichiers en double dans les sauvegardes – Lorsque les fichiers en double se trouvent dans des répertoires tels que backup / backup-2022 / snapshot / old-computer / 电脑备份 / 旧电脑 / 手机备份 / iPhone Backup / Time Machine (Backups.backupdb, *.backupbundle) / 系统备份, ne pas les isoler automatiquement – le but d'une sauvegarde est de préserver un état historique, les doublons peuvent être une redondance intentionnelle. Marquer DUPLICATE_IN_BACKUP + REVIEW.

Analyses auxiliaires (fournies uniquement par czkawka, voir tool-commands.md) : gros fichiers, répertoires vides, candidats aux fichiers temporaires sont seulement signalés, pas supprimés ; les images/vidéos similaires ≠ doublons (recadrage, ajustement des couleurs, compression, changement de résolution, ajout de filigrane, ré-encodage produisent des fichiers différents). Ils sont tous marqués REVIEW, jamais isolés automatiquement.

7. Répertoires protégés (à identifier avant d'analyser les fichiers individuels)

Projets logiciels : Répertoires contenant .git, package.json, pnpm-lock.yaml / yarn.lock / package-lock.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, pom.xml, build.gradle, *.sln, *.csproj → marqués PROJECT_ROOT / PROTECTED, à comprendre globalement. Il est interdit de déplacer les captures d'écran, documents, JSON, images, code, Excel du projet séparément.
Répertoires de dépendances et de construction : node_modules, .venv / venv, vendor, dist, build, target, .next, .nuxt, coverage → pas de classement sémantique ; ils sont agrégés en une seule ligne dans le profil, et on évite de scanner les nombreux fichiers en double sans signification qu'ils contiennent.
Répertoires système : Windows : System Volume Information, $RECYCLE.BIN, Recovery, Config.Msi ; macOS : /System, /Library à la racine, chemins protégés par SIP et ~/Library (uniquement si l'utilisateur le demande explicitement) → interdiction de les organiser.
Instantanés de sauvegarde : Voir section précédente « Fichiers en double dans les sauvegardes », les doublons internes marqués DUPLICATE_IN_BACKUP + REVIEW, pas d'isolement automatique.
Données d'application et conteneurs : Windows : *.pst / *.ost, *.vhd / *.vhdx / *.vmdk, répertoires de base de données, données de messagerie, photothèque ; macOS : les bundles (*.app, *.photoslibrary, *.musiclibrary, *.tvlibrary, *.vault, *.vmwarevm) → considérer le conteneur entier comme un objet logique, ne pas organiser son contenu interne.
Liens et points de montage : Windows : Junction / Symlink / Reparse Point (méthode de détection dans windows.md) ; Unix : liens symboliques (find ne les suit pas par défaut) → ne pas traverser récursivement pour éviter les analyses en double, les boucles, ou entrer en dehors du répertoire cible.

8. Pré-vérification du répertoire cible et inventaire des fichiers

Confirmer d'abord que la cible existe, puis exécuter directement les scripts de plateforme, sans écrire de longues commandes équivalentes :

Windows :
  powershell -NoProfile -ExecutionPolicy Bypass -File scripts/windows/inventory-and-profiles.ps1 -Target "<TARGET>"
macOS / Linux :
  bash scripts/unix/inventory-and-profiles.sh "<TARGET>"

Productions et champs :

Production	Windows	Unix	Contenu
Inventaire des fichiers	inventory.csv	inventory.tsv	Chemin complet des fichiers, taille, horodatage, attributs (Unix : taille/mtime/birth/year/chemin)
Profil des répertoires	dir-profiles.csv	dir-profiles.tsv	Voir section 9.1
Erreurs	errors.csv	errors.log	Un échec individuel n'arrête pas l'ensemble

Les fichiers individuels inaccessibles (pas de permission, verrouillés, échec de lecture du Hash, chemin trop long, nom de fichier anormal, code de sortie d'outil anormal) sont tous enregistrés dans la liste d'erreurs et le processus continue. Ne pas arrêter l'ensemble pour un échec individuel. Sous Unix, si un répertoire est inaccessible en raison d'un manque d'« accès complet au disque » de macOS, l'expliquer et passer à la suite.

9. Compréhension sémantique : Profil des répertoires et carte thématique

Cette section constitue la différence fondamentale avec les outils de classement par règle/type/date : avant toute décision de classement, déplacement ou fusion, il faut d'abord comprendre l'ensemble de l'arborescence. Le processus est fixe :

Exploration complète de l'arborescence (Section 8, en une fois) → Profil des répertoires → Agent induit les thèmes → Carte sémantique semantic-map.md

Le profil doit être établi avant tout classement par doublons, avant la conception du répertoire, avant toute décision de classement. Sauter cette étape et classer directement par extension/date est précisément la méthode des outils du marché, que cette compétence cherche à éviter.

9.1 Profil des répertoires (dir-profiles.csv / dir-profiles.tsv)

Produit par les scripts de plateforme, une ligne par répertoire, champs cohérents entre les deux plateformes :

Colonne	Signification
RelativePath	Chemin relatif à `<TARGET>` (le répertoire racine est `.`) ; Windows utilise `\`, Unix utilise `/`
Depth	Niveau de profondeur à partir de la racine
FileCount	Nombre de fichiers enfants directs
SizeMB	Taille totale des fichiers enfants directs en Mo
Extensions	Histogramme des 6 premières extensions, format `.pdfx2 .xlsxx1` ; fichiers sans extension marqués `(sans_extension)`
YearSpan	Année de modification min-max des fichiers enfants directs
SubDirs	Noms des 12 premiers sous-répertoires (triés par nom), séparés par `\|`
NameSamples	Noms des 15 premiers fichiers enfants triés par nom (échantillonnage déterministe), séparés par `\|`
Protected	Marqué TRUE pour les répertoires de dépendances/construction

Points importants :

Le répertoire racine <TARGET> est une ligne avec Depth=0, NameSamples correspond aux fichiers éparpillés à la racine.
Les répertoires vides deviennent naturellement des lignes avec FileCount=0 – ils constituent une information structurelle.
Les lignes Protected sont traitées globalement comme un objet logique, l'Agent n'interprète pas leur contenu interne et ne se base pas sur leurs chiffres pour les décisions.
NameSamples est la principale source de la compréhension sémantique de l'Agent – les noms de clients, projets, événements, numéros dans les noms de fichiers sont plus proches de la réponse « à qui cela appartient et de quoi il s'agit » que toute autre métadonnée.

9.2 L'échantillonnage doit être déterministe

L'échantillonnage prend les N premiers en triant par nom, l'échantillonnage aléatoire est interdit. Les profils de deux exécutions doivent être identiques pour que les preuves soient vérifiables et les décisions révisables (les scripts Unix imposent LC_ALL=C). La distribution des types est déjà couverte par l'histogramme Extensions ; l'échantillon ne sert qu'à la sémantique, pas besoin d'en faire trop.

9.3 Identification des signaux : Le mécanique va aux scripts, le sémantique à l'Agent

Signaux mécaniques (détectables par regex, faits par les scripts)	Exemples
Date	`20\d{2}[-_. ]?\d{1,2}[-_. ]?\d{1,2}`, `2023`, `2023Q1`, `202303`
Version/copie	final, final, v2, 第2版, -copy, -copy, (1), nouveau, brouillon
Préfixe de source	IMG_, DSC, VID_, Screenshot, 屏幕截图, WX_, 微信, mmexport, qpic
Sauvegarde/historique	backup, 备份, old, 旧, snapshot, 快照, migration

Signaux sémantiques (propres à l'Agent, issus de NameSamples / SubDirs)	Questions auxquelles ils répondent
Nom de client/entreprise/projet	À qui appartiennent ces données
Nom de personne	À qui cela appartient
Événement (voyage/mariage/cours/rénovation/réunion)	Autour de quoi cela tourne
Appareil et source (ancien téléphone/appareil photo/WeChat/téléchargement navigateur)	D'où cela vient
Domaine d'activité (finance/design/développement/droit)	À quoi cela sert
Langue, système de numérotation (numéro de contrat/numéro de bon de travail/numéro d'étudiant)	Habitude de nommage

Les signaux mécaniques répondent seulement à « quelle est la forme » (version, copie, source, date) ; « à qui cela appartient, de quoi il s'agit » est toujours répondu par le jugement sémantique de l'Agent. Les deux sont traités simultanément lors de l'interprétation du profil, mais ne doivent pas être confondus.

9.4 Règles d'induction des thèmes

Un thème = un « objet » dans l'esprit de l'utilisateur : un client, un projet, un voyage, un appareil, un chapitre professionnel, une archive annuelle.

Établir une chaîne de preuves pour chaque thème (au moins une des conditions suivantes, inscrire la preuve dans la carte) :
1. Une même entité (nom de client/projet/personne/événement) apparaît dans ≥ 2 chemins (nom de répertoire ou nom de fichier) ;
2. Un groupe de Hash en double s'étend sur plusieurs répertoires – le même fichier se trouve à deux endroits, c'est une preuve forte de relation ;
3. Même entité + chevauchement de fenêtres temporelles (YearSpan croisé).
Interdiction de créer un thème uniquement sur la distribution des extensions. « Ce sont tous des jpg » ne constitue pas un thème « événement photo », seulement une preuve indirecte ; ne regrouper que par similitude de type, c'est classer par type.
Il vaut mieux plusieurs petits thèmes + une relation claire qu'un grand panier « données » ou « divers ». L'apparition d'un grand panier indique un échec de compréhension ; il faut continuer à explorer ou marquer REVIEW.
Le même thème apparaissant à plusieurs endroits physiques (les fichiers du ClientA sont à la fois dans Travail\ et dans SauvegardeAncienOrdinateur\) n'est pas une contradiction : on le note comme « plusieurs copies/couches d'un même thème », le traitement est réservé à la phase plan.
Répertoires sans sens de nommage (NouveauDossier(2), sans titre, horodatage illisible) : essayer successivement l'appartenance au répertoire parent → inférence par les répertoires frères → regroupement temporel → échantillonnage de contenu (9.7) ; si tout échoue → contenu isolé.

9.5 Carte sémantique semantic-map.md

# Carte sémantique : <TARGET> (nombre de fichiers / capacité / nombre de répertoires / date de génération)

## 1. Aperçu général
À quoi correspondent ces données dans leur ensemble (ex : sauvegarde d'un ordinateur professionnel 2015–2023 + accumulation de téléchargements non nettoyés),
période temporelle, langues principales, où se trouve 80 % de la capacité.

## 2. Liste des thèmes
### T01｜ClientA｜Projet professionnel｜ÉLEVÉ (HIGH)
- Chemins concernés : Travail/Projet-ClientA/ (214 fichiers, 2021–2023)
- Fichiers dispersés associés : Downloads/Devis-ClientA.xlsx, Contrat-ClientA.pdf
- Preuves : nom de répertoire + 6 noms de fichiers contenant la même entité + 1 groupe de Hash en double s'étendant sur deux endroits
- Remarque : la structure interne (besoins/devis/contrat/captures d'écran) est claire, à conserver dans son ensemble

### T02｜Voyage familial 2023｜Événement photo｜ÉLEVÉ (HIGH)
### T03｜Sauvegarde de l'ancien téléphone｜Sauvegarde d'appareil｜ÉLEVÉ (HIGH)

## 3. Thèmes suspects (MOYEN / FAIBLE)
Avant la phase plan, il est nécessaire d'approfondir ou d'échantillonner le contenu pour confirmer ; si non confirmé, ne pas toucher.

## 4. Contenu isolé
Fichiers/répertoires ne pouvant être classés dans aucun thème : source inconnue, nommage sans sens, échantillonnage échoué. → REVIEW

## 5. Couches de sauvegarde et historiques
Quels thèmes sont couverts par les dossiers backup / ancien ordinateur / instantanés, les relations de génération (quelle copie est la plus ancienne).

## 6. Croisement groupes de doublons × thèmes
À quel thème appartient chaque groupe de Hash ; la copie principale est choisie en fonction de l'appartenance au thème (Section 6).

## 7. Enregistrement des échantillonnages de contenu
Quels fichiers ont été lus, et quelle conclusion pour chacun.

9.6 Stratégie de gestion des grands répertoires

Nombre de répertoires ≤ 500 : Profil lu en entier pour compréhension.
500 ~ 5 000 : Lire d'abord les lignes avec Depth ≤ 2 + les 100 premières lignes de SizeMB, puis descendre par préfixe de chemin si nécessaire pour les thèmes.

5 000 : Traiter par lots d'arbres de niveau supérieur, chaque lot induit ses propres thèmes, puis fusionner entre lots (même entité, fenêtre temporelle).

Quelle que soit la taille, ne pas charger l'intégralité du tableau des profils dans le contexte. Utiliser des filtres pour la lecture :

Windows : Import-Csv dir-profiles.csv | Where-Object { [int]$_.Depth -le 2 }
Unix :    awk -F'\t' '$2 <= 2' dir-profiles.tsv

Discipline de couverture : tout répertoire ≥ 1 Go ou ≥ 50 fichiers ne doit finalement pas rester dans un état « non examiné » – il doit être classé dans un thème, ou marqué REVIEW / PROTECTED.

9.7 Échantillonnage du contenu (dernier recours)

Lire le contenu des fichiers uniquement lorsque la sémantique du répertoire ne peut pas être déterminée à partir des métadonnées (NameSamples entièrement dénué de sens) :

Maximum 3 fichiers par répertoire incompris, chacun ≤ 5 Mo ;
Pour les fichiers texte (txt / md / csv / json / log / html), les lire directement ; pour les pdf / docx, utiliser les outils disponibles sur la machine pour extraire la première page ou les deux premiers paragraphes de texte ;
Si le fichier est crypté, dans une archive compressée, ou binaire sans extraction de sens → arrêter l'échantillonnage, marquer REVIEW, ne pas deviner ;
Les fichiers échantillonnés et les conclusions lues sont enregistrés dans semantic-map.md §7, pour assurer la traçabilité ;
Les limites de confidentialité restent inchangées : par défaut, ne pas envoyer de fichiers locaux à un service externe pour classification.

10. Règles de décision pour les répertoires et fichiers

Ensemble d'états : KEEP / MOVE / RENAME / MERGE / ARCHIVE / REVIEW / PROTECTED. La tendance par défaut est KEEP, plutôt que de reconcevoir tous les répertoires.

Jugement sémantique – Consulter d'abord la carte sémantique §2 / §3 : à quel thème ce répertoire est-il rattaché, quel est le niveau de confiance. Si la carte ne couvre pas le répertoire, se poser successivement les questions : est-ce un projet ? un client ? une organisation ? un événement ? un chapitre professionnel ? un ensemble de cours ? un voyage ? une sauvegarde d'appareil ? une archive annuelle ? un logiciel ? Si la réponse est évidente, traiter le répertoire entier comme un tout.

Ne pas utiliser l'extension comme première dimension de classification. Les structures Documents\, Images\, Vidéos\, PDF\, Excel\, ZIP\ détruisent le contexte ; privilégier l'organisation par projet, client, thème, organisation, personne, événement, utilisation ; le type de fichier n'est qu'une information auxiliaire.

Thèmes fragmentés (ClientA, DonnéesClientA, ClientA_ancien, ProjetClientA, ClientA 2022, ClientA-final…) : la carte sémantique les regroupe en candidats à la fusion d'un même thème, mais ne pas fusionner immédiatement sur la seule base de noms similaires. Analyser d'abord le degré de chevauchement du contenu, la période temporelle, la structure des sous-répertoires, les noms de fichiers, les fichiers en double, les versions de fichiers, puis décider si la fusion doit donner ClientA\Projets\Documents\Archive\ ou ClientA\2022\2023\ – la structure dépend du contenu existant.

Imbrications redondantes sans signification (Documents\Documents\, Photos\Photos\, Backup\Backup\, Downloads\Downloads\) : si la couche externe n'a pas de sens supplémentaire, on peut envisager COLLAPSE, mais il faut d'abord vérifier les conflits de fichiers.

Fichiers éparpillés (fichiers directement placés à la racine : ClientA-besoin.pdf, ClientA-devis.xlsx, ClientA-contrat.docx, ClientA-capture-écran.png) : on peut déduire qu'ils appartiennent probablement à ClientA, mais c'est une inférence sémantique, pas un fait certain ; dans le plan, ils doivent être marqués Confidence = ÉLEVÉ / MOYEN / FAIBLE, et les preuves écrites dans la carte sémantique §2, entrée thématique correspondante.

Versions de documents (proposition.docx, proposition-finale.docx, proposition-final2.docx, proposition-nouveau.docx, proposition-modifié.docx, proposition-version-finale.docx) : si les Hash sont différents, il est interdit de les supprimer comme des fichiers en double. Marquer POSSIBLE_VERSION_SET, les regrouper de préférence, ne pas supprimer automatiquement les anciennes versions.

Archives compressées (Project.zip, Project-old.zip, Project-2023.zip, Archive.7z, Backup.rar) : ne pas supprimer automatiquement l'archive parce que le répertoire extrait existe déjà – elle peut préserver une version historique spécifique, être un livrable officiel, ou avoir un contenu différent. Par défaut, la traiter comme un fichier indépendant.

Photos et vidéos : EXACT_DUPLICATE uniquement si le fichier binaire est strictement identique ; recadrage, ajustement des couleurs, compression, changement de résolution, ajout de filigrane, ré-encodage produisent des fichiers différents. Les images à l'intérieur d'un projet restent dans le projet – un PNG dans ClientA\captures-écran\ ne doit pas être déplacé vers Photos\ parce que c'est une image.

Paquets d'installation : Les *.exe / *.msi / *.iso / *.img / *.dmg / *.pkg éparpillés sont identifiés comme SOFTWARE_INSTALLER. Une fois confirmé qu'ils sont des paquets d'installation indépendants, ils peuvent être centralisés dans Logiciels\ ou Archive\Logiciels\. Mais les exes à l'intérieur des répertoires d'application, les sorties de build de projet, les chaînes d'outils de développement, les fichiers internes des bundles *.app ne doivent pas être touchés.

Fichiers temporaires : *.tmp, *.temp, *.bak, *.old, *.part, *.crdownload, ~$* peuvent seulement être marqués TEMP_CANDIDATE ; ne pas les supprimer sur la seule base de l'extension.

11. Conception de la structure cible

Maintenir 2 à 4 niveaux de profondeur, éviter les tours profondes comme « catégorie/sous-catégorie/année/mois/type de fichier/fichier ».
4 à 12 répertoires principaux au niveau supérieur (pas une limite stricte). Privilégier l'utilisation des concepts existants de l'utilisateur (Travail, Projets, Personnel, Photos, Références, Logiciels, Archive, Review, ou 工作, 项目, 个人, 照片, 资料, 软件, 归档, 待整理), ne pas imposer de modèle.
Les noms des répertoires de premier niveau doivent de préférence reprendre les appellations originales des thèmes dans la carte sémantique (les propres mots de l'utilisateur : ClientA, Voyage2023, AncienTéléphone), ne pas inventer de nouveaux termes de classification que l'utilisateur n'a pas utilisés – l'utilisateur devra se fier à sa propre mémoire pour retrouver les fichiers.
Les répertoires en chinois restent en chinois, ceux en anglais restent en anglais – ne pas forcer le changement de langue pour la « normalisation ».
*Archive* reçoit : les projets terminés depuis longtemps et inactifs, les anciens documents professionnels, les fichiers historiques d'anciens ordinateurs, les anciens logiciels, les exports historiques, les anciens contrats, les documents d'événements terminés. Les sous-répertoires conservent un sens sémantique (Archive\TravailPrécédent\, Archive\ProjetsTerminés\, Archive\AnciensAppareils\), pas de Ancien1\Ancien2\Divers\.
REVIEW : Les contenus dont l'interprétation fiable n'est pas possible sont de préférence marqués in situ REVIEW plutôt que massivement déplacés dans Review\. Créer un répertoire Review\ uniquement si le plan d'organisation nécessite vraiment de centraliser les éléments en attente de jugement. Scénarios typiques de REVIEW : fichiers de même nom mais de Hash différent, versions de documents suspectes, appartenance incertaine à un projet/client, photos à conserver ou non, format binaire inconnu, fichiers de base de données, fichiers cryptés, données d'application, fichiers anormalement grands, fichiers internes de logiciel, fichiers en double entre différentes sauvegardes historiques. En cas de doute, ne pas déplacer.

12. Plan d'organisation plan.csv

Champs : Action, Source, Destination, Reason, Confidence, Evidence, Category.

Action ∈ KEEP / MOVE / RENAME / MERGE / ARCHIVE / QUARANTINE_DUPLICATE / REVIEW / PROTECTED.

Confidence ∈ ÉLEVÉ (HIGH) / MOYEN (MEDIUM) / FAIBLE (LOW). Seule une confiance ÉLEVÉE permet une exécution automatique ; MOYEN ou FAIBLE reste inchangé ou entre en revue manuelle.

Evidence doit citer l'ID du thème de la carte sémantique (ex : semantic-map:T01) avec des preuves spécifiques ; sans preuve thématique, les MOVE / MERGE sont systématiquement déclassés en REVIEW.

Exemple 1 (déplacement par inférence sémantique) :

Action: MOVE
Source: D:\OldFiles\Downloads\Devis-ClientA.xlsx
Destination: D:\OldFiles\Travail\ClientA\Devis.xlsx
Reason: Le nom du fichier est fortement cohérent avec de multiples données ClientA dans le même répertoire, et le répertoire ClientA cible existe déjà
Confidence: ÉLEVÉ (HIGH)
Evidence: semantic-map:T01 (thème ClientA : nom de répertoire + 6 preuves de noms de fichiers + groupe de Hash en double)

Exemple 2 (isolement de doublon déterministe) :

Action: QUARANTINE_DUPLICATE
Source: D:\OldFiles\Downloads\proposition (1).pdf
Canonical: D:\OldFiles\Projets\Client-A\proposition.pdf
Reason: czkawka HASH doublon exact
Confidence: ÉLEVÉ (HIGH)
Evidence: semantic-map:T05 + doublons Groupe 001

13. Application du plan (apply)

Avant de déplacer un fichier, il faut d'abord produire un résumé : périmètre d'analyse, nombre total de fichiers, capacité totale, nombre de répertoires de premier niveau ; nombre de groupes de doublons exacts trouvés, espace de doublons libérable, gros fichiers, fichiers éparpillés, projets fragmentés, répertoires de sauvegarde, répertoires Protégés, nombre d'éléments en Review ; nombre suggéré de répertoires à conserver/déplacer/fusionner/archiver et nombre de fichiers doublons à isoler ; répertoires de premier niveau prévus après organisation. N'imprimez pas des dizaines de milliers de chemins de fichiers dans la conversation ; les détails sont écrits dans plan.csv.

Règles d'exécution :

Vérifier à nouveau que la Source existe ; si la Destination existe déjà → enregistrer COLLISION, arrêter l'opération en cours et la consigner. Interdiction d'écraser, interdiction de renommer automatiquement ou d'ajouter (1). Les autres opérations sécurisées continuent.
La comparaison pour COLLISION doit ignorer la casse : NTFS et les volumes APFS par défaut sont des systèmes de fichiers insensibles à la casse ; Rapport.pdf et rapport.pdf dans le même répertoire constituent un conflit.
Si possible, déplacer un répertoire entier plutôt que de déplacer un par un ses 500 fichiers (Downloads\Projet-ClientA\ en entier → Travail\ClientA\Projet-ClientA\).
L'isolement conserve la structure de répertoire d'origine pour permettre de retrouver l'emplacement d'origine (ex : D:\OldDisk\Downloads\A\report.pdf → D:\OldDisk\_quarantine\2026-10-18\Downloads\A\report.pdf).
Chaque opération réussie est écrite dans operations.csv : Timestamp, Action, OriginalPath, NewPath, Reason, Hash.
Générer un script d'annulation (Windows : undo.ps1, Unix : undo.sh, NewPath → OriginalPath). Lors de l'annulation : (1) vérifier que le nouveau chemin existe (2) créer le répertoire parent d'origine (3) vérifier qu'aucun nouveau fichier n'existe au chemin d'origine (4) en cas de conflit, arrêter l'opération correspondante (5) interdiction d'écraser.
Après le premier cycle d'organisation, produire uniquement un rapport des répertoires vides (Empty Directory Report), ne pas supprimer automatiquement les répertoires vides – les répertoires vides peuvent parfois contenir des informations structurelles historiques.

14. Vérification (verify)

Vérifier : nombre de fichiers utilisateur d'origine, nombre de fichiers déplacés avec succès, nombre de fichiers doublons isolés, nombre d'opérations échouées, nombre de fichiers utilisateur restants. L'équation doit approximativement être satisfaite :

Fichiers utilisateur avant organisation = Fichiers utilisateur normaux après organisation + fichiers en quarantaine

(Les fichiers générés en interne dans _organizer ne participent pas au calcul.)

Vérification de la couverture sémantique : Chaque répertoire de dir-profiles avec ≥ 1 Go ou ≥ 50 fichiers doit avoir une appartenance thématique (semantic-map §2 / §3) ou un marquage REVIEW / PROTECTED. Les gros blocs non couverts sont listés, et il faut retourner en 9.6 pour approfondir avant de décider du traitement – aucun gros répertoire « non examiné » ne doit passer la vérification.

Ensuite, réexécuter une analyse des doublons (outil ou script de repli) et générer les groupes de doublons exacts restants (Remaining Exact Duplicate Groups). La présence de doublons restants ne signifie pas un échec de l'organisation – des doublons peuvent être autorisés dans les instantanés de sauvegarde, les archives historiques et les projets protégés.

15. Performance, confidentialité et discipline de jugement

Ordre de performance (interdiction absolue de lire tout le contenu d'un disque dur externe volumineux au LLM en une fois) :

Exploration complète de l'arborescence (les scripts de plateforme produisent en une fois inventory + dir-profiles) → Identification des répertoires protégés → Analyse des doublons (mécanique, peut être parallélisée avec le profilage) → Compréhension sémantique par l'Agent (lecture du profil → thèmes → carte sémantique, avec approfondissement et échantillonnage de contenu si nécessaire) → Plan

Le LLM utilise par défaut uniquement les métadonnées pour le jugement : chemin du fichier, nom du fichier, extension, taille, horodatage, répertoire parent, fichiers frères, structure des répertoires, Hash

organisateur-de-dossiers

Qu'est-ce que organisateur-de-dossiers ?

Demander à votre IA préférée

Documentation