L'optimisation des performances d'une ferme SharePoint Subscription Edition (SE) passe inévitablement par une gestion fine de ses mécanismes de mise en cache. Parmi eux, le cache d'objets (Object Cache) joue un rôle critique. Sans lui, chaque visiteur déclencherait une multitude de requêtes directes vers la base de données SQL Server, provoquant une latence inacceptable et un goulot d'étranglement matériel.
Pourtant, c'est l'un des composants les plus mal configurés par les administrateurs, générant souvent des erreurs d'accès aléatoires ou des WebParts cassés. Voici une plongée technique ("Deep Dive") dans les entrailles du cache d'objets SharePoint.
1. Deep Dive : Anatomie et mécanique du cache d'objets
Le cache d'objets a un objectif clair : stocker les propriétés structurelles des éléments (pages, documents, requêtes de navigation) dans la mémoire RAM des serveurs Web Front-End (WFE) pour accélérer le rendu des pages web et réduire drastiquement la charge sur l'instance SQL Server.
Pour que ce mécanisme fonctionne sans compromettre la sécurité et les droits d'accès, SharePoint s'appuie sur deux comptes d'utilisateurs distincts :
-
Le Portal Super User (Superutilisateur du portail) : Ce compte possède un accès "Contrôle total" sur l'application web. Il a le privilège de voir absolument tous les éléments, y compris les versions de brouillon non publiées.
-
Le Portal Super Reader (Super lecteur du portail) : Ce compte possède un accès restreint en "Lecture totale". Il ne peut voir que les éléments officiellement publiés et approuvés.
Comment la magie opère-t-elle en arrière-plan ? Lorsqu'un utilisateur (ex: Hussein) navigue sur une page, le cache d'objets ne construit pas la requête SQL au nom de Hussein. S'il le faisait pour chaque utilisateur unique, la mémoire RAM du serveur saturerait instantanément. À la place, SharePoint exécute la requête deux fois en arrière-plan :
-
Une fois sous l'identité du Super User (récupération du contenu publié + les brouillons).
-
Une fois sous l'identité du Super Reader (récupération stricte du contenu publié).
Ces deux jeux de résultats globaux sont stockés en mémoire. Ensuite, lorsque Hussein demande la page, le moteur de SharePoint vérifie simplement l'ACL (Access Control List) de Hussein : "A-t-il le droit de voir les brouillons ?". Selon la réponse, le serveur lui sert instantanément le jeu de résultats A ou le jeu de résultats B directement depuis la RAM.
2. Le danger mortel des comptes par défaut
Si ce système est si performant, pourquoi faut-il le configurer manuellement après la création d'une Web Application ? Parce que les comptes utilisés par défaut par SharePoint sont destructeurs dans un environnement de production moderne.
Le problème des éléments extraits (Super User par défaut) : Par défaut, SharePoint utilise le "Compte système" du site comme Super User. Le risque majeur survient lorsque des documents sont extraits (check-out) par ce compte système (par exemple via des processus automatisés). Le cache va alors renvoyer la version en cours de modification (le brouillon exclusif) au lieu de la version officielle. Le moteur SharePoint détecte cette incohérence, invalide le cache, et refait des requêtes SQL directes. Les performances s'effondrent. Règle d'or : Les comptes dédiés au cache ne doivent jamais être utilisés par un humain pour se connecter ou modifier des documents.
L'erreur d'accès refusé inexpliquée (Super Reader par défaut) : Par défaut, le rôle Super Reader est assigné au compte Autorité NT\Service local. Dans SharePoint SE, l'authentification est basée par défaut sur les revendications (Claims-based authentication). Or, ce vieux compte système Windows ne gère pas correctement les jetons Claims. Résultat : le processus de mise en cache échoue silencieusement. Vos utilisateurs, même les administrateurs de la collection de sites, se retrouvent confrontés à des erreurs "Accès refusé" ou voient des menus de navigation et des WebParts "Requête de contenu" vides.
3. Script et mise en pratique : Configurer le cache d'objets
Pour corriger cette architecture, vous devez configurer manuellement ces comptes sur chaque Web Application via PowerShell, en utilisant le format de revendication (Claims format) approprié, généralement préfixé par i:0#.w|.
Étape 1 : Ajoutez d'abord les deux comptes Active Directory dans les "Stratégies de l'application Web" (User Policies) via l'Administration Centrale.
-
DOMAIN\sp_supuser-> Contrôle Total -
DOMAIN\sp_supreader-> Lecture Totale
Étape 2 : Exécutez ce script PowerShell pour lier les comptes au cache d'objets.
# Prérequis : Exécuter depuis le SharePoint Management Shell en tant qu'administrateur
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$WebAppUrl = "https://intranet.votre-entreprise.com"
# Attention à bien respecter le format Claims (i:0#.w|) pour l'AD
$SuperUserAccount = "i:0#.w|DOMAIN\sp_supuser"
$SuperReaderAccount = "i:0#.w|DOMAIN\sp_supreader"
Write-Host "Configuration du Cache d'Objets pour : $WebAppUrl" -ForegroundColor Cyan
# Récupération de l'application web
$WebApp = Get-SPWebApplication -Identity $WebAppUrl
if ($WebApp) {
# Assignation des comptes de cache
$WebApp.Properties["portalsuperuseraccount"] = $SuperUserAccount
$WebApp.Properties["portalsuperreaderaccount"] = $SuperReaderAccount
# Validation et sauvegarde des propriétés
$WebApp.Update()
Write-Host "Configuration appliquée avec succès." -ForegroundColor Green
Write-Host "Super User : $($WebApp.Properties["portalsuperuseraccount"])"
Write-Host "Super Reader : $($WebApp.Properties["portalsuperreaderaccount"])"
Write-Host "IMPORTANT : Un IISRESET est recommandé sur tous les serveurs WFE pour prendre en compte le nouveau cache." -ForegroundColor Yellow
} else {
Write-Error "Application Web introuvable."
}
4. Références officielles Microsoft
Pour approfondir la gestion des caches (Object Cache, BLOB Cache, et Page Output Cache) et garantir la stabilité de vos fermes, consultez la documentation de l'éditeur :
