## Le jeu ne me doit pas la solution
Je place Dark Souls 3 au-dessus de FFXIV, et je ne vais toujours pas débattre. Ce qui m’intéresse ici n’est pourtant pas son classement, ni même seulement sa difficulté.
Dark Souls 3 ne cherche pas constamment à m’expliquer quoi faire. Il me laisse observer, essayer et échouer. Le jeu peut refuser de me donner la solution sans pour autant rester silencieux sur ce qui vient de se passer.
Quand une action part, elle produit une réponse. Une animation se déclenche. Un son confirme un contact. Une barre évolue. Mon personnage se retrouve dans un nouvel état. Je ne sais pas forcément si mon choix était bon, mais je sais qu’il a bien été pris en compte.
Cette différence me paraît importante : ne pas expliquer n’est pas la même chose que ne pas répondre.
Le jeu conserve sa difficulté parce qu’il ne transforme pas chaque erreur en conseil. Il ne m’affiche pas une documentation après chaque coup raté. En revanche, il me donne assez de signaux pour construire moi-même une compréhension.
## Une interface n’a pas les mêmes excuses
Dans un logiciel, le silence produit rarement ce genre d’apprentissage.
Si je clique sur un bouton de sauvegarde dans l’admin de mon portfolio et que rien ne change, je ne suis pas face à une difficulté intéressante. Je me demande simplement si le clic a fonctionné, si la requête est partie ou si je dois recommencer.
Le problème est encore plus visible avec les opérations qui ne sont pas instantanées. Mon portfolio gère notamment de la validation, de l’authentification et des uploads. Entre l’action dans le navigateur et la réponse du serveur, plusieurs états existent réellement :
- l’action n’a pas encore commencé ;
- elle est en cours ;
- elle a réussi ;
- elle a échoué d’une manière attendue ;
- elle a cassé d’une manière que l’interface ne sait pas expliquer précisément.
Masquer ces états ne simplifie pas l’interface. Cela déplace seulement leur interprétation vers l’utilisateur.
React rend d’ailleurs cet état d’attente explicite avec le booléen isPending retourné par `useActionState`. La primitive ne décide pas du message, de sa position ou de son importance. Elle évite simplement de traiter l’attente comme un vide entre deux rendus.
C’est là que je retrouve Dark Souls 3. Le jeu ne me promet pas de m’expliquer mon erreur. Il me confirme quand même que le système a réagi. Dans mon admin, je dois au minimum faire pareil. La différence est que je peux souvent aller plus loin et indiquer ce que l’utilisateur peut corriger.
## Confirmer avant d’expliquer
J’ai tendance à regrouper tous les retours sous le même mot : feedback. En pratique, ils ne répondent pas à la même question.
Le premier retour dit : « ton action a été reçue ».
Le deuxième dit : « voici son résultat ».
Le troisième peut dire : « voici ce que tu peux modifier ».
Si le premier manque, les deux autres arrivent déjà trop tard. Un message d’erreur très précis après plusieurs secondes de silence laisse quand même le doute s’installer. À l’inverse, un état d’attente immédiat ne remplace pas le résultat final.
Le W3C recommande d’indiquer clairement et rapidement le succès ou l’échec d’une action. Il distingue aussi les simples messages de statut des alertes plus importantes dans ses explications sur les changements d’état. Cette distinction m’évite une autre erreur : rendre chaque réponse aussi bruyante qu’un échec critique.
Tout ne mérite pas une modale. Tout ne mérite même pas une alerte. Une sauvegarde réussie peut rester discrète. Une validation refusée doit être visible près de ce qui peut être corrigé. Une erreur inconnue doit au moins dire que l’état attendu n’a pas été obtenu.
Dark Souls 3 garde une partie de ses règles dans l’ombre, mais ses signaux ont un poids différent. Mon logiciel doit lui aussi hiérarchiser ses réponses, sans utiliser le mystère comme excuse.
## Ce que je vais vérifier dans mon admin
Mon prochain passage dans l’admin du portfolio ne commencera pas par une nouvelle fonctionnalité. Je vais reprendre ses actions principales, notamment la sauvegarde et l’upload, et noter pour chacune les quatre états visibles : repos, attente, succès et erreur.
Je veux surtout repérer les moments où le serveur travaille pendant que l’écran ne dit rien. C’est ce silence-là que je vais retirer. La difficulté peut rester dans ce que l’outil permet de faire, pas dans la question de savoir s’il a entendu le clic.