Hachage d'intégrité SHA-256. Gestion structurelle mineurs/tuteurs. Révocation automatique. Pas du blabla marketing — voici exactement ce qui se passe sous le capot.
Chaque participant dans un parc doit signer une décharge de responsabilité (waiver) avant de pouvoir participer. Le système l'impose à chaque point d'entrée — réservation en ligne, inscription sur site, check-in au POS et réclamation de tickets. Une décharge est toujours liée à un parc spécifique et à un utilisateur spécifique. Si un utilisateur visite plusieurs parcs sur la plateforme, il signe une décharge séparée pour chaque parc.
Le processus de signature comporte 6 étapes, déclenché après l'inscription, la réservation ou la réclamation de ticket.
Après l'inscription, la réservation ou la réclamation de ticket, l'utilisateur est redirigé vers la page de conformité.
Le système vérifie si l'utilisateur a déjà une décharge valide pour ce parc. Si oui, l'étape de conformité est entièrement ignorée.
L'utilisateur voit le texte complet de décharge de responsabilité du parc, un résumé de ses données personnelles, et est invité à fournir son adresse, taper son nom légal complet, dessiner sa signature et confirmer son acceptation.
À la soumission, le système capture et stocke toutes les données de la décharge, y compris les hachages cryptographiques.
Un job en arrière-plan génère une copie PDF de la décharge signée et la stocke avec l'enregistrement de la décharge.
L'utilisateur est renvoyé là d'où il venait — confirmation de réservation, inscription ou aperçu de réclamation.
Chaque décharge signée enregistre 15 points de données pour la protection juridique et la traçabilité forensique.
Oui. Le système calcule un hash SHA-256 sur une représentation JSON canonicalisée de toutes les données de la décharge — nom, email, téléphone, date de naissance, texte du document, nom de signature, IP, user agent et adresse. Ce hash est stocké sur l'enregistrement de la décharge et imprimé sur le PDF.
Si un champ de l'enregistrement de la décharge était modifié après la signature, le hash ne correspondrait plus. Cela fournit une preuve cryptographique que les données stockées de la décharge n'ont pas été falsifiées depuis le moment de la signature.
L'image de signature a sa propre somme de contrôle SHA-256 séparée, calculée au moment de l'upload. Cela prouve indépendamment que le fichier de signature n'a pas été modifié.
C'est plus solide que l'approche par ID de document de Smartwaiver (un identifiant opaque, pas une preuve cryptographique) et l'approche de chiffrement seul de ROLLER (pas de hash par décharge documenté publiquement).
Un mineur (toute personne en dessous de l'âge légal du parc, typiquement 18 ans) ne peut pas signer sa propre décharge et ne peut pas être le titulaire de la réservation. Un parent ou tuteur légal doit créer son propre compte, signer la décharge au nom du mineur et ajouter le mineur comme participant.
Un schéma de validation Zod vérifie la date de naissance par rapport à l'âge légal du parc. Les soumissions de mineurs sont rejetées avec des instructions claires pour les mineurs et les parents désorientés.
Le premier écran demande : Adulte ou Enfant ? Sélectionner Enfant oblige l'adulte à s'inscrire d'abord.
Lors de la réclamation d'un ticket pour un enfant, le système exige qu'un adulte soit identifié en premier.
Quand le personnel demande une décharge pour un mineur, un overlay les oblige à chercher et sélectionner l'adulte responsable en premier.
Le champ signedBy pointe toujours vers l'adulte qui a signé — jamais vers l'enfant. Le PDF montre clairement 'Signé pour : [enfant]' et 'Signé par : [parent]'.
signedBy et userId sont des champs de première classe séparés dans le modèle de données. La relation signataire-participant est structurelle, interrogeable et imposée par le code — pas juste une distinction textuelle sur un formulaire comme chez Smartwaiver ou ROLLER.
Oui. Quand le personnel modifie le profil d'un utilisateur via le POS, la décharge est automatiquement invalidée et doit être re-signée avec les données actuelles. Le personnel peut aussi explicitement demander une nouvelle décharge, ce qui révoque la décharge actuelle et envoie une demande de conformité à la tablette.
Chaque re-signature crée une nouvelle WaiverVersion. Toutes les versions précédentes sont préservées et interrogeables. L'historique complet des signatures d'un utilisateur dans un parc est toujours disponible.
| Fonctionnalité | wakesys | Smartwaiver | ROLLER |
|---|---|---|---|
| Capture de signature dessinée | |||
| Texte complet du document conservé par signature | |||
| Hash d'intégrité SHA-256 par décharge | (doc ID) | ||
| Somme de contrôle SHA-256 sur l'image de signature | |||
| Adresse IP capturée | |||
| User agent du navigateur capturé | |||
| Génération PDF par décharge | |||
| signedBy / signedFor séparés dans le modèle de données | Non (niveau formulaire) | Non (niveau formulaire) | |
| Historique des versions de décharge par utilisateur | |||
| Révocation automatique lors de modification de profil | |||
| Vérification d'âge au checkout de réservation | N/A (pas de réservation) | Au niveau de la décharge | |
| Vérification d'âge à l'inscription sur site | N/A | Au niveau de la décharge | |
| Demande de décharge en temps réel au POS | N/A (pas de POS) | ||
| Expiration de décharge avec rappels | |||
| Certifié SOC 2 Type II |
Nous croyons en la transparence sur ce que le système fait et ne fait pas.
La vérification d'âge n'est pas une vérification d'identité. Il n'y a pas d'upload de pièce d'identité ni de contrôle biométrique — le système se base sur des déclarations sincères, comme tous les systèmes de réservation en ligne.
Les PDF sont générés de manière asynchrone. L'enregistrement en base de données avec son hash d'intégrité est l'enregistrement faisant foi, pas le PDF.