Hiérarchie des erreurs et mise en évidence des priorités

1) Pourquoi une hiérarchie des erreurs est nécessaire

• expliquer ce qui a mal tourné,
• montrer pourquoi c'est important,
• dire quoi faire ensuite,
• hiérarchiser si les erreurs sont multiples.
• La hiérarchie des erreurs réduit la charge cognitive, accélère la correction et augmente la conversion des étapes (inscription, paiements, KYC).

2) Modèle des niveaux de criticité (Severity)

1. Info (information) - « Le profil est incomplet, vous pouvez le remplir plus tard ». Ne bloque pas.

2. Avis (attention) - « La limite est presque épuisée ». Nous vous recommandons d'agir.

3. Warning (avertissement) - « Décalage de format, données enregistrées partiellement ». Ça pourrait te gêner.

4. Error (erreur) - « Format incorrect/champ obligatoire vide ». Bloque une action spécifique.

5. Critique (critique) - « Paiement refusé/risque de sécurité ». Bloque le script, nécessite une étape immédiate.

• Un écran - un statut principal.
• En cas d'erreurs multiples : nous montrons le critique en haut et nous passons régulièrement à la première erreur.

3) Principes de mise en évidence des priorités

1. Hiérarchie visuelle : couleur/icône/épaisseur/contraste augmente avec la critique.
2. Proximité spatiale : erreur près du champ/zone à laquelle elle appartient.
3. Focus et défilement : auto-scroll à la première erreur + focus dans le champ problématique.
4. Un callout principal : une bannière/alerte commune sur un problème critique + des indices locaux.
5. Séquence de tokens : les couleurs/icônes/polices pour Info/Warning/Error sont inchangées dans tout le produit.
6. Durée de vie : erreurs locales - pas encore corrigées ; bannières - avant fermeture/correction.
7. Ne confondons pas les états : « vide » ≠ « erreur », « en attente » ≠ « erreur ».

4) Langage visuel (tokens UI)

• Info - neutre bleu/gris,
• Notification - ambre/jaune,
• Warning - orange,
• Error est rouge,
• Critical est un fond rouge + contraste saturé.
• Icônes : info ⓘ, notice, error/, success.

• Message inline sous le champ (cadre minimum).
• Row-callout par ligne/carte.
• Page-alert (bannière) - pour général/critique.
• Microanimations : apparence douce, pas de mise en page « derganya ».

5) Textes d'erreur : formule et exemples

Formule : Ce qui ne va pas + Comment corriger + (Pourquoi/restriction).

Format de date incorrect. Entrez au format DD. MM. GGG"

Le fichier est trop grand (10 Mo maximum). Téléchargez un fichier plus petit

"Niveau de vérification insuffisant. Passez KYC - cela prendra ~ 2 minutes"

Le paiement a été refusé par la banque. Essayez une autre méthode ou contactez votre banque"

« Erreur 400 », « Quelque chose s'est mal passé », l'humour est stressant.

6) Hiérarchie sous formes complexes (inscription/CUS/paiements)

1. Inline-validation sur blur : nous attrapons les erreurs locales immédiatement.
2. Vérification globale sur submit : nous montrons la bannière « Corriger les champs marqués » et la liste/ancre.
3. Navigation par erreur : clavier/tabulation, « Aller à erreur # 1/# N ».
4. Ordre de correction : d'abord bloquant (Error/Critical), puis Warning/Notice.
5. Enregistrement du contexte : les données saisies ne sont pas perdues en cas d'erreur.

7) Spécificité des scénarios

7. 1 Paiements/conclusions

Critique : rejet par le fournisseur/la banque, activité suspecte.
Error : champ carte/IBAN, limites de somme/fréquence.
Warning : réseau lent/dépassement du temps d'attente.

Texte : "Paiement refusé par la banque. Essayez une autre méthode ou contactez votre banque. La Commission n'a pas été annulée"

7. 2 CUS/sécurité

Critique : document falsifié/pays bloqué/compte multiple.
Erreur : document illisible/non-correspondance de date.

Texte : "La photo du document est floue. Téléchargez une image plus claire sous une bonne lumière"

7. 3 Recherche/filtres

Ce n'est pas une erreur, c'est un résultat nul.

Texte : "Aucun résultat pour "{query}". Supprimez le filtre Fournisseur : X ou essayez {alt}. [Réinitialiser les filtres]"

8) Disponibilité (A11y) et exigences techniques

Les erreurs sont déclarées au crieur : aria-live = « assertive » pour les critiques, « polite » pour les autres.
Champs avec erreur : aria-invalid = » true », aria-describedby par message.
Le focus est porté à la première erreur ; l'ordre de tabulation conserve la logique.
Contraste selon WCAG AA ; l'icône ne remplace pas le texte.
Le texte doit être lu à haute voix sans perte de sens.

9) Localisation et précision juridique

Évitez le jargon et les métaphores culturelles.
Harmoniser les termes (glossaire) : « paiement refusé », « limite dépassée », « vérification ».
Spécifiez les dates et limites dans le format local : « jusqu'à 15 minutes », devise/date.

10) Métriques de qualité

Taux d'erreur par champ/étape (proportion d'utilisateurs confrontés à une erreur).
Time-to-Fix (temps moyen avant la correction de la première erreur).
Drop-off après une erreur (combien partent sans corriger).
Répétabilité des erreurs (recurrence) par utilisateur/session.
Demandes de support par type d'erreur.
Convertir l'étape avant/après les changements dans la hiérarchie.

• Auto-scroll et focus vs seulement couleur/texte.
• La formulation exacte de la cause vs est générale.
• Ordre de surbrillance (d'abord bannière → inline) vs (inline seulement).
• Ajouter le lien « Afficher les exigences » en regard de l'erreur.

11) Chèque-liste avant la sortie

• Chaque erreur a un niveau (Info/Notice/Warning/Error/Critical).
• Couleur/icône/conteneur correspondent au niveau.
• Il y a un défilement vers la première erreur et un transfert de mise au point.
• Le message explique quoi/comment/pourquoi.
• Les termes correspondent au glossaire ; localisation vérifiée.
• Disponibilité : attributs aria, contraste, lisibilité à haute voix.
• Les données ne sont pas perdues en cas d'erreur.
• Les statuts « résultat zéro » et « attente » ne sont pas présentés comme des erreurs.

12) Exemples « avant/après »

Formulaire de date

Avant : « Erreur 400 »

Après : "Format de date incorrect. Utilisez le DD. MM. GGG"

Paiement

Avant : « Le paiement n'est pas passé »

Après : "Paiement refusé par la banque. Essayez une autre méthode ou contactez votre banque. La Commission n'a pas été annulée"

KYC

Avant : « Document non accepté »

Après : "Impossible de reconnaître le document. Téléchargez la photo sans éblouissement, les coins et le texte sont visibles"

Recherche nulle (pas une erreur !)

Avant : « Erreur : Rien trouvé »

Après : "Il n'y a pas de résultats sur "roulette vivante". Enlevez le filtre « High-limit » ou essayez « roulette ». [Réinitialiser les filtres]"

13) Composants du système de conception

``

Пропсы: `message`, `severity`, `ariaDescribedBy`, `compact`.
Rendu : texte + icône, couleur par 'severity'.

``

Пропсы: `title`, `description`, `severity`, `actions[]`.
Options : 'info | notice | warning | error | critical'.

``

Liste des erreurs avec ancres aux champs, navigation clavier, « Aller au # 1 ».

'' (logique)

Règles par champ/formulaire/étape, priorités, schémas (par exemple JSON-Schema), localisation des messages.

14) Modèles rapides de phrases

15) Incorporation dans le processus

Concevez des textes en même temps que la logique de validation.
Gardez les lignes dans i18n à côté des composants, versez.
Dans la chèque PR : conformité au niveau, présence d'attributs aria, localisation correcte.
Je rummage régulièrement des erreurs sur les métriques et les commentaires de support.

Trempe finale

Numériser les niveaux : Info → Critique.
Montrez la priorité visuellement et en focus.
Expliquez la correction brièvement et précisément.
N'appelez pas le vide une erreur.
Mesurez et améliorez : taux d'erreur, Time-to-Fix, drop-off.