Procédure de certification

Cette procédure s'applique à tout éditeur de PMS, CRS ou intégrateur qui a terminé le développement de sa connectivité avec Bridg_ et souhaite la mettre en production. Elle est la même pour les deux modèles (XML on-premise et JSON cloud). La certification porte sur le connecteur (une version donnée du logiciel de l'éditeur), pas sur un hôtel : une fois certifié, chaque établissement suivant n'a plus qu'une mise en service courte (§ 8).

Résultat attendu : un certificat Bridg_ qui autorise l'activation de connexions en production, et l'URL de production remise à l'éditeur.

Un point bloquant à n'importe quelle phase renvoie à la phase précédente ; rien ne passe en production avant la phase 6.

---

1. Dossier de candidature (éditeur)

Première prise de contact : le formulaire Demande de connectivité au bas de cette page (ou votre contact Bridg_). Bridg_ renvoie la fiche de candidature (annexe) à compléter. Sans ce dossier, aucune connexion staging n'est créée.

Identité et contacts

• Éditeur, produit PMS, version du connecteur présentée à la certification (numéro figé : c'est elle qui sera certifiée).
• Contact technique (nom, e-mail, téléphone) et contact d'astreinte joignable pendant le pilote et après la mise en production.
• Modèle choisi : XML on-premise (opera-oxi ou XML Fidelio vendor-neutral) ou JSON cloud (json).

Architecture

• Qui initie les connexions, depuis quelles adresses IP sortantes (pour l'hôtel pilote et pour la production).
• Hébergement du connecteur (chez l'hôtel, cloud de l'éditeur, tiers) et pays d'hébergement des données de réservation.
• En JSON : l'URL de l'API que le PMS expose à Bridg_ (webhook) et sa politique de disponibilité.

Notes de capacité (reprises telles quelles dans le certificat)

• Variantes de durée de séjour supportées (min stay à l'arrivée / sur le séjour, max stay).
• Restrictions non supportées par le PMS.
• Multi-chambres et multi-tarifs dans une même réservation : oui / non.
• Prix par occupation (1..N) ou occupation de référence seulement.
• Horizon ARI que le PMS est capable d'envoyer (365 jours attendus).
• Devises gérées ; fuseau horaire des dates envoyées.

Sécurité

• Où et comment le secret est stocké (chiffré, jamais journalisé), et comment il est remplacé en cas de compromission.
• Confirmation écrite qu'aucun numéro de carte ne transite (paymentCardToken est un jeton PSP, rien d'autre).
• Version TLS minimale du client HTTP (1.2 ou plus) et validation du certificat serveur.

---

2. Mise en place staging (Bridg_ et hôtel pilote)

1. Bridg_ désigne avec l'éditeur un hôtel pilote (réel ou fictif sur staging) et crée la connexion en statut PENDING dans le menu Interface PMS de cet établissement.
2. Les identifiants sont remis à l'éditeur : connectionId, clientToken, secret (affiché une seule fois). L'éditeur confirme leur réception et leur stockage.
3. Les codes sont mappés : au moins 2 types de chambre et 2 plans tarifaires, plus un code volontairement non mappé pour le test 10.
4. JSON : l'API du PMS est enregistrée (Réglages → API du PMS) et Tester la connexion affiche le catalogue du PMS.
5. XML : la configuration OXI (ou équivalente) pointe l'URL staging ; corps non compressé (zipData=N) ; rateEndDateInclusive laissé par défaut jusqu'au test 5.

---

3. Auto-recette (éditeur)

L'éditeur déroule lui-même le cahier de recette pas à pas, qui met en œuvre les 19 tests de certification et y ajoute la mesure de fréquence et de volume (§ E) et le contrôle du lendemain (§ G) : scénarios A à B en PENDING, passage en ACTIVE, scénarios C à G. Pour chaque test, la grille porte le résultat et l'identifiant du message (messageId JSON ou transactionId XML) qui le prouve : c'est cet identifiant que Bridg_ retrouve dans ses journaux à la phase 4.

Critères de passage de la phase :

• les 19 tests sont OK, ou N/A avec une justification reprise dans les notes de capacité ;
• aucun des anti-patterns listés dans la page des tests n'a été observé ;
• la grille est transmise avec la version du connecteur et la date.

---

4. Contrôle Bridg_ (ce que nous vérifions nous-mêmes)

Bridg_ ne se contente pas de la grille : chaque point ci-dessous est contrôlé dans les journaux de la connexion (messages entrants avec leur corps exact, émissions sortantes, erreurs par message). Bloquant = certification refusée tant que ce n'est pas corrigé ; réserve = certification possible, mention au certificat.

Forme des messages

• ☐ Un message porte plusieurs items ; pas un item par appel — bloquant.
• ☐ Les natures (disponibilité, prix, restrictions) sont séparées dans des messages homogènes — réserve.
• ☐ Identifiant de message unique et stable ; deux envois du même identifiant donnent l'accusé mémorisé — bloquant.
• ☐ Dates au format AAAA-MM-JJ, plage [from, to) en JSON, borne de fin vérifiée en XML — bloquant.
• ☐ Corps non compressé, UTF-8, moins de 5 Mo — bloquant.
• ☐ Horizon : 365 jours glissants couverts par la synchronisation complète — réserve si moins.

Comportement dans le temps

• ☐ Après la synchronisation initiale, le PMS envoie des deltas ; aucun full sync sur minuterie à quelques minutes — bloquant.
• ☐ Un refus déterministe (UNMAPPED_UNIT_TYPE, VALIDATION_ERROR…) n'est pas réémis en boucle — bloquant.
• ☐ Un 500 de Bridg_ est réémis après un délai croissant ; un 429 ralentit l'envoi sans perdre de mise à jour — bloquant.
• ☐ Débit observé sous 600 requêtes / minute, envois séquentiels pour une même connexion — bloquant.
• ☐ Fréquence et volume (cahier § E) : régime calme sans message, une action = un message par nature, synchronisation complète en quelques messages, au plus un full sync par jour, aucun doublon de contenu — bloquant au-delà des seuils du cahier.
• ☐ Les messages sont envoyés dans l'ordre chronologique ; aucune modification périmée n'écrase une annulation — bloquant.

Réservations Bridg_ → PMS

• ☐ Le PMS n'acquitte qu'une fois la réservation écrite chez lui (RESULT XML / 2xx JSON) — bloquant.
• ☐ Les révisions sont appliquées dans l'ordre ; une révision périmée est ignorée — bloquant.
• ☐ Un refus métier est signalé explicitement (RESULT FAIL, success: false, 4xx) et visible en dead-letter — bloquant.
• ☐ Pendant une panne simulée du PMS, aucune réservation n'est perdue ni dupliquée — bloquant.
• ☐ Le PMS renvoie la disponibilité autoritaire par le flux ARI après chaque réservation reçue — bloquant.

Réservations PMS → Bridg_

• ☐ La réservation porte sa date de création (bookedAt / originalBookingDate) et le message ARI qui suit confirme le chiffre, sans double décompte — bloquant.
• ☐ Devise du prix cohérente avec le tarif (CURRENCY_MISMATCH absent des journaux) — bloquant.

Sécurité

• ☐ TLS 1.2 ou plus, certificat serveur vérifié par le client — bloquant.
• ☐ JSON : signature HMAC-SHA256 correcte sur le corps exact ; XML : secret uniquement dans ?key= ou Basic — bloquant.
• ☐ Le secret n'apparaît dans aucun journal, URL de diagnostic ou e-mail échangé pendant la recette — bloquant.
• ☐ Aucun numéro de carte dans aucun message — bloquant, et fin de la certification.
• ☐ Régénération du secret testée : l'ancien couple est refusé immédiatement, le connecteur repart avec le nouveau sans intervention à chaud — réserve.

Robustesse

• ☐ Rejeu d'un message déjà traité : accusé mémorisé, rien appliqué deux fois — bloquant.
• ☐ Reprise après redémarrage du connecteur : les envois reprennent sans perte ni doublon — réserve.

---

5. Pilote en conditions réelles

Un hôtel réel, sept jours d'exploitation, connexion ACTIVE, avec l'astreinte de l'éditeur joignable.

• Jour 0 : activation, libération des réservations retenues pendant la recette, synchronisation initiale complète, première réservation directe de contrôle acquittée par le PMS.
• Jour 1 : audit du lendemain par Bridg_ (messages entrants, émissions, dead-letters, écarts de disponibilité entre le PMS et le calendrier Bridg_).
• Jours 1 à 7 : exploitation normale, journal tenu par l'éditeur et Bridg_.

Critères de passage :

• aucune réservation perdue ni dupliquée, dans aucun des deux sens ;
• aucune dead-letter sans explication ni correction ;
• aucun écart de disponibilité non expliqué entre le PMS et Bridg_ ;
• aucune boucle de réémission ni dépassement de débit ;
• tout incident traité dans le délai convenu avec l'astreinte.

---

6. Décision et certificat

Trois issues possibles :

Le certificat mentionne : éditeur, produit, version du connecteur, modèle (XML/JSON), date, notes de capacité, réserves, hôtel pilote, référence de la grille de contrôle. Il est lié à la version : une version majeure suivante, ou un changement de modèle, passe à nouveau par les phases 3 à 5 (phases 1 et 2 allégées).

---

7. Après la certification — engagements de l'éditeur

• Astreinte : un contact joignable, délai de première réponse convenu pour un incident bloquant (réservations non livrées, ARI arrêté).
• Changements : prévenir Bridg_ 30 jours avant toute modification du connecteur touchant les messages, l'authentification ou l'API webhook ; une version majeure se recertifie.
• Secrets : rotation à la demande de Bridg_ ou de l'hôtel, sous 24 h, sans perte de message.
• Suivi du changelog Bridg_ : les évolutions de l'interface sont publiées dans la documentation ; les changements incompatibles sont annoncés 30 jours avant et versionnés dans l'URL (/api/pms/v1/…).
• Retrait : des incidents répétés non corrigés (perte de réservations, boucles d'envoi, fuite de secret) entraînent la suspension du certificat ; les connexions passent en PAUSED jusqu'à correction et nouvelle recette.

---

8. Mise en service d'un hôtel supplémentaire avec un PMS déjà certifié

Pas de nouvelle certification : une mise en service courte, menée par l'hôtel avec l'éditeur.

1. Création de la connexion par le propriétaire (menu Interface PMS), identifiants remis à l'éditeur.
2. Correspondance de tous les codes de l'hôtel (types de chambre, plans tarifaires).
3. Synchronisation complète en PENDING ; contrôle du calendrier Bridg_ sur quelques dates et tarifs (prix, stop-sell, borne de fin de plage).
4. JSON : API du PMS enregistrée et testée. XML : rateEndDateInclusive vérifié.
5. Activation (ACTIVE), libération des réservations retenues, réservation directe de contrôle acquittée par le PMS.
6. Audit du lendemain par Bridg_.

---

Annexe — Fiche de candidature (à retourner)

Annexe — Modèle de certificat

Certificat d'interface PMS — Bridg Channel Manager
Éditeur : …            Produit : …            Version du connecteur : …
Modèle : XML on-premise / JSON cloud          Date : AAAA-MM-JJ
Hôtel pilote : …       Grille de contrôle : réf. …
Décision : Certifié / Certifié avec réserves / Refusé
Notes de capacité : …
Réserves : …
Validité : cette version ; recertification à la version majeure suivante.