Des papiers déposés une fois, retrouvés par leur texte
Papra archive les documents qu'on garde des années sans les rouvrir : factures, garanties, contrats, courriers. On dépose le fichier, Papra en extrait le texte, et la recherche plein texte le retrouve le jour où il faut le produire. Une démo sans backend, dont les données restent dans le navigateur, tourne sur demo.papra.app.
E-mail, dossier surveillé et cinq moteurs d'extraction
- Import sans ouvrir l'interface : adresse e-mail générée (via OwlRelay, relais de l'équipe Papra, ou un Email Worker Cloudflare), dossier surveillé, CLI (
papra documents import) ou API. Le dossier surveillé attend qu'un fichier cesse de grossir avant de l'importer, pour ne pas prendre un scan à moitié écrit. - Extraction en cascade : le moteur interne,
@papra/lecturebâti sur Tesseract.js, marche sans réglage. Mistral OCR, Docling, Azure Document Intelligence ou un service HTTP à soi se placent devant lui dansCONTENT_EXTRACTION_STRATEGY, et si l'un échoue, le suivant reprend le document. - Tags par règle ou par LLM : une règle tague selon le nom ou le contenu et se rejoue sur les documents déjà importés. Depuis la 26.6.0, un LLM (OpenAI, Anthropic, Mistral ou un modèle local via Ollama) choisit parmi les tags existants d'après leur description. L'IA est coupée par défaut.
- Chiffrement optionnel : AES-256-GCM, une clé par document, elle-même chiffrée par une clé maître versionnée qui autorise la rotation. Les fichiers vont sur disque local, S3 ou Azure Blob, et un doublon exact (même empreinte SHA-256) est refusé dans une organisation.
- Partage : organisations à rôles owner et member, propriétés personnalisées, liens de partage externes avec mot de passe et date d'expiration.
Un seul conteneur sur SQLite, porté par un développeur
SQLite est la seule base possible. Le serveur passe par le client libSQL : un fichier db.sqlite dans le volume app-data, ou une base libSQL distante. Aucun serveur de base n'est à installer à côté, et PostgreSQL n'est pas proposé.
L'original n'est jamais modifié. Le principe de non-mutation exclut la conversion de format, l'injection de métadonnées et l'ajout d'une couche OCR aux PDF scannés. Le texte extrait sert la recherche dans Papra ; le PDF téléchargé reste celui du scanner.
Sur le disque, les fichiers ne portent pas leur nom. Par défaut, ils sont rangés sous l'identifiant du document. Des chemins lisibles comme {{organization.id}}/{{document.name}} demandent DOCUMENT_STORAGE_USE_LEGACY_STORAGE_KEY_DEFINITION_SYSTEM=false (depuis la 26.3.0). Chiffrés, les fichiers prennent un format propre à Papra (en-tête PP01), illisible sans la base et la clé maître.
L'import par e-mail demande une instance joignable depuis Internet. OwlRelay comme le Worker Cloudflare livrent les messages par webhook, et le Worker exige un domaine chez Cloudflare.
Paperless-ngx est la référence revendiquée. Le site publie une comparaison avec Paperless-ngx : un conteneur de 524 Mo contre deux (application et Redis) et, côté Papra, stockage S3 ou Azure, organisations et offre hébergée officielle. La même page présente Paperless-ngx comme le plus mûr des deux.
La cible est le foyer ou la petite équipe. Le README destine les organisations à la famille, aux amis ou aux collègues. L'offre hébergée, en Europe, a un palier gratuit de 512 Mo et 3 membres par organisation.
Dernière version : 26.7.1, du 22 octobre 2026. La numérotation suit l'année (AA.MINEUR.CORRECTIF) et rien n'est rétroporté : les correctifs de sécurité n'arrivent que dans la dernière version. L'API change parfois de façon cassante, jusque dans un correctif : la 26.7.1 réduit la réponse de PUT /api/users/me.
Presque tous les commits viennent d'une personne. Corentin Thomasset, l'auteur, en signe 1 089 ; aucun autre contributeur humain n'en compte plus de cinq.
Le README a du retard sur les versions. Il range encore l'IA et l'application mobile parmi les fonctions « Coming maybe one day », alors que l'étiquetage par LLM est livré depuis la 26.6.0 et que l'application mobile en est à la 1.1.0 (1er octobre 2026).