La demande de modification est restée sans réponse.
Qu’est-ce qui justifierait une nouvelle tentative ?

Prenons un projet de processus industriel dans lequel un assistant modifie le statut de revue documentaire d’un fournisseur. Il s’agit d’un scénario d’examen, pas d’un déploiement observé. Le guide Retry de Microsoft décrit l’ambiguïté centrale : un service peut traiter correctement une demande sans parvenir à renvoyer sa réponse. Un délai d’attente dépassé ne prouve donc ni l’échec ni la réussite. Le dossier de décision que nous proposons commence par la destination et l’opération initiales, la version de l’interface ou la configuration pertinente si elle est connue, le contenu envoyé, les identifiants, l’heure d’envoi et l’observation réelle. Conservez des références autorisées aux preuves plutôt que de recopier inutilement des données confidentielles. Séparez la demande initiale de toute correction ultérieure ; sinon, la personne chargée de la revue ne pourra pas savoir si une nouvelle tentative correspond au même travail.

Le guide Idempotent Consumer de Microsoft distingue une clé stable propre à une opération logique d’un identifiant de corrélation reliant plusieurs messages. Ce dernier peut associer une demande à ses réponses sans identifier une modification unique pour le dédoublonnage. De même, l’identifiant du fournisseur ne suffit pas à préciser la modification que l’on souhaite répéter. Demandez au responsable technique quel identifiant le service destinataire reconnaît réellement, où la protection s’applique et ce que promet la documentation. Qualifier une demande d’idempotente décrit les effets de sa répétition dans un périmètre défini. Cela ne prouve ni une exécution de bout en bout exactement une fois, ni la justesse métier du résultat, ni une règle universelle fondée sur la méthode de la requête.

L’exemple du guide Idempotent Consumer utilise des messages Service Bus et des commandes enregistrées dans Azure Cosmos DB. Lorsqu’un identifiant existe déjà, le consommateur compare une empreinte de la demande, représentation compacte de son contenu, ou des champs métier immuables. Si les contenus correspondent, il traite le message comme un doublon. Si le contenu diffère sous le même identifiant, il le signale pour traitement au lieu de l’écarter silencieusement. C’est un exemple précis de messagerie et de base de données, pas une réponse garantie par une API de gestion des fournisseurs. Pour une modification proposée, demandez comment l’interface réelle distingue un renvoi inchangé d’une demande corrigée. Garder l’ancien identifiant ou en créer un nouveau ne résout pas, à lui seul, l’incertitude initiale. La conservation doit figurer dans le même dossier. Microsoft avertit qu’une suppression trop précoce des enregistrements de dédoublonnage permet des doublons tardifs, notamment lors de renvois manuels après la période habituelle de redistribution. Demandez la durée documentée et vérifiez si elle couvre encore cette opération. Ces sources ne fixent aucune durée universelle pour les clés ; la présence d’un identifiant dans un journal ne prouve pas que le destinataire le reconnaît toujours.

Le guide Asynchronous Request-Reply de Microsoft sépare acceptation, état et résultat final. Il propose de renvoyer la ressource d’état existante pour une clé d’idempotence déjà reçue, au lieu d’ajouter un nouveau travail. Demandez si l’interface réelle suit cette conception et comment un appelant autorisé peut retrouver l’opération initiale lorsque la réponse d’acceptation a été perdue. Ne supposez pas que tout point de terminaison permet une recherche par clé. Interprétez l’état selon l’interface documentée. Le guide décrit des implémentations qui renvoient 404 avant la création de la ressource cible, réponse qui peut être confondue avec celle d’un identifiant invalide. Il recommande par ailleurs une politique de conservation des états et des résultats. Demandez ce que signifie leur expiration ; ne présumez ni un code particulier ni une preuve de non-exécution. Le guide du consommateur traite aussi des actions externes qui ne peuvent pas participer à une transaction de la base locale. Une marque « en cours » peut correspondre à un travail partiel ou à un autre consommateur encore actif. Microsoft préconise de rapprocher les preuves ou de faire intervenir un responsable pour les cas non résolus. Le dédoublonnage local ne protège pas automatiquement les services en aval.

Nous proposons un dossier de transmission unique réunissant l’identité et le contenu de l’opération, le périmètre et la conservation documentés du dédoublonnage, les preuves d’état accessibles par les moyens prévus, les actions externes non résolues et le responsable de la décision. Les responsables techniques expliquent ce que les preuves permettent de conclure ; le responsable métier autorise la suite. L’autorisation de la modification initiale ne prouve pas son résultat. Pour une évaluation autorisée, demandez comment l’équipe traiterait des contenus identiques, un contenu modifié sous le même identifiant, un état indisponible et des preuves au-delà de leur durée de conservation. Ce sont nos propositions de cas de revue, pas des procédures imposées par le fournisseur ni des tests réalisés ici. Elles ne déterminent aucun nombre de tentatives ni délai entre elles. Si les preuves obtenues par les moyens prévus établissent l’achèvement, consignez-le sans effectuer une nouvelle modification pour simple confirmation. Si les règles documentées applicables permettent une autre tentative, précisez ses conditions avant autorisation. Si aucun rapprochement n’est possible ou si le résultat reste non concluant, le responsable doit autoriser explicitement une mise en attente et attribuer le suivi. Une réponse manquante n’autorise pas à répéter le changement.