Sept lecteurs sur dix d’un site de presse ne consultent jamais plus de deux ou trois articles par mois sans y être abonnés. C’est ce type de constat, tiré d’analyses d’audience répétées sur ce secteur, qui pousse de nombreux médias à opter pour un mur de contenu progressif (« metered paywall ») plutôt qu’un mur strict qui bloquerait l’accès dès le premier article : laisser le visiteur anonyme lire un nombre limité d’articles gratuits par période, puis bloquer l’accès au-delà, en encourageant l’abonnement au moment précis où l’intérêt du lecteur est le plus fort.
Construire ce mécanisme pour un client du secteur médias impose une architecture différente d’un simple contrôle d’accès binaire. Le comptage doit être fiable pour un visiteur non identifié, résister aux tentatives de contournement basiques (suppression de cookies, navigation privée), et rester compatible avec les impératifs de référencement d’un site de presse, qui a tout intérêt à ce que Google continue d’indexer le début de ses articles.
Compter les vues sans compte utilisateur
Pour un visiteur anonyme, l’identifiant de suivi ne peut reposer sur un ID utilisateur WordPress classique. Un cookie de session à durée de vie glissante, couplé à un identifiant généré côté serveur, constitue une base plus robuste qu’un simple compteur JavaScript, qui échoue dès qu’un bloqueur de scripts est actif :
function media_get_identifiant_lecteur(): string {
if ( ! empty( $_COOKIE['media_lecteur_id'] ) ) {
return sanitize_text_field( $_COOKIE['media_lecteur_id'] );
}
$id = wp_generate_uuid4();
setcookie( 'media_lecteur_id', $id, time() + MONTH_IN_SECONDS, COOKIEPATH, COOKIE_DOMAIN );
return $id;
}
Ce cookie seul reste contournable par la suppression manuelle des cookies ou la navigation privée. Sur les projets où ce contournement représentait un enjeu commercial significatif, une couche supplémentaire de comptage par adresse IP anonymisée (hachée, jamais stockée en clair) en complément du cookie a permis de limiter le contournement le plus basique, sans viser une fiabilité absolue — un objectif de toute façon irréaliste sans compte utilisateur.
Stocker le compteur côté serveur, pas seulement côté client
Un compteur stocké uniquement dans le localStorage du navigateur se réinitialise au moindre nettoyage du cache ou changement d’appareil. Le comptage fiable doit vivre côté serveur, dans un transient ou une table dédiée indexée par l’identifiant lecteur :
function media_compter_lecture( string $lecteur_id ): int {
$cle = 'media_vues_' . $lecteur_id;
$vues = (int) get_transient( $cle );
$vues++;
set_transient( $cle, $vues, MONTH_IN_SECONDS );
return $vues;
}
Utiliser un transient à expiration mensuelle reproduit naturellement la logique d’un quota renouvelé chaque mois, sans tâche cron supplémentaire pour réinitialiser les compteurs.
Bloquer le contenu sans casser le référencement
Le filtre the_content est le point d’ancrage naturel pour tronquer l’article au-delà du quota, mais il doit distinguer un visiteur humain d’un robot d’indexation. Bloquer Googlebot reviendrait à empêcher l’indexation complète de l’article, ce qui nuirait au référencement du média sur le long terme :
- Vérifier le user-agent de la requête pour ne jamais appliquer le mur aux robots de crawl connus.
- Conserver un extrait substantiel visible avant le mur, utile au référencement et à l’aperçu sur les réseaux sociaux.
- Afficher un message de mur explicite plutôt qu’un contenu tronqué sans explication, pour éviter une mauvaise expérience perçue comme un bug.
Le mur ne doit pas apparaître aux abonnés
Un visiteur identifié comme abonné (via un rôle WordPress dédié ou une donnée de statut d’abonnement synchronisée depuis un système de facturation externe) doit systématiquement contourner le compteur, quel que soit son nombre de vues. Cette vérification doit intervenir avant même le calcul du quota, pour éviter un traitement inutile :
if ( media_utilisateur_est_abonne( get_current_user_id() ) ) {
return $content; // Pas de mur pour les abonnés.
}
Ce que ce module ne couvre pas
L’architecture décrite ici concerne uniquement le comptage et le blocage d’accès. Le paiement et la gestion de l’abonnement lui-même — intégration Stripe, gestion des cycles de facturation, relances d’échec de paiement — relève d’un module distinct, volontairement laissé hors périmètre ici pour ne pas mélanger deux responsabilités très différentes.
Le mur progressif fonctionne d’autant mieux qu’il reste imprévisible pour l’utilisateur lambda : un quota trop visible ou trop facilement contournable perd toute son utilité commerciale.
Notre verdict
Un mur de contenu progressif pour un média de presse repose sur un compteur côté serveur fiable, une distinction stricte entre visiteur anonyme, abonné et robot d’indexation, et un blocage qui préserve l’essentiel du référencement naturel. C’est une architecture qui demande plus de rigueur qu’un simple contrôle d’accès binaire, mais qui reste la seule approche cohérente avec un modèle économique fondé sur la conversion progressive du lecteur occasionnel en abonné.
