Lena en septembre 2026 : vers un accueil fiable

Réponse directe : Lena Concierge est développée comme une concierge IA multilingue pour les visiteurs, les hébergeurs et les partenaires touristiques de Saas-Fee/Saastal. En septembre, la priorité n’a pas été d’accumuler les fonctions visibles, mais de consolider le service : retrouver le bon contexte d’une conversation, limiter les données personnelles dans les diagnostics, utiliser des réponses déterministes en cas d’urgence et vérifier que chaque revue de code concerne exactement la version livrée.

L’essentiel en quatre points :

• ✓L’interface visiteurs est disponible en allemand, anglais, français, italien et russe.
• ✓Au 16 septembre 2026, des améliorations concrètes concernant la continuité des échanges, les diagnostics, les urgences et le processus de livraison avaient rejoint la branche principale du projet.
• ✓Une concierge IA est particulièrement pertinente dans une station, où les ouvertures, la météo, les manifestations et les disponibilités évoluent sans cesse.
• ✓Un environnement de test permanent, les procédures complètes d’effacement, une éventuelle connexion à Deskline et un pilote hivernal restent des projets ou des travaux ouverts. Ils ne sont pas encore en production.

Pourquoi une station touristique a besoin d’une concierge IA

Une destination n’est pas un annuaire figé. Le matin, un visiteur veut savoir quelle remontée fonctionne. L’après-midi, une famille cherche une activité adaptée au temps. Le soir, elle souhaite un restaurant. S’ajoutent les questions sur l’arrivée, les événements, la pharmacie, les commerces, le logement et la sécurité.

La vallée de Saas illustre bien cette complexité. La destination officielle réunit quatre communes et tient à jour des informations sur les remontées mécaniques, les sentiers pédestres et VTT, les restaurants d’altitude et les installations de loisirs. Saas-Fee est en outre une station sans voitures, située à 1 800 mètres. Dans ce contexte, une réponse actuelle et liée au lieu vaut davantage qu’une liste générique de conseils.

L’utilité se joue au moment précis de la question

Une concierge IA ne se contente pas de rassembler des contenus. Elle peut formuler une réponse en fonction de la langue, du lieu de séjour, des dates, du groupe et de l’intention immédiate.

Pour une destination, cela représente cinq avantages concrets :

• ✓Des réponses 24 h/24. Le visiteur n’attend pas l’ouverture de l’office du tourisme ou de la réception.
• ✓Un accès multilingue. Un même service comprend et traite les questions courantes dans plusieurs langues.
• ✓Moins de recherches dispersées. La personne reçoit une prochaine étape claire plutôt qu’une dizaine de liens.
• ✓Moins de demandes répétitives pour les équipes. Les professionnels gardent du temps pour l’accueil, le jugement et les situations particulières.
• ✓Une meilleure lecture des besoins. Les thèmes agrégés montrent ce que les visiteurs demandent réellement, à condition que la protection des données soit prévue dès la conception.

Une concierge IA ne remplace ni l’office du tourisme, ni l’hébergeur, ni les secours. Elle répond rapidement aux questions répétitives, s’appuie sur des sources de référence et transmet au bon moment à une personne ou à un parcours d’urgence prédéfini.

Les progrès vérifiés de septembre

Les changements ci-dessous avaient rejoint la branche principale au 16 septembre 2026. Il s’agit de réalisations confirmées. Les chantiers futurs sont indiqués séparément.

Une conversation cohérente pour les visiteurs connectés

Lorsqu’une personne connectée changeait d’appareil ou perdait le stockage local du navigateur, l’historique pouvait réapparaître à l’écran sans que le modèle dispose du même contexte. La restauration relie désormais la réponse suivante à la conversation pertinente.

La limite est volontairement précise : cette amélioration concerne les visiteurs identifiés et connectés. Elle ne signifie pas qu’une conversation anonyme suit automatiquement une personne d’un appareil à l’autre.

Diagnostiquer une panne sans recopier les mots du visiteur

Certains fournisseurs réutilisent une partie de la requête dans leur message d’erreur. Pour une demande de restaurant, cela peut inclure un nom, un contact ou une demande particulière. Lena conserve maintenant des éléments techniques structurés — fournisseur, statut HTTP, code machine — au lieu d’enregistrer sans filtre le texte libre de l’erreur.

Le même principe s’applique aux erreurs des fournisseurs d’IA et aux envois WhatsApp. L’objectif n’est pas de masquer les incidents, mais de pouvoir les réparer sans multiplier inutilement les copies de données personnelles.

Une revue doit porter sur la version réellement livrée

Le processus de livraison vérifie désormais qu’une revue de code mentionne le commit exact qui va être fusionné. L’avis positif donné sur une version antérieure ne peut donc plus valider un code modifié ensuite.

Ce contrôle reste invisible pour les visiteurs, mais il donne du sens à la revue : elle doit couvrir la version qui fonctionnera réellement.

Des parcours d’urgence plus étroits et mesurables

Certains signalements d’urgence ne sont pas traités comme une question ordinaire. Lena renvoie alors des consignes prédéfinies plutôt qu’un texte librement généré.

Une évaluation interne limitée aux signalements d’incendie montre comment ce travail est mesuré. Sur un corpus fixe de 166 exemples annotés en cinq langues, la détection des vrais signalements est passée de 88 à 89 sur 89, la bonne classification du danger de 83 à 89 sur 89, et les fausses alertes parmi 77 cas de contrôle de 13 à zéro. Il ne s’agit pas d’un taux général de sécurité, mais du résultat d’un corpus délimité — utile précisément parce que sa portée est explicite.

Ce qui n’est pas encore terminé

Pour un service destiné aux visiteurs, dire ce qui reste ouvert est plus crédible que de donner une impression d’achèvement total.

Un environnement de test permanent

L’équipe a décidé de créer un environnement non productif permanent, avec ses propres projets de base de données et d’hébergement. Il devra fonctionner sans données réelles de visiteurs et permettre de répéter les essais de livraison. Au 20 septembre, c’est une prochaine étape décidée, pas une infrastructure déjà opérationnelle.

Effacement et droits sur les données

La suppression complète d’un compte de propriétaire n’est pas encore finalisée. La demande vérifiable d’effacement pour un visiteur anonyme reste aussi un problème de conception : sans compte, il faut retrouver les bonnes données tout en vérifiant l’identité de la personne qui en demande la suppression. Ces questions doivent être résolues avant un déploiement large.

Deskline et un éventuel pilote hivernal

Une connexion à Deskline est à l’étude comme prochaine intégration avec la destination, afin de rendre les changements d’information touristique disponibles plus rapidement. Un pilote de six mois pendant l’hiver fait également partie des discussions. Aucun des deux n’est présenté comme déjà lancé.

Les cinq décisions à prendre avant un pilote

La technologie ne suffit pas à créer un service fiable. Une station doit d’abord décider :

• ✓quels systèmes font foi pour les horaires, événements, prix et disponibilités ;
• ✓quelles informations sont publiques et lesquelles sont réservées aux clients vérifiés d’un hébergement ;
• ✓quelles demandes doivent être transmises immédiatement à une personne ou à un parcours d’urgence fixe ;
• ✓comment détecter, corriger et retester une information devenue obsolète ;
• ✓quels indicateurs mesurent l’utilité réelle : activation, questions résolues, escalades, retours ou réutilisation.

Le meilleur point de départ n’est pas un déploiement dans toute la destination. Un pilote délimité, avec des sources nommées, quelques hébergements partenaires, des questions mesurables et une responsabilité humaine, produit plus vite des enseignements solides.

La suite

Lena n’a pas besoin de paraître aussi humaine que possible. Elle doit être réellement utile dans une station : rapide pour les questions courantes, prudente avec les données personnelles, actuelle lorsque les opérations changent et sans ambiguïté lorsqu’une personne ou un service de secours doit prendre le relais.

La prochaine étape ne se mesurera donc pas uniquement au nombre de fonctions. Il faudra vérifier que les livraisons peuvent être répétées en sécurité, que les droits sur les données fonctionnent en pratique et que les informations des partenaires atteignent le visiteur sans retard ni détail inventé.