Une station, un site qui tient l'année
Le métier station change. Pendant longtemps, un site de domaine skiable pouvait se contenter de tourner cinq mois sur douze, avec un mode veille le reste de l'année. Cette équation ne tient plus. Le tourisme d'été en montagne prend une place qu'on ne peut plus traiter en sous-produit : randonnée, VTT, lacs d'altitude, événements estivaux, séjours bien-être. Sur beaucoup de stations, l'été pèse maintenant dans le chiffre d'affaires au point d'être négocié au même titre que la saison de neige. Un site qui ne porte que l'hiver passe à côté de la moitié de ce que la station vend. La double saisonnalité devient structurelle, et le site doit basculer d'un univers à l'autre sans qu'une équipe ait à reconstruire des pages à chaque changement de saison.
On connaît le terrain avant de coder.
Une station, vue du back-office, c'est un patchwork de briques que personne ne gère seul. Le système d'information touristique, Apidae le plus souvent, tient les hébergeurs, les restaurants, les activités, les événements ; les remontées mécaniques publient leurs ouvertures de pistes via Lumiplan ; les webcams remontent par Skaping ; les ventes de forfaits et de séjours passent par des plateformes tierces, MSEM, Ingenie ou la billetterie maison du domaine skiable. Le visiteur, lui, ne veut pas savoir d'où ça vient : il veut un écran qui réunit l'enneigement du matin, les pistes ouvertes, un lit à la bonne date, le prix du forfait et la météo de jeudi. Le travail consiste à faire cohabiter ces flux sans que la couture se voie, à servir une copie locale pour rester rapide et debout quand un service tiers ne répond pas, et à laisser la station maîtresse de ce qui s'affiche au-dessus.
Sur ce terrain, deux références à l'actif : Avoriaz en 2020 et Flaine en 2024. Avoriaz, c'est un site headless · back-office WordPress et front Nuxt en SSR · branché sur Apidae, Lumiplan, Skaping et Ingenie pour la billetterie. Flaine, c'est WordPress full ACF avec Algolia pour la recherche, intégration Apidae continue, et module MSEM personnalisé pour que la réservation reste dans le tunnel du site plutôt que de partir sur une page tierce. Deux architectures différentes, deux stations très différentes, un même fil : la donnée touristique alimentée automatiquement, l'éditorial qui pose la voix de la destination par-dessus, et un parcours d'achat qu'on ne renvoie pas chez un prestataire au moment où le visiteur est prêt à payer.
La posture qui guide ces projets tient en peu de mots. Un site de station se consulte autant gant à moitié retiré au pied des pistes que sur un grand écran à la maison la veille du départ : on conçoit pour la main mobile avant l'écran de salon, pour la connexion qui faiblit en altitude, pour l'écran qu'un soleil de mars rend illisible. On dimensionne pour le pic, parce que la fréquentation d'une saison se concentre sur quelques week-ends et quelques chutes de neige, et qu'une page qui se fige le matin du premier samedi des vacances coûte plus cher qu'une saison entière de maintenance. Et on assume la réalité météo : un site honnête qui met en avant ce qui reste praticable un jour de redoux garde une crédibilité que des promesses maquillées perdent au premier visiteur déçu.
Les limites, on les pose dès le cadrage. Le site affiche ce que le SIT contient et ce que les prestataires tiers exposent ; une fiche pauvre dans Apidae restera pauvre en ligne, une API de billetterie qui ne propose pas le bon endpoint ne se contourne pas en écrivant plus de code. Quand l'intégration propre n'est pas possible avec un fournisseur, on l'annonce avant de promettre un parcours sans couture qui ne tiendrait pas. Faire tomber la neige, garnir l'agenda d'été, remplir les lits, tout cela reste l'affaire de la station. Le travail commence à l'instant où le visiteur ouvre son écran pour décider de venir, hiver comme été, et s'arrête là où il faudrait inventer ce que la donnée ne porte pas encore.