Cahier de recette pas à pas

Le déroulé opérationnel de la certification, scénario par scénario : ce qu'on fait, ce qu'on doit voir, à quoi ressemble l'échec, où regarder. Il met en œuvre la grille des 19 tests (numéros rappelés entre crochets) et ajoute ce que la grille ne mesure pas : la fréquence et le volume des messages (§ E) et le lendemain (§ G). Cible : staging, hôtel pilote, connexion PENDING puis ACTIVE.

Notez le résultat de chaque scénario, même conforme, avec l'identifiant du message qui le prouve (messageId JSON, transactionId XML) : c'est cet identifiant que Bridg_ retrouve dans ses journaux au contrôle.

---

Avant de commencer — quatre pièges

1. En XML, la réponse HTTP n'est pas l'accusé. Le 200 dit « message reçu et enregistré ». Le verdict est le RESULT que le PMS vient chercher ensuite sur GET …/messages. Un test ARI en XML ne se conclut jamais sur le 200.

2. En PENDING, aucune réservation ne part vers le PMS. Elles sont retenues au journal des émissions. Les scénarios C exigent le passage en ACTIVE ; les réservations retenues pendant la recette se libèrent ensuite une par une — certaines sont des tests, ne libérez pas tout à l'aveugle.

3. Un code non mappé est refusé item par item, et ce refus est définitif. Réémettre le même message donne le même refus. Si votre connecteur « réessaie » un refus déterministe, c'est un échec de certification, pas un détail.

4. Le calendrier Bridg_ est le juge des tests ARI, le PMS est le juge des tests de réservation. Ne concluez pas depuis vos propres logs : l'écran Interface PMS de l'établissement montre chaque message entrant avec le corps exact reçu, chaque émission sortante, chaque erreur par message, et le bouton Rejouer. Gardez-le ouvert en permanence.

---

Ordre conseillé

---

A. Préparation

• Connexion staging en PENDING, dialecte figé, identifiants reçus et stockés chiffrés.
• 2 types de chambre et 2 plans tarifaires mappés ; 1 code volontairement non mappé gardé sous la main pour B10.
• JSON : API du PMS enregistrée (Réglages → API du PMS), Tester la connexion affiche le catalogue.
• XML : OXI (ou équivalent) pointé sur l'URL staging, ?key=, corps non compressé, rateEndDateInclusive laissé par défaut jusqu'à B5.
• Une période de test calme, de 10 nuits, d'ici deux à six semaines.
• Écran Interface PMS ouvert ; côté PMS, journal des envois ouvert avec les identifiants de message.
• Heure de début notée : elle sert au comptage de § E.

---

B. ARI — le PMS est la source de vérité

B1 · Synchronisation complète [1]

Déclencher depuis le PMS l'envoi de la disponibilité, des prix et des restrictions sur 365 jours, pour tous les types et tarifs mappés.

• Attendu : quelques messages volumineux, regroupés par nature ; le calendrier Bridg_ est rempli sur 365 jours pour chaque type × tarif ; les accusés sont positifs.
• Échec : des centaines de messages d'un item ; un calendrier qui s'arrête avant l'horizon ; un accusé UNMAPPED_* sur un code que vous pensiez mappé.
• Où vérifier : calendrier Bridg_ (dernière nuit de l'horizon) ; journal entrant (nombre et taille des messages).

Résultat :

B2 · Disponibilité — une nuit [2]

Prendre une réservation à la réception du PMS sur un type, une nuit de la période de test.

• Attendu : un message de disponibilité part en quelques secondes ; le calendrier Bridg_ affiche le chiffre décrémenté sur cette seule nuit.
• Échec : rien ne part ; ou le PMS envoie toute la plage de 365 jours pour une nuit changée.

Résultat :

B3 · Disponibilité — plage, plusieurs types [3]

Changer l'inventaire de 2 types sur 5 nuits d'un coup (clôture de chambres, maintenance…).

• Attendu : un seul message portant les deux types et les cinq nuits ; le calendrier reflète les nouveaux chiffres.
• Échec : dix messages d'une nuit chacun.

Résultat :

B4 · Prix — une nuit [4]

Changer le prix d'un type × tarif sur une nuit.

• Attendu : le prix à l'occupation 2 dans le calendrier Bridg_ est celui attendu, TTC ou HT selon la définition du tarif Bridg_ ; devise cohérente (aucun CURRENCY_MISMATCH).
• Échec : prix d'une autre occupation ; prix reçu en HT là où le tarif est TTC.

Résultat :

B5 · Prix — plages, plusieurs tarifs, borne de fin [5]

Envoyer des prix sur 2 tarifs, du 01 au 03 de la période de test.

• Attendu : un message, deux tarifs, trois nuits chacun. En XML, regarder la nuit du 03 : si elle ne porte pas le prix, régler rateEndDateInclusive et recommencer.
• Échec : une nuit de trop ou de moins en bout de plage. C'est l'erreur la plus fréquente en recette.

Résultat :

B6 · Fermeture et réouverture d'un tarif [6]

Fermer un tarif (stop-sell) sur 3 nuits, vérifier, puis le rouvrir.

• Attendu : fermé puis ouvert dans le calendrier ; la réouverture ne touche ni CTA/CTD ni les durées de séjour posées par ailleurs.
• Échec : la réouverture efface des restrictions qu'elle n'a pas posées.

Résultat :

B7 · Durées de séjour [7]

Poser minLos = 2 sur une plage, puis maxLos = 5.

• Attendu : les deux valeurs visibles ; un minLos seul ne rouvre pas un tarif fermé.
• Échec : minLos remis à 1 quand on pose maxLos ; tarif rouvert par effet de bord.

Résultat :

B8 · CTA / CTD [8]

Fermer à l'arrivée sur 2 nuits, puis au départ, puis rouvrir les deux.

• Attendu : chaque drapeau bouge seul ; l'autre reste inchangé.

Résultat :

B9 · Restrictions combinées [9]

Un seul message qui combine stop-sell, CTA, CTD et durées de séjour, sur 2 tarifs et 2 plages.

• Attendu : tout est appliqué, en un message.

Résultat :

B10 · Code non mappé — refus déterministe [10]

Envoyer un message ARI avec, parmi d'autres items valides, un item portant le code non mappé gardé en A.

• Attendu : l'accusé signale l'item (UNMAPPED_UNIT_TYPE ou UNMAPPED_RATE_PLAN), les autres items sont appliqués. Le PMS journalise le refus et ne réémet pas. Vérifier dix minutes plus tard : aucun nouveau message identique.
• Échec : tout le message rejeté par le PMS ; ou réémission en boucle (visible au journal entrant comme une suite de messages identiques refusés).

Résultat (identifiant du message + nombre de réémissions observées) :

---

C. Réservations Bridg_ → PMS — en ACTIVE

Passer la connexion en ACTIVE (geste du propriétaire). Les écrans ARI de Bridg_ passent en lecture seule. Faire les scénarios dans l'ordre : chaque révision s'appuie sur la précédente.

C1 · Créer une réservation [11]

Créer une réservation sur le moteur de réservation direct de l'hôtel pilote (ou une OTA de test) : 1 chambre, 2 nuits, un tarif mappé.

• Attendu : la réservation arrive au PMS avec le bon type, le bon tarif, les nuits datées et le total ; le PMS l'écrit puis l'acquitte (JSON : 2xx ; XML : RESULT positif) ; la ligne passe à DONE dans le journal des émissions ; le PMS renvoie sa disponibilité par le flux ARI et le calendrier Bridg_ affiche le chiffre décrémenté.
• Échec : accusé reçu avant l'écriture dans le PMS (si le PMS plante entre les deux, la réservation est perdue) ; aucune disponibilité renvoyée.

Résultat (référence Bridg_, numéro PMS) :

C2 · Modifier les dates [12]

Décaler la réservation de C1 d'une nuit.

• Attendu : le PMS reçoit l'état complet avec une révision supérieure et remplace la réservation ; la disponibilité suit (nuit libérée, nuit prise).
• Échec : une seconde réservation créée au PMS au lieu d'une modification.

Résultat :

C3 · Ajouter puis retirer une chambre [13]

Passer la réservation à 2 chambres, vérifier, puis revenir à 1.

• Attendu : deux lignes au PMS, puis la ligne retirée annulée côté PMS ; une seule réservation côté Bridg_.
• Échec : la chambre retirée reste réservée au PMS.

Résultat :

C4 · Annuler [14]

Annuler la réservation depuis Bridg_.

• Attendu : annulée au PMS, acquittée ; disponibilité restituée par le flux ARI.

Résultat :

C5 · Modification périmée après annulation [14]

Depuis les journaux Bridg_, rejouer l'émission de C2 (révision ancienne) après l'annulation de C4.

• Attendu : le PMS l'ignore (révision périmée) et la réservation reste annulée.
• Échec : la réservation ressuscite au PMS.

Résultat :

C6 · Refus déterministe côté PMS [15]

Créer une réservation sur un type volontairement inconnu du PMS (mapping retiré le temps du test).

• Attendu : le PMS refuse explicitement (JSON : 4xx ; XML : RESULT d'échec) ; la ligne passe en dead-letter FAILED, visible à l'hôtelier ; après remise du mapping, Rejouer la fait passer.
• Échec : le PMS acquitte une réservation qu'il n'a pas pu créer ; ou Bridg_ réessaie en boucle un refus explicite.

Résultat :

C7 · Panne transitoire du PMS [16]

Rendre le PMS indisponible (JSON : couper l'API webhook ; XML : arrêter le GET du feed) pendant 10 minutes, créer 2 réservations dans Bridg_, puis rétablir.

• Attendu : JSON : Bridg_ réessaie avec backoff et les deux réservations arrivent après le retour, une fois chacune ; XML : elles sont servies au premier GET qui suit. Zéro perte, zéro doublon.
• Échec : une réservation en double au PMS ; une réservation jamais arrivée.

Résultat :

---

D. Réservations PMS → Bridg_

D1 · Créer à la réception [17]

Prendre une réservation à la réception du PMS : 1 chambre, 2 nuits, un tarif mappé, un client avec e-mail.

• Attendu : elle apparaît dans Bridg_ avec la source PMS et sa date de création (bookedAt JSON / originalBookingDate XML) ; Bridg_ la décompte de la disponibilité à réception ; le message ARI qui suit confirme le même chiffre, sans second décompte.
• Échec : la disponibilité baisse deux fois (réservation + ARI) ; ou pas du tout ; aucun numéro de carte dans le message.

Résultat :

D2 · Modifier au PMS [17]

Changer les dates et le nombre de personnes au PMS.

• Attendu : la réservation Bridg_ est remplacée (mêmes référence, révision supérieure), pas dupliquée.

Résultat :

D3 · Annuler au PMS [17]

• Attendu : passée en annulée dans Bridg_ ; disponibilité confirmée par l'ARI suivant.

Résultat :

D4 · Révision périmée

Réémettre depuis le PMS la révision de D2 après l'annulation de D3.

• Attendu : ignorée, la réservation reste annulée.

Résultat :

---

E. Fréquence et volume — ce que la grille ne mesure pas

Le comptage se fait sur le journal entrant de l'écran Interface PMS (par nature et par fenêtre horaire, avec la taille de chaque message) et, côté Bridg_, par l'audit de la connexion sur la période. Les seuils :

Résultat E1 (fenêtre, nombre de messages par nature) :
Résultat E2 :
Résultat E3 (nombre de messages, taille max, durée) :
Résultat E4 :
Résultat E5 :
Résultat E6 :
Résultat E7 (pic / minute, nombre de 429) :
Résultat E8 :

---

F. Robustesse

F1 · Rejeu du même message [18]

Renvoyer un message ARI déjà traité, même identifiant, même corps.

• Attendu : l'accusé mémorisé, rien appliqué deux fois (le calendrier ne bouge pas).

Résultat :

F2 · Redémarrage du connecteur

Arrêter le connecteur pendant 5 minutes, faire 3 changements au PMS, redémarrer.

• Attendu : les trois changements partent après le redémarrage, une fois chacun, dans l'ordre.
• Échec : changements perdus ; ou full sync complet déclenché à chaque redémarrage.

Résultat :

F3 · Régénération du secret

Régénérer les identifiants dans l'écran Interface PMS, reconfigurer le PMS.

• Attendu : l'ancien couple est refusé (401) immédiatement ; le connecteur repart avec le nouveau sans message perdu ; le secret n'apparaît dans aucun journal des deux côtés.

Résultat :

---

G. Le lendemain

À faire le matin suivant les scénarios B à D, connexion restée ACTIVE toute la nuit.

G1 · Rien n'a bougé

Comparer le calendrier Bridg_ (prix, fermetures, durées de séjour posés la veille) avec la veille au soir.

• Attendu : identique, sauf ce que le PMS a volontairement changé.
• Échec : une synchronisation nocturne du PMS a écrasé des restrictions ou rouvert des tarifs.

Résultat :

G2 · L'horizon avance

Regarder la dernière nuit du calendrier Bridg_.

• Attendu : elle a avancé d'un jour (le PMS envoie la nuit entrée dans la fenêtre). XML / OPERA : c'est le réglage de l'Automatic Transmission Schedule qui le garantit ; une fenêtre réglée un jour trop loin tombe au-delà de l'horizon et est écartée sans aucune erreur.
• Échec : l'horizon est resté au même jour.

Résultat :

G3 · Audit du lendemain

Bridg_ relève sur la connexion : messages reçus par nature, refus, émissions en attente ou en échec, réservations portant un numéro PMS, dernier appel du PMS. L'éditeur fournit le même relevé de son côté.

• Attendu : les deux relevés concordent ; aucune émission en échec sans explication ; disponibilité PMS = calendrier Bridg_ sur 5 nuits × 2 types tirées au sort.

Résultat :

---

Synthèse

---

Si quelque chose part de travers

Récupérez l'identifiant du message et son corps exact, pas un résumé : l'écran Interface PMS conserve les octets reçus, votre connecteur doit conserver ceux envoyés. La comparaison des deux tranche entre un défaut d'émission, un défaut d'interprétation et un refus légitime. Un refus déterministe se corrige dans la donnée ou le mapping, jamais en réémettant.