Partenariats et opérations
Intégrer un fournisseur voyage : sécuriser la première vente et la centième
Une connexion réussie ne se limite pas à afficher une offre. Elle doit permettre de confirmer la prestation, informer le voyageur, traiter une modification et expliquer les flux financiers. Ce guide transforme ces obligations en essais concrets avant l’ouverture à la vente.
Réponse directe
Écrire la promesse commerciale avant la connexion
Commencez par un produit précis, un marché, un canal de vente et un rôle pour chaque partie. « Nous vendons des hôtels » ne dit pas si le fournisseur confirme immédiatement la chambre, qui encaisse, qui émet le document ni qui répond au voyageur un dimanche soir. Rédigez un dossier type de la recherche au retour du client, puis marquez les étapes tenues par votre équipe, le fournisseur et, le cas échéant, un autre intermédiaire.
Vérifiez les restrictions de distribution avant de charger un catalogue : territoires, marques, devises, clientèle autorisée, prix publics ou négociés et usage des images. Une offre techniquement reçue n’est pas nécessairement commercialisable dans votre contexte. Le calcul de la contribution doit intégrer paiement, support et remboursements, pas seulement la remise affichée.
Aligner contrat, produit et opérations
| Question | Preuve à obtenir | Écart fréquent |
|---|---|---|
| Qui détient le stock ? | Règle de confirmation et de blocage | Disponibilité vue mais non confirmable |
| Quel prix fait foi ? | Devise, taxes, frais et moment de garantie | Montant différent à l’émission |
| Qui encaisse ? | Flux, facture, échéance et remboursement | Paiement client sans réservation |
| Qui assiste ? | Interlocuteur et délai selon l’incident | Voyageur renvoyé entre deux services |
| Comment sortir ? | Export des dossiers et continuité du support | Réservations ouvertes sans responsable |
Gardez la version des conditions applicable à chaque dossier. Les conditions générales d’un site fournisseur, le contrat B2B et la réponse d’une API peuvent porter des périmètres différents : faites confirmer par écrit toute ambiguïté importante.
Tester l’identité des produits et la circulation des données
Reliez l’identifiant fournisseur à votre identifiant produit, à la version du contenu présenté et à la réservation finale. Vérifiez les noms de chambres, options incluses, horaires locaux, coordonnées du lieu et conditions particulières. Un même hébergement peut être présent par deux sources avec des descriptions divergentes : la déduplication doit conserver ce qui change réellement pour le voyageur.
Ne collectez et ne transmettez que les informations utiles à l’opération. La CNIL rappelle le principe de minimisation : chaque donnée personnelle demandée doit correspondre à une finalité. Documentez aussi qui peut corriger une erreur de nom ou supprimer une donnée devenue inutile.
Lancer un pilote qui couvre les cas difficiles
- Charger quelques produits dont les conditions diffèrent : remboursable, non remboursable, disponibilité rare.
- Comparer la recherche et la confirmation au même instant, puis réserver la dernière unité.
- Modifier dates ou voyageurs et vérifier prix, document et notification.
- Simuler un paiement accepté suivi d’un refus fournisseur et attribuer la résolution.
- Annuler une partie du dossier, puis rapprocher avoir, remboursement et relevé.
Conservez les références, dates et réponses de chaque étape. Un refus bien expliqué et réversible vaut mieux qu’un faux succès qui laisse le voyageur sans prestation. La traçabilité des appels aide à isoler ces cas.
Étendre le catalogue à partir des preuves
Ouvrez progressivement de nouveaux produits et canaux. Regardez la part des offres affichées qui peuvent réellement être confirmées, l’âge des données, les erreurs de mapping, les temps de réponse et les dossiers nécessitant une intervention manuelle. Classez les incidents par cause et vérifiez que leur fréquence baisse après correction.
Une fiche de partenariat de deux pages : périmètre vendu, responsabilités, références techniques, contacts d’escalade, scénarios de recette et indicateurs à revoir après trente jours.
Si le fournisseur remplace un acteur existant, appliquez aussi la méthode de migration des dossiers ouverts.
Vérifier le plan d’accès et le sens des objets
Avant le développement, obtenez le plan ou contrat ouvrant les API, les droits du compte et la liste des opérations. Ensuite, mappez un dossier réel : devise, voyageurs, prestations, dates et états. Si vous utilisez un modèle OpenTravel, documentez la version et les écarts avec le fournisseur. Testez une valeur inconnue et un statut sans équivalent interne : la conversion doit préserver l’information source plutôt que fabriquer un état de confirmation.
Logiciels voyage : production, API et modèle de données : fonctions documentées, limites et questions à poser à quatre acteurs du secteur.
Attribuer les accès humains et techniques avant le premier dossier
Le contact commercial, le titulaire du portail et le responsable du connecteur peuvent être trois personnes différentes. Retrouvez la procédure de récupération du compte et préparez le remplacement de l’accès technique. Ces procédures complètent les tests de réservation et de suivi ; elles ne se déduisent pas de l’existence d’une API publique.
Fermer le contrat avant le premier dossier
Scénario fictif : Le fournisseur transmet un exemple réussi, mais sans cas où l’identifiant manque. Demandez ces deux documents et faites montrer à quelle étape l’intégration suspend le dossier incomplet.
| Point | Preuve | Contrôle proposé |
|---|---|---|
| Contrat à conserver | Contrat de document et contre-exemple | Faire préciser ce qui est fourni et ce que le traitement peut conclure. |
| Résultat à rapprocher | Étape de refus et référence interne | Comparer le résultat effectivement observé à celui attendu pour ce cas. |
| Décision de reprise | La vente ne s’ouvre pas sur la seule présence d’un exemple heureux. | Attribuer la suite et garder l’inconnue visible tant que la preuve manque. |
La vente ne s’ouvre pas sur la seule présence d’un exemple heureux.
Cadre documentaire : JSON Schema : vocabulaire de validation 2020-12 — référence consultée le . Validation structurelle 2020-12 ; aucun résultat de validation d’un catalogue réel ni contrôle des droits de vente.
Matrice d’essai · fournisseur fictif
Huit contrôles réussis ne prouvent pas trois parcours complets.
Une équipe teste trois périmètres dans un environnement d’essai : hôtel en France en euros, hôtel en Espagne en euros et activités en France en euros. Pour cet exercice, chaque parcours doit démontrer quatre opérations. Une case « non exécuté » reste une preuve manquante ; elle ne signifie pas que le fournisseur est incapable de l’opération.
| Opération attendue | Hôtel · France · EUR | Hôtel · Espagne · EUR | Activités · France · EUR |
|---|---|---|---|
| Rechercher une offre compatible | Démontré en essai | Démontré en essai | Démontré en essai |
| Créer et retrouver une réservation | Démontré en essai | Démontré en essai | Non exécuté |
| Annuler et retrouver l’état final | Démontré en essai | Non exécuté | Non exécuté |
| Rapprocher la référence et le document de service | Démontré en essai | Démontré en essai | Non exécuté |
- 12 contrôles prévusTrois périmètres × quatre opérations définies pour l’exercice.
- 8 contrôles démontrésLe taux global serait d’environ 66,7 %.
- 1 parcours complet en essaiSeul le périmètre hôtel France a ses quatre preuves.
La recherche d’activités fonctionne, mais la vente reste à démontrer.
Trois recherches réussies ne prouvent pas trois circuits de réservation exploitables. Pour l’hôtel Espagne, l’annulation reste à jouer. Pour les activités, création, annulation et document de service manquent encore. Le taux global ne doit pas masquer ces dépendances.
Quelle prochaine séance de test préparer ?
Choisissez le parcours prioritaire et jouez ses opérations manquantes avec les mêmes références. Conservez l’état avant et après, les interventions humaines et les limites. Ajoutez ensuite les exceptions propres au produit plutôt que de multiplier seulement les recherches réussies.
Que manque-t-il encore pour passer en production ?
Les droits du compte réel, le périmètre commercial confirmé, les références et moyens de paiement nécessaires, les responsabilités de service et les procédures de reprise. Un résultat en essai reste attaché à son environnement, à ses données et à la version de l’interface ; il ne démontre pas l’accès au même service en production.
Les douze cases sont une trame simplifiée, sans pondération. Adaptez les opérations obligatoires au produit vendu et gardez les exigences bloquantes visibles. Consulter la matrice de couverture · Organiser le pilote et la décision.
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.
Mews : arrêter la synchronisation ne prouve pas que les ventes sont fermées
Pour fermer une distribution hôtelière, vérifiez les ventes encore accessibles sur chaque canal. Le réglage de synchronisation et la fermeture commerciale demandent des preuves distinctes.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Tarif non synchronisé | Mews peut encore recevoir des réservations d’un tarif non synchronisé, sans envoyer ses mises à jour de prix et de restrictions. | N’utilisez pas ce seul réglage comme preuve d’arrêt des ventes. |
| Retrait d’une catégorie d’un tarif | La chambre reste réservable via d’autres tarifs synchronisés du channel manager. | Inventoriez les couples catégorie–tarif encore ouverts pour les dates à fermer. |
| Réception de réservations | Si Download reservations ou Receive reservations reste actif, la réception peut continuer malgré la déconnexion. | Faites vérifier les opérations de l’intégration utilisée et désignez l’équipe qui reprend les nouveaux dossiers. |
| Inventaire déjà transmis | La déconnexion ne retire pas l’inventaire déjà envoyé au channel manager. | Contrôlez le calendrier externe et faites confirmer la fermeture par le canal concerné. |
Deux fermetures à contrôler côté distributeur
Tarifs et calendriers fictifs.
Le tarif flexible est retiré mais le non remboursable reste ouvert
Une chambre fictive était vendue avec deux tarifs. L’équipe retire son association au tarif flexible sans examiner le second.
Tarif flexible : association retirée
Tarif non remboursable : encore synchronisé
Date à fermer : 15 novembreLecture du cas. Contrôlez aussi le second tarif pour le 15 novembre. La preuve de fermeture doit couvrir les chemins de vente concernés, avec une trace du résultat côté canal.
L’intégration est désactivée mais le calendrier externe affiche encore une offre
Une équipe fictive coupe une intégration après un dernier envoi d’inventaire. Elle observe ensuite une offre encore affichée par le distributeur.
Dernier envoi d’inventaire : effectué
Intégration : désactivée
Offre externe : encore affichéeLecture du cas. Faites reprendre l’offre par le responsable de distribution et vérifiez la fermeture auprès du canal. Conservez les références des réservations éventuellement reçues pendant la transition.
Référence Mews consultée le 23 octobre 2026. Les options varient selon l’intégration. Cette grille sert à préparer une fermeture avec les équipes concernées ; elle ne déclenche aucune déconnexion.
Mews — Connect and configure your channel manager integration · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Duffel : lire la limite du point d’accès et l’heure de réouverture
Une recherche bloquée par un quota demande de relire les en-têtes de la réponse. Elle ne prouve pas une panne de la compagnie.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Quota appliqué | ratelimit-limit donne le plafond de la période et ratelimit-remaining le nombre restant. | Conserver le point d’accès et l’environnement ; ne pas recopier le quota d’une autre opération. |
| Reprise après 429 | Le code rate_limit_exceeded demande d’attendre le moment indiqué par ratelimit-reset, exprimé comme une date HTTP. | Lire une date, pas un nombre de secondes ; éviter de renvoyer immédiatement tous les appels en attente. |
| Autres erreurs | Le tableau Duffel demande de ne pas réessayer les erreurs serveur 500 et 502 et de transmettre le request_id au support. | Définir le traitement par code et par opération, sans règle universelle « toute erreur serveur se relance ». |
Comportement Duffel documenté. Aucune limite de compte ni autorisation de nouvelle réservation ne découle de cet exemple ; une écriture à résultat incertain doit être rapprochée séparément.
Duffel — Response handling · 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.
- Tourplan : Production et gestion des voyagistes et DMC : Tourplan présente un ensemble opérationnel et comptable pour voyagistes et DMC, avec sourcing, devis et interfaces web/XML. (consultée le )
- Kaptio : Plateforme de voyage multi-jours : Kaptio présente une plateforme d’achat, vente et exploitation du voyage multi-jours, issue de l’écosystème Salesforce. (consultée le )
- WeTravel APIs : Échanges de données de réservation et paiement : WeTravel indique ses API comme fonctionnalité Pro et liste notamment Booking, Transactions, Payment Links et Suppliers. (consultée le )
- OpenTravel Alliance : Modèle d’objets d’échange touristique : OpenTravel présente un modèle d’objets 2.0 avec des bibliothèques réutilisables pour structurer les échanges du voyage. (consultée le )
- JSON Schema : vocabulaire de validation 2020-12 : Validation structurelle 2020-12 ; aucun résultat de validation d’un catalogue réel ni contrôle des droits de vente. (consultée le )
- 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 )
- Mews — Connect and configure your channel manager integration : Référence Mews consultée le 23 octobre 2026. Les options varient selon l’intégration. Cette grille sert à préparer une fermeture avec les équipes concernées ; elle ne déclenche aucune déconnexion. (consultée le )
- Duffel — Response handling : Comportement Duffel documenté. Aucune limite de compte ni autorisation de nouvelle réservation ne découle de cet exemple ; une écriture à résultat incertain doit être rapprochée séparément. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Que faut-il vérifier avant de signer avec un fournisseur ?
Définissez le produit vendu, les marchés et canaux autorisés, la source du prix et du stock, les responsabilités de paiement et de support, les conditions d’annulation et la restitution des données. Demandez un scénario complet plutôt qu’une simple liste de fonctions.
Une API fonctionnelle suffit-elle pour lancer la vente ?
Non. Il faut aussi confirmer la qualité du contenu, l’écart entre recherche et réservation, les documents reçus, les cas d’échec et les procédures humaines. Un pilote sur peu de produits et de canaux permet d’observer ces points.
Comment juger la qualité du lancement ?
Suivez confirmations reçues, refus après affichage, tickets de support, écarts de prix et délais de résolution. Reliez chaque incident au fournisseur, au produit et à sa cause avant d’étendre le catalogue.
Fermer le contrat avant le premier dossier : quelle preuve conserver ?
Conservez contrat de document et contre-exemple, étape de refus et référence interne et la décision attribuée. La vente ne s’ouvre pas sur la seule présence d’un exemple heureux.
