J'étais une fois de plus en train de farfouiller dans mon épaisse pile de papelards plus ou moins importants, rêvant d'une fonction "recherche" qui fonctionnerait sur le bois. Et encore, maintenant que de plus en plus de factures sont envoyées électroniquement, on ne peut même pas tout mettre au même endroit à moins de faire chauffer l'imprimante, ce qui réduit fortement l'intérêt écologique de la manoeuvre. Sûrement, il y a une manière moins pénible de retrouver un document! Après tout, classifier et rechercher, c'est ce que les ordinateurs savent faire le mieux, non?

Il y a plein de solutions commerciales, mais quelle est la difficulté de se monter ça chez soi pour pas un rond?

A y regarder de plus près, probablement pas grand chose. Toutes les briques sont déjà là:
- Tout d'abord, le document, disons un PDF, soit scanné (gscan2pdf), soit directement reçu.
- Ensuite, le contenu du document (l'on doit pouvoir chercher via le texte). Si c'est du scan, gocr en extraira le texte. La qualité est décevante, mais dans notre cas, c'est amplement suffisant. Si l'on a le pdf d'origine, un bête pdftotext fera l'affaire.
- Maintenant, l'on peut enregistrer notre document dans une base de données. Prenons Postgresql, le document en lui-même dans une colonne, le contenu sous une forme qui permettra le "Full Text Search". Rajoutons quelques tags pour faire bonne mesure, histoire de différencier une facture d'eau de son relevé de cotisations retraite.

Et voilà, un système de documentation! Rajoutons le support pour de plus nombreux types de document, peut-être un aperçu, un chiffrage des données (pas si évident si l'on veux également chiffrer les index de Full Text Search), et enfin une interface graphique intégrée, et nous y voilà. Donnez moi deux week-ends, et je ponds ça!


I was once again deep under my heavy pile of more or less important administrative documents, bills and all, dreaming of a "search" function that would work on wood. That would be notwithstanding the numerous bills that are now being sent electronically, preventing from at least trying to consolidate the stuff, unless you start printing everything, defeating the ecological purpose. Surely, there is a less painful way of finding a document. After all, classifying and searching, that is what computers are good at, isn't it?

There are many commercial solutions, but how hard is it to build an amateur system for free?

Looking closely, it does not look that hard. All the bricks are already there:
- First of all, the document, let's say a PDF, either scanned, or received through an e-mail.
- Then, the contents of the document. If it's a scan, gocr will extract the text. Quality is disappointing, but good enough for our purpose. If we have the original PDF, a simple pdftotext will do the job.
- Now, we can save our document in a database. Let's take Postgresql, with the document in a column, and the contents under a format that will allow for full text search in another one. Let's add a simple tagging system, so that we can differentiate a water bill from a pension summary.

And here we are, a documentation system! Let's add support for more numerous document systems, maybe thumbnails, encrypted data (not that easy to encrypt the full search text index, actually!), and an integrated graphical user interface, and we're in. Give me two week-ends, and I make it!