Aller au contenu
Blog

Marque blanche ou moteur de réservation développé sur mesure

Rédaction Tekravel

Le devis arrive et le montant paraît tenable. Un développeur en qui vous avez confiance a chiffré un moteur de réservation — recherche, résultats, paiement, un back-office, trois mois — et ce n'est pas délirant. Vous voulez votre propre système depuis deux ans. C'est à cet instant que se tranche le choix entre marque blanche et moteur de réservation développé sur mesure, et il se tranche presque toujours sur la mauvaise pièce du dossier : le prix du premier mois plutôt que la forme de la deuxième année.

Le devis est honnête. Il ne chiffre que la partie visible du travail.

Ce qu'un devis chiffre réellement

Presque tous les devis chiffrent des surfaces : un formulaire de recherche, une liste de résultats, une page passagers, une étape de paiement, un tableau de réservations dans le back-office. C'est du vrai travail, et une équipe compétente le fait bien. C'est aussi la moitié banalisée — celle sur laquelle deux agences qui vendent le même Paris–Dubaï ne se battent jamais. Personne n'a jamais choisi une agence parce que son écran de disponibilité était mieux espacé.

L'autre moitié est le côté que l'on ne voit pas depuis un navigateur : celui des fournisseurs. C'est là que passent les années.

Le coût, c'est le nombre d'intégrations, pas l'interface

Demandez un accès à un fournisseur : vous ne recevez pas une API key par retour de courriel. Vous recevez un environnement de test, une procédure de certification, des identifiants délivrés par entité juridique, un document de règles et un interlocuteur qui répond à son rythme. Puis vous découvrez son dialecte : des tarifs statiques ici, de la disponibilité live là, de l'allotement avec release period à côté du free-sale, un cut-off que votre moteur doit respecter, des fare rules qui décident si une modification est payante, un catalogue d'ancillaires qui ne correspond à celui de personne. Multipliez par le nombre de fournisseurs que vos clients attendent de vous.

Une intégration, c'est un projet. Six, c'est un service — et il ne finit jamais, parce qu'aucun de ces six n'a promis d'arrêter de changer.

Ce calcul est précisément ce que le devis laisse dehors, et ce n'est pas une variable d'ajustement face à l'interface : c'est le produit. Sur une plateforme en marque blanche, ce travail est déjà fait et déjà tenu par une équipe : le contenu fournisseur arrive sur la boutique par des groupes de fournisseurs et non par des contrats signés un par un, et un site active vols, hôtels, forfaits ou activités selon ce qu'il vend vraiment.

Le même piège se cache derrière chaque écran que le devis, lui, mentionne. La recherche paraît être une fonctionnalité jusqu'au jour où deux compagnies renvoient le même itinéraire à deux prix et où il faut décider, dans le code, lequel le client voit. Le remboursement paraît être un bouton jusqu'à ce que la fare rule dise pénalité, le fournisseur avoir, et le client sa carte. La marge paraît être un nombre dans une page de réglages jusqu'au jour où il vous faut une règle pour les comptes entreprises, une autre pour un sous-agent à Casablanca et une troisième pour le comptoir, sur le même billet.

La comparaison qui tient en deuxième année

Lisez le tableau en exploitant, pas en achetant. La question de chaque ligne est la même : qui porte le risque ?

 Développer soi-mêmeMarque blanche
Délai avant la première vraie réservationUn cycle de développement, puis la certification avec chaque fournisseurLe jour même, sur un sous-domaine de la plateforme — l'assistant d'inscription le provisionne sans demander de carte
Connexions fournisseursÀ vous de les obtenir, certifier et maintenir, une par uneIncluses ; vous activez celles que vous vendez
Langues et devises au lancementCe que vous avez cadré et payé40 langues, écritures de droite à gauche comprises ; chaque site choisit sa devise par défaut et la liste qu'il propose
Un fournisseur change son APIVotre backlog, à sa date à luiLe problème de la plateforme, réglé une fois pour tous les sites
L'émission tombe à 2 h du matinVous, ou le développeur que vous arrivez à joindreL'astreinte de la plateforme
Changer l'apparence du siteUne mise en productionUn réglage — thème, couleurs, polices et logo se changent depuis le back-office sans redéploiement
Un processus que personne ne vendDéveloppable, exactement comme vous travaillezSeulement si la plateforme le modélise déjà
À qui appartient le codeÀ vousPas à vous — vous détenez la marque, les clients et les conditions commerciales

Deux de ces lignes plaident pour développer. Ce ne sont pas des lots de consolation : si ce que vous vendez est assez particulier, elles pèsent plus lourd que tout le reste du tableau.

Ce que l'erreur coûte vraiment

Un moteur maison ne rate pas en s'effondrant. Un projet qui s'effondre se voit, fait mal, et se surmonte. La version chère, c'est un système qui marche — puis s'arrête lentement.

Le développeur qui l'a écrit passe à autre chose, et le suivant chiffre chaque petite modification comme un risque parce que plus personne n'a lu ce code. Un fournisseur retire un endpoint à sa date, et les réservations commencent à échouer d'une manière que vos clients remarquent avant votre supervision. Une fare rule codée correctement la première année n'est plus revue, et l'ADM qui suit est débitée sur votre numéro IATA, pas sur celui du prestataire. Les identifiants de paiement expirent. Les certificats expirent. Un framework en retard de deux versions devient une conversation de sécurité pour laquelle vous n'aviez pas prévu de semaine.

Rien de tout cela n'arrive sous forme de facture, et c'est pourquoi rien n'apparaît dans la comparaison que les gens font réellement. Cela arrive sous forme d'attention. Un dirigeant qui passe son mardi sur un PNR cassé ne vend pas le mardi, et les agences qui s'éteignent après un développement maison le font rarement parce que le logiciel a lâché : elles s'éteignent parce que celui qui ramenait les affaires est devenu celui qui maintient l'outil.

Quand développer est le bon choix

Cela arrive, et les cas sont assez précis pour que vous vous y mesuriez.

  • Le logiciel est votre différence. Si vous vendez de la technologie à d'autres entreprises du voyage plutôt que du voyage, vous ne pouvez pas sous-traiter ce que vous facturez.
  • Vous employez déjà des ingénieurs et vous avez budgété le deuxième. Pas celui qui développe — celui qui reprend après le départ du premier. Un développement sans plan de succession est une location avec des étapes en plus.
  • Vous avez un processus que personne ne modélise. Un opérateur de pèlerinage qui tient ses propres lits et rattache des PNR de groupe à des jalons de visa ne fera jamais entrer cela tout à fait dans un moteur générique.

Il existe une troisième voie : acheter la boutique et ne développer que la pièce qui vous appartient vraiment. La plateforme expose des API vols et hôtels pour exactement cela, même si l'accès commence par une conversation plutôt que par une clé en libre-service. Chiffrez cet hybride avant de vous engager sur le développement complet, car ce que vous vouliez contrôler est en général un processus, pas un moteur entier.

Et si votre modèle repose sur des sous-agents, chiffrez-le aussi. Les limites de crédit et la facturation de règlement sont ici des notions de premier rang, pas un tableur que quelqu'un rapproche le dimanche ; dans un développement maison, c'est un deuxième projet que personne n'a mis dans le premier devis.

Une question, posée aux deux

Avant de signer quoi que ce soit, posez la même question au développeur et à la plateforme : un fournisseur change sa certification en mars — qui fait le travail, selon le calendrier de qui, et comment suis-je prévenu ? Les réponses ne se ressembleront pas, et l'écart entre elles est ce entre quoi vous choisissez réellement.

Comparer une boutique qui tourne à un devis est un test plus honnête que comparer deux documents ; pour voir ce qui est réellement provisionné avant de vous engager, lancez un site depuis l'assistant — il ne demande pas de carte, et le sous-domaine qu'il vous donne reste en place même après le branchement de votre propre nom de domaine.

Rédaction Tekravel

Desk technologies du voyage

Le desk technologies du voyage de Tekravel écrit pour les professionnels : dirigeants d'agences, consolidateurs et développeurs qui les intègrent. Chaque article est vérifié sur la plateforme qu'il décrit avant publication.