Concevez la politique. Testez les échecs. Puis décidez.
NP AgeVerify 1.2.11 combine règles pays/catalogue, quatre méthodes déclaratives, textes par langue et storefront à votre marque. Inspectez décision, vraie UI, données stockées et limites sans envoyer de données personnelles.
- 1.2.11
- ZIP déterministe · SHA-256 publié
- 4
- méthodes déclaratives
- 6 × 5
- thèmes × mises en page
- PS 8 + 9
- runtime réel vérifié
Un age gate est un système de politique, pas seulement un popup.
Choisir le modèle de preuve
Date, année, case et Oui/Non sont des déclarations. Aucune n’établit l’identité.
Définir la priorité des âges
Le pays remplace la base ; catégorie, produit et panier peuvent l’augmenter. Le maximum gagne.
Concevoir l’interruption
Choisissez six thèmes, cinq layouts, logo, icône, palette, fond, consentement et exclusions.
Assumer les opérations
Surveillez audit/analyses, exportez CSV, testez RGPD et opérez la rétention. Les sept jours ne concernent pas l’audit.
Inspectez la version exacte avant de lui confier une politique réelle.
Comparez le ZIP livré, les sources PS8/PS9 identiques, les catalogues et les vraies captures EN/FR/ES/IT, puis vérifiez si l’auto-déclaration convient au risque et à votre exploitation.
Une version publique, une identité d’artefact privé.
Le pointeur de version courante et le chemin privé résolvent vers le même ZIP déterministe utilisé par tous les contrôles.
993ab5b044446d751ad29698251effa43ecba6b8a18655973b1cae5bcee0b4f8Le package n’a pas de Product Key PrestaShop et aucun passage authentifié du Validator officiel n’est revendiqué. La soumission marketplace reste bloquée malgré la livraison directe active.
Reproduisez le portail sans envoyer de données personnelles.
Utilisez une date inventée. Modifiez politique, pays détecté et niveaux catalogue pour voir âge effectif, cookie, paiement et audit.
- Âge exemple calculé
- 24
- Âge effectif requis
- 21+
- Portail sur cette surface
- Visible
- Cookie de décision
- Serait posé pour 30 jours
- Paiement
- Aucune redirection dans cet état
Enregistrement navigateur
Token signé first-party HttpOnly np_age_verified ; SameSite=Lax ; Secure en HTTPS ; session de secours si nécessaire.
Enregistrement serveur
Événement de cet état: verify / passed / birth_year 2002
Colonnes de la table livrée
id_shop · id_customer · id_cart · event_type · result · rule_context · minimum_age · birth_year · ip_hash · user_agent_hash · date_add
La 1.2.11 n’a aucune purge automatique du journal. Les jours cookie ne suppriment pas l’audit ; les sept jours concernent seulement les lignes techniques.
Simulateur produit uniquement. Il ne détermine ni âge, preuve, base, rétention ou contrôle livraison applicable.
Les valeurs restent dans ce navigateur et ne sont jamais envoyées. Utilisez uniquement des exemples inventés.
Suivez la décision client jusqu’aux opérations marchand.
1. Afficher la règle effective
Le vrai portail PS9 affiche l’âge requis et garde confirmer/partir accessibles. La date complète est une des quatre méthodes.
Ouvrir cette scène dans le tour →
2. Configurer politique, portée et présentation
Le back-office responsive commence par la santé puis regroupe vérification, ciblage, design, sécurité et alertes.
Ouvrir cette scène dans le tour →
3. Examiner et exporter les décisions
Filtrez date, événement et résultat, inspectez âge/contexte et exportez en CSV. La table stocke l’année si fournie, pas la date complète.
Ouvrir cette scène dans le tour →
4. Suivre le fonctionnement
Les analyses agrègent réussites, échecs, blocages et fallback afin de détecter friction et abus sans SaaS externe.
Ouvrir cette scène dans le tour →
Le traitement first-party exige toujours une décision de rétention.
| Emplacement | Ce que 1.2.11 utilise | Limite opérationnelle |
|---|---|---|
| Requête de vérification | Champs date, année, attestation ou Oui/Non ; un âge en attente signé lie la requête à la règle affichée. | Traitement same-origin. La date complète est évaluée mais pas stockée dans l’audit. Utilisez un spécialiste si une preuve plus forte est nécessaire. |
| Décision navigateur | Cookie signé first-party HttpOnly np_age_verified, SameSite=Lax, Secure en HTTPS ; cookie d’âge temporaire et probe. | La durée du cookie ne supprime pas l’audit. Si les cookies échouent, une session sécurisée est utilisée. |
| Table d’audit | id_shop · id_customer · id_cart · event_type · result · rule_context · minimum_age · birth_year · ip_hash · user_agent_hash · date_add | Vue filtrée, CSV et hooks RGPD existent. Aucune purge automatique par ancienneté ; le marchand opère la rétention. |
| Protections limitation/alerte | Compteurs hash IP, cooldown et fenêtres d’alerte pour limiter les abus et avertir les opérateurs. | Les lignes techniques de plus de sept jours sont supprimées opportunément. Cela ne concerne pas l’audit. |
Adaptez le niveau de confiance au risque réel.
Le Comité européen distingue l’auto-déclaration des méthodes plus fortes, recommande un choix proportionné au risque et note que sa fiabilité dépend surtout de la bonne foi. Il exige aussi finalité, minimisation, rétention transparente et sécurité. NP AgeVerify reste une auto-déclaration contrôlée par le marchand ; cette page n’est pas un avis juridique.
Lire la déclaration EDPB 1/2025 ↗Nécessité d’abord
Documentez pourquoi ce produit, parcours et public ont besoin de cette décision.
Confiance proportionnée
L’auto-déclaration est une preuve faible. Adaptez la méthode à la conséquence d’une erreur.
Minimiser et limiter la finalité
Évaluez année, ID et hash ; ne réutilisez jamais l’audit pour du profilage.
Opérer la suppression
Attribuez responsable, durée, suppression, preuve, sauvegardes et réponse aux incidents.
Utilisez l’auto-déclaration uniquement lorsqu’elle suffit.
Bon profil · auto-déclaration revue
Une revue accepte la déclaration, vous voulez du first-party et règles pays/catalogue plus contrôle de marque comptent.
Profil conditionnel · stack custom
Checkout custom, contrôleurs, overrides, consentement et CDN/cache exigent un staging réaliste sur chaque route.
Pas adapté · identité ou livraison vérifiée
Utilisez un spécialiste pour documents, biométrie, jetons fiables, paiement, transporteur ou livraison.
Prouvez la boutique, le parcours et chaque cas limite avant lancement.
| Décision ou risque | Ce que fait 1.2.11 | Ce que le marchand doit prouver |
|---|---|---|
| Limite date et requêtes directes | Le serveur refuse dates impossibles, années avant 1900, dates futures et entiers non stricts. Une date future échoue sans cookie. | Testez avant/jour/après anniversaire, 29 février, impossible, future, tableaux, décimales, négatifs, zéro et valeurs partielles. |
| Priorité pays et niveaux | Le pays remplace la base ; catégorie, produit et panier peuvent augmenter. Le maximum est signé. | Testez pays absent/inconnu, chaque pays, multi-catégories, overrides et panier mixte. |
| Précision de la source GeoIP | Le module utilise en-têtes CDN fiables ou GeoLite2. Sans pays, la politique de base s’applique. | Validez confiance proxy/header, IPv4/IPv6, VPN/inconnu, base disponible et fallback. |
| Checkout et contrôleurs custom | Un panier restreint sans décision est bloqué avant paiement. Les exclusions contournent volontairement certaines surfaces. | Testez checkout classique/one-page, express, restauration, compte/auth, contrôleurs et exclusions. |
| Cookie et session de secours | Un cookie signé HttpOnly SameSite=Lax garde le seuil. Si les cookies échouent, une session sécurisée prend le relais. | Testez HTTPS, sous-répertoire, cookies bloqués, privé, expiration, seuil modifié, onglets et cache/CDN. |
| Rétention de l’audit | L’audit n’expire pas automatiquement. Les sept jours couvrent seulement les tables techniques. | Prouvez job de suppression, droits, sauvegardes, alertes, hooks RGPD et comptes après la durée. |
| Robots et UX accessible | Les robots reconnus peuvent contourner. Les layouts bloquants retiennent le focus ; inline est une région. Aucune garantie. | Utilisez clavier/lecteur ; vérifiez scroll mobile, HTML, liens, aperçus, robots et Search Console. |
Connaître la limite avant production
Est-ce une vérification d’identité ?+
Non. Le visiteur déclare date, année ou confirmation. Le module ne contrôle ni document, biométrie, paiement, base publique ou livraison et ne prouve pas l’auteur.
La 1.2.11 gère-t-elle pays et produits ?+
Oui. Un pays ISO2 peut remplacer la base ; catégorie, produit et panier peuvent l’augmenter. Le maximum applicable gagne. Testez GeoIP sur le vrai réseau.
Les dates futures sont-elles refusées côté serveur ?+
Oui. La 1.2.11 refuse dates futures/impossibles, années avant 1900 et entiers invalides. Les tests directs passent sur PS8 et PS9.
Stocke-t-il la date complète ?+
La date complète est envoyée same-origin, mais l’audit n’a ni jour ni mois. Il peut stocker année, ID, résultat, contexte, âge, hash et date.
Puis-je configurer la rétention automatique ?+
Non. L’audit a filtres, CSV et hooks client, mais aucun planificateur. Le marchand opère la rétention. Les sept jours concernent seulement les lignes techniques.
Fonctionnera-t-il avec chaque checkout et thème ?+
Aucune garantie universelle. La 1.2.11 est vérifiée sur PS8/PS9, mais contrôleurs, one-page, express, overrides, consentement et cache/CDN exigent staging.
L’achat établit-il la conformité ?+
Non. Âges, preuve, base, information, rétention, accessibilité, livraison et règles dépendent du contexte. Obtenez une revue indépendante.
Gardez simulateur, écrans réels et preuves de version ensemble.
L’expérience publie le SHA-256 exact 1.2.11, des captures runtime en français, la checklist et le prix unique de 49 €. Achetez seulement après revue et staging de la preuve, des parcours, de l’accessibilité, de l’information et de la rétention.