---
id: "d54a1f20-03e6-4925-982b-923a37331749"
number: 75
title: "Écran d'appairage web : clavier numérique sur mobile alors que le code contient des lettres"
status: "qa"
priority: "medium"
sprint: null
links: [{"target":"#69","kind":"relatesTo"},{"target":"#74","kind":"relatesTo"}]
agentRefs: []
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1784277353320
updatedAt: 1784277530792
version: 2
---
## Symptôme (constaté live, téléphone)

Sur l'écran d'appairage web (`PairingScreen`), le clavier virtuel qui s'ouvre est un pavé **numérique uniquement**, alors que le code d'appairage à saisir contient des **lettres**. Impossible de saisir le code sans changer de clavier à la main.

## Cause racine (confirmée)

Le code généré côté serveur est **hexadécimal, 8 caractères, majuscules** (`0-9A-F`) :

```rust
// crates/web-server/src/lib.rs:2220
fn new_pairing_code() -> String {
    Uuid::new_v4().simple().to_string().chars().take(8)
        .collect::<String>().to_ascii_uppercase()
}
```

Or `frontend/src/features/web/PairingScreen.tsx:79` force `inputMode="numeric"` (introduit par #69 en supposant un code purement chiffré), et le placeholder `p. ex. 4821-93` (ligne 74) décrit un format qui n'existe pas.

## Attendu

- Le clavier mobile permet de saisir lettres **et** chiffres.
- Le placeholder reflète le format réel (hex 8 caractères majuscules).
- La saisie reste sans autocorrection ni capitalisation surprise ; le code étant en majuscules, la casse ne doit pas être un piège pour l'utilisateur.

## Périmètre

Frontend pur. Le format du code côté serveur n'est pas remis en cause par ce ticket.

## DoD

- Saisie possible au clavier mobile standard, lettres incluses.
- Placeholder cohérent avec `new_pairing_code()`.
- Test de non-régression sur le champ.