Traitement des erreurs et explication UX

1) Pourquoi est-ce important

• explique ce qui s'est passé et ce qu'il faut faire ensuite,
• conserve les données saisies et évite la perte de progrès,
• donne une répétition sûre ou une voie alternative,
• reste disponible (SR/clavier) et ne révèle aucun superflu.

2) Typologie des erreurs (pour l'interface)

1. Validation des données (4xx client) : champs vides/incorrects, format, longueur, conflit de règles.
2. Règles d'affaires : limites, géo-restrictions, KYC/KYB, prises, fentes inaccessibles.
3. Droits/permissions : rôle, accès à la ressource, limites d'âge.
4. Réseau/serveur : temporisation, hors ligne, 5xx, surcharge, rate limit.
5. Conflits/état : 409/412 (données changées), courses, blocages.
6. Manque de ressource : 404/410, supprimé/déplacé.
7. Paiement et risque : rejet par la banque/PSP, antifrod, limites du jeu responsable.

3) Canaux et niveau d'affichage

Règle : ne cachez pas le critique dans les toasts/hover. Là où l'utilisateur regarde, c'est le message.

4) Copie des erreurs

Structure : cause → conséquence → action.
Ton : Honnête, neutre, sans culpabilité.
Spécificité : spécifier le champ/condition, éviter les codes et les piles.
Bouton-action : Répéter, Modifier la carte, Réinitialiser les filtres, Ouvrir le chat.
Données sensibles : ne pas afficher (masque PAN, attributs personnels).

Exemples

Bon : "Le paiement n'est pas passé : la banque a rejeté la transaction. Essayez une autre méthode ou répétez-la plus tard".
Mauvais : "Erreur 500. Quelque chose a mal tourné".
Ok : "La limite des dépenses journalières est atteinte. Fixez une nouvelle limite ou essayez demain".
Bon : "Le fichier est trop grand (25 Mo maximum). Compressez ou téléchargez plusieurs fichiers.

5) Comportement et focus (A11y)

L'erreur est mise en contexte focal : nous traduisons le focus au premier champ erroné.
Régions vivantes : 'role = « status » (polite) pour info,' role = « alert » (assertive) pour critique.
Visible ': focus-visible', contraste ≥ AA, alternatives à la couleur (icône/texte).
Le message est lié au champ via 'aria-describedby'.

html
<label for = "pwd "> Password </label>
<input id="pwd" name="password" aria-describedby="pwd-err" aria-invalid="true">
<p id = "pwd-err" role = "alert"> Minimum 8 characters </p>

6) Retrai, backoff et idempotence

Une répétition est proposée s'il y a une chance de succès (pannes réseau, 5xx, rate limit).
Backoff exponentiel 1-2-4-8 s, limite de tentative, bouton « Refaire » compréhensible.
Transactions critiques (taux/paiements) : Idempotency-Key obligatoire → excluant les prises.
Les retours des mises à jour optimistes sont un retour visuel clair + une explication.

js async function retry(fn, attempts=3){
let wait=1000; for(let i=0; i<attempts; i++){
try{ return await fn(); }catch(e){ if(i===attempts-1) throw e; await new Promise(r=>setTimeout(r,wait)); wait=2; }
}
}

7) Hors ligne, temporisation et contenu partiel

Hors ligne : nous affichons la bannière « Pas de connexion », l'accès à la cache (read-only), la file d'attente de synchronisation.
Timaouts : Timaout UI (3-5 s) → état « En attente de confirmation »... avec répétition/annulation sécurisée.
Succès partiel : nous gardons ce qui a réussi ; on marque « non synchronisé ».

8) Conflits et concurrence

409/412 : les données sont dépassées. Suggérer « Mettre à jour » et montrer le diff (ce qui a changé).
Verrous : nous informons qui tient le bloc, et combien de temps, bouton « Demander l'accès ».

9) Modèles d'UI échantillons

html
<div class="banner banner--error" role="alert">
<strong> Connection failed. </strong> Shows cached data.
<button class =" btn btn--ghost" id = "retry "> Retry </button>
</div>

html
<div role="alertdialog" aria-labelledby="err-title" aria-describedby="err-desc">
<h2 id = "err-title "> Session expired </h2>
<p id = "err-desc "> Sign in again to continue. </p>
<button class = "btn "> Sign in </button>
<button class =" btn btn--ghost"> Home </button>
</div>

tsx function Fallback({ id, onRetry }: { id: string; onRetry: ()=>void }) {
return (
<div role="alert" className="banner banner--error">
<strong> We couldn't load the page. </strong>
<div> Try again. Код: <code>{id}</code> <button onClick={()=>navigator. clipboard. writeText (id)}> Copy </button> </div>
<button onClick = {onRetry}> Retry </button>
</div>
);
}

10) Jetons d'erreur (système de conception)

json
{
"error": {
"tones": { "danger": "#", "warning": "#", "info": "#" },
"aria": { "polite": true, "assertive": true },
"timing": { "toastMs": 3500, "retryBackoffMs": [1000,2000,4000] },
"layout": { "fieldGap": 8, "bannerIcon": 20 }
}
}

css
.banner--error { background: var(--bg-danger); color: var(--on-danger); padding: 12px 16px; border-radius: 12px; }
.field-error { color: var(--role-danger); margin-top: 6px; font-size:.875rem; }

11) Sécurité et vie privée

Ne sortons pas les piles, les identifiants internes, les chemins OBD.
Nous masquons les valeurs sensibles (cartes, documents).
Les messages ne doivent pas dire à un intrus (par exemple, qu'un compte existe).
Pour le support - ID de corrélation au lieu des pièces.

json
{"level":"error","event":"payment_fail","correlation_id":"c-8f1...","user_id":"u-","route":"/pay","psp_code":"DO_NOT_EXPOSE_TO_USER"}

12) Métriques et contrôles

INP et la fraction Long Tasks au moment de l'erreur (l'erreur ne doit pas « accrocher » l'UI).
Taux de réussite Retry, erreurs pour 1000 actions, temps avant la restauration.
CTR sur « Aide/Chat », pourcentage de formulaires abandonnés.
Cartes thermiques : où les champs-erreurs se produisent le plus souvent.

13) Liste de vérification QA

Disponibilité

• Focus sur le premier champ erroné ; 'aria-describedby '/' aria-invalid' sont exposés.
• Messages critiques - 'role =' alert '; contraste ≥ AA.

Comportement

• Ces formulaires ne sont pas perdus en cas d'erreur.
• Il y a un 'Retry' compréhensible et un backoff correct.
• Le mode hors ligne/cache fonctionne ; on voit la bannière.

Copywriting

• Cause → action ; sans jargon technique et sans charges.
• Les textes sont localisés et ne cassent pas la grille.

Sécurité

• Aucune fuite de PII/secrets ; nous affichons uniquement les codes/ID sécurisés.
• L'idempotence est incluse pour les opérations critiques.

14) Spécificité de iGaming

• UI enregistre immédiatement 'busy' ; avec un retard> 3 s - « En attente de confirmation »....
• Avec fail : statut honnête (« marché fermé », « coefficient changé ») + sécurisé « Retry ».
• Clé idempotent pour éliminer le double pari.

• Nous distinguons « défaillance de la banque/PSP » vs « défaillance du serveur ». Pour le premier, « Choisir une autre méthode », pour le second, « Retry ».
• Étapes transparentes KYC/AML ; liens "Pourquoi est-ce nécessaire ? ».

• Le ton est attentionné, sans pression. Limite atteinte - Faites une pause ou mettez à jour la limite.
• Pas d'éclosions/néon ; contraste AAA, disponibilité sous SR.

• Expliquez clairement les restrictions et suggérez « Lisez les règles/support ».

15) Anti-modèles

« Quelque chose s'est mal passé » sans action et sans contexte.
Réinitialiser le formulaire après une erreur.
Cacher le critique dans un toast pendant 3 secondes.
Seule la couleur sans texte/icône.
Des retraits sans fin sans possibilité d'annulation.
Afficher les codes/piles internes.

16) Documentation dans le système de conception

Компоненты: `FieldError`, `FormError`, `PageBanner`, `AlertDialog`, `ErrorBoundary`.
Tokens de tonalité/contraste/timing, presets a11y et exemples ARIA.
Carte des scénarios types (validation, réseau, droits, paiements) avec des modèles de texte.
« Do/Don't » : écrans réels avant/après avec métriques d'échec/succès.

Résumé succinct

Rendre les erreurs compréhensibles et gérables : parlez un langage humain, conservez les données saisies, offrez une répétition et des alternatives sécurisées, respectez l'accessibilité et la vie privée. Alors même les situations anormales maintiennent la confiance et n'interrompent pas le chemin de l'utilisateur - en particulier dans les scénarios critiques de taux et de paiement.