Skip to main content

260813 - solutions de page Internet pour transfert des epub sur la liseuse Kobo Aura 2

Transfert d'epub sur la Kobo Aura Edition 2 sans câble USB

Date : 2026-08-13 — Statut : en production, validé sur l'appareil Matériel : Kobo Aura Edition 2 (6 pouces, micro-USB) URL de service : juxjux.ovh/56ifciz (HTTP)— répond en HTTP et en HTTPS

1. Le problème

Le port USB de la liseuse ne permet plus aucun transfert. Le PC ne détecte rien du tout — pas même un périphérique en erreur.

Diagnostic mené sur le poste Windows julie :

Vérification Résultat
Périphérique VID_2237 (Kobo Inc.) présent absent
Périphérique inconnu ou en erreur (Status ≠ OK) aucun
Historique registre Enum\USB — trace d'un VID_2237 aucune
Historique USBSTOR un seul boîtier ASMT, jamais de Kobo
Disques vus Patriot (C:), Toshiba (D:), ASMT (E:), Seagate (F:) — rien de plus

Conclusion : Windows ne reçoit aucun handshake USB. Le problème est en amont du système — ce n'est ni un pilote, ni une lettre de lecteur, ni une base de registre à nettoyer. Aucune piste logicielle n'est exploitable.

Causes matérielles possibles, par probabilité décroissante :

  1. Câble charge seule — cause n°1 et de loin. Beaucoup de câbles micro-USB ne câblent que 2 fils sur 4
  2. Port de la liseuse encrassé — la micro-USB accumule peluches et poussière de poche
  3. Batterie profondément déchargée — une Kobo à plat ne s'énumère pas, même branchée. Il faut la laisser une heure sur un chargeur secteur avant de retenter
  4. Port physiquement HS

Le contournement décrit ci-dessous rend la liseuse pleinement utilisable, mais ne remplace pas un test câble. Voir § 7.

Commandes de diagnostic réutilisables (PowerShell) :

Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'USB' } |
    Select-Object Status,Class,FriendlyName,InstanceId | Sort-Object Class

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Enum\USB' |
    Where-Object { $_.PSChildName -match 'VID_2237' }

2. Solutions écartées, et pourquoi

Ce tableau évite de refaire le tour des mêmes impasses.

Piste Verdict Raison
GUI Syncthing impossible Ne permet aucun téléchargement de fichier — Syncthing synchronise, il ne sert pas de fichiers. Et c'est une application JS moderne, illisible sur ce navigateur
FileBrowser (files.juxjux.ovh) impossible SPA + login JWT — injouable sur le WebKit de la liseuse
OPDS (Komga, Kavita, Ubooquity) impossible Le navigateur stock de la Kobo ne lit pas l'OPDS. Ne deviendrait pertinent qu'avec KOReader installé
Kobo Sync natif de Calibre-web bloqué C'est la bonne solution sur le papier : synchronisation native par Wi-Fi. Mais elle impose de modifier api_endpoint dans .kobo/Kobo/Kobo eReader.conf sur la liseuse — donc exige l'USB, précisément ce qui est en panne. À reconsidérer si le port refonctionne
Yourls pour raccourcir l'URL inutile juxjux.ovh/56ifciz est déjà court à taper au doigt.doigt, Éviteret éviter la redirection supprime un point de fragilité, et Yourls est en HTTPS — même problème TLS (§ 4)fragilité
Page HTML nue en autoindex retenu Pas de JavaScript, pas de session, pas de cookie. Le navigateur Kobo télécharge le fichier et l'ajoute à la bibliothèque

3. La solution retenue

Un location nginx en autoindex greffé sur le vhost juxjux.ovh existant, servant un dossier de l'arbre Syncthing.

Dépôt du fichier            Syncthing              nginx autoindex         Navigateur bêta
D:\Syncthing\Kobo\    →   (n'importe quelle   →   juxjux.ovh/56ifciz  →   de la liseuse
                           machine du maillage)     (port 80)                → bibliothèque

Aucun DNS ni certificat n'a été créé — la location est greffée sur un vhost déjà en place.

Élément Valeur
URL liseuse juxjux.ovh/56ifciz (HTTP, pas HTTPS)
Dossier VPS /home/debian/Documents/Kobo/
Équivalent Windows D:\Syncthing\Kobo\
Propriétaire debian:debian (Syncthing tourne sous cet utilisateur)
Vhost modifié /etc/nginx/sites-available/juxjux.ovh
Sauvegarde /etc/nginx/sites-available/juxjux.ovh.bak-260813

Mode d'emploi

Déposer un livre : le glisser dans D:\Syncthing\Kobo\ depuis n'importe quelle machine du maillage. Syncthing le pousse au VPS, il apparaît dans la page — aucune autre manipulation.

Le récupérer sur la liseuse : Menu → Plus → Navigateur bêta → taper juxjux.ovh/56ifciz → toucher le lien de l'epub. Téléchargement, puis ajout automatique à la bibliothèque.

4. Les quatre pièges, et leur correctif

Ce sont les points à ne pas défaire par inadvertance.

4.1 HTTPLe volontairechemin doit exister dans les deux blocs — nela pasliseuse « corriger » enforce HTTPS

LeC'est le point qui a demandé une correction après coup, et l'hypothèse de départ était fausse.

Hypothèse initiale (erronée) : le navigateur de l'Aura Edition 2 estétant un WebKit ancien.ancien, Deuxon risquesa cumuléssupposé enqu'il HTTPSéchouerait :

sur
    la ses versionsconfig TLS peuventactuelle être— antérieuressoit àpar ceune qu'accepteversion nginxTLS trop vieille (options-ssl-nginx.conf impose TLS 1.2+), sonsoit par un magasin de racines peut ignorerignorant la chaîne Let's Encrypt actuelle(ISRG Root X2 → ISRG Root X1). La location n'a donc d'abord été posée que dans le bloc listen 80, en HTTP volontaire.

    Ce que l'appareil a montré : le navigateur bêta force HTTPS. Avec la location absente du bloc 443, il tombait sur un 404. Et le magasin de racines de la liseuse connaît parfaitement ISRG Root X1 — le TLS n'a jamais été le problème.

    Correctif appliqué le 2026-08-13 à 14:49 : la location /56ifciz/ a été dupliquée à l'identique dans le bloc listen 443 ssl, le bloc listen 80 étant conservé pour la robustesse. Les deux serépondent soldentaujourd'hui par un échec sec, indiagnosticable depuis la liseuse200. En HTTP, ces deux risques disparaissent.

    https://juxjux.ovh/56ifciz/Aucun renvoieassouplissement 404TLS n'a été nécessaire ni appliqué — c'estpas attendude etTLS voulu,1.0/1.1 réactivé, pas de ciphers CBC hérités. Ne pas en ajouter « au cas où » : ce serait dégrader la locationsécurité de tout le domaine pour un problème qui n'existe que sur le port 80.pas.

    Sauvegarde avant cet ajout : /etc/nginx/sites-available/juxjux.ovh.bak-260813-https

    Contrepartie : la liseuse passant par 443, le chemin et les fichiers ne circulent plus forcément en clair.clair. Mais le bloc HTTP reste ouvert, et surtout le seul rempart demeure l'obscurité de l'URL (§ 7). Ne rien déposer de sensible dans ce dossier.

    4.2 La redirection 80 → 443 devait être restructurée

    Le vhost portait la redirection sous cette forme, posée par Certbot :

    if ($host = juxjux.ovh) { return 301 https://$host$request_uri; }

    Écrit au niveau serveur, ce if s'évalue en phase rewrite — c'est-à-dire avant le choix de la location. Il est donc impossible d'y soustraire un chemin : /56ifciz/ partait en redirection HTTPS comme tout le reste.

    Correctif : remplacer le if par un location / explicite. Une location plus spécifique (/56ifciz/) l'emporte alors naturellement.

    location / {
    return 301 https://$host$request_uri;
}

    4.3 nginx ne connaît pas le type MIME epub

    /etc/nginx/mime.types ne contient ni epub, ni mobi, ni azw. Sans déclaration, le fichier est servi en text/plain et la liseuse l'affiche au lieu de le télécharger.

    Piège dans le piège : un bloc types { } placé dans une location remplace intégralement la table MIME pour cette location — il ne s'y ajoute pas. Tout type utile doit donc y figurer, d'où le default_type application/octet-stream en filet de sécurité.

    4.4 Permissions — Syncthing dépose parfois en 640

    www-data doit pouvoir lire les fichiers déposés. Or Syncthing crée parfois des fichiers en 640, ce qui produirait un 403 silencieux.

    Correctif — une ACL par défaut sur le dossier, qui force la lisibilité des fichiers à venir :

    setfacl -m  o::rx /home/debian/Documents/Kobo
setfacl -d -m o::r  /home/debian/Documents/Kobo
setfacl -d -m u::rw /home/debian/Documents/Kobo
setfacl -d -m g::r  /home/debian/Documents/Kobo

    Attention : si le dossier est créé avec sudo, il appartient à root et Syncthing ne peut plus y écrire. Vérifier chown -R debian:debian après création.

    5. Configuration nginx appliquée

    Bloc port 80 du fichierFichier /etc/nginx/sites-available/juxjux.ovh. Le bloc location /56ifciz/ est identique dans les deux server — c'est délibéré (§ 4.1) : la liseuse force HTTPS, le port 80 est conservé pour la robustesse.

    server {
    listen 80;
    server_name juxjux.ovh www.juxjux.ovh;

    root /var/www/juxjux.ovh/html;
    index index.html index.htm;

    # --- Acces liseuse Kobo Aura Edition 2 (ajout 2026-08-13)13, volet HTTPS)
    # HTTP volontaire :Duplique le navigateurlocation dedu labloc :80. La liseuse estimpose tropHTTPS ancien-> pource lachemin
    # configdoit TLSexister actuelleaussi (TLSen 1.2+ / racine Let's Encrypt).443. Ne rien mettre # de sensible dans /home/debian/Documents/Kobo.
    location /56ifciz/ {
        alias /home/debian/Documents/Kobo/;
        autoindex on;
        autoindex_exact_size off;
        autoindex_localtime on;
        charset utf-8;
        add_header X-Robots-Tag "noindex, nofollow" always;

        types {
            application/epub+zip            epub;
            application/pdf                 pdf;
            application/x-mobipocket-ebook  mobi;
            application/vnd.amazon.ebook    azw3;
            application/vnd.comicbook+zip   cbz;
            text/plain                      txt;
        }
        default_type application/octet-stream;
    }

    location / {
        try_files $uri $uri/ =404;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate     /etc/letsencrypt/live/juxjux.ovh/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/juxjux.ovh/privkey.pem;   # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;   # managed by Certbot
}

server {
    listen 80;
    server_name juxjux.ovh www.juxjux.ovh;

    # --- Acces liseuse Kobo Aura Edition 2 (ajout 2026-08-13)
    location /56ifciz/ {
        # ... bloc strictement identique a celui du server 443 ...
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

    LeEn bloccas portde 443 est inchangé (racine /var/www/juxjux.ovh/htmlmodification, certificatpenser Certbot).à reporter le changement dans les deux blocs. Une divergence entre les deux produirait un comportement dépendant du protocole, très déroutant à diagnostiquer depuis la liseuse.

    6. Vérifications de bon fonctionnement

    Depuis le VPS et depuis l'extérieur :

    # Page d'index dans les deux protocoles — les deux doivent repondre 200
for u in http https; do
  curl -s -o /dev/null -w '"$u : HTTP %{http_code}  type=%{content_type}\n'n" http:\
       $u://juxjux.ovh/56ifciz/
done

# Type MIME du fichier — doit repondre application/epub+zip
curl -s -o /dev/null -D - "http:https://juxjux.ovh/56ifciz/<fichier>.epub" | grep -iE 'HTTP/|content-type'

# La racine doit toujours rediriger en HTTPS
curl -s -o /dev/null -w 'HTTP %{http_code} -> %{redirect_url}\n' http://juxjux.ovh/

    Résultats attendus, relevés le 2026-08-1323 :

    Test Attendu Obtenu
    Index HTTP
    200 / text/html; charset=utf-8 conforme Index HTTPS 200 / text/html; charset=utf-8 conforme Epub 200 / application/epub+zip conforme Index HTTPS 404 (location absente du bloc 443) conforme Racine / en HTTP 301 vers https://juxjux.ovh/ conforme Lecture par www-data autorisée conforme

    Un 404 sur un seul des deux protocoles signifie que la location a disparu du bloc correspondant — c'est le symptôme exact de la panne corrigée le 13 août (§ 4.1).

    7. Limites et suites

    Sécurité

    La seule protection est l'obscurité du chemin. Il n'y a aucune authentification — le navigateur Kobo gère mal les invites Basic Auth, ce qui l'excluait. Un X-Robots-Tag: noindex, nofollow évite l'indexation par les moteurs.

    Le passage en HTTPS (§ 4.1) chiffre le transport, mais ne change rien à ce point : quiconque connaît l'URL accède à tout le dossier, et le bloc HTTP reste ouvert.

    Conséquence pratique : ce dossier est à considérer comme public. Y déposer uniquement des livres, jamais un document personnel.

    Nommage des fichiers

    Éviter accents et espaces. L'autoindex les encode correctement (%20), mais le navigateur de la liseuse est capricieux sur les URL encodées.

    À faire — tester le câble USB

    Le contournement fonctionne, mais la panne USB reste non élucidée. Dans l'ordre :

    1. Tester un autre câble dont on sait qu'il transporte des données (celui d'un disque externe ou d'un téléphone déjà utilisé en transfert)
    2. Inspecter et nettoyer le port de la liseuse à la lampe, appareil éteint, avec un cure-dent en bois — jamais en force
    3. Laisser une heure sur chargeur secteur (pas le PC) avant de retenter
    4. Reset matériel : bouton d'alimentation maintenu 30 secondes
    5. Croiser les variables : ce câble sur un autre appareil, cette liseuse sur un autre PC

    Si l'USB revient, basculer sur le Kobo Sync de Calibre-web — synchronisation native, bidirectionnelle, avec suivi de la position de lecture. Nettement supérieur à cette page. Il ne faut l'USB qu'une seule fois, pour écrire api_endpoint dans .kobo/Kobo/Kobo eReader.conf.

    Voir aussi

    • CLAUDE.md — section « Liseuse Kobo Aura Edition 2 — dépôt epub par le navigateur »
    • Page 249 — stabilité du PC Windows (même chapitre, dépannages)
    Back to top