Traitement en cours : suivre une tâche longue sans relancer la demande

Un client demande un export, lance l’analyse d’un document ou fait préparer un rapport par une IA. La page affiche une animation, puis plus rien ne change. Peut-il fermer l’onglet ? Le travail continue-t-il ? Faut-il recommencer ? Une fonctionnalité peut fonctionner côté serveur tout en laissant son utilisateur dans l’incertitude.

Pour ces traitements longs, le parcours ne s’arrête pas au bouton « Lancer ». Il faut aussi concevoir l’attente, le retour et la récupération du résultat. Voici les points à inscrire dans un cahier des charges. Les situations décrites sont illustratives, sans résultat client revendiqué.

Distinguer une demande acceptée d’un travail terminé

« Votre demande a été reçue » et « Votre rapport est disponible » ne désignent pas le même événement. Cette distinction doit apparaître dans l’interface comme dans les échanges techniques.

Le code HTTP 202 Accepted indique qu’une demande a été acceptée pour traitement, sans confirmer son achèvement. Le traitement peut même ne pas avoir commencé. Ce code ne garantit pas non plus la réussite future : il faut un autre moyen de consulter la suite. Explication de HTTP 202 sur MDN.

Pour un export, évitez donc une confirmation « Export réussi » dès la mise en file d’attente. Préférez « Export demandé », puis un état confirmé lorsque le fichier est prêt. Si aucune demande n’a pu être enregistrée, dites-le également : une animation ne doit pas masquer cet échec initial.

Demandez au prestataire de montrer quel événement réel déclenche chaque message. Cette vérification simple permet de repérer les interfaces qui annoncent une réussite trop tôt.

Prévoir un suivi qui existe au-delà de l’onglet

Un modèle courant consiste à séparer le lancement du travail et la consultation de son état. Le serveur fournit une référence de suivi ; l’interface s’en sert ensuite pour obtenir les mises à jour. Le modèle « Asynchronous Request-Reply » de Microsoft décrit notamment cette organisation avec une ressource de statut consultée périodiquement. Documentation Microsoft.

Ce n’est pas une obligation de technologie. Pour le client, le besoin est plus concret : retrouver le traitement déjà lancé sans en créer un autre.

Dans un espace connecté, prévoyez une liste des demandes récentes avec leur objet, leur date et leur état. Une reconnexion ou un rechargement doit permettre de rouvrir le bon suivi. L’action « Actualiser le statut » ne doit pas être présentée comme « Relancer » si elle ne fait que consulter.

Faites aussi vérifier les droits d’accès à chaque consultation et téléchargement. Une référence de traitement ne suffit pas, à elle seule, à établir qu’une personne est autorisée à voir son contenu. Le suivi ne doit pas exposer les documents ou résultats d’un autre compte.

Afficher une progression que le système connaît vraiment

Commencez par des états compréhensibles : « En attente », « En cours », « Disponible », « Échec » et, si cette possibilité existe, « Annulé ». Ne multipliez les étapes que si elles correspondent à des informations réellement disponibles.

Une barre qui avance automatiquement jusqu’à presque 100 % donne une impression de précision sans informer sur le travail restant. Pour une génération IA dont la durée n’est pas estimable, « Analyse en cours » peut être plus honnête qu’un pourcentage calculé d’après le temps écoulé.

L’élément HTML <progress> peut représenter une progression indéterminée lorsque son attribut value est absent. Sa documentation précise aussi les possibilités de libellé accessible. Référence MDN sur progress.

Si le système connaît seulement le nombre de documents parcourus, affichez cette mesure comme telle. « Documents parcourus » ne signifie pas nécessairement « Rapport presque terminé ». Évitez une estimation de durée tant qu’elle ne repose pas sur une méthode adaptée et explicitée.

Distinguez enfin l’état du travail de celui de la connexion : « Impossible d’actualiser le suivi » n’établit pas que le traitement a échoué. Conservez la dernière information connue en la signalant comme telle.

Rendre l’attente compréhensible sans imposer une surveillance

Le message doit préciser ce que la personne peut faire : continuer dans l’application, revenir plus tard ou rester sur la page, selon le fonctionnement réel. Ne promettez pas qu’un travail continue après fermeture si cela n’a pas été testé.

Pour un rapport interne, le parcours pourrait être : lancer la préparation, consulter d’autres dossiers, puis retrouver le résultat dans une rubrique dédiée. Un email peut compléter ce suivi si prévu, mais il ne devrait pas être l’unique endroit où retrouver le document.

Les changements importants doivent aussi être perceptibles avec les technologies d’assistance. Le critère WCAG 4.1.3 vise les messages de statut pouvant être déterminés par programmation, sans déplacement du focus. Explication du W3C.

Faites tester l’annonce du résultat au lecteur d’écran, sans déplacer automatiquement la personne vers une nouvelle zone. Évitez également de répéter une annonce à chaque interrogation du serveur lorsque rien n’a changé. Une succession de messages identiques peut gêner la poursuite de la navigation.

Préparer la fin, l’échec et l’annulation

Un état « Disponible » doit mener à une action utilisable : ouvrir, télécharger ou examiner le résultat. Pour une production IA, distinguez la fin technique du traitement de la validation métier. Un texte généré n’est pas nécessairement un livrable approuvé.

Décidez aussi combien de temps le résultat reste accessible et ce qu’affiche le suivi après son expiration. Mieux vaut expliquer qu’un fichier n’est plus disponible que laisser un bouton qui aboutit systématiquement à une erreur.

Si vous proposez l’annulation, séparez « Annulation demandée » et « Annulé ». La demande peut parvenir alors que le travail approche de sa fin. Le modèle Microsoft prévoit que le traitement prenne en compte cette instruction avant de mettre à jour son état. Il faut donc définir le comportement réel, notamment si une action a déjà eu lieu.

En cas d’échec, indiquez la prochaine étape possible sans afficher de détails techniques sensibles : corriger une entrée, contacter l’équipe avec une référence, ou demander une nouvelle exécution lorsque c’est approprié. La gestion des doublons reste un sujet distinct, traité dans notre article sur les erreurs et reprises n8n.

Tester le parcours complet avant livraison

Avec des données fictives, demandez une démonstration couvrant :

• un traitement qui attend avant de commencer ;
• un rechargement et un retour après reconnexion ;
• une interruption réseau pendant la consultation ;
• une réussite, un échec et un résultat expiré ;
• une annulation demandée pendant l’exécution ;
• une tentative d’accès depuis un autre compte ;
• la navigation au clavier et l’annonce des changements importants.

Pour chaque essai, comparez le message visible avec l’état réel côté serveur. Le livrable attendu est un parcours où chacun sait ce qui est confirmé, ce qui reste incertain et quelle action est possible. Une animation d’attente, à elle seule, ne répond pas à ces questions.