Continuité de service
Réagir à un incident de réservation sans perdre la trace des voyageurs
Une recherche en panne, un paiement accepté sans confirmation ou un fournisseur indisponible n’appellent pas la même réponse. Le premier objectif est de connaître l’état réel des dossiers et d’éviter d’aggraver l’incident.
Réponse directe
Stabilisez le parcours avant de relancer les ventes
Un incident peut toucher l’affichage des offres, le calcul du prix, la création d’une réservation, le paiement, l’émission d’un document ou la transmission au fournisseur. La première décision consiste à savoir quelles étapes fonctionnent encore et lesquelles produisent un résultat incertain. Désignez une personne qui pilote la réponse, centralise les faits et autorise la reprise.
Ne relancez pas automatiquement un paiement ou une réservation dont l’état n’a pas été vérifié : vous pourriez créer un doublon ou promettre une prestation non confirmée.
Localiser la rupture et estimer son périmètre
Notez l’heure de début observée, les canaux touchés, les produits concernés et le dernier parcours réussi. Comparez les événements de votre site avec ceux du fournisseur : requête envoyée, réponse reçue, identifiant de dossier, statut de paiement, confirmation et message client. Conservez des identifiants de corrélation exploitables sans exposer inutilement les données personnelles.
| Symptôme | Vérification prioritaire | Action provisoire |
|---|---|---|
| Offres absentes | Source, cache et filtres actifs | Retirer les offres non fiables |
| Prix qui change au paiement | Règles tarifaires et revalidation | Suspendre la confirmation touchée |
| Paiement sans dossier | Transaction, idempotence et retour fournisseur | Bloquer une nouvelle tentative aveugle |
| Dossier sans document | Confirmation réelle et émission du voucher | Informer le client de l’état vérifié |
| Modification impossible | Droits, statut du dossier et canal fournisseur | Diriger vers une équipe habilitée |
Classer les dossiers selon l’urgence réelle
Les voyageurs déjà en déplacement, les départs proches et les paiements sans confirmation doivent remonter avant les simples recherches échouées. Créez une liste unique des dossiers à traiter, avec statut vérifié, prochain geste, responsable et heure du dernier contact. Une file partagée évite que deux personnes modifient le même dossier dans des systèmes différents.
Si plusieurs partenaires interviennent, identifiez celui qui détient l’action possible : fournisseur de contenu, plateforme de paiement, agence émettrice ou équipe d’assistance. Une escalade utile transmet l’identifiant du dossier, la chronologie et la demande précise, sans supposer qu’un partenaire voit l’ensemble du parcours.
Choisir un mode dégradé compréhensible
Un mode dégradé peut limiter la vente à des offres dont la disponibilité est vérifiable, transformer une confirmation automatique en demande examinée par un conseiller ou suspendre temporairement un moyen de paiement. Il doit être visible pour l’utilisateur : ne présentez pas une demande en attente comme une réservation ferme.
- Indiquer les étapes indisponibles sans afficher de prix ou de disponibilité non vérifiés.
- Conserver un identifiant pour chaque demande reçue pendant l’incident.
- Définir qui valide manuellement une confirmation et dans quel délai.
- Empêcher les doubles clics ou nouvelles tentatives de créer plusieurs dossiers.
Informer avec des faits et une prochaine échéance
Les équipes internes ont besoin d’un état court : périmètre, opérations autorisées, opérations gelées et contact d’escalade. Le voyageur a besoin de savoir si son dossier est confirmé, en vérification ou annulé, ainsi que le moment prévu pour la prochaine information. Mettez les messages à jour lorsque l’état change ; évitez une formule générale de « retour à la normale » tant que les dossiers affectés ne sont pas rapprochés.
Après résolution technique, contactez les personnes dont la demande a été reçue sans résultat certain. Le message doit distinguer une tentative non finalisée d’une réservation confirmée.
Rapprocher les événements avant de clôturer
Testez à nouveau le parcours complet sur chaque catégorie touchée : recherche, prix, réservation, paiement, confirmation, document et demande de modification. Rapprochez ensuite les transactions et dossiers sur la période de l’incident. Cherchez notamment les paiements isolés, doublons, dossiers confirmés sans notification et annulations restées en attente.
Terminez par une chronologie factuelle : ce qui a été détecté, ce qui a ralenti la réponse, quels contrôles ont protégé les clients et quelle amélioration sera testée. Transformez une ou deux causes concrètes en scénario de recette. Une procédure courte, tenue à jour et répétée par les équipes vaut mieux qu’un document long impossible à utiliser pendant une panne.
Après une panne : rapprocher avant de relancer
Une base restaurée ne rétablit pas les états des systèmes externes. Le guide de reprise d’activité décrit l’isolement, le rapprochement et la décision de réouverture. Utilisez la fiche de reprise pour garder les inconnues attribuées.
Qualifier une reprise après une réponse perdue
Après un délai dépassé, le système partenaire peut avoir exécuté l’opération sans que la réponse soit arrivée. Conservez l’intention et recherchez l’état avant de créer une autre commande. Une référence différente pour chaque clic ne garantit pas l’absence de double réservation.
Le mécanisme de paiement et celui de réservation doivent être vérifiés séparément. Décrivez portée, paramètres et critères de reprise dans les documents applicables. La clôture compte les effets dans les systèmes responsables ; une seule confirmation affichée à l’utilisateur ne démontre pas un seul dossier fournisseur. Consultez le Réservations et paiements : organiser des reprises sans doublon.
Qualifier les dossiers incertains avant de relancer
Google SRE relie les objectifs de service aux résultats utiles aux utilisateurs et à des mesures définies.
Scénario fictif : l’appel de réservation expire sans réponse après l’envoi. Le tableau d’exploitation indique une erreur technique mais le fournisseur peut avoir créé le dossier. Isolez la liste des opérations concernées, recherchez leur état par les moyens documentés et attribuez une décision de reprise. Informez le support du périmètre connu. La priorité métier est d’éviter une seconde vente tout en retrouvant les départs menacés, pas seulement de faire disparaître les erreurs du journal.
| Point | Preuve à conserver | Contrôle à effectuer |
|---|---|---|
| Périmètre | Fenêtre, opérations et références. | Distinguer recherche échouée et écriture incertaine. |
| État | Preuve fournisseur et dernière observation. | Vérifier avant toute nouvelle commande. |
| Reprise | Action, approbation et information support. | Observer un dossier repris jusqu’à son état attendu. |
Gardez les dossiers non rapprochés ouverts dans le bilan d’incident. Un service disponible de nouveau ne confirme pas leur résolution.
Approfondir le parcours : Activité et météo : décision fournisseur, notification et suite du dossier
Un incident lié à la météo doit garder distincts prévision, décision de l’exploitant et état du dossier. La notification reçue demande un rapprochement par canal. L’alternative et la communication conservent leur responsable jusqu’à la preuve attendue.
Activité et météo : décision fournisseur, notification et suite du dossier · Rapprocher les preuves du parcours
Trace Context : formats des identifiants et portée du suivi
La version 00 de traceparent distingue l’identité de la trace complète et celle du segment parent. Le format permet le rapprochement technique sans remplacer l’identifiant métier du dossier.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| trace-id | 32 caractères hexadécimaux minuscules, correspondant à 16 octets ; la valeur entièrement nulle est interdite. | Rejeter un contexte invalide sans le traiter comme une preuve de continuité. |
| parent-id | 16 caractères hexadécimaux minuscules, soit 8 octets ; la valeur entièrement nulle est également interdite. | Suivre les changements de segment sans créer artificiellement un nouveau dossier commercial. |
| Confidentialité | Les en-têtes de contexte ne doivent pas transporter d’informations permettant d’identifier une personne. | Garder coordonnées client, jetons et contenu sensible hors du contexte propagé. |
Une trace retrouvée atteste un chemin technique observé, sans démontrer à elle seule l’acceptation ou l’émission d’une réservation.
W3C — Trace Context, recommandation du 23 novembre 2021 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Expedia Rapid : reprendre une création sans réponse certaine
Expedia indique qu’une réservation peut être confirmée et débitée même si une défaillance réseau empêche le revendeur de recevoir la réponse. Un silence technique ne doit donc pas être assimilé à un refus.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Référence revendeur | affiliate_reference_id doit être unique par réservation et conservé lors d’une reprise de la même demande. | Ne pas créer une nouvelle référence à chaque expiration réseau. |
| Relecture | Retrieve peut employer la référence revendeur et l’email initiaux, ou itinerary_id et le lien de relecture retourné. | Retrouver la demande existante avant de proposer une nouvelle création au voyageur. |
| Attente | Le guide recommande une relecture après 90 secondes sans réponse et un suivi des relectures pendant 30 minutes avant escalade au support. | Prévoir un état en cours et appliquer la procédure Rapid ; ces délais ne sont pas une promesse de rapidité au client. |
Procédure propre à Rapid Lodging. Une réponse de relecture temporairement absente peut encore correspondre à une création en cours.
Expedia Rapid — Handling booking requests · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Viator : accusé technique et information du voyageur
Ce circuit distingue la prise en charge technique et le message au client. Le niveau de partenariat change les responsabilités.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Fenêtre Merchant | Pour les partenaires Merchant, le circuit prévoit un accusé dans les cinq minutes suivant l’annulation ; à défaut, Viator envoie un email au contact support enregistré. | Ne faites pas repartir le délai au moment où votre équipe lit la notification. |
| Type d’événement | L’accusé de modified-since/acknowledge concerne uniquement eventType CANCELLATION. | Une modification et une annulation ne suivent pas automatiquement la même opération d’accusé. |
| Réponse de l’opération | Un HTTP 200 sans corps constitue une réussite de cet accusé. | Ne relancez pas l’opération au seul motif que la réponse ne contient pas de JSON. |
| Partenaire Affiliate avec accès Booking | Les partenaires Affiliate avec accès Booking ne doivent pas utiliser cette opération d’accusé ; leur contrat prévoit l’information du client par Viator. | Confirmez le modèle Merchant ou Affiliate avant d’attribuer la communication. |
Quatre preuves à garder distinctes
Schéma de lecture du circuit Merchant ; les cases ne représentent aucune opération réelle.
- Annulation fournisseur
Retrouver le dossier et l’événement.
- Transaction collectée
Conserver les références à traiter.
- Accusé technique
Vérifier le résultat de l’opération.
- Voyageur informé
Suivre séparément le message client.
Relire une réponse technique
États fictifs, sans appel à Viator ni envoi de message.
L’accusé retourne 200 et aucun corps
Le circuit Merchant obtient le résultat suivant.
HTTP : 200
Corps : vide
Message client : à suivreLecture du cas. L’accusé est réussi dans le contrat décrit. Le message client garde son propre suivi.
Un événement est une modification
La transaction reçue porte sur une modification de réservation.
eventType : AMENDMENT
Accusé CANCELLATION : non applicableLecture du cas. Ne faites pas passer cet événement dans l’opération réservée aux annulations. Retrouvez le traitement correspondant au type et au niveau de partenariat.
Périmètre du circuit Viator documenté, vérifié le 23 octobre 2026. Un accusé ne prouve ni lecture client ni rapprochement financier.
Viator — Automating supplier cancellations and amendments · publiée le 11/09/2025 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Lire le résultat opérationnel
Duffel : une réponse 202 ne permet pas de recommencer la commande
Pour la création d’une commande Flights ou d’une réservation Stays, Duffel distingue 201 (ressource créée), 200 (réservation faite chez le fournisseur, informations encore incomplètes) et 202 (résultat en cours de confirmation). Le 200 décrit ici un cas particulier, pas toutes les réponses de l’API. En 202, Duffel demande de ne pas renvoyer la création, au risque d’un doublon.
Duffel — création des commandes et réservations · consulté le . Ces réponses dépendent du produit et du moyen de paiement ; le mode avec votre propre agence impose un suivi spécifique.
| Situation | À retrouver | Décision à préparer |
|---|---|---|
| 201 · ressource créée | Conserver son identifiant et relire le détail de la prestation. | Rattacher la référence fournisseur au dossier, puis examiner séparément son paiement. |
| 200 · informations à compléter | Attendre la ressource et rapprocher la notification ou la liste des réservations. | La réservation est annoncée comme faite ; ne pas créer une seconde commande pour obtenir son identifiant. |
| 202 · résultat en cours | Suivre l’issue de la demande initiale et prévoir un relais humain. | Garder le dossier en attente et empêcher la répétition de la création. |
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.
- Google SRE : mise en œuvre des SLO : Méthode de définition des objectifs et indicateurs de service ; aucune garantie contractuelle d’une API voyage. (consultée le )
- W3C — Trace Context, recommandation du 23 novembre 2021 : Une trace retrouvée atteste un chemin technique observé, sans démontrer à elle seule l’acceptation ou l’émission d’une réservation. (consultée le )
- Expedia Rapid — Handling booking requests : Procédure propre à Rapid Lodging. Une réponse de relecture temporairement absente peut encore correspondre à une création en cours. (consultée le )
- Viator — Automating supplier cancellations and amendments : Périmètre du circuit Viator documenté, vérifié le 23 octobre 2026. Un accusé ne prouve ni lecture client ni rapprochement financier. (consultée le )
- Duffel — création des commandes et réservations : Ces réponses dépendent du produit et du moyen de paiement ; le mode avec votre propre agence impose un suivi spécifique. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Que faire si le paiement semble accepté mais que la réservation n’est pas confirmée ?
Mettez le dossier dans un état explicite de vérification. Contrôlez séparément le paiement et la confirmation fournisseur avant de relancer une transaction ou de promettre la prestation au client.
Faut-il masquer toutes les offres pendant un incident ?
Cela dépend du périmètre. Si une seule source est touchée, retirez ou désactivez les offres concernées. Si l’état des prix et disponibilités ne peut plus être garanti, suspendez l’étape de confirmation plutôt que de laisser créer des dossiers incertains.
Quand informer le voyageur ?
Dès qu’un incident affecte son dossier ou sa capacité à réserver, avec un message précis sur ce qui est connu, ce qui reste à vérifier, le prochain point d’information et le canal de contact.
Comment savoir que le service est réellement revenu ?
Vérifiez une recherche, un prix, une réservation, un paiement et une confirmation de bout en bout. Rapprochez ensuite les dossiers créés pendant l’incident avant de déclarer la situation close.
Que signifie l’état inconnu après un délai dépassé ?
L’absence de preuve suffisante sur l’exécution. Cet état doit être suivi avant de conclure à un refus ou de créer une autre intention.
Le retour de l’API clôture-t-il l’incident ?
Il reste à rapprocher les dossiers touchés, traiter les états incertains et vérifier les conséquences pour les voyageurs.
