Deux grands points d'abord, puis le reste. Je suis direct parce que c'est plus utile pour vous que d'être poli. 1. Laissez-nous concevoir le moteur de réservation, ou construisons le nôtre par-dessus le vôtre. Le moteur est notre point de conversion le plus faible, et je le vois dans nos analyses : les gens arrivent sur notre page d'atterrissage, lisent à propos des établissements, explorent plusieurs pages, entrent leurs dates, sont dirigés vers le moteur Little Hotelier et partent. Le taux de sortie à cet endroit est le plus élevé de tout le parcours, et cela est dû à la faible possibilité de modification. Choisir des couleurs n'est pas une personnalisation. Un exemple qu'on nous demande chaque semaine : une maison d'une chambre affiche une icône de personne avec "4", alors que la réalité est deux adultes, un enfant et un bébé. Cette icône crée de la confusion et des emails, et nous ne pouvons ni la modifier ni l'expliquer. Ce dont nous avons besoin, c'est soit un contrôle de conception réel, c'est-à-dire du HTML, CSS et de l'injection de code personnalisé sur le moteur, soit mieux encore une API de réservation headless (recherche, devis, réservation, paiement) pour que nous puissions construire notre propre interface qui alimente directement Little Hotelier. Actuellement, la conception est suffisamment médiocre pour que des établissements comme le nôtre envisagent de passer à un autre système, afin que les prospects pour lesquels nous avons déjà travaillé dur deviennent des réservations. 2. L'API n'est pas suffisante. La récupération de la disponibilité et des tarifs en temps réel s'arrête là. Il n'y a aucun moyen d'écrire un tarif ou une restriction, pas de webhooks lorsqu'une réservation est effectuée, pas d'export iCal ni de flux de réservations, et vos conditions interdisent le scraping, il n'existe donc aucun moyen autorisé pour les outils d'un exploitant hôtelier d'agir sur le compte. Nous avons créé un script qui interroge votre API toutes les trente minutes pour afficher la disponibilité en temps réel sur notre site, et chaque changement de tarif doit encore être effectué manuellement via l'interface web. Mon équipe travaille principalement avec l'IA, Claude en particulier, et c'est aussi le cas pour la plupart des petits exploitants maintenant. Nous avons avancé rapidement en faisant construire par l'IA les systèmes qui connectent notre PMS et notre POS, et Little Hotelier est la partie qui ne peut pas être connectée. Une API de lecture/écriture appropriée, des webhooks et une intégration officielle pour les assistants IA vous permettraient à vous, exploitants comme moi, de gérer la propriété beaucoup plus efficacement, et cela ferait de vous le choix évident pour les clients que vous vendez réellement. 3. Chambres virtuelles. Vendre plusieurs chambres comme une unité, ou une unité comme plusieurs, est essentiel pour un établissement comme le nôtre, et Cloudbeds le fait depuis des années. J'ai été surpris de constater qu'il manquait. 4. Les plans tarifaires fermés apparaissent comme "Complet". Lorsque je ferme la vente d'un plan tarifaire à tarif réduit à certaines dates, les clients voient ce plan listé comme "Complet" à côté du tarif standard pour le même établissement, ce qui donne l'impression que quelque chose est indisponible alors que ce n'est pas le cas. Un plan fermé pour les dates recherchées ne devrait tout simplement pas apparaître. En outre : il n'existe aucune règle pour "ce plan tarifaire ne s'applique pas aux séjours touchant ces dates", donc le seul outil est la fermeture de vente, canal par canal. Le moteur traduit automatiquement les noms de nos établissements. Lorsqu'un navigateur est réglé en thaï, "White House" devient ทำเนียบขาว, la résidence du président américain, "Turquoise" devient la couleur, et l'une de nos descriptions traduites contient un fragment de japonais au milieu d'une phrase thaïlandaise. Les noms propres ne doivent jamais être traduits automatiquement, et nous devons revoir ou surcharger les traductions par langue. 1. Les mises à jour en masse des tarifs écrasent silencieusement. Le dernier tarif enregistré à une date l'emporte, donc enregistrer un tarif de base sur une plage efface les majorations de week-end et de fêtes déjà en place sur ces dates. Il n'y a pas d'aperçu de ce qui changera, pas de possibilité d'annuler et pas de piste d'audit des modifications tarifaires. Nous travaillons désormais selon un ordre strict en trois étapes pour éviter de détruire nos propres prix, ce que aucun exploitant ne devrait avoir à apprendre à la dure. 2. Étiquettes que nous ne pouvons pas contrôler. Chaque tarif dans le moteur indique "30% d'acompte requis" à cause d'un réglage, que ou non une passerelle de paiement soit connectée, et il n'y a aucun moyen de le modifier ou de le masquer. Même famille que l'icône d'occupation : le moteur indique aux clients des choses que nous n'avons pas dites. 3. La sécurité est excessive pour ceux qui l'utilisent quotidiennement. Déconnexions constantes, changements de mot de passe forcés tous les quelques mois, idem sur l'application. Les appareils de confiance, les clés d'accès ou des sessions plus longues sur des appareils connus permettraient de maintenir la sécurité sans la friction quotidienne. Frustrant, mais pas aussi coûteux que les points précédents. Deux plus petits. Les remises pour la durée du séjour sur Airbnb ne sont pas gérées via le channel manager, donc la parité tarifaire y est maintenue manuellement. Et les rapports sont des exports plutôt que des insights : nous avons fini par faire nos propres analyses pour comprendre où les réservations décroissent, ce qui nous permet de confirmer que le point un est vrai. Merci de votre question. Nous aimons le produit, c'est pourquoi le moteur de réservation et l'API comptent tellement pour nous.