Limites connues¶

Limitations identifiées de ColleC V0.9.0. Beaucoup peuvent être levées dans des versions ultérieures — voir changelog et les issues GitHub.

Modèle et données¶

Pas de migration automatique depuis V0.5/V0.6. Le modèle a été refondu en V0.9.0 (introduction de Fonds, suppression de Collection.parent_id, ajout de item_collection). Les bases anciennes nécessitent un ré-import via les profils v2.
Item.metadonnees : champ JSON libre, pas de validation de schéma. La structure dépend du profil d'import.
Pas de versionnage des items : les modifications sont journalisées dans modification_item mais l'historique granulaire (qui a changé quoi) n'est pas encore exposé dans l'UI.

EDTF non converti vers ISO 8601 : les dates EDTF (1969?, 1969/1985, 192X) sont préservées telles quelles dans les exports. Les consommateurs DC/Nakala doivent supporter EDTF (Nakala l'accepte).
TIFF dans la visionneuse web : les navigateurs ne supportent pas nativement TIFF. La visionneuse propose un fallback téléchargement. Les dérivés JPEG (générés par archives-tool deriver) sont la solution recommandée.
PDF : pour la dérivation, seule la première page est rasterisée (via PyMuPDF, à 200 dpi). Les PDF multipages perdent les pages 2+ dans la prévisualisation.
Type COAR non validé contre la liste officielle. Le rapport d'export signale les valeurs hors http://purl.org/coar/resource_type/, mais l'export n'est pas bloqué.
Pas de JSON-LD : prévu pour une session ultérieure (contextes COAR et Nakala).

Sensibilité à la casse : sur macOS et Windows, le système de fichiers est insensible à la casse par défaut. ColleC considère les noms comme sensibles à la casse (cohérent avec Linux / serveur de production). Conséquence : un même chemin écrit dans deux casses différentes peut entrer en collision silencieuse à l'export ou au déploiement.
Chemins Unicode (NFC/NFD) : géré sur macOS via chemin_existe_nfc_ou_nfd. Des comportements inattendus peuvent subsister sur des chemins exotiques (caractères supplémentaires Unicode hors BMP).

Cellules Excel : limite de 32 767 caractères par cellule (limite Excel native). Les descriptions plus longues sont tronquées par Excel à l'ouverture (pas par ColleC).
Titres de feuille xlsx : limite de 31 caractères. Tronqués silencieusement, les caractères interdits ([]:*?/\) retirés.
CSV Nakala : encodage UTF-8 BOM (compatible Excel). Pas d'échappement spécial des ; à l'intérieur des valeurs au-delà des règles RFC 4180.

Bases > 50 000 items : non testé en production. Les contrôles qa et le dashboard peuvent ralentir.
Renommage massif : pour des renames > 5 000 fichiers, le rapport Rich peut devenir verbeux. Le format JSON (controler --format json) est disponible pour le contrôle ; idem pour montrer. Pour renommer, le format JSON est prévu en V0.9.1.
Hash SHA-256 à l'import : calculés sur le binaire complet, ce qui peut être lent pour des fichiers très lourds (TIFF

100 MP). En dry-run, les hash ne sont pas calculés.

V0.9.0 est mono-utilisateur. Pas d'authentification ni de gestion de droits. L'utilisateur est lu de config_local.yaml (champ informatif sur les écritures : cree_par, modifie_par).
V1.0 ajoutera une auth simple (table Utilisateur, page de login par sélection, cookie de session) — destinée à un réseau interne de confiance, pas à une exposition publique. Pas de mot de passe : c'est de l'attribution, pas de la sécurité forte.
Édition concurrente V0.9.0 : pas de verrou sur les items. Deux utilisateurs (ou deux onglets) qui modifient simultanément le même item ont un comportement « last write wins ». Le verrou optimiste basé sur le champ version (déjà présent dans TracabiliteMixin) est prévu pour V0.9.1.
Édition inline : les métadonnées s'éditent via formulaire de page (pattern PRG). L'édition cellule-par-cellule dans les tableaux est prévue mais reportée à V0.9.1+.

Le modèle Fichier stocke (racine, chemin_relatif). La racine est une clé logique configurée dans config_local.yaml. Conséquence : une racine peut pointer vers un disque local ou un mount WebDAV, sans modification du modèle.
ShareDocs (Huma-Num) est validé comme cible de stockage partagé pour V1.0 (300 Go par compte projet). Test de faisabilité de la latence WebDAV à faire avant déploiement.
Pas de partage de base SQLite entre instances. Chaque contexte (poste local, VPS) a sa propre base. SQLite n'est pas conçu pour l'écriture concurrente sur réseau partagé.

OpenSeadragon : la visionneuse riche IIIF/DZI est prévue pour une version future. V0.9.0 utilise un <img> direct pour les formats raster supportés navigateur.

Dépôt automatique vers Nakala via leur API : hors scope. L'upload du CSV bulk se fait manuellement via l'interface Nakala.
OCR intégré : non prévu. Les outils OCR externes (Tesseract, Transkribus) doivent être utilisés en amont.
Refactoring de métadonnées en masse (renommer un champ, scinder/fusionner) : prévu pour V2 avec aperçu et journal.
Vue tableau éditable type tableur : prévu pour V2 avec raccourcis clavier (« feuille de scan »).

Plusieurs de ces limites peuvent être levées dans les versions suivantes :

V0.9.1 : édition inline, polish de l'UI.
V1.0 : stabilisation après usage en production. Pas de nouvelle fonctionnalité majeure prévue d'ici là — priorité au polish, à la doc et à la robustesse.
V2 : refactoring métadonnées en masse, vue tableau éditable, intégration Nakala API.
V3 : versionnement des fichiers, opérations sur scans (rotation, recadrage, scission), OCR, empaquetage distribuable.

Voir changelog pour les jalons réalisés.