# 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` — 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) :

```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, et éviter la redirection supprime un point de 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 Le chemin doit exister dans les **deux** blocs — la liseuse force HTTPS

C'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 étant un WebKit ancien, on a supposé qu'il échouerait sur la config TLS actuelle — soit par une version TLS trop vieille (`options-ssl-nginx.conf` impose TLS 1.2+), soit par un magasin de racines ignorant la chaîne Let's Encrypt (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 répondent aujourd'hui `200`.

> **Aucun assouplissement TLS n'a été nécessaire ni appliqué** — pas de TLS 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 sécurité de tout le domaine pour un problème qui n'existe 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**. 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 :

```nginx
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.

```nginx
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 :

```bash
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

Fichier `/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.

```nginx
server {
    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, volet HTTPS)
    # Duplique le location du bloc :80. La liseuse impose HTTPS -> ce chemin
    # doit exister aussi en 443. Ne rien mettre de sensible dans 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;
    }
}
```

> **En cas de modification**, penser à 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 :

```bash
# 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" \
       $u://juxjux.ovh/56ifciz/
done

# Type MIME du fichier — doit repondre application/epub+zip
curl -s -o /dev/null -D - "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-23 :

| 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 |
| 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)