Intégration et fiabilité
Reprendre une opération sans créer un second dossier
Après un délai dépassé, l’absence de réponse ne prouve pas l’absence d’exécution. Réenvoyer une réservation ou un paiement avec une nouvelle référence peut créer une seconde opération. La reprise doit identifier l’intention initiale, connaître les mécanismes du service et vérifier les états du paiement et de la réservation séparément.
Identifier l’opération avant son premier envoi
Définissez une intention métier précise : confirmer ce panier, effectuer cette capture ou demander ce remboursement. Une nouvelle commande et la reprise de la même commande ne sont pas équivalentes. Conservez une référence technique non sensible qui permet de relier les tentatives sans utiliser des données personnelles comme identifiant.
Stripe documente l’usage d’une clé d’idempotence pour reprendre une création ou modification après une erreur de connexion. Ce mécanisme est distinct d’une clé d’accès API : l’identifiant de reprise suit une opération, tandis que l’authentification établit les droits d’appel au service. La référence de suivi doit rester reliée à l’intention et au système qui la reconnaît.
Vérifier le mécanisme de chaque système
Une protection du paiement ne protège pas automatiquement une réservation chez un autre fournisseur. Décrivez opération couverte, paramètres comparés, durée de conservation et périmètre du mécanisme dans la documentation utilisée. Adyen précise notamment des limites de portée entre points d’accès régionaux : un changement d’endpoint peut donc compter dans la reprise.
Si le service ne propose pas de mécanisme équivalent, prévoyez une procédure de recherche d’état et d’escalade avant une nouvelle émission. Ne déduisez pas la possibilité d’une reprise sûre d’un simple code HTTP ou d’un identifiant client conservé dans votre CRM. La capacité doit être établie pour l’opération réelle.
Conserver intention et paramètres pendant la reprise
Stripe explique que les tentatives avec la même clé retrouvent le résultat mémorisé et que des paramètres différents peuvent provoquer une erreur. Une modification de panier doit donc être distinguée d’une répétition technique. Conservez version du panier et empreinte non sensible des éléments utiles au rapprochement.
Exemple pédagogique : une réservation d’essai expire côté navigateur après son envoi, mais le fournisseur a pu la confirmer. Le scénario doit d’abord retrouver son état et la référence initiale. Une nouvelle intention créée automatiquement à chaque clic ne constitue pas une protection contre le double dossier.
Lire le résultat avant de choisir la prochaine action
Un mécanisme d’idempotence n’est pas un outil pour rendre toute erreur réessayable. Stripe indique qu’un résultat d’erreur peut être mémorisé ; Adyen décrit un indicateur transient-error pour les reprises autorisées dans son modèle. L’équipe doit suivre les règles du service et garder les échecs explicitement non résolus.
Rapprochez réponse synchrone, événement autorisé et lecture d’état. Un webhook reçu tardivement peut éclairer l’opération, sans justifier une autre commande. La transition vers confirmé, refusé ou à traiter manuellement doit rester liée à la référence du système responsable et à la preuve disponible.
Valider une seule conséquence métier attendue
La recette inclut double clic, réponse perdue, tentatives concurrentes et reprise après interruption. Vérifiez le nombre de réservations, transactions et notifications finales, avec leurs références. Un seul écran de confirmation ne prouve pas qu’il n’existe qu’un seul dossier chez les partenaires.
La fiche de contrôle des reprises et le registre des intentions et tentatives rendent le résultat relisible. Toute opération encore inconnue doit être suivie avec un responsable. Le critère de réussite porte sur les effets constatés dans chaque système, avec les limites de conservation et de reprise réellement documentées.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- Stripe : requêtes idempotentes — Résultat mémorisé, paramètres et conservation propres au service ; ne pas transposer à toute API de réservation. (consultée le )
- Adyen : idempotence API — Portée du mécanisme, reprises autorisées et indicateur transient-error ; vérifier l’environnement et le point d’accès utilisés. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Un délai dépassé signifie-t-il que rien n’a été exécuté ?
Non. L’opération peut avoir été exécutée sans réponse reçue. Retrouvez son état et sa référence avant de créer une autre intention.
L’idempotence du paiement empêche-t-elle deux réservations ?
Elle protège l’opération et le périmètre documentés par le service de paiement. Le mécanisme de réservation doit être vérifié séparément.
Une clé d’idempotence est-elle une clé d’accès ?
Non. Elle identifie les reprises d’une opération dans le mécanisme du service. Les accès et secrets de production restent distincts.