Une requête-réponse n’est pas qu’un échange technique : elle commence et finit chez une personne. L’interface est le point où l’intention humaine devient protocole, et où la réponse du serveur redevient quelque chose de compréhensible. Cette page part de ce rôle, rappelle ce qui rend une interface utilisable, introduit la réactivité, puis montre comment la construire par blocs dans le navigateur.

1. Le rôle de l’interface dans la communication

Tout part d’une intention : l’utilisateur veut quelque chose. L’interface traduit cette intention en une interaction (un geste, une saisie), qui devient une requête. Le serveur la traite et renvoie une réponse, que l’interface transforme en un changement d’affichage. L’utilisateur évalue ce changement, ce qui reforme une intention. La boucle recommence.

2. Heuristiques et bonnes pratiques d’utilisabilité

Avant de parler de réactivité, voyons ce qui rend généralement une interface utilisable. Les heuristiques de Nielsen en donnent une liste éprouvée. Les plus utiles ici :

• Visibilité de l’état du système : l’utilisateur sait toujours ce que fait le système.
• Correspondance avec le monde réel : le vocabulaire et les concepts sont ceux de l’utilisateur, pas ceux de la machine.
• Contrôle et liberté : on peut annuler, revenir, sortir d’un état non voulu.
• Cohérence et standards : les mêmes choses se font de la même façon.
• Prévention des erreurs : mieux vaut empêcher l’erreur que la rattraper.
• Reconnaissance plutôt que rappel : les options sont visibles, on n’a pas à se souvenir.
• Esthétique et minimalisme : pas de bruit qui noie l’essentiel.

À ces heuristiques s’ajoutent les principes de Norman : les affordances (ce qu’un objet permet de faire), les signifiants (les indices qui le donnent à voir), le retour d’information, la correspondance entre commandes et effets, les contraintes qui guident, et un modèle conceptuel clair que l’utilisateur peut se forger.

3. Réactivité, transparence et contrôle

Une interface réactive reflète en continu l’état du système et les actions possibles, et garde l’utilisateur aux commandes. Trois exigences la résument.

1. Rendre visible l’état (retour d’information) : chargement, succès, erreur, hors ligne. Une action sans retour laisse l’utilisateur dans le doute.
2. Rendre lisibles les actions possibles et permises (affordances, signifiants, contraintes) : on voit ce qu’on peut faire, et ce qui est interdit ou désactivé, sans deviner.
3. Garder l’utilisateur en contrôle : pouvoir annuler, comprendre ce qui se passe, ne pas être surpris par un changement qu’on n’a pas déclenché.

Quand une de ces exigences manque, l’interface trahit l’utilisateur, qu’elle soit physique ou numérique.

• Physique. La porte de Norman : une poignée invite à tirer, mais il faut pousser. Une plaque de cuisson dont les boutons ne correspondent pas, dans l’espace, aux feux qu’ils commandent : un défaut de correspondance qui force l’essai-erreur.
• Numérique. Un envoi de formulaire sans aucun retour (a-t-il abouti ?). Un indicateur qui tourne sans fin ni progression. Un bouton désactivé qui a l’air actif. Un état caché : l’application est hors ligne, mais rien ne le dit.

Refléter l’état n’est pas un instantané pris au chargement : une interface réactive s’adapte à l’état et le suit dans le temps.

Adapter l’interface à l’état. La forme même de l’interface dépend de l’état.

• Une liste vide n’affiche pas un blanc muet, mais une invitation à agir ;

• Les actions proposées s’ajustent de la même façon : un bouton n’apparaît que si l’action est permise, et se désactive sinon.
• L’interface se reconfigure selon l’état, et selon le contexte (taille d’écran, droits, capacités), au lieu d’être un gabarit figé.

Mettre à jour en continu (temps réel). L’état ne change pas qu’à l’initiative de l’utilisateur : le temps passe, le serveur pousse une donnée, un autre usager agit. L’interface doit continuer de refléter l’état sans qu’on la rafraîchisse à la main.

4. Sur le web : réactivité et composition par blocs

Le navigateur nous expose des outils, le DOM, les événements et la liaison de données, avec lesquels nous construisons des interfaces réactives sous forme de pages web. On structure alors l’interface en blocs (des composants), chacun avec un rôle, un sous-état, des entrées et des sorties. Les blocs communiquent par l’état partagé et par des événements, jamais en lisant le contenu des autres.

5. Méthodologie : construire une interface par étapes

On ne dessine pas une interface d’un seul trait. On procède par blocs et par état. Prenons un panneau de signalement d’arrivée d’autobus pour un arrêt : choisir un arrêt, signaler une arrivée, et rechercher les signalements d’une ligne.

Étape 1 : identifier les blocs, leurs rôles et le sous-état

L’état partagé se réduit à deux pièces centrales : arretSelectionne et signalements. La ligne cherchée est une petite donnée propre au bloc de recherche. Le reste (la liste filtrée, le nombre d’actifs) s’en dérive, sans être stocké à part.

Étape 2 : identifier les mécanismes d’interaction et la paramétrisation

Chaque bloc se décrit par ses entrées (ce qu’on lui passe) et ses sorties (ce qu’il émet).

Étape 3 : composer jusqu’à l’interface complète

Un composant parent détient l’état partagé, distribue les données filtrées et reçoit les événements pour mettre à jour l’état. Toutes les vues se redessinent.

function Panneau() {
  const [arret, setArret] = useState("a1");
  const [signalements, setSignalements] = useState([]);

  const visibles = signalements.filter((s) => s.arretId === arret);

  return (
    <>
      <SelecteurArret valeur={arret} onChoisir={setArret} />
      <SignalementsRecents items={visibles} />
      <FormulaireSignalement
        arret={arret}
        onSignaler={(sig) => setSignalements((prev) => [sig, ...prev])}
      />
    </>
  );
}

Illustration du panneau composé

6. À retenir