Le silence ne prouve pas l’absence d’action

Une application envoie une commande, le serveur l’enregistre, puis la réponse se perd. Le client voit une erreur et réessaie. Si chaque tentative crée une commande, un problème réseau devient un problème métier. « Réessayer jusqu’à réussir » ne constitue donc pas une stratégie suffisante.

Un délai d’attente limite l’attente de l’appelant ; il n’annule pas automatiquement l’action distante. L’interface doit distinguer un échec confirmé d’un résultat encore inconnu. Si nécessaire, permettez de consulter l’état de l’opération avant d’en créer une autre.

Donnez une identité à l’opération

Une clé d’idempotence identifie la même intention entre les tentatives. Le serveur doit la conserver, la reconnaître et l’associer au résultat. Changer de clé à chaque tentative annule son intérêt. Les requêtes simultanées doivent aussi être traitées pour éviter deux créations.

Cela ne signifie pas ignorer les différences. Une même clé avec un autre montant ou destinataire doit être traitée explicitement. Définissez sa durée de conservation et le comportement ensuite. La garantie dépend du contrat et de l’implémentation, pas du nom de l’en-tête.

Moins réessayer peut mieux rétablir

Pour les pannes transitoires, limitez les tentatives et espacez-les progressivement. Une variation aléatoire, le jitter, évite des retours simultanés. Une attente ne corrige généralement ni identifiants invalides ni données rejetées. Respectez les consignes et limites du service appelé.

Surveillez les couches : des tentatives non coordonnées dans l’application, la bibliothèque et un intermédiaire multiplient la charge. Choisissez où les contrôler et suivez les résultats inconnus. Le message utilisateur doit proposer une suite sans affirmer un échec encore incertain.

Testez la réponse qui n’arrive jamais

Dans un environnement de test, perdez volontairement la réponse après enregistrement. Réessayez avec la même clé et vérifiez l’unicité du résultat. Testez ensuite des appels simultanés et une clé réutilisée avec d’autres données. Écrivez d’abord le comportement attendu : préserver l’intention de l’utilisateur.

Sources & lectures complémentaires

Sources consultées le 24 octobre 2026. Les exemples chiffrés et les scénarios sont donnés à titre illustratif.

Et si nous passions à la pratique ?

Nous pouvons travailler ensemble sur le défi de votre équipe ou votre prochain projet.

Contacter Calembe ↗