Pour la logique de séparation des responsabilités: +1 :-)
Pour ce qui est de coupler l'application avec un moteur de recherche desktop: C'est sûrement possible. C'est même déjà plus ou moins le cas: Paperwork génère des .jpg+.txt. Le .txt sera donc déjà indexé par le moteur. D'après mes souvenirs d'expérimentations d'il y a quelques années, le plus gros problème est en fait de pouvoir ouvrir le jpg correspondant au .txt: les moteurs de recherche desktop, dans leurs listes de résultats, ont la fâcheuse habitude de juste permettre l'ouverture du .txt, et non pas du dossier parent de ce fichier. J'avais juste trouvé Google Desktop qui permettait de le faire …
Après il y a une autre problématique: Les défauts d'OCR. Paperwork fournit (enfin tente) des suggestions de recherche basées sur les mots effectivement obtenus par l'OCR. Ça permet occasionnellement de rattraper certains glitchs de l'OCR (par exemple, j'ai un document qui a pour mot clef "Flescih" au lieu de "Flesch"). Je ne pense pas qu'un moteur de recherche desktop puisse fournir ces suggestions facilement.
Pour les tags/catégories: C'est déjà implémenté (c'est appelé 'labels' dans l'application)
Pour le reste, tel que je vois ça:
L'emplacement physique de l'original: les tags peuvent servir pour faire ça.
La confidentialité du document: idem, les tags peuvent servir pour faire ça.
La durée de conservation / une option pour faire le ménage: Je me sais pas dans quel mesure un ménage de printemps serait pertinent connaissant les capacités de stockage des disques durs actuels. Quand bien même quelqu'un tiendrait à le faire, c'est faisable avec les tags: Les documents sont identifiés (et triés) par leur date de scan. Il suffit donc de les tagger ensuite sur la période qu'on veut les garder. Lorsqu'on veut faire le ménage, on peut alors faire une recherche sur un des tags de durée, et supprimer les documents trop vieux. Par contre il faudrait que j'autorise la sélection de multiples documents simultanément.
Concernant la volumétrie: J'ai actuellement 792 pages. Elles prennent 859Mo. Quand il démarre, Paperwork met environ 10 à 20 secondes à les indexer sur ma machine (problème qui disparaitra lorsque j'utiliserais Sqlite pour stocker l'index sur le disque).
[^] # Re: Très intéressant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Gérer sa paperasse quand on est une feignas^W^W un programmeur. Évalué à 1.
Pour la logique de séparation des responsabilités: +1 :-)
Pour ce qui est de coupler l'application avec un moteur de recherche desktop: C'est sûrement possible. C'est même déjà plus ou moins le cas: Paperwork génère des .jpg+.txt. Le .txt sera donc déjà indexé par le moteur. D'après mes souvenirs d'expérimentations d'il y a quelques années, le plus gros problème est en fait de pouvoir ouvrir le jpg correspondant au .txt: les moteurs de recherche desktop, dans leurs listes de résultats, ont la fâcheuse habitude de juste permettre l'ouverture du .txt, et non pas du dossier parent de ce fichier. J'avais juste trouvé Google Desktop qui permettait de le faire …
Après il y a une autre problématique: Les défauts d'OCR. Paperwork fournit (enfin tente) des suggestions de recherche basées sur les mots effectivement obtenus par l'OCR. Ça permet occasionnellement de rattraper certains glitchs de l'OCR (par exemple, j'ai un document qui a pour mot clef "Flescih" au lieu de "Flesch"). Je ne pense pas qu'un moteur de recherche desktop puisse fournir ces suggestions facilement.
Pour les tags/catégories: C'est déjà implémenté (c'est appelé 'labels' dans l'application)
Pour le reste, tel que je vois ça:
Concernant la volumétrie: J'ai actuellement 792 pages. Elles prennent 859Mo. Quand il démarre, Paperwork met environ 10 à 20 secondes à les indexer sur ma machine (problème qui disparaitra lorsque j'utiliserais Sqlite pour stocker l'index sur le disque).