Comment décider quelles tâches exécuter en arrière-plan et lesquelles nécessitent une réponse immédiate

Une tâche prend plusieurs secondes et l’équipe propose de l’exécuter en arrière-plan. La décision semble technique, mais elle commence par une question produit : la personne peut-elle poursuivre son objectif sans connaître le résultat immédiatement ? Si oui, le traitement asynchrone peut réduire les interruptions. Si elle a besoin du résultat pour décider ou accomplir l’étape suivante, attendre peut être plus clair et plus sûr.

Déplacer une opération en arrière-plan ne supprime ni sa durée ni sa complexité. Cela change le moment où l’utilisateur reçoit une réponse et les responsabilités du produit : signaler le début du travail, en conserver l’état et faciliter la reprise en cas de problème. Ce cadre permet d’évaluer l’expérience, l’architecture et le fonctionnement avant de modifier un parcours.

La décision dépend de ce que l’utilisateur doit faire ensuite

La durée d’exécution ne détermine pas à elle seule le bon modèle. Une opération brève peut être pénible si elle bloque une action importante ; une opération longue peut être acceptable si l’utilisateur peut passer à autre chose et revenir plus tard. Il faut examiner le parcours dans son ensemble, et pas uniquement l’appel ou le service qui prend du temps.

Demandez-vous quelle décision dépend du résultat. Si une personne modifie une adresse de livraison et doit savoir si celle-ci a été acceptée avant de confirmer un achat, une réponse immédiate l’aide à éviter de décider à l’aveugle. Si elle demande l’exportation d’un rapport qu’elle utilisera plus tard, elle peut généralement laisser le système le préparer tout en poursuivant son travail.

Le coût de l’attente compte également. L’écran bloqué empêche-t-il de terminer une tâche urgente ? La personne perdrait-elle ce qu’elle a déjà saisi si elle quittait le parcours ? Peut-elle comprendre la situation sans contacter l’assistance ? Lorsque l’attente interrompt un objectif essentiel, mais que le résultat n’est pas nécessaire pour continuer, une confirmation rapide de la demande suivie d’un traitement en arrière-plan peut mieux résoudre le problème.

Critères pour choisir entre premier plan et arrière-plan

Évaluez chaque opération à partir de critères observables. Il n’est pas nécessaire de les transformer en score universel : ils servent à expliciter les compromis et à repérer les hypothèses différentes entre les équipes produit, design et ingénierie.

• Dépendance au résultat : si l’étape suivante exige de connaître le résultat, prévoyez une réponse immédiate ou découpez le parcours afin de demander une confirmation au moment nécessaire.
• Effet de l’attente : si l’utilisateur est bloqué ou perd le fil, envisagez un traitement qui lui permet de continuer. Si l’attente est brève et compréhensible, ajouter des états et de la navigation peut être plus complexe qu’utile.
• Possibilité de retrouver le travail : en arrière-plan, l’utilisateur doit pouvoir reconnaître ce qu’il a demandé et consulter de nouveau son état. Si quitter l’écran fait disparaître l’opération ou son contexte, le modèle est incomplet.
• Réversibilité et conséquences : lorsqu’un résultat modifie de l’argent, des autorisations, des données partagées ou des engagements externes, définissez précisément ce que signifient « demandé » et « terminé ». Ne confondez pas acceptation et réussite finale.
• Besoin d’informer sur l’avancement : si connaître la progression aide à s’organiser, fournissez un état utile. Si vous ne pouvez afficher qu’une barre sans lien fiable avec le travail réel, indiquez que celui-ci est en cours au lieu de simuler une précision inexistante.
• Dépendances externes : les services tiers peuvent introduire de la variabilité ou laisser le résultat en attente de confirmation. Rédigez le message en fonction de ce que vous savez réellement, et non de ce que vous espérez voir se produire.

En pratique, gardez au premier plan les décisions qui nécessitent une réponse avant de poursuivre. Envisagez l’arrière-plan lorsque l’utilisateur peut considérer la demande comme lancée, continuer à avancer et retrouver le résultat sans perdre d’informations.

Quand le traitement asynchrone convient-il, et quand l’éviter ?

Les tâches qui produisent un résultat consultable plus tard et ne conditionnent pas l’action suivante sont de bonnes candidates : générer une exportation, traiter un ensemble de documents, préparer un aperçu détaillé ou synchroniser des informations dont le résultat n’est pas nécessaire sur le moment. Dans ces cas, l’utilisateur peut recevoir une confirmation de lancement, quitter l’écran et revenir à l’élément lorsqu’il est prêt.

Ce modèle peut également convenir aux processus comportant plusieurs étapes ou dépendances externes, dont l’issue n’est pas immédiate. À condition que le produit puisse représenter des états significatifs, comme « reçu », « en cours », « nécessite une intervention » ou « terminé ». Si le système ne peut pas déterminer l’état du travail, il ne doit pas présenter comme certaine une finalisation qu’il n’a pas vérifiée.

À l’inverse, une réponse immédiate est généralement préférable lorsque l’utilisateur doit corriger des données avant de continuer, lorsque le résultat détermine son choix suivant ou lorsqu’une confirmation erronée pourrait lui porter préjudice. Vérifier que les champs obligatoires d’un formulaire sont renseignés, confirmer qu’une action a été acceptée ou indiquer si un paramètre a été enregistré sont des exemples de réponses qui peuvent faire partie intégrante du parcours.

Il existe aussi des cas mixtes. Une opération peut confirmer immédiatement que la demande a été reçue, puis effectuer le travail plus tard. Cette première réponse doit être explicite : « Nous avons reçu votre demande » ne signifie pas « L’opération est terminée ». Cette distinction est particulièrement importante pour les opérations financières, les changements ayant des effets externes et les processus susceptibles de nécessiter une intervention.

Ce que l’interface doit communiquer

Une expérience asynchrone ne se résume pas à un indicateur de chargement. Avant le lancement, expliquez ce qui va se passer et si l’utilisateur peut quitter l’écran. Une fois la demande acceptée, confirmez que le système l’a enregistrée et, si le parcours le nécessite, indiquez une référence ou un emplacement clairement identifiable où consulter le résultat.

• Confirmation : précisez ce qui a été demandé et son état actuel. Évitez les messages qui suggèrent une réussite définitive alors que seule la réception a été confirmée.
• Progression : affichez des étapes uniquement si elles reflètent les informations disponibles et aident à comprendre l’attente. Sans estimation fiable, n’inventez ni pourcentage ni heure de fin.
• Continuité : indiquez si l’utilisateur peut fermer l’écran, changer de rubrique ou continuer à utiliser le produit sans annuler le travail.
• Résultat et étape suivante : lorsque le travail est terminé, expliquez ce qui a changé, où trouver le résultat et ce que la personne peut faire si elle doit le vérifier ou le corriger.
• Problèmes : indiquez si le travail nécessite une action, est incomplet ou n’a pas pu être confirmé. Proposez une prochaine étape compréhensible et évitez les messages génériques qui obligent à contacter l’assistance.

Une notification ne remplace pas un état persistant. Si l’utilisateur revient plus tard, il doit pouvoir comprendre ce qui s’est passé sans dépendre d’une alerte qui a peut-être disparu. Définissez également ce qui se passe si le résultat arrive alors que la personne consulte un autre écran, ou si le travail n’est plus pertinent.

Conséquences opérationnelles et signaux de diagnostic

Le traitement en arrière-plan déplace une partie de l’expérience de l’écran vers le fonctionnement du produit. L’équipe doit pouvoir distinguer les travaux en attente, en cours, terminés et nécessitant une vérification, examiner des cas particuliers et aider l’assistance à expliquer les écarts. Cela n’oblige pas à exposer des détails techniques à l’utilisateur, mais l’équipe doit disposer d’assez de contexte pour savoir ce qui a été demandé et ce qui s’est passé.

Observez les signaux liés au parcours, et pas seulement la durée moyenne de traitement. Si davantage d’utilisateurs quittent le parcours avant d’obtenir une confirmation, l’attente est peut-être trop bloquante. Si les demandes à l’assistance du type « Est-ce que ça a été terminé ? » se multiplient, la visibilité est insuffisante ou la confirmation manque de clarté. Si les personnes répètent une action parce qu’elles ignorent si la première demande a été enregistrée, le design risque d’encourager les doublons. Si presque personne ne consulte la progression, une vue persistante ou une notification complexe n’apporte peut-être pas de valeur.

Avant le lancement, convenez de la personne responsable lorsqu’un travail est bloqué, de la manière de communiquer un résultat partiel et de la marche à suivre si une dépendance externe ne fournit aucune réponse concluante. Pour les actions sensibles, définissez également qui peut consulter l’état et le résultat. Ces décisions relèvent du produit ; elles ne peuvent pas être reportées jusqu’au premier incident.

Questions à se poser avant de modifier un parcours

1. Que doit savoir l’utilisateur pour passer à l’étape suivante, et à quel moment ?
2. Peut-il continuer à travailler pendant la préparation du résultat ? Quel contexte faut-il conserver ?
3. Quelle confirmation pouvons-nous fournir avec certitude : réception, progression ou achèvement ?
4. Comment retrouvera-t-il le résultat après avoir fermé l’écran ou être revenu un autre jour ?
5. Quelles seraient les conséquences d’un état erroné, incomplet ou difficile à récupérer ?
6. Quel signal d’usage ou d’assistance montrerait que l’attente a été améliorée, au lieu d’être simplement déplacée vers un autre écran ?

La bonne décision ne consiste pas à automatiser en arrière-plan tout ce qui prend du temps. Il s’agit de réserver la réponse immédiate aux moments où elle apporte de la sécurité ou permet d’avancer, et de laisser le reste se poursuivre sans accaparer l’attention de l’utilisateur. Si vous ne pouvez pas expliquer comment le travail est confirmé, consulté et retrouvé, votre parcours asynchrone n’est pas encore complet.