Comment SkiTable est devenue la première plateforme agentique de forfaits de ski

La plupart des systèmes de réservation de ski ont été conçus pour des personnes cliquant sur un site web. Nous pensons que la prochaine vague de réservations viendra d'agents IA agissant pour le compte d'un skieur, alors nous avons reconstruit SkiTable pour être appelée par des logiciels aussi facilement qu'elle est consultée par une personne.

Cet article décrit ce que nous avons livré et pourquoi nous avons fait ces choix.

Le pari

Entre fin 2025 et début 2026, le Model Context Protocol est passé de la préversion à la version stable chez les principaux fournisseurs de modèles, et les assistants grand public ont commencé à recourir à des outils plutôt qu'à répondre à partir des données d'entraînement. Une station qu'un assistant ne peut pas appeler est une station qui disparaît de la liste de recommandations.

Les acteurs établis de la réservation de ski n'ont aucune surface pour agents. C'est l'ouverture, et elle ne reste ouverte que jusqu'à ce qu'ils réagissent. Nous avons donc agi.

Ce que nous avons livré

Un agent peut désormais faire tout ce qu'un acheteur humain compétent peut faire, en un ou deux allers-retours :

• Un serveur MCP doté de neuf outils, couvrant la recherche de stations (texte libre et par caractéristiques), la découverte des régions, les tarifs en direct, la comparaison entre stations, la planification de séjour en groupe, la réservation et l'état des commandes.
• Trois points d'accès REST conçus pour les agents : search transforme une demande en langage naturel en stations classées, plan construit des itinéraires candidats pour un groupe et une plage de dates, et quote renvoie un prix ferme à durée limitée.
• Une interface en ligne de commande (pipx install skitable) pour les développeurs et les agents qui préfèrent appeler un programme plutôt que parler HTTP.
• Des fichiers de découverte pour qu'un agent trouve tout cela en un seul saut : /llms.txt, /.well-known/agent.json et /.well-known/mcp.json, ainsi que des données produit et tarifaires structurées sur chaque page de station.

Tout est agnostique vis-à-vis du fournisseur. MCP est le point d'entrée, mais la surface REST fonctionne pour tout agent qui parle HTTP, quel que soit le modèle derrière.

Des décisions à souligner

Des clés par agent, pas un mot de passe partagé. Chaque agent reçoit sa propre clé avec son propre quota. Cela nous permet d'offrir une formule réellement gratuite (mille requêtes et cinquante stations distinctes par jour, attribution requise, usage non commercial) tout en gardant une responsabilité par agent. Une clé qui se comporte mal peut être plafonnée ou révoquée sans affecter les autres.

Les paiements vont toujours directement à la station. Une réservation initiée par un agent utilise le même modèle de paiement direct qu'une vente web. La station est toujours le commerçant officiel via Stripe Connect, et la plateforme ne détient jamais de fonds. Nous n'allions pas abandonner cela pour un nouveau canal. C'est ce qui gagne la confiance des stations, et cela reste intact.

Un devis ferme, pour que le prix montré soit le prix réservé. Quand un agent demande un devis, il reçoit un jeton signé qui verrouille le prix pendant quelques minutes. La validation honore ce jeton au lieu de recalculer, de sorte qu'il n'y a aucun écart entre "voici le prix" et "voici votre réservation". Le jeton est lié au produit et à la date exacts pour lesquels il a été établi, et il est à usage unique : un prix proposé ne peut donc pas être reporté sur une autre date ni rejoué.

La compréhension des requêtes sans appel de modèle par requête. La recherche en langage naturel lit une demande comme "station familiale au Tyrol à moins de soixante euros" avec un analyseur déterministe, pas un appel de modèle en direct. C'est plus rapide, cela ne coûte rien par requête, et cela n'invente jamais un filtre que le skieur n'a pas demandé. Une étape de compréhension par modèle est un ajout propre pour plus tard, placé devant la même recherche structurée.

Anti-abus sans bloquer les vrais agents

Le risque, en ouvrant une surface de données, est que quelqu'un tente d'aspirer tout le catalogue. Notre défense est discrète et précise : un plafond par clé sur le nombre de stations distinctes vues par jour. Les consultations répétées de la même station sont gratuites, de sorte que le comportement normal d'un agent n'est jamais affecté, mais aspirer tout le catalogue prendrait à une clé gratuite bien plus d'un mois, même à efficacité parfaite. Le plafond est appliqué de façon atomique, il tient donc sous un trafic concurrent.

Les clés gratuites portent une exigence d'attribution : un agent qui présente une station à un skieur affiche un lien "via SkiTable" en retour. Les formules payantes, pour un volume plus élevé et un usage commercial, arrivent ensuite.

Trois façons d'acheter

Le résultat : un skieur peut acheter un forfait sur SkiTable de trois façons : sur le web, via une boutique intégrable sur le site d'une station, ou via un agent IA. La voie des agents est la nouveauté, et à notre connaissance SkiTable est la première plateforme de forfaits de ski à l'offrir comme un canal de premier plan plutôt qu'en accessoire.

La suite

La phase 1 étoffe l'ensemble des outils MCP, ajoute des invites réutilisables, livre des formules payantes avec attribution des réservations par clé pour que les stations voient exactement ce que le trafic des agents rapporte, et étend la même surface pour agents à une plus grande part du catalogue. Les fondations sont en place. Reste à découvrir quels agents nous choisiront.

Si vous construisez un agent de voyage et souhaitez l'essayer, la clé gratuite et la documentation sont accessibles depuis la page "Pour les agents".