La persistance de session est un comportement d’équilibrage de charge qui envoie les requêtes d’un même client ou d’une même session utilisateur vers le même serveur backend pendant une période définie. On l’appelle aussi sessions collantes ou affinité de session.

Ce mécanisme compte parce que toutes les applications ne sont pas totalement sans état. Certains parcours de connexion, paniers, chats, formulaires en plusieurs étapes et traitements en mémoire conservent encore des données temporaires sur une instance précise. Si une requête suivante arrive sur un autre backend qui ne possède pas cet état local, la session peut se rompre ou devenir incohérente.

La persistance de session coordonne donc le modèle de session de l’application et le répartiteur de charge. Elle n’est pas toujours nécessaire, mais elle devient pratique lorsque l’état applicatif reste attaché à une instance backend.

Elle maintient un client lié à un backend pendant un temps afin que les interactions avec état restent cohérentes.

Ce que signifie la persistance de session

Un chemin backend cohérent pour une session client

Le client est routé plusieurs fois vers le même backend au lieu d’être redistribué à chaque requête. Avec une répartition classique, chaque demande peut aller vers le serveur le plus approprié selon l’algorithme. Avec la persistance, la continuité du client devient prioritaire tant que l’enregistrement reste valide.

Le but n’est pas seulement de simplifier le routage, mais de préserver le fonctionnement d’une application dont l’état n’a pas encore été déplacé vers un stockage partagé ou un modèle par jeton sans état.

Dans l’architecture réelle, l’utilisateur ne voit pas toujours cette fonction, mais elle évite des ruptures dans des séries de requêtes liées.

Aussi appelée sessions collantes ou affinité de session

Les termes persistance de session, sessions collantes et affinité de session décrivent généralement la même idée : conserver temporairement la relation entre un client et un backend.

Les fournisseurs emploient des vocabulaires différents, mais le concept reste comparable dans les clouds, les proxys, les passerelles et les environnements Ingress.

La persistance de session ne rend pas une application avec état par elle-même ; elle aide simplement une application avec état à rester cohérente.

Comment fonctionne la persistance de session

Le répartiteur prend une décision initiale

Le premier accès suit souvent l’algorithme normal : round robin, moindre nombre de connexions, routage pondéré ou autre méthode.

Une fois le backend choisi, la plateforme mémorise les informations nécessaires pour reconnaître le même client plus tard.

La première requête est donc équilibrée, puis les suivantes peuvent devenir fondées sur l’affinité.

Le système stocke une clé d’affinité

Cette clé peut être un cookie, une adresse IP source, un hachage ou une donnée applicative personnalisée.

Les requêtes suivantes sont associées au même backend tant que la clé et le serveur restent valides.

La fiabilité dépend de la capacité de cette clé à représenter correctement une vraie session dans son contexte réseau.

Les requêtes suivantes réutilisent le même backend

Quand le client revient, le répartiteur consulte l’enregistrement de persistance et envoie la requête vers le backend déjà associé.

Cela stabilise les connexions, paniers, formulaires et flux en plusieurs étapes.

Il faut donc concevoir la persistance avec les délais d’expiration, les contrôles de santé et les scénarios de panne.

La persistance crée un enregistrement d’affinité après la première requête et réutilise ce choix ensuite.

Méthodes courantes de persistance

Persistance par cookie

C’est l’une des méthodes les plus utilisées pour HTTP et les applications web. Le répartiteur ou l’application place un cookie qui identifie la relation session-backend.

Elle convient aux navigateurs, à l’authentification, aux portails et aux achats en ligne, car les cookies accompagnent naturellement les échanges HTTP et HTTPS.

Elle est souvent le choix par défaut le plus précis pour les applications web classiques.

Persistance par IP source ou hachage

Cette méthode utilise l’adresse IP source ou un hachage d’un attribut de requête. Elle est simple, mais moins précise.

Des utilisateurs derrière un NAT partagé peuvent être regroupés par erreur, et les utilisateurs mobiles peuvent changer d’adresse visible.

Elle est donc plus adaptée aux environnements contrôlés qu’aux populations Internet imprévisibles.

Persistance applicative ou personnalisée

Certaines plateformes utilisent des champs applicatifs, des données de protocole ou une logique personnalisée.

Cela répond aux modèles de session complexes et peut offrir une affinité plus fiable.

Ces méthodes exigent toutefois davantage de conception, de tests et de compréhension opérationnelle.

La meilleure méthode dépend de la manière dont l’application identifie une session, pas seulement des fonctions du répartiteur.

Avantages de la persistance de session

Continuité pour les applications avec état

Elle permet à l’utilisateur de poursuivre son interaction avec la même instance lorsque les données temporaires sont locales.

Elle réduit les sessions rompues, les reconnexions, les pertes partielles de formulaire et les comportements incohérents.

Dans certains cas, elle rend une application utilisable derrière un répartiteur de charge.

Architecture plus simple dans certains cas

Elle évite parfois de déplacer immédiatement tout l’état vers un stockage distribué.

Elle peut servir de solution de transition pendant une modernisation progressive.

C’est pourquoi les sessions collantes restent fréquentes dans les systèmes de production.

Avantages potentiels de performance

Si le backend conserve un cache ou un état chaud, les requêtes suivantes évitent des reconstructions inutiles.

Ce gain est visible dans les interactions répétées et courtes.

La persistance peut donc améliorer la continuité et l’efficacité backend.

Elle est surtout utile quand les requêtes répétées dépendent d’un état temporaire attaché à une instance.

Compromis et limites

Répartition de charge moins uniforme

La plateforme ne peut plus redistribuer librement toutes les requêtes selon la charge instantanée.

Des sessions longues ou lourdes peuvent créer des points chauds.

La persistance doit donc être activée de manière réfléchie.

Complexité du basculement

Si le backend lié tombe en panne, l’enregistrement d’affinité doit être rompu ou réassigné.

La persistance n’est pas un substitut à une gestion résiliente de l’état applicatif.

Une bonne architecture combine continuité et reprise gracieuse.

Pas idéale pour les architectures totalement sans état

Les systèmes cloud-native déplacent souvent l’état vers des stockages partagés, des jetons ou des caches distribués.

Dans ce cas, l’affinité peut réduire la flexibilité sans valeur réelle.

Il faut l’utiliser quand elle résout un vrai problème d’état, et l’éviter quand le stateless suffit.

La persistance est pratique, mais pas une bonne pratique universelle.

Applications de la persistance de session

Applications web avec état de connexion

Elle maintient l’authentification et le contexte sur la même instance.

Elle est utile pour les portails anciens ou personnalisés.

Elle sert de pont entre sessions héritées et infrastructure moderne.

Paniers et commerce électronique

Elle protège le contenu du panier, le prix temporaire et le checkout local.

La perte de continuité a un impact commercial immédiat.

Elle est précieuse lorsque le panier reste local au nœud.

Formulaires multi-étapes et transactions

Elle maintient les données en mémoire entre les étapes.

Elle réduit les interruptions au milieu d’un parcours.

Ces flux révèlent vite les incohérences de session.

Chat, sessions temps réel et passerelles API

Elle peut réduire la reconstruction d’état dans les interactions temps réel.

Les API doivent l’utiliser seulement lorsque l’état le justifie.

La décision dépend de l’emplacement réel du contexte.

Kubernetes et Ingress

Elle aide les charges web avec état ou les migrations.

Ingress peut maintenir un routage stable vers les pods.

C’est un compromis courant dans les clusters hybrides.

Bonnes pratiques

L’utiliser seulement pour un vrai problème

Si l’application est déjà sans état, l’affinité peut nuire au balance.

Une utilisation sélective garde l’architecture plus propre.

Elle facilite aussi la migration vers des modèles plus résilients.

Choisir la méthode avec soin

Les cookies conviennent au web, l’IP ou le hachage aux environnements contrôlés.

Un mauvais choix crée une affinité faible ou de faux regroupements.

Le choix est applicatif autant qu’infrastructurel.

Régler les délais et les pannes

Le délai doit couvrir le flux sans conserver une affinité obsolète.

Il faut tester la panne du backend lié.

Bien configurée, la persistance apporte de la stabilité sans rigidité.

FAQ

Qu’est-ce que la persistance de session simplement ?

Une fonction de balance qui garde les requêtes d’un utilisateur sur le même backend pendant une partie de la session.

Est-ce la même chose que les sessions collantes ?

Oui, les deux termes désignent généralement le même mécanisme.

Pourquoi certaines applications en ont besoin ?

Parce qu’elles gardent un état temporaire local, comme login, panier, chat ou formulaire.

Quelles sont les principales méthodes ?

Cookies, IP source, hachage et méthodes applicatives personnalisées.

Est-ce toujours une bonne idée ?

Non. Elle sert aux applications avec état, mais les architectures sans état n’en ont souvent pas besoin.