« Un produit numérique peut être bien plus qu’un fichier à télécharger » : c’est ce constat, plus que la recherche d’une extension de billetterie, qui a orienté le choix technique d’une salle de spectacle voulant émettre des billets nominatifs pour une jauge de quelques centaines de places par soirée. Plutôt que d’ajouter une extension de billetterie dédiée avec son propre système de comptes et de paiement, l’équipe a préféré exploiter ce que Easy Digital Downloads (EDD) sait déjà très bien faire : livrer un fichier généré dynamiquement après un achat, avec un contrôle d’accès strict.
Le raisonnement tient en une phrase : un billet, techniquement, n’est qu’un fichier PDF unique associé à un acheteur et à une place. EDD, conçu pour vendre des produits numériques comme des ebooks ou des licences logicielles, dispose déjà des briques nécessaires pour générer ce fichier à la demande et en tracer la livraison.
Un billet comme fichier généré à la volée
Plutôt que de stocker un PDF statique par billet, la génération se fait au moment du téléchargement, via le hook edd_process_download. Chaque billet est donc unique et contient l’identifiant de commande, le nom de l’acheteur saisi lors de l’achat, la date de la représentation et un identifiant de place attribué séquentiellement.
add_action( 'edd_process_download', function ( $file, $download_id, $payment ) {
if ( 'billet-spectacle' !== get_post_meta( $download_id, '_edd_product_type', true ) ) {
return;
}
$donnees = array(
'commande' => $payment->ID,
'nom' => $payment->email,
'place' => get_post_meta( $payment->ID, '_place_attribuee', true ),
);
// Génération du PDF à la volée avec les données ci-dessus.
}, 10, 3 );
Empêcher la falsification par capture d’écran
La difficulté n’est pas de générer un billet nominatif — c’est trivial — mais d’empêcher qu’une photo du billet, transférée à un tiers, permette une entrée frauduleuse. La solution retenue combine deux mécanismes : un QR code qui n’encode jamais directement l’identifiant de commande, mais une empreinte signée avec une clé secrète propre à la salle (via hash_hmac() côté PHP), et une invalidation du billet dès son premier scan validé à l’entrée.

$empreinte = hash_hmac( 'sha256', $donnees['commande'] . $donnees['place'], WP_BILLET_CLE_SECRETE );
$contenu_qr = $donnees['commande'] . '|' . $donnees['place'] . '|' . $empreinte;
À l’entrée, l’application de contrôle (une simple page web fonctionnant hors ligne sur une tablette, avec une copie locale des empreintes valides synchronisée avant l’ouverture des portes) recalcule l’empreinte à partir des données lues et la compare à celle encodée dans le QR code. Toute divergence, ou tout billet déjà marqué comme scanné, déclenche une alerte visuelle pour l’agent d’accueil.
Pourquoi pas une extension de billetterie classique
Les extensions de billetterie dédiées apportent une gestion de jauge par zone, des places numérotées et une interface de contrôle prête à l’emploi. Mais elles introduisent aussi un second système de comptes clients, parfois redondant avec celui déjà géré par WordPress, et un coût de licence récurrent difficile à justifier pour une salle qui organise une dizaine de soirées par an. Le détournement d’EDD, plus artisanal, reste proportionné à ce volume.
Ce que cette approche ne couvre pas
Cette architecture répond à la question de la falsification du billet lui-même. Elle ne traite pas l’organisation du contrôle d’accès le jour de l’événement — nombre d’agents, gestion des flux d’entrée, files d’attente — qui relève d’une problématique logistique distincte et dépend surtout de la configuration physique de la salle.
- Génération du billet : hook
edd_process_download, données propres à chaque acheteur. - Anti-falsification : empreinte HMAC encodée dans un QR code, jamais l’identifiant brut.
- Contrôle : application hors ligne, invalidation au premier scan valide.
Un billet qui affiche fièrement son numéro de commande en clair dans un QR code n’est pas un billet sécurisé : c’est une invitation à le partager. L’empreinte signée coûte trois lignes de code et change tout.
Pour aller plus loin
Cette approche tient tant que le volume reste maîtrisable par une équipe technique interne capable de maintenir l’application de contrôle. Au-delà d’une certaine taille de programmation (plusieurs salles, plusieurs centaines de représentations par an), l’investissement dans une extension dédiée redevient pertinent, ne serait-ce que pour mutualiser la maintenance de l’application de scan entre plusieurs lieux.