Comment les données des clients restent séparées
Un client demande le mot de passe Wi-Fi. Un autre demande le même mot de passe sans jamais avoir mis les pieds dans cet appartement. Ce qui les distingue n’est pas une règle dans le prompt.
La première décision d’architecture de ce projet a été prise durant la deuxième semaine et porte encore tout le système : il existe deux espaces de connaissances, pas un seul. Les informations publiques sur Saas-Fee — restaurants, remontées mécaniques, météo, événements, pharmacie, accès — se trouvent dans un corpus que tout le monde peut interroger. Tout ce qui concerne un appartement ou un hôtel précis se trouve dans un second corpus, qui n’est jamais consulté sans un accès client valide.
La distinction paraît évidente jusqu’à ce que l’on construise l’alternative. Un corpus unique accompagné d’une règle de prompt disant « ne fournir les données de l’hébergement qu’aux clients autorisés » transfère le contrôle d’accès à un modèle de langage. Ce n’est pas un contrôle d’accès, c’est une demande.
Ce qui fait d’un client un client
L’accès est accordé de deux manières : par un lien personnel fourni par l’hébergement, ou par une session vérifiée au moyen d’un code à usage unique envoyé par SMS. Les deux aboutissent à des jetons, et une règle s’applique ici sans exception : seul le hachage SHA-256 est enregistré, jamais la valeur elle-même. Lire la base de données ne permet donc pas de se connecter.
- Code SMS à usage unique : valable 10 minutes
- Session client : 90 jours
- Accès d’un client à un hébergement : jusqu’à 12 mois après le séjour
- Conversations et réservations : jusqu’à 24 mois
Ces durées ne figurent pas seulement ici. Elles sont consignées dans le registre interne des traitements RGPD, avec chaque service qui voit des données et la raison pour laquelle il les voit. Un client peut demander à tout moment une copie ou la suppression de ses données ; une page et une adresse sont prévues à cet effet.
Ce qui arrive de l’extérieur ne fait pas foi
Twilio, Meta et apaleo appellent nos points de terminaison. Chacun de ces appels est vérifié à l’aide de sa signature et journalisé — mais la seconde règle est encore plus importante : le contenu d’un webhook n’est pas utilisé comme source de données. Quand apaleo signale qu’une réservation a changé, nous relisons cette réservation dans l’API à partir de son identifiant. Falsifier le message ne permet donc pas de falsifier une réservation.
Le parcours d’urgence
Lorsque Lena reconnaît une urgence médicale, la réponse provient d’un texte fixe : le numéro des secours d’abord, puis les informations à donner à la centrale, puis la Rega pour les endroits qu’un véhicule ne peut pas atteindre. Aucun modèle ne rédige cette réponse et aucune des dix règles complémentaires qui réécrivent les autres réponses ne la modifie. Un modèle qui passe une mauvaise journée ne doit pas se trouver entre un client et un numéro d’urgence.
Ce qui est écrit ici a été mesuré. Ce qui manque est nommé.
Et quelque chose manque. Aucun outil de suivi des erreurs n’est actuellement en service et aucune surveillance externe ne teste le parcours d’urgence depuis l’extérieur. Aujourd’hui, nous apprenons qu’une panne existe lorsqu’un client nous la signale. Ce sont les deux prochaines étapes, dans cet ordre : rendre une panne visible est la condition nécessaire pour pouvoir vérifier tout ce qui suit.