INTRODUCTION
Un bouton Réessayer promet qu’une nouvelle tentative aidera l’utilisateur à terminer la même action. Cette promesse se brise lorsque l’interface prend l’absence de réponse pour la preuve que rien ne s’est passé.
La question utile précède l’indicateur de chargement : si la première tentative a réussi mais que sa réponse s’est perdue, que fera le prochain clic ? Les équipes produit et technique doivent partager la réponse.
Donner une identité durable à l’action
Imaginons une application collaborative. Un client clique sur Créer un espace, le serveur le crée, puis la connexion se coupe avant la confirmation. Un second clic muni d’un nouvel identifiant de requête pourrait créer un second espace. Désactiver brièvement le bouton limite les clics rapides ; cela ne règle ni le rechargement de la page, ni l’ouverture d’un autre onglet, ni une réponse tardive.
Un enregistrement d’opération peut conserver l’intention initiale malgré ces interruptions. L’interface reprend cette opération au lieu de repartir de zéro. Le support peut consulter la même trace sans demander au client de reconstituer toute la séquence.
La Builders’ Library d’AWS explique comment un identifiant fourni par l’appelant distingue une reprise d’une véritable nouvelle demande. Des paramètres identiques ne suffisent pas : une personne peut vouloir créer deux ressources identiques.
Vérifier les garanties associées à la clé
Une clé d’idempotence identifie une opération répétée, mais ses garanties dépendent de l’API. La documentation Stripe précise qu’une requête répétée avec la même clé renvoie le résultat mémorisé, y compris une erreur serveur. Les clés peuvent être supprimées après au moins 24 heures ; réutiliser une clé supprimée crée une nouvelle requête.
La durée de conservation devient donc un sujet produit. Une intervention du support plusieurs jours plus tard ne peut pas supposer que le prestataire se souvient encore de la tentative initiale. Conserver le lien entre l’opération locale et la ressource distante permet de vérifier un résultat incertain avant d’émettre une nouvelle commande. Une intention modifiée mérite une nouvelle opération, pas une modification discrète de l’ancienne.
Un événement livré doit encore devenir un travail terminé
Le trajet retour comporte ses propres risques. Stripe documente les livraisons de webhooks en double et l’absence de garantie d’ordre. Une retransmission manuelle réussie n’annule pas automatiquement les nouvelles tentatives déjà programmées.
Dans notre exemple, recevoir une notification et terminer la création de l’espace devraient donc correspondre à deux états distincts. Une boîte de réception persistante enregistre l’arrivée ; un worker suit le traitement. Une contrainte en base ou une prise en charge transactionnelle empêche deux workers de se croire simultanément les premiers. Si le traitement échoue, l’opération doit rester récupérable plutôt qu’être définitivement marquée comme terminée.
Les effets externes exigent leur propre protection. Une transaction en base ne peut pas englober atomiquement un service d’envoi d’e-mails indépendant. Consigner l’action en attente, utiliser les garanties de déduplication du prestataire lorsqu’elles existent et rendre les résultats ambigus vérifiables permet de préparer la reprise. Une file d’attente ne garantit pas, à elle seule, une exécution unique de tout le parcours.
Montrer l’incertitude sans abandonner l’utilisateur
Trois états d’interface sont plus utiles qu’une erreur générique :
- Traitement en cours : garder l’opération visible et expliquer comment son état sera actualisé.
- Résultat non confirmé : vérifier l’opération existante plutôt que présenter une nouvelle soumission comme anodine.
- Échec confirmé : proposer une reprise lorsque sa sécurité est établie, ou expliquer l’étape de récupération suivante.
Pour une action réversible et sans grand enjeu, une solution plus légère peut suffire. L’objection est légitime : une orchestration persistante a un coût de maintenance. Le bon niveau de protection dépend du dommage qu’un doublon peut causer et de la facilité à l’annuler. Créer un second brouillon et envoyer une seconde invitation n’ont pas les mêmes conséquences.
Tester la promesse avant la mise en ligne
- Perdre la réponse après la validation de l’écriture serveur.
- Soumettre la même opération depuis deux onglets simultanément.
- Livrer deux fois le même événement et inverser deux événements.
- Arrêter le worker entre l’enregistrement de la réception et la fin du traitement.
- Rouvrir une ancienne opération incertaine après la durée de conservation du prestataire.
Pour chaque test, vérifier le résultat visible par l’utilisateur et la trace de reprise, au-delà du statut HTTP. L’objectif est un système capable d’expliquer ce qui s’est passé et de terminer sans danger l’action voulue.
Pour élargir la réflexion, voir quels workflows de développement automatiser en premier (article en anglais). Une revue produit peut commencer par une seule action coûteuse et cartographier ses états incertains avant d’ajouter de l’automatisation.
Couverture : illustration conceptuelle originale générée par IA, avec le logo officiel Blanche ajouté séparément.