---
id: "c91f547f-96f0-4c9c-9fde-dbe7d2772dbc"
number: 76
title: "Appairage : la comparaison du code est sensible à la casse côté serveur"
status: "open"
priority: "low"
sprint: null
links: [{"target":"#75","kind":"relatesTo"}]
agentRefs: []
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1784277540034
updatedAt: 1784277540034
version: 1
---
## Constat

`crates/web-server/src/lib.rs:1612` compare le code d'appairage reçu au code attendu par égalité stricte :

```rust
if request.code != state.pairing_code() { … }
```

Or `new_pairing_code()` (ligne 2220) génère le code en majuscules. Un client qui envoie `3f7a9c21` au lieu de `3F7A9C21` est donc rejeté.

## Pourquoi c'est une dette et pas un bug bloquant

Le fix #75 rend l'écran web tolérant en normalisant la saisie en majuscules avant `POST /api/pair`. La tolérance vit donc **côté client** : tout autre client de l'API (curl, un futur client mobile natif, un test manuel) échouera encore sur une saisie minuscule, avec un message d'erreur qui n'explique pas pourquoi.

## Attendu

La comparaison serveur normalise la casse (et les espaces) avant égalité. La normalisation côté UI de #75 devient alors redondante mais inoffensive — pas besoin de la retirer.

## Vigilance

La comparaison doit rester en temps constant si elle l'est aujourd'hui : normaliser ne doit pas introduire de court-circuit exploitable en timing. À vérifier lors de l'implémentation.

## Périmètre

Backend pur, `crates/web-server`.