Refúgio da Azinheira : l'arithmétique de la réservation directe
Nous avons construit le site et le moteur de réservation d'un refuge rural sur la N2. Le site est la partie facile. Le difficile est de décider ce que l'on ne construit pas.
Une maison rurale qui vit des plateformes de réservation a un problème silencieux : elle n'est pas propriétaire de la relation avec l'hôte. Elle n'a pas son courriel, elle ne choisit pas le message, elle ne fixe pas son prix sans pénalité, et elle cède une part de chaque nuit à celui qui a fait les présentations.
Le Refúgio da Azinheira se trouve sur la N2, en Alentejo. Nous lui avons construit son site et son moteur de réservation directe, et l'objectif n'a jamais été « d'avoir une présence en ligne ». Il était de changer qui contrôle la réservation.
Ce que nous avons décidé en premier : un beau site ne vend rien
C'est là que beaucoup de projets échouent, et nous l'avons vu arriver. On fait un site élégant, avec des photos de couchers de soleil, puis le visiteur clique sur « réserver » et tombe sur un formulaire qui promet une réponse sous 24 heures.
Personne n'attend 24 heures. Pendant ces 24 heures, la personne a déjà réservé ailleurs, parce que l'autre a répondu en dix secondes.
C'est le critère avec lequel nous avons mesuré chaque décision du projet : le chemin entre « ça me plaît » et « c'est réservé » doit être plus court que sur la plateforme. Pas égal. Plus court. Ce qui ne raccourcissait pas ce chemin n'est pas entré.
Ce que nous avons construit, et pourquoi
Nous avons mis la disponibilité réelle à l'écran. Un calendrier qui montre ce qui est libre, maintenant, sans coup de téléphone. Si le visiteur doit demander s'il reste de la place, nous l'avons déjà perdu.
Nous avons synchronisé les calendriers par iCal. C'est le détail qui sépare un projet sérieux d'une brochure, et c'est la pièce à laquelle nous avons donné le plus d'attention. Si les réservations directes ne parlent pas à celles des plateformes, le résultat inévitable est la double réservation : deux familles, une nuit, un lit. Une erreur pareille coûte plus cher que toutes les commissions économisées en un an.
Nous avons choisi WhatsApp, et refusé le formulaire. Dans l'hébergement local, la conversation est le canal. Les gens veulent savoir si les animaux de compagnie sont acceptés, s'il y a de l'ombre, si le portail s'ouvre la nuit. Un formulaire tue cette conversation ; WhatsApp la fait naître sur le téléphone, là où la personne se trouve déjà.
Nous avons fait le site en cinq langues. La N2 est une route internationale. Un visiteur allemand qui arrive sur un site uniquement en portugais n'hésite pas : il retourne à la plateforme, qui parle sa langue. Nous avons mis portugais, anglais, espagnol, français et allemand, avec un hreflang complet, et non par vanité : par conversion. Sans lui, Google montre la page portugaise à l'Allemand, et l'Allemand s'en va.
Le périmètre, et la technologie que nous avons choisie
Site institutionnel et moteur de réservation directe pour un hébergement local, en cinq langues, avec disponibilité en temps réel et synchronisation avec les plateformes.
| Application | ASP.NET Core, servie par Kestrel |
| Hébergement | Azure App Service |
| Internationalisation | 5 langues (PT, EN, ES, FR, DE), avec hreflang complet et x-default |
| SEO | données structurées BedAndBreakfast avec coordonnées et adresse, pour que Google présente la maison comme un hébergement et non comme une page quelconque |
| Réservations | calendrier de disponibilité et synchronisation iCal avec les plateformes |
| Contact | WhatsApp direct, pas de formulaire |
Ce que nous avons refusé de construire
Il existait une version de ce projet avec un CMS headless, une SPA devant, une API au milieu et des microservices qui flirtaient au fond. Elle aurait très bien rendu dans une présentation.
Nous ne l'avons pas faite, et la raison est simple : une maison n'est pas une chaîne hôtelière. Le contenu change une demi-douzaine de fois par an. L'exploitation, c'est une personne avec un téléphone. Chaque pièce ajoutée serait une chose de plus à maintenir, à mettre à jour et à casser, sans rien apporter que l'hôte puisse voir.
Nous avons livré du HTML rendu côté serveur, en ASP.NET Core, sur un App Service. Ennuyeux, solide, et peu coûteux à exploiter.
L'ingénierie difficile n'est pas de choisir la technologie la plus grosse. C'est de choisir la plus petite qui résout le problème, et de savoir la défendre devant le client. Il est plus facile de vendre un canon que d'expliquer à quelqu'un pourquoi il n'en a pas besoin. Nous, nous préférons expliquer.
Ce qui change quand ça marche
La commission économisée est ce qui se voit en premier, et c'est la partie la moins intéressante.
Ce qui change vraiment, c'est que la maison possède désormais les contacts de ses hôtes. Elle peut leur écrire en hiver. Elle peut leur proposer de revenir sans payer personne pour ce privilège. Elle cesse de louer la relation et en devient propriétaire.
Ce que nous ne promettons pas
Nous ne promettons pas que les plateformes cessent d'être utiles. Elles le restent, et elles continuent d'amener des gens qui n'ont jamais entendu parler de la maison.
Le but n'est pas de les quitter. C'est de cesser de dépendre uniquement d'elles. Et pour cela, ce que nous avons construit doit être aussi rapide et aussi fiable qu'elles.
Il est en ligne sur refugioazinheira.pt.
