Comprendre les sessions PHP : fondements, usages et cas particuliers
Quand un utilisateur passe d’une page à l’autre sur un site, il ne laisse aucune trace entre deux requêtes — à moins qu’on l’y aide. Une session PHP permet justement de créer ce lien invisible, ce fil conducteur qui rend l’expérience cohérente. C’est elle qui rend possible l’affichage d’un prénom dans l’en-tête, la conservation d’un panier actif, ou la poursuite d’un formulaire en plusieurs étapes.
Avant de plonger dans le code, encore faut-il savoir ce qu’est réellement une session PHP, comment elle fonctionne, ce qu’elle permet, et jusqu’où on peut l’adapter. Ce premier article se concentre sur les mécanismes de base : comment la session est créée, comment les données sont conservées, et ce qu’il est possible d’en faire dans un projet réel. On y abordera aussi des cas un peu moins classiques, comme le partage de session entre sous-domaines ou la personnalisation de son comportement selon le contexte d’usage.
Pourquoi utiliser une session PHP ?
Imaginez un site sans mémoire : vous vous connectez, passez à la page suivante, et tout s’efface. Aucune trace de votre nom, de vos choix ou de votre progression. Sans session, chaque requête PHP repartirait de zéro, incapable de reconnaître l’utilisateur.
Dans la réalité, on a simplement besoin d’un lien entre les pages. Un fil conducteur. C’est là qu’intervient la session PHP. Elle repose sur un élément central : le cookie. Ce petit fichier, stocké dans le navigateur, contient un identifiant unique. C’est lui qui permet à PHP de reconnaître le visiteur et d’associer cet identifiant à des données côté serveur, accessibles via la superglobale $_SESSION. Rien n’apparaît dans l’URL, ni dans le HTML : tout reste discret, mais disponible pendant toute la durée de la session.
C’est un petit espace mémoire bien pratique : on y glisse un nom pour accueillir la personne sur chaque page, un tableau panier pour suivre ses choix, une variable page_en_cours pour savoir où elle en est dans un formulaire, ou un auth_token pour reconnaître qu’elle est connectée. Rien de spectaculaire, mais juste assez pour que le site suive le fil sans jamais perdre le visiteur.
Prenons un site de réservation : la session mémorise le choix d’une date, un créneau horaire, des coordonnées. À chaque étape, PHP retrouve les données stockées et permet d’avancer sans tout avoir à recommencer.
Simple, souple, efficace : la session PHP fait partie des outils de base. Encore faut-il savoir s’en servir avec justesse.
Comment fonctionne une session PHP ?
Derrière chaque appel à session_start(), PHP utilise un identifiant de session — une chaîne unique stockée dans un cookie nommé PHPSESSID. Ce cookie est invisible dans l’interface utilisateur, mais visible dans les outils de développement du navigateur, dans l’onglet Stockage > Cookies.
Côté serveur, cet identifiant sert de lien avec un fichier temporaire où PHP enregistre les données de session. Ce fichier est lu et mis à jour automatiquement à chaque requête, sans qu’on ait à s’en préoccuper.
Ce mécanisme fonctionne automatiquement, mais il est utile de comprendre qu’il repose sur un échange entre le navigateur (cookie PHPSESSID) et le serveur (fichier associé). Si le cookie disparaît, ou si le serveur perd son fichier, la session est rompue.
Comprendre ce va-et-vient entre navigateur et serveur permet de mieux cerner les limites du système… et d’anticiper les besoins futurs, comme partager une session entre plusieurs domaines ou choisir un autre mode de stockage.
Créer et manipuler une session
Avant de parler de ce qu’on y met, voyons comment une session se met en place. Tout commence par l’appel à session_start(). Cette fonction doit être appelée avant tout affichage dans la page (donc avant tout echo, print, ou même un espace HTML).
Elle permet à PHP d’ouvrir une session existante (si l’identifiant est reconnu via le cookie), ou d’en créer une nouvelle. Une fois la session ouverte, on peut lire et écrire des données via la superglobale $_SESSION, comme si c’était un tableau classique :
<?php
session_start();
// puis nous pouvons stocker dans $_SESSION tout ce que nous voulons réutiliser
$_SESSION['nom'] = 'Lucie';
$_SESSION['panier'] = ['article1', 'article2'];
// pour utiliser une valeur stockée, il suffit de l'invoquer
echo "Bonjour " . $_SESSION['nom'];
?>Chaque variable assignée dans $_SESSION est automatiquement enregistrée côté serveur. Et à la prochaine requête, tant que la session est active, ces données seront à nouveau disponibles.
Pour supprimer une seule variable, on peut utiliser unset($_SESSION['theme']). Pour supprimer toutes les données de session (mais garder la session ouverte), on peut utiliser session_unset(). Enfin, pour tout détruire proprement (données + cookie), on appelle :
session_unset();
session_destroy();À noter que cela ne supprime pas forcément le cookie immédiatement côté navigateur. Pour être rigoureux, on peut aussi supprimer le cookie en le réécrivant vide. On utilise ici session_name() pour cibler dynamiquement le nom du cookie de session (souvent PHPSESSID, sauf si vous l’avez personnalisé) :
setcookie(session_name(), '', time() - 3600);Ces quelques fonctions suffisent à mettre en place un mécanisme complet : ouverture de session, lecture/écriture, suppression ciblée ou totale. Et tout ça sans base de données, ni configuration compliquée.
Que peut-on stocker dans une session ?
Tout ce qui peut être représenté par une valeur simple ou un tableau peut être stocké dans une session PHP. Cela inclut du texte, des chiffres, des booléens, ou même des tableaux associatifs. C’est une solution pratique pour mémoriser un identifiant utilisateur (id_utilisateur), une préférence d’affichage (mode_sombre), ou un panier de commandes (panier[]).
<?php
$_SESSION['id_utilisateur'] = 42;
$_SESSION['mode_sombre'] = true;
$_SESSION['panier'] = [
['produit' => 'Stylo', 'quantite' => 3],
['produit' => 'Carnet', 'quantite' => 1]
];
// On peut aussi utiliser la session pour suivre un parcours utilisateur dans une interface multi-étapes :
$_SESSION['etape'] = 'coordonnees';
?>En revanche, mieux vaut éviter d’y placer des objets complexes, des chaînes très longues, ou des données sensibles non protégées. La session n’est pas une base de données, ni un coffre-fort.
Autre point de vigilance : tout ce que l’on place dans $_SESSION est stocké physiquement sur le serveur, souvent dans un fichier temporaire. Si on y place des données inutiles, on alourdit le serveur. Et si plusieurs sessions deviennent trop volumineuses, on peut vite saturer l’espace disque ou ralentir le traitement des requêtes.
Une session bien pensée se limite à l’essentiel. Elle doit être explicite, concise, et ne contenir que ce qui est strictement nécessaire pour assurer la continuité de l’expérience utilisateur.
Où sont stockées les données de session ?
Quand on travaille avec $_SESSION, on a l’impression que tout reste en mémoire, comme par magie. En réalité, PHP stocke ces données côté serveur, le plus souvent dans des fichiers temporaires.
Par défaut, chaque session génère un fichier dans un dossier défini par session.save_path. Sur un serveur Apache classique, ce dossier peut ressembler à /var/lib/php/sessions/ ou /tmp. Le nom du fichier correspond à l’identifiant de session. C’est ce fichier que PHP lit et met à jour automatiquement à chaque requête.
Il est possible de modifier ce comportement. PHP permet par exemple d’utiliser un gestionnaire personnalisé (session.save_handler) pour stocker les sessions en base de données, en mémoire (Redis, Memcached), ou même dans un service distant. Ces cas ne sont pas courants pour des petits sites, mais deviennent essentiels dès qu’on cherche à mieux répartir la charge, ou à partager les sessions entre plusieurs serveurs.
On peut aussi changer d’autres paramètres comme le chemin, la durée de vie, ou le mode de sérialisation des données. Cela se fait via le fichier php.ini, .htaccess, ou par appel à ini_set() dans le code.
ini_set('session.save_path', '/chemin/vers/mon/dossier');
session_start();Enfin, même si tout cela est transparent pour l’utilisateur, il est bon de savoir que ce mécanisme repose sur un support physique. Si le dossier n’est pas accessible en écriture, ou si le serveur nettoie les fichiers trop vite, les sessions risquent de ne pas fonctionner comme prévu.
Comprendre où ces données vivent permet de mieux diagnostiquer un dysfonctionnement, ou d’adapter l’environnement à des besoins plus complexes.
Sessions entre sous-domaines ou domaines différents
Une session PHP repose sur un cookie stocké dans le navigateur. Ce cookie est automatiquement renvoyé au serveur… à condition que le domaine corresponde exactement. C’est là que les choses se compliquent dès qu’on travaille avec des sous-domaines (app.monsite.com, admin.monsite.com) ou des domaines différents (monsite.com, autresite.fr).
Par défaut, une session n’est pas partagée entre domaines et sous-domaines distincts. Pour contourner cela, il faut définir manuellement le domaine de validité du cookie, en utilisant session_set_cookie_params() ou en configurant session.cookie_domain dans php.ini. Il faut que ce domaine soit commun (ex. .monsite.com) pour que tous les sous-domaines y aient accès.
Voici un exemple de configuration en PHP, à placer avant le session_start() :
<?php
if (session_status() !== PHP_SESSION_ACTIVE) {
// On vérifie que la session n’est pas déjà active,
// car appeler session_start() deux fois provoquerait une erreur.
// Cela permet de réutiliser ce code dans plusieurs fichiers sans conflit.
session_set_cookie_params([
'lifetime' => 3600,
'path' => '/',
'domain' => '.monsite.com', // Partagé entre les sous-domaines
'secure' => true, // Si votre site est en HTTPS
'httponly' => true,
'samesite' => 'Lax'
]);
session_start();
}
?>Ce bloc permet de s’assurer que la session est bien accessible depuis tous les sous-domaines de monsite.com, tout en activant les protections nécessaires (secure, httponly, samesite). Chaque propriété utilisée ici a son importance et peut être ajustée selon le contexte. L’article Sessions PHP : sécuriser les identifiants, durées et invalidations explore en détail le rôle et les effets de chacun de ces paramètres, avec des conseils pratiques pour adapter la configuration à votre projet.
Attention : les navigateurs récents imposent des règles strictes avec samesite, un paramètre qui contrôle dans quelles situations un cookie peut être envoyé. Si ce réglage est absent ou mal adapté, le cookie peut être ignoré, notamment dans les cas d’iframe, de redirection ou de navigation inter-domaine. Cette propriété peut avoir trois valeurs possibles :
Strict: le cookie n’est envoyé que si l’utilisateur reste sur le même site. Aucun envoi lors d’une navigation externe.Lax: le cookie est envoyé lors de navigations simples (comme un clic sur un lien), mais pas avec des requêtes POST ou des chargements en iframe.None: le cookie est toujours envoyé, même en contexte inter-domaine, mais il doit impérativement être accompagné deSecure(HTTPS obligatoire).
Sur des domaines réellement différents, le partage de session via cookie devient donc quasi impossible sans recourir à une API ou un système d’authentification partagé.
Retenir qu’un cookie est attaché à un domaine précis, et que cette attache détermine si une session peut ou non suivre un utilisateur d’un sous-domaine à un autre, est essentiel pour concevoir une architecture cohérente. Cette réflexion est prolongée dans l’article Sessions PHP – Contextes modernes et intégrations avancées, notamment dans le chapitre Partage de session entre services où ces notions sont complétées et élargies.
Besoin de personnaliser une session ?
Pour la plupart des sites, les sessions PHP par défaut suffisent largement. Mais dès qu’on travaille sur un environnement plus poussé — plusieurs applications, des tests croisés, ou une infrastructure distribuée — quelques techniques supplémentaires peuvent être utiles.
On peut par exemple changer le nom de la session si l’on souhaite distinguer plusieurs contextes d’usage :
session_name('MONAPPLI');
session_start();Cela permet d’éviter les conflits entre deux applications hébergées sur le même domaine, chacune ayant son propre cookie de session.
Il est aussi possible de forcer manuellement un identifiant de session, notamment pour des tests ou du débogage :
session_id('abc123test');
session_start();Cela doit rester ponctuel, car cela court-circuite le système automatique et peut causer des collisions si plusieurs visiteurs ont le même identifiant.
Enfin, on peut modifier le type de stockage utilisé avec session.save_handler, pour choisir entre fichiers (files), mémoire (memcached, redis), ou base de données (via un gestionnaire personnalisé). On ne détaillera pas ici ces options, mais elles existent, et peuvent s’avérer précieuses dans des architectures plus complexes.
L’idée n’est pas de tout maîtriser d’un coup, mais de savoir que ces possibilités existent, et qu’elles peuvent être explorées quand le besoin s’en fait sentir.
Un mot sur les cookies et sur $_COOKIE
Le fonctionnement des sessions PHP repose sur un petit élément souvent ignoré : le cookie PHPSESSID. Ce fragment de donnée, transmis par le serveur, est stocké dans le navigateur du visiteur. Comme expliqué dans le chapitre Comment fonctionne une session PHP ?, ce cookie contient l’identifiant unique qui permet à PHP de reconnaître l’utilisateur d’une requête à l’autre. Ce cookie est donc renvoyé automatiquement par le navigateur à chaque interaction avec le site.
Ce cookie est donc accessible en PHP via $_COOKIE['PHPSESSID'], comme n’importe quelle autre donnée transmise par le navigateur. En pratique, on le lit rarement à la main, mais il peut servir pour des vérifications ou des diagnostics.
Dès que l’attribut HttpOnly est activé — ce qui est recommandé pour des raisons de sécurité —, le cookie devient invisible pour JavaScript. En revanche, si cet attribut est désactivé, JavaScript peut y accéder via document.cookie.
//PHP
session_set_cookie_params([
// paramétrage sécurisé
'httponly' => true
]);
// Javascript
console.log(document.cookie);
// Résultat : rien ou seulement les autres cookies non protégés
//PHP
session_set_cookie_params([
// paramétrage moins sécurisé
'httponly' => false
]);
// Javascript
console.log(document.cookie);
// Résultat : "PHPSESSID=abc123xyz" (et potentiellement d'autres cookies)| Condition | Accès via JavaScript |
|---|---|
| HttpOnly = false | Oui, via document.cookie |
| HttpOnly = true | Non, inaccessible côté client |
Ce comportement montre pourquoi HttpOnly est si important : il empêche les scripts malveillants d’accéder aux cookies de session.
Si plusieurs cookies sont présents, document.cookie renvoie une chaîne les contenant tous, séparés par des points-virgules. Il faut alors parser la chaîne pour en extraire la valeur souhaitée.
"PHPSESSID=abc123xyz; pref_theme=sombre; consent=true"Conclusion
Les sessions PHP ont beau être anciennes, elles restent un outil simple, fiable et pertinent pour suivre un utilisateur d’une page à l’autre. Comprendre comment elles fonctionnent, ce qu’elles stockent, et comment elles interagissent avec le navigateur permet de les utiliser avec justesse, même dans des contextes plus complexes.
Ce premier article s’est concentré sur le fonctionnement global : démarrage, stockage, domaine, cookies et limites. Pour aller plus loin, vous pouvez consulter l’article complémentaire Sessions PHP : sécuriser les identifiants, durées et invalidations, qui aborde les bonnes pratiques en matière de sécurité, d’invalidation et de gestion des durées.
