Fiabilité des dossiers
Identifiants de réservation : garder un seul fil entre tous les systèmes
Un voyage peut avoir une référence commerciale, un dossier fournisseur, plusieurs billets ou vouchers et plusieurs transactions. Les relier explicitement évite les confirmations introuvables et les corrections en double.
Réponse directe
Donnez une identité stable au dossier, puis reliez chaque preuve externe
Une réservation de voyage n’est pas un objet unique dans tous les systèmes. Une agence peut créer un dossier commercial avant que le fournisseur ne confirme une chambre. Un transporteur peut attribuer une référence de réservation puis émettre un ou plusieurs billets. Une activité peut produire un voucher par participant. Le paiement possède encore sa propre référence. La bonne question n’est donc pas « quel est le numéro ? », mais « quel système a créé cette référence, à quel objet correspond-elle et dans quel état se trouve-t-elle ? »
Conservez un identifiant interne qui ne change pas quand un fournisseur remplace sa référence. Reliez-y les commandes, segments, voyageurs, paiements et documents. Affichez aux équipes la référence qui leur sert pour agir, avec son libellé précis : numéro de dossier agence, référence compagnie, numéro de billet ou numéro de voucher.
Construire une carte des références plutôt qu’un champ unique
| Objet | Question à résoudre | Exemple de contrôle |
|---|---|---|
| Dossier interne | Quel voyage et quel client suit-on de bout en bout ? | Une référence stable apparaît dans le devis, le service et la comptabilité. |
| Demande technique | La même action a-t-elle déjà été envoyée ? | Une relance après délai dépassé ne produit pas une deuxième vente. |
| Référence fournisseur | Quel dossier le prestataire peut-il retrouver ? | Le support connaît aussi le fournisseur et le canal qui ont émis la référence. |
| Prestation et document | Quel segment, chambre, billet ou voucher est concerné ? | Une annulation partielle n’efface pas les prestations maintenues. |
| Transaction | Quel paiement ou remboursement correspond à quelle opération ? | Le montant et la devise se rapprochent de la bonne version du dossier. |
Une correspondance doit contenir sa source, sa date et, si nécessaire, sa version. N’écrasez pas l’ancienne référence lorsque le fournisseur réémet un billet ou modifie une confirmation : l’historique sert à comprendre une demande ultérieure.
Rejouer un changement qui traverse plusieurs systèmes
- Vendre. Créez un dossier avec un vol, une chambre et une activité. Notez la référence interne, les références des trois prestataires et les documents remis.
- Modifier. Changez la date du vol et d’une seule nuit d’hôtel. Vérifiez quelles références restent stables et lesquelles sont remplacées.
- Encaisser. Ajoutez un supplément et effectuez un remboursement partiel. Rattachez chaque transaction à l’opération correspondante.
- Assister. À partir de la seule référence donnée par le voyageur, retrouvez tous les éléments utiles sans afficher les données d’un autre client.
- Exporter. Sortez le dossier et sa chronologie dans un format que le service peut encore lire hors du logiciel d’origine.
Le résultat attendu est une chronologie compréhensible par une autre personne que celle qui a réalisé la vente. Si un segment ne peut être relié au paiement ou au document remis, le dossier n’est pas suffisamment traçable.
Traiter les délais et doublons sans créer un second voyage
Une réponse technique tardive ne prouve pas que la réservation a échoué. Avant tout nouvel appel, cherchez une confirmation dans les notifications, le portail partenaire ou le support du fournisseur. Utilisez un identifiant de demande lorsque l’interface le permet et gardez la trace de chaque tentative. Lorsque l’état reste incertain, placez le dossier dans une file de vérification humaine plutôt que de répéter l’achat.
Surveillez particulièrement trois anomalies : paiement capturé sans prestation confirmée, prestation confirmée sans paiement attendu et deux confirmations pour une seule demande. Chacune appelle un rapprochement et une décision documentée. Les guides sur les webhooks et le rapprochement des paiements détaillent les flux voisins.
Définir les contrôles et la reprise des données
Mesurez les dossiers sans référence fournisseur, les références dupliquées, les événements reçus sans dossier connu et le délai nécessaire au service pour retrouver une réservation. Une liste d’exceptions quotidienne est souvent plus utile qu’un total de réservations réussies. Attribuez un propriétaire à chaque exception et gardez le lien vers la preuve de résolution.
Avant un changement de plateforme, exportez des dossiers simples et complexes, puis reconstruisez leurs relations dans l’outil cible. Vérifiez que les billets, vouchers et paiements restent lisibles et que les réservations futures peuvent encore être servies. La capacité d’export doit être discutée dès le cahier des charges, pas au moment du départ. Le glossaire précise les notions de référence fournisseur et de réservation orpheline.
Rattacher une correction à la même personne et aux bons titres
Décrivez les relations personne, réservation, titre et services associés. Le nom n’est pas un identifiant stable : il peut être partagé ou corrigé. Lors d’une demande après émission, l’équipe doit retrouver les objets réellement affectés et conserver les références qui n’ont pas changé.
Faites traiter une correction dans le CRM sans intervention fournisseur, puis demandez au testeur de montrer le titre valide. Cet écart révèle la différence entre donnée locale et document de transport. La clôture doit préciser ce qui a été corrigé et ce qui reste à vérifier.
Approfondir : correction et propagation de l’identité.
Préserver les références lorsque le dossier passe entre systèmes
Mews distingue identifiant de réservation, numéro et référence de canal dans son modèle.
Scénario fictif : la référence du client ressemble au numéro de l’OTA mais le support recherche un identifiant interne. Construisez une table de correspondance avec système d’origine, type de référence et périmètre. Un changement de fournisseur ou une réservation à plusieurs chambres peut créer plusieurs objets externes pour un seul dossier client. Ne remplacez pas une référence par la plus récente : conservez ses relations et son état pour retrouver les opérations anciennes.
| Point | Preuve à conserver | Contrôle à effectuer |
|---|---|---|
| Nature | Système et type d’identifiant. | Éviter une jointure fondée sur un libellé seul. |
| Relation | Dossier parent et objets externes. | Tester un cas un-à-plusieurs. |
| Recherche | Référence remise et canal support. | Retrouver le dossier sans session initiale. |
Conservez les références historiques utiles et leurs propriétaires. Une clé unique locale ne rend pas les identifiants fournisseurs interchangeables.
Cas à rapprocher : UUID des dossiers : conserver l’identité sans en faire un droit d’accès
Une référence UUID doit conserver son type d’objet et son producteur à côté du dossier métier. Plusieurs tentatives peuvent avoir leurs propres identités sans créer plusieurs réservations. La forme de la chaîne ne démontre ni un état final ni un droit d’accès.
UUID des dossiers : conserver l’identité sans en faire un droit d’accès · Vérifier les preuves de ce dossier
Mews : fenêtres de synchronisation et références de canal
La version d’opération 2023-06-06 sépare les identifiants de réservation des références reçues d’un canal OTA, GDS ou CRS.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| ReservationIds | Le filtre accepte au maximum 1 000 identifiants de réservation. | Fractionner une reprise de références sans tronquer silencieusement la liste. |
| ChannelNumbers | Les références de canal ont leur propre filtre, limité à 100 éléments. | Conserver le type de référence ; une chaîne OTA n’est pas automatiquement l’Id Mews. |
| CreatedUtc et UpdatedUtc | Les intervalles de ces filtres sont limités à trois mois. | Découper un historique plus long et suivre les bornes réellement traitées. |
| Accès | Les réservations retournées sont limitées au périmètre de l’AccessToken. | Un résultat vide ne démontre pas l’absence de réservation dans les établissements hors périmètre. |
| Version de l’opération | ChannelNumbers accepte 1 000 éléments dans la version 2017-04-12, contre 100 dans la version 2023-06-06. | Conserver le chemin versionné avec la limite avant de construire les lots. |
Limites propres à cette opération documentée ; elles ne décrivent pas toutes les API Mews ni les droits d’un contrat particulier.
Mews Connector API — reservations/getAll/2023-06-06 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
GetYourGuide Supplier : une modification peut conserver la référence GYG
Une demande de changement d’effectif ou d’horaire crée un nouveau cycle de réservation dans le parcours documenté.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Même référence GYG | GetYourGuide crée une nouvelle réserve puis une réservation avec la même référence GYG, mais des données modifiées. | Ne pas ignorer la demande comme un doublon uniquement parce que la référence GYG est déjà connue. |
| Nouveau résultat | L’intégrateur doit détecter les données modifiées et retourner une nouvelle réservation. | Conserver la référence fournisseur et les détails de chaque version. |
| Ancienne réservation | Après réussite de la nouvelle réservation, GetYourGuide demande l’annulation avec l’ancienne référence de réservation fournisseur. | Appliquer l’annulation à la bonne version. |
Parcours Supplier API lorsque le client demande une modification à GetYourGuide ; distinct des droits de l’API partenaire de distribution.
GetYourGuide Integrator Portal — Booking Change · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Entiers JSON : un nombre accepté peut déjà avoir perdu une unité
Un import peut réussir sans conserver tous les chiffres. Pour les quantités et les identifiants du catalogue, contrôlez la valeur reçue avant de comparer, rapprocher ou republier.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Précision du lecteur | RFC 8259 permet aux implémentations de limiter la plage et la précision des nombres. | La validité du document ne garantit pas une lecture exacte par tous vos outils. |
| Plage commune des entiers | Le texte identifie la plage de −9 007 199 254 740 991 à 9 007 199 254 740 991 pour un accord exact entre lecteurs courants. | Testez les valeurs frontières et les grands identifiants dans toute la chaîne. |
| Écritures numériques | La syntaxe autorise fractions et exposants mais pas les zéros initiaux d’un nombre. | Un code 00123 doit garder son statut de texte si ces zéros font partie de son identité. |
| Valeurs spéciales | Les littéraux NaN et Infinity ne sont pas autorisés comme nombres JSON. | Distinguez une erreur de calcul d’une valeur manquante ; ne les remplacez pas automatiquement par zéro. |
Deux contrôles avant de rapprocher des références
Exemples fictifs. Le lecteur interactif de ce guide permet d’observer le comportement du navigateur.
Deux références voisines se retrouvent identiques après import
Un fournisseur fictif transmet deux références comme nombres ; l’interface n’en montre plus qu’une seule valeur.
Référence A : 9007199254740992
Référence B : 9007199254740993
Champ utilisé : identifiant, sans calcul métierLecture du cas. Comparez les données brutes à la valeur obtenue par le lecteur. Une égalité après conversion ne prouve pas un doublon fournisseur ; examinez une représentation textuelle convenue pour préserver l’identité.
Le code commence par deux zéros
Un catalogue fictif utilise le code produit 00123 et l’import veut le convertir en quantité.
Code source : 00123
Rôle du champ : référence de produit
Calcul nécessaire : aucunLecture du cas. Conservez les zéros du code dans le format prévu pour ce champ. Ne normalisez pas une référence en nombre pour faciliter un tri ou une jointure.
Référence JSON consultée le 23 octobre 2026. Le type attendu dépend du contrat de chaque champ. Conserver un identifiant comme texte est une décision à convenir avec le fournisseur, pas une conversion à imposer à toutes les quantités.
IETF — RFC 8259, section 6 : Numbers · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
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.
- Mews Connector API — reservations/getAll/2023-06-06 : Limites propres à cette opération documentée ; elles ne décrivent pas toutes les API Mews ni les droits d’un contrat particulier. (consultée le )
- GetYourGuide Integrator Portal — Booking Change : Parcours Supplier API lorsque le client demande une modification à GetYourGuide ; distinct des droits de l’API partenaire de distribution. (consultée le )
- IETF — RFC 8259, section 6 : Numbers : Référence JSON consultée le 23 octobre 2026. Le type attendu dépend du contrat de chaque champ. Conserver un identifiant comme texte est une décision à convenir avec le fournisseur, pas une conversion à imposer à toutes les quantités. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Faut-il utiliser la référence du fournisseur comme numéro de dossier interne ?
Une référence interne stable facilite le suivi lorsque plusieurs fournisseurs ou plusieurs prestations interviennent. Conservez chaque référence externe dans une table de correspondance avec son émetteur et son état.
Que faire si une confirmation arrive après une réponse de délai dépassé ?
Recherchez d’abord le dossier par l’identifiant de demande et les références connues. Ne relancez pas aveuglément la réservation : vous pourriez créer un doublon. Rapprochez ensuite la confirmation et le paiement.
Une référence suffit-elle à identifier un billet ou un voucher ?
Pas toujours. Un dossier peut contenir plusieurs voyageurs, segments et documents. Stockez les relations entre dossier, prestation, personne, document et version.
Que faut-il exporter lors d’un changement de logiciel ?
Les références internes et externes, leurs relations, les états des prestations, les réservations futures et les événements nécessaires au service après-vente. Testez cet export sur quelques dossiers complexes.
La correction du profil modifie-t-elle le billet ?
Vérifiez le circuit de propagation et le résultat fournisseur. Un changement du profil local ne prouve pas la modification d’un titre déjà émis.
Le numéro affiché au client est-il l’identifiant de l’API ?
Pas nécessairement. Documentez la correspondance et le système qui attribue chaque référence.
Une référence GYG déjà connue désigne-t-elle forcément une demande à ignorer ?
Non. Dans le parcours de modification Supplier documenté par GetYourGuide, la référence GYG reste identique alors que les détails changent et qu’une nouvelle réservation fournisseur est créée. Conservez les versions et leurs références pour annuler ensuite l’ancienne réservation.
Tableau de travail
Relier les références sans les confondre
Proposition de revue éditoriale ; cocher un point ne valide ni un fournisseur ni une réservation.
| Point | Pièce à rapprocher | Suite à préparer | Votre revue |
|---|---|---|---|
| Origine | Référence du canal et système qui l’attribue | Conserver le système avec l’identifiant. | |
| Prestation | Référence fournisseur et lien avec le dossier | Contrôler les doublons avant un rapprochement automatique. | |
| Paiement | Référence de transaction distincte | Retrouver les versements sans remplacer la référence de réservation. |
0 / 3 points marqués comme examinés.
Les marques restent dans cet onglet et ne sont ni envoyées ni enregistrées par ce module.
