Lorsqu'un outil d'IA génère du contenu, traite un ensemble de données ou exécute une tâche autonome, l'utilisateur a besoin d'une issue de secours claire. Trop d'interfaces traitent l'arrêt d'urgence comme une réflexion après coup. Elles se contentent de changer l'étiquette d'un bouton de « Stop » à « Stopped » et considèrent que le travail est fait. La couleur peut devenir grise. L'animation peut paraître fluide. Pourtant, la tâche continue de s'exécuter sur le serveur, et l'utilisateur n'a aucune idée que quelque chose ne va pas. Pour une personne utilisant un lecteur d'écran, l'échec est encore plus grave. Elle entend une confirmation audio indiquant que le processus est terminé, alors que le travail continue silencieusement en arrière-plan. Ce n'est pas un bug mineur. C'est une rupture de confiance.

Le mensonge d'un bouton d'arrêt silencieux

Un mauvais bouton d'arrêt ment à vos utilisateurs. Il affiche le mot « Stopped » alors que la tâche continue de s'exécuter quelque part dans un conteneur ou sur un worker distant. Cela arrive parce que les développeurs front-end effectuent souvent des mises à jour optimistes de l'interface avant que le serveur ne confirme l'arrêt. Un utilisateur visuel pourrait remarquer l'incohérence si une barre de progression continue de bouger ou si un journal continue de défiler, mais un utilisateur de lecteur d'écran ne dispose pas d'un tel canal secondaire. Il dépend entièrement de ce que l'interface annonce. Si le texte du bouton change prématurément et qu'aucun retour audio ne clarifie l'état réel, l'utilisateur croit que l'urgence est passée alors que ce n'est pas le cas. Ici, l'accessibilité n'est pas une simple demande de fonctionnalité. C'est une exigence de sécurité.

Deux états distincts

Un véritable contrôle d'urgence doit gérer deux responsabilités distinctes. Premièrement, le système accepte votre requête. Deuxièmement, le système révoque l'autorité. Ce n'est pas la même chose. L'acceptation signifie que le front-end vous a entendu et a transmis le message. La révocation signifie que le back-end a réellement terminé le processus. En raison de la latence réseau, des files d'attente de tâches et des couches d'orchestration, l'écart entre ces deux moments peut durer plusieurs secondes. Pendant cette fenêtre, votre interface doit dire la vérité sur l'étape où vous vous trouvez. Fusionner ces deux étapes en un seul instant suppose une infrastructure qui n'existe pas. Vos utilisateurs en paieront le prix à cause de cet optimisme.

Mapper les quatre états à votre interface

Construisez votre UI autour de quatre états explicites afin que les utilisateurs sachent toujours où ils en sont.

  • En cours (Running) : Affichez un bouton clairement étiqueté « Arrêter la tâche ». Gardez-le visible en tout temps. Ne l'enterrez pas sous des onglets ou des panneaux accordéons.
  • Requête en cours (Requesting) : Désactivez le bouton pour que l'utilisateur ne puisse pas envoyer des requêtes supplémentaires en boucle. Affichez un message « Arrêt demandé ». Cette honnêteté est importante. Elle indique à l'utilisateur que sa commande est en cours d'acheminement et que le système n'a pas encore confirmé la fin de l'opération.
  • Arrêté (Stopped) : Désactivez le bouton. Affichez un ID de reçu. Cela donne à l'utilisateur la preuve que le serveur a répondu et que l'arrêt a été enregistré. Cela transforme une simple affirmation en un enregistrement.
  • Échec (Failed) : Activez un bouton « Réessayer l'arrêt ». Affichez un message d'échec spécifique. Ne laissez jamais l'utilisateur dans un vide silencieux. Si le serveur a expiré ou a renvoyé une erreur, dites-le.

Ces états doivent piloter le retour visuel et auditif. Lorsque l'état change, les lecteurs d'écran doivent annoncer le nouveau libellé et le statut via une région live (live region) correctement gérée. Un bouton désactivé combiné à une annonce textuelle empêche la confusion sur l'activité du contrôle.

Des règles de conception qui résistent à la pression

Les commandes d'urgence portent une charge de conception différente des boutons ordinaires. Les utilisateurs peuvent être anxieux, pressés ou réagir à un résultat inattendu. Votre interface doit rester utilisable dans ce stress.

N'utilisez pas la couleur comme seul signal. Un bouton passant du rouge au vert aide certains utilisateurs voyants, mais les utilisateurs daltoniens et ceux utilisant un lecteur d'écran ont besoin de changements textuels et structurels. Associez la couleur à des libellés explicites, l'iconographie à des alternatives textuelles et des annonces d'état.

Ne cachez pas les commandes dans des menus au survol. Personne ne devrait chercher dans un menu déroulant lors d'une urgence. Le bouton d'arrêt doit se trouver dans le viewport principal, toujours accessible sans une chorégraphie précise du curseur.

Rendez les boutons faciles à cliquer avec un pointeur. Le stress réduit le contrôle moteur fin. Utilisez un espacement (padding) généreux et une large zone de clic. Si l'utilisateur tremble ou utilise un pavé tactile dans un train en mouvement, il doit toujours pouvoir réussir son clic.

Assurez-vous que les utilisateurs au clavier puissent atteindre le bouton rapidement. L'ordre de tabulation ne doit pas forcer quelqu'un à parcourir trente éléments focalisables avant d'atteindre la commande d'urgence. Envisagez un lien d'évitement (skip link) ou un placement logique du focus qui place l'action d'arrêt à portée de main immédiate.

Évitez les raccourcis clavier accidentels. Les raccourcis globaux qui interrompent un processus doivent utiliser des combinaisons difficiles à déclencher par erreur. Si un raccourci courant de sauvegarde ou d'impression chevauche votre commande d'arrêt, quelqu'un l'activera accidentellement et perdra son travail.

N'utilisez pas de confirmation en plusieurs étapes pour les urgences. Une boîte de dialogue de confirmation est un mur, pas un garde-fou. Le temps que l'utilisateur lise « Êtes-vous sûr ? » et clique à nouveau, le résultat indésirable a peut-être déjà été envoyé. Une seule action décisive devrait suffire.

Reçus, perte de réseau et limites de transparence

Un identifiant de reçu prouve que le serveur a répondu. Il ne prouve pas que tous les effets en aval ont été annulés. Votre tâche d'IA a pu déclencher des API externes, des écritures de fichiers ou des files d'attente de messages au moment où la commande d'arrêt est arrivée. L'arrêt de l'orchestrateur ne garantit pas que chaque processus enfant s'est interrompu instantanément. Soyez honnête sur cette limitation dans vos messages et votre documentation.

Vous devez également concevoir pour des modes de défaillance qui se situent en dehors de votre salle de serveurs. Testez ce qui se passe lorsque l'utilisateur perd la connectivité réseau juste après avoir cliqué sur arrêt. Testez ce qui se passe lorsque la réponse prend dix secondes au lieu de cent millisecondes. Si la requête est bloquée, votre interface doit expirer vers un état d'échec plutôt que de rester bloquée sur « En cours de requête » indéfiniment. Les utilisateurs méritent de savoir quand la connexion est coupée.

Tester avec sérieux

La vérification ne peut pas être une réflexion après coup. Soumettez votre interface aux conditions réelles rencontrées quotidiennement par les utilisateurs en situation de handicap.

Navigation au clavier uniquement. Débranchez votre souris. Naviguez avec la touche Tab à travers chaque état. Assurez-vous de pouvoir atteindre le bouton d'arrêt depuis n'importe quel point du flux de travail sans piéger le focus ou créer des arrêts de tabulation invisibles.

Zoom du navigateur à 200 %. Agrandissez la page. Vérifiez si le bouton d'arrêt se réorganise ou disparaît. Les utilisateurs malvoyants comptent sur le zoom, et l'effondrement de la mise en page cache souvent des commandes critiques.

Paramètres de mouvement réduit. Votre état « En cours de requête » peut utiliser une animation pulsée ou un indicateur de chargement rotatif. Respectez prefers-reduced-motion. Fournissez des indicateurs visuels statiques en complément de tout mouvement afin que les utilisateurs qui désactivent les animations reçoivent tout de même un retour d'état clair.

Ordre d'annonce du lecteur d'écran. Utilisez une région live pour diffuser les changements d'état, mais testez la séquence avec soin. L'ordre des annonces doit correspondre à la progression logique des événements. Si le bouton se désactive avant que le lecteur d'écran ne dise « Arrêt demandé », testez si cette séquence crée de la confusion. De petits bugs de synchronisation dans les technologies d'assistance peuvent brouiller le message ; vérifiez donc avec un véritable lecteur d'écran plutôt que de supposer que le balisage seul suffira.

L'essentiel à retenir

Concevoir un arrêt d'urgence accessible signifie respecter suffisamment vos utilisateurs pour leur dire la vérité. L'interface doit s'exprimer clairement, se déplacer de manière prévisible et ne jamais prétendre qu'une requête est identique à un résultat. Lorsque la pression est forte et que les données sont en péril, la clarté sauve plus que du temps. Elle sauve la confiance. Un bouton d'arrêt honnête ne se contente pas d'interrompre une tâche. Il prouve que votre produit est, avant tout, sûr à utiliser.