# Cache par rôle sur un thème classique pour une plateforme de formation

> Retour chiffré sur une stratégie de cache différenciée selon le rôle apprenant, formateur ou invité, appliquée à un thème classique livré pour une grande plateforme de formation.

- Auteur : Clément Hadrot
- Publié le : 2025-11-25
- Mis à jour le : 2025-11-25
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/elearning-50000-apprenants-cache-par-role-theme/

## L’essentiel

- Un cache de page classique ne suffit pas dès que le contenu varie selon le rôle
- Des variantes de cache par rôle réduisent la charge sans revenir au tout dynamique
- Le formateur et l'apprenant ne voient jamais la même page, même sur la même URL

Un apprenant et un formateur qui consultent la même URL de cours ne doivent jamais voir exactement la même page : le premier voit sa progression personnelle et ses prochains modules, le second voit des statistiques de complétion et un accès d'administration au contenu. Sur une plateforme de formation en ligne dépassant les 50 000 apprenants actifs, cette variation par rôle rendait au départ tout cache de page classique impossible à activer sans casser l'expérience de l'un ou l'autre profil.

Ce billet détaille la stratégie de cache différenciée par rôle mise en place sur le thème classique de cette plateforme, avec les chiffres mesurés avant et après. Il ne traite ni le moteur de cours lui-même, développé par ailleurs, ni la gestion des paiements des inscriptions.

## Pourquoi le cache de page classique échouait ici

Un cache de page statique, du type de celui que propose un plugin de cache généraliste, met en cache une réponse HTML unique par URL, indépendamment de l'utilisateur qui la consulte. Sur cette plateforme, activer un tel cache sans précaution aurait signifié : soit servir à un formateur la page mise en cache pour un apprenant (perte de ses fonctions d'administration), soit désactiver le cache dès qu'un utilisateur est connecté — ce qui, avec 50 000 apprenants quasiment tous connectés en journée, revenait à ne quasiment jamais bénéficier du cache.

## La stratégie : des variantes de cache par rôle

La solution retenue repose sur une clé de cache composite, incluant non seulement l'URL mais aussi le rôle fonctionnel de l'utilisateur — apprenant, formateur, ou invité non connecté. Trois variantes de la même page sont ainsi mises en cache séparément, chacune servie au bon segment d'utilisateurs.

```
function plateforme_cle_cache_page( $url ) {
    $role = 'invite';

    if ( is_user_logged_in() ) {
        $utilisateur = wp_get_current_user();
        $role = in_array( 'formateur', $utilisateur->roles, true )
            ? 'formateur'
            : 'apprenant';
    }

    return md5( $url . '|' . $role );
}
```

Cette clé alimente un cache objet Redis, distinct du cache de page HTML habituel, qui stocke des fragments de page plutôt que la page entière : le squelette de mise en page (en-tête, navigation, pied de page) reste identique et mis en cache une seule fois, tandis que le bloc central de contenu — spécifique au rôle — est mis en cache séparément par variante.

### Fragmentation plutôt que page entière

```
function plateforme_afficher_bloc_progression() {
    $cle = plateforme_cle_cache_page( 'bloc-progression-' . get_the_ID() );
    $html = wp_cache_get( $cle, 'plateforme_fragments' );

    if ( false === $html ) {
        ob_start();
        get_template_part( 'template-parts/bloc-progression' );
        $html = ob_get_clean();
        wp_cache_set( $cle, $html, 'plateforme_fragments', 10 * MINUTE_IN_SECONDS );
    }

    echo $html;
}
```

Cette approche par fragments, plutôt que par page entière en cache, présente un avantage supplémentaire : la durée de vie du cache peut être ajustée indépendamment pour chaque fragment. Le squelette de navigation, qui change rarement, reste en cache une heure ; le bloc de progression personnelle, plus volatile, n'est mis en cache que dix minutes.

> L'essentiel à retenir : Un cache de page classique ne suffit pas dès que le contenu varie selon le rôle ; Des variantes de cache par rôle réduisent la charge sans revenir au tout dynamique ; Le formateur et l'apprenant ne voient jamais la même page, même sur la même URL

## Les résultats mesurés

| Indicateur | Avant cache par rôle | Après cache par rôle |
| --- | --- | --- |
| Temps de réponse moyen (page de cours) | 1,8 seconde | 0,23 seconde |
| Requêtes SQL par chargement | 62 | 9 |
| Charge serveur en heure de pointe (18h-20h) | Proche saturation | Marge confortable |

La baisse de 87 % du temps de réponse moyen a été mesurée sur un échantillon représentatif de pages de cours consultées à la fois par des apprenants et des formateurs, sur une période de deux semaines avant et après le déploiement de la stratégie.

## Le point de vigilance : la purge sélective

Un cache par rôle complique la purge : publier une mise à jour de cours doit invalider le fragment de contenu pour toutes les variantes de rôle concernées, sans purger inutilement des fragments non affectés comme le squelette de navigation. Un hook sur `save_post`, ciblant précisément les clés de fragment liées au cours modifié, évite une purge globale coûteuse à chaque publication.

> Un cache différencié par rôle n'a de valeur que si sa purge reste chirurgicale. Une purge globale trop fréquente annule tout le bénéfice de performance obtenu, aussi finement pensée que soit la stratégie de mise en cache elle-même.

## Pour aller plus loin

Cette stratégie de cache par rôle reste spécifique à des plateformes où le contenu affiché varie structurellement selon le profil de l'utilisateur connecté. Sur un site où tous les visiteurs voient un contenu identique, un cache de page classique reste largement suffisant et plus simple à opérer. La complexité supplémentaire ne se justifie qu'à l'échelle et à la diversité de rôles rencontrées sur cette plateforme de 50 000 apprenants.