[{"data":1,"prerenderedAt":129},["ShallowReactive",2],{"seo-verification":3,"blog-heberger-paperless-ngx-ma-fr":6,"promo-bar-likely":128},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-heberger-paperless-ngx-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":35,"sections":36,"ctaTitle":68,"ctaBody":69,"ctaButton":70,"ctaUrl":71,"relatedPosts":72},85,"heberger-paperless-ngx",{"fr":10,"en":12,"ar":13,"es":14},"host-paperless-ngx-on-your-own-vps","استضافة-paperless-ngx-على-خادمك-الافتراضي-الخاص-vps","alojar-paperless-ngx-en-un-vps","Héberger Paperless-ngx sur VPS : guide complet 2026","Installer Paperless-ngx sur VPS : Docker Compose, OCR multilingue, migration 2.x→3.x, incompatibilité Redis\u002FValkey et sauvegarde automatique. Guide mis à jour.",17,2,false,"2026-03-27T00:00:00+00:00","2026-09-08T02:42:11+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fheberger-paperless-ngx-poster.svg",{"categorySlug":25,"appSlug":34},"paperless-ngx","Paperless-ngx transforme vos documents scannés en une archive cherchable. Ce guide couvre l'installation, la configuration OCR, les problèmes de dates et de timeouts fréquents sur VPS entrée de gamme, ainsi que la procédure de migration de la branche 2.x vers la série 3.x avec ses incompatibilités connues.",[37,41,44,47,50,53,56,59,62,65],{"type":38,"title":39,"body":40},"h2","Pourquoi Paperless-ngx pour votre GED self-hosted","Paperless-ngx est la fork communautaire la plus active de Paperless — un système de gestion électronique de documents (GED) qui indexe vos PDF et images scannées, en extrait le texte via OCR, et vous permet de les retrouver par mot-clé, date, correspondant ou tag.\n\nPar rapport aux alternatives (Mayan EDMS, OpenDocMan), Paperless-ngx se distingue par sa simplicité d'installation (Docker Compose en moins de 10 minutes), son interface web écrite en **Angular**, et son support de l'OCR multilingue via Tesseract.\n\nLe projet est maintenu par sa communauté et publie des releases régulières — vérifiez la version courante sur la page des releases GitHub avant d'installer. La branche courante est la série **3.x** ; si vous partez d'une instance 2.x déjà en service, lisez la section « Mettre à jour de 2.x vers 3.x » plus bas **avant** de toucher à votre `docker-compose.yml` : la v3 rend obligatoires deux réglages qui étaient déduits ou implicites, et change plusieurs comportements par défaut.\n\n**Cas d'usage typiques :**\n- Archive des factures fournisseurs pour une micro-entreprise ou une PME\n- Dossier médical personnel ou familial (ordonnances, analyses, courriers)\n- Gestion des documents d'une association ou d'une copropriété\n- Archive des contrats et des baux pour une agence immobilière",{"type":38,"title":42,"body":43},"Prérequis et choix du VPS","Paperless-ngx est plus gourmand qu'il n'y paraît, surtout à l'import. Le traitement OCR d'un PDF multi-pages sollicite intensément le CPU — c'est la principale source de timeouts sur les petites configurations.\n\n**Configuration minimale recommandée :**\n- CPU : 2 vCPU (le traitement OCR est mono-thread par tâche, mais plusieurs tâches peuvent tourner en parallèle)\n- RAM : 2 Go minimum ; 4 Go pour un usage confortable\n- Stockage : SSD, 20 Go minimum pour l'application + prévoir l'espace pour vos documents\n- OS : Debian 12 ou Ubuntu 22.04\u002F24.04\n\n**Ce qui crée des timeouts sur les petits VPS :** les PDFs scannés à haute résolution (300+ DPI) ou comportant de nombreuses pages (50+) peuvent dépasser le `PAPERLESS_WORKER_TIMEOUT` par défaut (1 800 secondes). La section dédiée plus bas couvre la résolution.\n",{"type":38,"title":45,"body":46},"Installation avec Docker Compose","L'installation officielle recommandée utilise Docker Compose avec trois services : `webserver` (l'application), `broker` (la file de tâches) et `db` (la base PostgreSQL).\n\n⚠️ **Téléchargez les TROIS fichiers, pas seulement le `docker-compose.yml`.** C'est le piège d'installation le plus coûteux de cette page, parce qu'il échoue **en silence**. Le compose officiel déclare `env_file: docker-compose.env` : les réglages du conteneur sont lus dans **ce** fichier-là. Le `.env` du répertoire, lui, ne porte qu'une seule ligne — `COMPOSE_PROJECT_NAME=paperless` — et sert à Docker Compose pour nommer le projet et préfixer les volumes ; il n'est **pas** injecté dans les conteneurs. Écrire vos `PAPERLESS_*` dans `.env` ne produit aucune erreur : le conteneur démarre, l'interface répond, et aucun de vos réglages n'est appliqué. L'OCR retombe alors sur l'anglais — exactement le piège que la section suivante décrit.\n\n```bash\n# Répertoire de travail\nmkdir -p \u002Fopt\u002Fpaperless && cd \u002Fopt\u002Fpaperless\n\n# Les TROIS fichiers officiels\nBASE=https:\u002F\u002Fraw.githubusercontent.com\u002Fpaperless-ngx\u002Fpaperless-ngx\u002Fmain\u002Fdocker\u002Fcompose\ncurl -fsSL $BASE\u002Fdocker-compose.postgres.yml -o docker-compose.yml\ncurl -fsSL $BASE\u002Fdocker-compose.env          -o docker-compose.env\ncurl -fsSL $BASE\u002F.env                        -o .env\n\n# Générer la clé AVANT d'écrire quoi que ce soit : un heredoc QUOTÉ (\u003C\u003C'EOF') n'exécute\n# aucune substitution, la ligne serait écrite littéralement et le « secret » serait public.\nSECRET_KEY=$(openssl rand -hex 32)\n\n# Le gabarit livre PAPERLESS_SECRET_KEY=change-me : on la REMPLACE, on ne la duplique pas.\nsed -i \"s|^PAPERLESS_SECRET_KEY=.*|PAPERLESS_SECRET_KEY=$SECRET_KEY|\" docker-compose.env\n\n# Le reste des réglages va dans le MÊME fichier (heredoc non quoté : $VAR est bien remplacé)\ncat >> docker-compose.env \u003C\u003CEOF\nPAPERLESS_URL=https:\u002F\u002Fpaperless.votre-domaine.com\nPAPERLESS_TIME_ZONE=Europe\u002FParis\nPAPERLESS_OCR_LANGUAGE=fra+eng+ara\nPAPERLESS_OCR_LANGUAGES=fra ara\nEOF\n\ndocker compose pull\ndocker compose up -d\n```\n\n`PAPERLESS_DBENGINE`, `PAPERLESS_DBHOST` et `PAPERLESS_REDIS` sont déjà posés dans le bloc `environment:` du compose officiel : ne les redéclarez pas dans `docker-compose.env`. En revanche, si vous écrivez votre propre compose, `PAPERLESS_DBENGINE=postgresql` est **obligatoire** depuis la v3 (voir la section migration) : sans lui, Paperless part sur SQLite.\n\nL'interface est accessible sur le port 8000 après environ 60 secondes de démarrage, et vous invite à créer le compte administrateur à la première connexion. Si vous préférez le faire en ligne de commande — installation scriptée, ou reprise d'accès plus tard :\n\n```bash\ndocker compose exec webserver createsuperuser\n```\n\nConfigurez ensuite votre reverse proxy (nginx ou Traefik) pour exposer le service avec TLS. Si vous en placez un devant Paperless, lisez le paragraphe sur `PAPERLESS_TRUSTED_PROXIES` dans la section migration : en v3, un proxy mal déclaré fait échouer le login en `403`.",{"type":38,"title":48,"body":49},"Configuration OCR multilingue","L'OCR est le cœur de Paperless-ngx. Sa configuration détermine la qualité de l'indexation et la capacité à retrouver vos documents.\n\n**Langues Tesseract disponibles :** le paramètre `PAPERLESS_OCR_LANGUAGE` accepte les codes de langue Tesseract séparés par `+`. Pour un usage franco-marocain :\n\n```bash\nPAPERLESS_OCR_LANGUAGE=fra+ara+eng   # langues utilisées à l'OCR\nPAPERLESS_OCR_LANGUAGES=fra ara      # paquets Tesseract à INSTALLER (séparés par des espaces)\n```\n\n⚠️ **Les deux variables sont nécessaires, et c'est le second piège coûteux de cette page.** `PAPERLESS_OCR_LANGUAGE` vaut `eng` par défaut et ne fait que *choisir* la langue ; pour toute langue non présente dans l'image, la doc impose de renseigner **aussi** `PAPERLESS_OCR_LANGUAGES` (liste séparée par des **espaces**, pas par des `+`) sur les déploiements Docker. Sans elle, l'OCR retombe silencieusement sur l'anglais : vos documents sont indexés, mais le texte français et arabe est illisible — et rien dans l'interface ne le signale.\n\nL'image embarque déjà l'anglais, l'allemand, l'italien, l'espagnol et le français : seul le reste est à installer. Garder aussi en tête que Tesseract consomme nettement plus de CPU avec plusieurs langues activées — n'en déclarez que ce que vous scannez réellement.\n\n**Mode OCR :** `PAPERLESS_OCR_MODE` contrôle quand l'OCR est appliqué. Quatre valeurs existent — et `skip`, qu'on lit souvent, n'en fait **pas** partie :\n- `auto` (**défaut**) : Paperless regarde via `pdftotext` si le PDF porte déjà du texte ; s'il y en a assez, l'OCR est sauté pour ce document, sinon il tourne normalement. C'est l'option la plus sûre sur un fonds mixte\n- `redo` : ré-OCRise toutes les pages et tente de remplacer les couches de texte existantes — utile quand le scanner a produit un OCR médiocre. Peut échouer sur certains documents (formulaires) ; le texte d'origine est alors conservé\n- `force` : rastérise le document, transforme le texte en image et pose l'OCR par-dessus. Marche partout, mais le fichier grossit et le texte est moins net au zoom\n- `off` : n'invoque jamais l'OCR ; pour les PDF le texte est extrait par `pdftotext` seul, et les images ressortent sans texte\n\n⚠️ Si vous arrivez d'une instance 2.x, `skip` et `skip_noarchive` **existaient** et ont été **retirés** en v3. Une valeur retirée n'est pas honorée en silence : Paperless journalise un avertissement au démarrage et applique le défaut. La v3 sépare en deux réglages ce que `skip` mélangeait — quand faire l'OCR (`PAPERLESS_OCR_MODE`) et quand produire l'archive PDF\u002FA (`PAPERLESS_ARCHIVE_FILE_GENERATION`, valeurs `auto` par défaut, `always`, `never`). La section migration donne la table de correspondance.\n\nPour la plupart des usages, laissez `auto` : il évite de re-traiter les PDF natifs (contrats, factures générées par un logiciel) sans que vous ayez rien à régler.",{"type":38,"title":51,"body":52},"Gestion des dates de document : le problème et la solution","La détection automatique des dates est l'une des fonctionnalités les plus puissantes de Paperless-ngx — et l'une des plus frustrantes quand elle ne fonctionne pas. Par défaut, Paperless-ngx essaie de détecter la date du document dans son contenu textuel et son nom de fichier. Plusieurs raisons peuvent mener à une date incorrecte ou absente.\n\n**Problème 1 : La date est en format non reconnu.** Paperless-ngx détecte les formats courants (`DD\u002FMM\u002FYYYY`, `YYYY-MM-DD`, etc.) mais peut rater des formats ambigus (`08\u002F09\u002F2025` : le 8 septembre ou le 9 août ?).\n\n**Solution :** vérifier — et non « configurer » — l'ordre de lecture. `PAPERLESS_DATE_ORDER` vaut **déjà `DMY`** par défaut, c'est-à-dire jour, mois, année : le poser explicitement ne change donc rien et ne résout pas une ambiguïté. Ce réglage ne sert qu'à s'en **écarter**, par exemple pour un fonds de documents américains :\n```bash\nPAPERLESS_DATE_ORDER=MDY  # MM\u002FDD\u002FYYYY — à ne poser QUE si vos documents sont datés ainsi\n```\nPour un fonds mixte, aucun ordre global ne peut être correct : c'est le nommage des fichiers (problème 3 ci-dessous) qui tranche.\n\n**Problème 2 : Le document a plusieurs dates et la mauvaise est choisie.** Par exemple, une facture qui mentionne la date de la prestation ET la date d'émission — Paperless-ngx prend la première trouvée.\n\n**Solution :** utiliser le champ de date manuel dans l'interface web pour corriger les documents mal datés, ou configurer des règles de correspondance (`Matching rules`) qui assignent une date depuis le nom de fichier.\n\n**Problème 3 : La date de création du fichier est utilisée à la place.** Quand aucune date n'est trouvée dans le contenu, Paperless-ngx utilise la date de modification du fichier comme fallback — ce qui peut être très trompeur pour des documents anciens scannés récemment.\n\n**Solution :** nommer les fichiers d'import avec la date du document (`YYYY-MM-DD_nom-document.pdf`) — Paperless-ngx détecte ce format dans le nom de fichier avant d'analyser le contenu.",{"type":38,"title":54,"body":55},"Résolution des timeouts sur VPS entrée de gamme","Sur un VPS avec 1 ou 2 vCPU, le traitement OCR de documents volumineux peut dépasser le timeout par défaut et laisser le document en statut « En attente de traitement » indéfiniment.\n\n**Diagnostic :** vérifier les logs du worker :\n```bash\ndocker compose logs celery --tail=50\n```\nLes lignes `SoftTimeLimitExceeded` confirment un timeout.\n\n**Résolution — quatre leviers :**\n\n**1. Augmenter le timeout des tâches :**\n```bash\nPAPERLESS_WORKER_TIMEOUT=3600  # 1 heure (défaut : 1800 s)\n```\n⚠️ Le nom exact compte : `PAPERLESS_WORKER_TIMEOUT`. Un réglage mal orthographié n'est pas rejeté par Paperless — il est **ignoré en silence**, et les timeouts continuent exactement comme avant, ce qui se lit à tort « le correctif n'a pas marché ».\n\n**2. Réduire la résolution d'import.** Si vous scannez vous-même les documents, 200 DPI est suffisant pour un OCR de qualité — 300 DPI double le temps de traitement sans amélioration perceptible pour du texte standard.\n\n**3. Limiter le traitement parallèle :**\n```bash\nPAPERLESS_TASK_WORKERS=1        # tâches en parallèle (défaut : 1)\nPAPERLESS_THREADS_PER_WORKER=1  # pages traitées en parallèle sur UN document\n```\nNon défini, `PAPERLESS_THREADS_PER_WORKER` vaut `max(floor(nb_cœurs \u002F PAPERLESS_TASK_WORKERS), 1)`. La règle upstream à ne pas franchir : le **produit** `TASK_WORKERS × THREADS_PER_WORKER` ne doit pas dépasser le nombre de cœurs, sinon l'instance devient extrêmement lente. Beaucoup de workers = beaucoup de documents en parallèle ; beaucoup de threads = un gros document traité plus vite.\nSur un VPS 2 vCPU, traiter deux documents en parallèle peut provoquer des timeouts que traiter le même volume séquentiellement éviterait.\n\n**4. Optimiser le préprocessing PDF :**\n```bash\nPAPERLESS_OCR_USER_ARGS={\"optimize\": 1, \"pdfa-image-compression\": \"jpeg\"}\n```\nCeci compresse les images dans les PDFs avant traitement, réduisant la charge mémoire et CPU.",{"type":38,"title":57,"body":58},"Mettre à jour de 2.x vers 3.x","La série 3.x de Paperless-ngx apporte des changements structurels qui rendent la migration in-place obligatoire, et ajoute des conditions préalables qui n'existaient pas sur la branche 2.x.\n\n**Le prérequis qu'on oublie :** la montée en v3 n'est supportée **que depuis la 2.20.15**. Si vous tournez sur une version antérieure, montez d'abord en 2.20.15, puis seulement en 3.x. Basculer directement l'étiquette de l'image d'une 2.14 vers une 3.x n'est pas un chemin supporté, et rien ne vous en avertira au démarrage.\n\nL'export\u002Fimport entre versions (`document_exporter` puis `document_importer` sur une instance vierge) n'est **pas supporté** — et la règle upstream est plus large qu'on ne le croit : elle vaut entre **deux versions quelconques**, pas seulement entre majeures, parce qu'un export contient une image exacte de la base. En pratique, `document_importer` prévient (`Version mismatch: Currently 3.1.x, importing 2.20.15. Continuing, but import may fail.`) puis échoue sur `KeyError: 'show_on_dashboard'` — un champ du modèle `SavedView` qui existait en 2.20.15 et n'existe plus dans le schéma 3.x. La seule voie sûre est de laisser les migrations s'appliquer sur la base existante.\n\n**Procédure recommandée :**\n\n1. Faire une sauvegarde complète avant toute chose (voir la section dédiée ci-dessous).\n2. Arrêter les services : `docker compose down`.\n3. Passer en revue dans `docker-compose.env` et `docker-compose.yml` les réglages que la v3 rend obligatoires ou retire (détaillés juste après).\n4. Pointer l'image du `docker-compose.yml` sur la version 3.x cible et relancer : `docker compose up -d` — les migrations Django s'appliquent automatiquement au démarrage du `webserver`.\n5. Surveiller les logs : `docker compose logs webserver --tail=100` — une migration qui échoue affiche l'erreur et bloque le démarrage.\n\n**`PAPERLESS_SECRET_KEY` devient obligatoire.** Il existait auparavant une clé interne par défaut ; en v3 elle doit être déclarée, et Paperless refuse de démarrer sans elle. Réutiliser l'ancienne valeur conserve les sessions et les jetons signés ; en poser une nouvelle les invalide tous. C'est un choix à faire sciemment, pas un détail de configuration.\n\n**`PAPERLESS_DBENGINE` devient obligatoire avec PostgreSQL ou MariaDB.** En v2, le moteur était **déduit** de la présence de `PAPERLESS_DBHOST` ; en v3 il doit être explicite, et la valeur par défaut est `sqlite`. Les valeurs acceptées sont `sqlite`, `postgresql` et `mariadb` — rien d'autre. C'est le piège de migration numéro un : sans ce réglage, l'instance démarre sur une base SQLite vide, votre PostgreSQL est intact mais plus personne ne le lit, et l'écran d'accueil vous annonce zéro document.\n```yaml\n# v2 (PostgreSQL déduit de PAPERLESS_DBHOST)\nPAPERLESS_DBHOST: db\n# v3 (le moteur doit être explicite)\nPAPERLESS_DBENGINE: postgresql\nPAPERLESS_DBHOST: db\n```\n\n**`PAPERLESS_OCR_MODE=skip` disparaît.** Les valeurs `skip` et `skip_noarchive` sont retirées, et une variable retirée n'est pas honorée en silence : un avertissement est journalisé au démarrage. Conserver le comportement de la v2 demande de répartir l'intention entre deux réglages désormais indépendants :\n```bash\n# v2 : sauter l'OCR si du texte est présent, mais toujours archiver\nPAPERLESS_OCR_MODE=skip\n# v3 : équivalent\nPAPERLESS_OCR_MODE=auto\nPAPERLESS_ARCHIVE_FILE_GENERATION=always\n```\n\n**Incompatibilité Redis → Valkey.** Depuis la v3, le compose **officiel** embarque **Valkey** comme broker (`valkey\u002Fvalkey:9-alpine`), et non plus Redis : ce n'est pas un choix marginal, c'est ce que vous récupérez dès que vous remplacez votre compose par le gabarit du projet. Si votre volume de broker a été créé par une version récente de Redis, Valkey refuse de le charger et le conteneur entre en boucle de redémarrage sur `Can't handle RDB format version 15` (ou `13`, selon l'origine), pendant que le `webserver` attend un broker qui ne vient jamais. La solution est de **supprimer le volume du broker** avant de basculer : il ne contient que des tâches en file, aucune donnée persistante critique.\n```bash\ndocker compose down\ndocker volume rm paperless_redisdata   # le préfixe vient de COMPOSE_PROJECT_NAME\ndocker compose up -d\n```\n\n**L'index de recherche se reconstruit tout seul.** La v3 remplace Whoosh par Tantivy, et le format est incompatible : l'index est régénéré depuis zéro au premier démarrage — ce qui explique un premier lancement plus long. Sous Docker, le conteneur exécute `document_index reindex --if-needed` à chaque démarrage, donc aucune action manuelle n'est requise. Si malgré tout la consommation échoue sur `Schema error: 'An index exists but the schema does not match.'` (cas rapporté sur une instance ayant tourné la bêta 3.0), forcez une reconstruction propre :\n```bash\ndocker compose exec webserver document_index reindex --recreate\n```\nAttention aussi à la syntaxe de recherche : `note:` devient `notes.note:` et `custom_field:` devient `custom_fields.value:`. Les vues enregistrées portant un préfixe explicite sont migrées automatiquement, mais une recherche **sans** préfixe qui trouvait auparavant le contenu d'une note ne le trouvera plus.\n\n**Trois changements de comportement qui surprennent.** L'historique des tâches est **effacé** pendant la mise à jour : les tâches passées, échouées ou acquittées ne réapparaîtront pas. La v3 ne **rejette plus les doublons** par défaut — elle les accepte et permet de les repérer dans l'interface ; si vous comptiez sur ce rejet, réactivez-le avec `PAPERLESS_CONSUMER_DELETE_DUPLICATES=true`. Enfin, derrière un reverse proxy, la limitation de débit du login détermine désormais autrement l'IP du client : si la connexion renvoie `403 Forbidden` après la mise à jour, déclarez la chaîne avec `PAPERLESS_TRUSTED_PROXIES`, et au besoin `PAPERLESS_ALLAUTH_TRUSTED_PROXY_COUNT` — le nombre de sauts dans `X-Forwarded-For`, qui n'est pas forcément le nombre d'IP configurées.\n\n**À propos de MariaDB.** Elle reste supportée (`PAPERLESS_DBENGINE=mariadb`), même si le projet recommande PostgreSQL pour les nouvelles installations. Les échecs de migration sur Debian 12 qui circulent dans les forums ne venaient pas du pilote : ils venaient d'installations **bare-metal** où la nouvelle version avait été dépaquetée par-dessus l'ancienne. Les fichiers de migration périmés restés sur le disque font échouer `manage.py migrate` sur un `NodeNotFoundError`. Le remède est de supprimer l'arbre de sources précédent (`src\u002F`, `static\u002F`) avant de déployer, pas de changer de moteur de base de données — et dans un déploiement Docker comme celui de ce guide, ce scénario ne peut pas se produire, puisque l'image est remplacée en bloc.\n\n**Le courrier après la mise à jour.** La commande qui force la relève du courrier est `mail_fetcher`, sans argument : elle traite tous les comptes et toutes les règles configurés.\n```bash\ndocker compose exec webserver mail_fetcher\n```\nSi un flux de courrier cesse de produire des documents après la mise à jour, regardez d'abord l'erreur de la tâche dans l'interface : les cas rapportés pointaient vers l'index de recherche (le `Schema error` ci-dessus), pas vers les identifiants. Vérifiez ensuite que le compte conserve ses autorisations IMAP ; si vous utilisez un jeton OAuth, cochez la case indiquant que le mot de passe est en réalité un jeton.",{"type":60,"body":61},"tip","Avant toute mise à jour majeure, testez la procédure sur une copie de votre environnement. Avec Docker Compose, cela revient à copier votre répertoire `\u002Fopt\u002Fpaperless` sur un second VPS, à pointer un sous-domaine de test, et à y appliquer la mise à jour. Vous pouvez ensuite valider que vos documents, tags et correspondants sont intacts avant d'intervenir sur la production.",{"type":38,"title":63,"body":64},"Sauvegarde automatique de Paperless-ngx","Paperless-ngx gère deux types de données critiques : la base de données PostgreSQL (métadonnées, tags, correspondants, règles) et les fichiers documents. Les deux doivent être sauvegardés — l'un sans l'autre ne restaure rien d'utilisable.\n\n**Script de sauvegarde quotidien :**\n```bash\n#!\u002Fbin\u002Fbash\nBACKUP_DIR=\"\u002Fbackups\u002Fpaperless\u002F$(date +%Y%m%d)\"\nmkdir -p \"$BACKUP_DIR\"\n\n# Dump PostgreSQL\ndocker compose exec -T db pg_dump -U paperless paperless \\\n  | gzip > \"$BACKUP_DIR\u002Fdb.sql.gz\"\n\n# Export natif Paperless (inclut config et documents)\ndocker compose exec -T webserver document_exporter ..\u002Fexport\ntar -czf \"$BACKUP_DIR\u002Fexport.tar.gz\" \u002Fopt\u002Fpaperless\u002Fexport\u002F\n\n# Rotation — garder 14 jours\nfind \u002Fbackups\u002Fpaperless -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +\n\necho \"Sauvegarde terminée : $BACKUP_DIR\"\n```\n\nPlanifier ce script en cron (`0 3 * * *` pour 3h du matin), et vérifier que les backups arrivent bien sur un stockage externe au VPS (rsync vers un bucket S3 ou un autre serveur). Le `-T` derrière `exec` évite l'erreur « the input device is not a TTY » quand le script tourne sans terminal.\n\n⚠️ Un export ne remplace pas une sauvegarde de volumes, et ne sert pas de pont entre versions : il ne se réimporte que dans **la même version** de Paperless-ngx que celle qui l'a produit. Pour une restauration après incident, gardez donc aussi une copie des volumes Docker, ou notez la version exacte à côté de l'export.",{"type":38,"title":66,"body":67},"Mise à jour et maintenance","Paperless-ngx publie des releases régulières. La mise à jour est simple avec Docker Compose :\n\n```bash\n# Tirer la nouvelle image\ndocker compose pull\n\n# Redémarrer les services (les migrations de base de données s'appliquent automatiquement)\ndocker compose up -d\n\n# Vérifier que tout est OK\ndocker compose logs webserver --tail=20\n```\n\n**Avant chaque mise à jour majeure :** lire le CHANGELOG sur GitHub — les versions majeures (v2.x → v3.x) peuvent nécessiter des étapes de migration supplémentaires, et parfois une **version intermédiaire obligatoire**, comme la 2.20.15 avant la v3. La section dédiée ci-dessus détaille les incompatibilités connues de la série 3.x.\n\n**Surveillance :** Paperless-ngx n'expose **pas** d'endpoint `\u002Fmetrics` à lui. Ce qui existe est **Flower**, le moniteur des tâches Celery, activé en définissant `PAPERLESS_ENABLE_FLOWER` ; c'est Flower qui exporte des métriques exploitables par Prometheus, en plus de montrer les tâches en cours, en file et terminées. C'est le bon endroit pour repérer un traitement qui s'arrête en silence — le symptôme d'un timeout OCR, précisément.\n\n⚠️ Un détail qui change après une montée en v3 : l'historique des tâches ayant été effacé par la migration, une liste vide au premier démarrage n'est pas le signe d'une panne. Ce sont les tâches **postérieures** à la mise à jour qui font foi.","Numérisez et indexez tous vos documents","Le VPS Cloud ServOrbit offre le CPU, le stockage et Docker prêts pour Paperless-ngx, son OCR Tesseract, PostgreSQL et Redis. Transformez vos piles de papier en archive cherchable, sauvegardée et sous votre seul contrôle.","Déployer Paperless-ngx sur un VPS Cloud","\u002Fvps-cloud",[73,92,110],{"id":74,"slug":75,"slugs":76,"title":80,"excerpt":81,"readTime":82,"views":83,"isPinned":19,"noindex":19,"publishedAt":84,"updatedAt":85,"category":86,"categories":87,"featuredImage":30,"bgImage":31,"posterImage":89,"relatedSolution":90},71,"heberger-nextcloud",{"fr":75,"en":77,"ar":78,"es":79},"hosting-nextcloud-on-your-own-vps","استضافة-nextcloud-على-خادمك-الـvps-الخاص","alojar-nextcloud-en-su-propio-vps","Héberger Nextcloud sur VPS : guide NC 35, PHP 8.3 et MariaDB 11","Hébergez Nextcloud sur VPS : Docker Compose, Redis, sauvegarde MariaDB, envois de plus de 40 Go derrière Cloudflare et alternative à Office 2021.",20,1,"2026-04-10T00:00:00+00:00","2026-11-08T16:32:50+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[88],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-nextcloud-poster.svg",{"categorySlug":25,"appSlug":91},"nextcloud",{"id":93,"slug":94,"slugs":95,"title":99,"excerpt":100,"readTime":101,"views":83,"isPinned":19,"noindex":19,"publishedAt":102,"updatedAt":103,"category":104,"categories":105,"featuredImage":30,"bgImage":31,"posterImage":107,"relatedSolution":108},72,"heberger-ghost",{"fr":94,"en":96,"ar":97,"es":98},"hosting-ghost-on-your-own-vps","استضافة-ghost-على-خادمك-الـvps-الخاص","alojar-ghost-en-un-vps","Héberger Ghost sur VPS : guide complet 2026","Déployez Ghost v6 sur votre VPS avec Caddy, MySQL, Ghost CLI et Stripe Tax : installation, reverse proxy TLS, mise à jour et dépannage des erreurs fréquentes.",10,"2026-04-09T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[106],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-ghost-poster.svg",{"categorySlug":25,"appSlug":109},"ghost",{"id":111,"slug":112,"slugs":113,"title":117,"excerpt":118,"readTime":23,"views":119,"isPinned":19,"noindex":19,"publishedAt":120,"updatedAt":121,"category":122,"categories":123,"featuredImage":30,"bgImage":31,"posterImage":125,"relatedSolution":126},73,"heberger-wordpress",{"fr":112,"en":114,"ar":115,"es":116},"host-wordpress-on-your-own-vps","استضافة-wordpress-على-خادم-vps-الخاص-بك","alojar-wordpress-en-un-vps","Héberger WordPress sur votre propre VPS","Hébergez WordPress sur votre VPS pour des performances et un contrôle maximaux : Docker, MariaDB, cache, reverse proxy et SSL.",0,"2026-04-08T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[124],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-wordpress-poster.svg",{"categorySlug":25,"appSlug":127},"wordpress",true,1794270727850]