Couche 5 du modèle OSI (session) : ouvrir, maintenir et reprendre un échange

TL;DRLa couche session du modèle OSI ouvre, organise et referme le dialogue entre deux applications, et permet de reprendre un échange interrompu sans tout recommencer. Dans l'Internet réel, elle n'a pas de protocole propre : voici où l'on retrouve ses idées, comment observer une reprise de session TLS, et pourquoi elle n'a rien à voir avec la session de votre site.

📌 La couche session en une phrase#

La couche 5 (layer 5) du modèle OSI, appelée couche session, organise le dialogue entre deux applications : elle l'ouvre, le fait vivre, le découpe en étapes que l'on peut reprendre, puis le ferme proprement. Là où la couche 4 livre des données d'un programme à un autre, la couche 5 se demande : qui parle, quand, et où en est-on si la ligne coupe ?

C'est aussi la couche la plus discrète du modèle : dans l'Internet réel, elle n'a pas de protocole propre. Voyons ce que la norme attend d'elle et où l'on retrouve ses idées.

📌 Ce que la norme attend de la couche session#

Le modèle OSI est un modèle de référence (ISO/IEC 7498-1, ITU-T X.200) ; le service de session est détaillé dans la recommandation ITU-T X.215. Son rôle tient en quatre verbes.

• Établir la session, en s'accordant sur les règles du dialogue.
• Gérer les tours de parole et le transfert des données.
• Synchroniser : poser des repères pour revenir en arrière en cas de problème.
• Terminer de façon ordonnée, sans perdre ce qui était en transit.

📌 Les modes de dialogue#

Deux interlocuteurs peuvent communiquer de trois façons :

Le service de session OSI organise surtout les deux derniers cas : le dialogue à l'alternat, où un jeton (token) désigne qui a le droit d'émettre, et le dialogue simultané. Le simplex, à sens unique, n'est pas vraiment un dialogue.

📌 Les points de synchronisation#

Pendant un long transfert, les deux parties posent des points de synchronisation, des repères numérotés qui signifient « tout ce qui précède est bien arrivé ». Si la communication est interrompue, on ne recommence pas depuis le début : on reprend au dernier point validé. La norme distingue des points majeurs, qui découpent l'échange en grandes étapes confirmées, et des points mineurs, plus légers.

📌 Dans TCP/IP, la couche 5 n'existe pas en tant que telle#

Il faut le dire franchement : Internet ne suit pas le modèle OSI à la lettre. Il repose sur le modèle TCP/IP, décrit notamment dans la RFC 1122, qui ne compte que quatre couches : liaison, internet, transport et application. Les couches 5, 6 et 7 de l'OSI y sont fondues dans une seule couche application.

Aucun protocole courant ne s'occupe uniquement « de session ». Ses fonctions sont assurées :

• par les applications elles-mêmes (un navigateur qui reprend un téléchargement, un logiciel de visioconférence qui se reconnecte) ;
• par des protocoles hybrides, qui mélangent des fonctions de plusieurs couches, comme TLS ;
• parfois par la couche transport : TCP ouvre et ferme déjà ses connexions et fonctionne en full-duplex.

C'est pourquoi les exemples de « protocoles de couche 5 » varient d'un manuel à l'autre : ce sont des repères pédagogiques.

📌 Des exemples réels, à classer avec nuance#

Au quotidien : ouvrir un dossier partagé sur le serveur de fichiers du bureau ouvre une session SMB ; le téléphone IP de l'accueil sonne parce que SIP a établi une session d'appel ; une messagerie web qui affiche un nouveau message sans recharger la page utilise souvent une connexion WebSocket.

📌 Session réseau ou session de votre site : deux choses différentes#

Le mot « session » désigne deux réalités souvent confondues.

• La session au sens réseau (couche 5, ou ce qui en tient lieu) : le dialogue technique entre deux machines, comme une session TLS ou une session SMB. Elle vit tant que l'échange dure et ne sait rien de qui vous êtes sur le site.
• La session applicative d'un site web : la mémoire que le site garde de vous d'une page à l'autre. C'est elle qui retient votre panier ou votre connexion à l'espace client.

HTTP est un protocole sans état : chaque requête est indépendante. Pour vous reconnaître, un site PHP vous envoie un cookie de session, par défaut nommé PHPSESSID, qui contient un identifiant. Le serveur associe cet identifiant à des données qu'il conserve de son côté. Votre navigateur peut changer de connexion TCP, de session TLS ou de réseau Wi-Fi : tant qu'il renvoie le cookie, la session applicative continue.

Vous pouvez voir ce cookie avec curl :

$ curl -s -o /dev/null -D - https://www.websource.fr/login | grep -i set-cookie
set-cookie: PHPSESSID=e94b…; expires=Thu, 29 Oct 2026 08:57:29 GMT; Max-Age=604800; path=/; secure; httponly; samesite=lax

Relevé le 22 octobre 2026 (identifiant volontairement tronqué). Le serveur crée une session applicative et demande au navigateur de garder le cookie 604 800 secondes, soit sept jours. Les attributs secure, httponly et samesite=lax protègent cet identifiant (HTTPS seulement, invisible pour le JavaScript, envoi limité depuis d'autres sites).

Sur un site à plusieurs serveurs, des sessions restées sur le disque d'une seule machine font perdre leur panier aux visiteurs : notre article sur le load balancing et les sessions persistantes détaille les solutions.

📌 Le téléchargement qui reprend : un point de reprise concret#

L'illustration la plus parlante des points de synchronisation se trouve dans HTTP. Un client peut demander seulement une partie d'un fichier avec l'en-tête Range, défini dans la RFC 9110. Le serveur qui accepte répond par le code 206 Partial Content et indique la portion envoyée dans l'en-tête Content-Range.

$ curl -s -o /dev/null -D - -r 0-99 https://www.websource.fr/uploads/blog/SEO-SEM-1024x635-1.avif
HTTP/2 206
content-length: 100
content-range: bytes 0-99/6479

Relevé le 22 octobre 2026 : nous avons demandé les octets 0 à 99, le serveur en a renvoyé 100 sur un fichier qui en compte 6 479. C'est ce mécanisme qui permet à un navigateur, ou à curl -C - -O, de reprendre un téléchargement interrompu là où il s'était arrêté.

Nuance importante : ce n'est pas la couche 5 de l'OSI qui fait le travail, mais HTTP et l'application. Et le serveur n'est pas obligé d'accepter : il peut répondre 200 et renvoyer tout le contenu.

📌 Essayez vous-même : la reprise de session TLS#

En HTTPS, sur le port 443, le navigateur négocie d'abord une session TLS : échange de clés, vérification du certificat. Pour ne pas tout refaire à chaque visite, le serveur peut lui remettre un ticket de session. À la connexion suivante, le client présente ce ticket et la session reprend avec une poignée de main abrégée. En TLS 1.3, la RFC 8446 décrit ce mécanisme sous le nom de reprise par clé pré-partagée (PSK) et limite la durée de vie d'un ticket à sept jours.

Avec openssl s_client, l'option -reconnect se reconnecte cinq fois en tentant de reprendre la session :

$ openssl s_client -connect www.websource.fr:443 -servername www.websource.fr -tls1_2 -reconnect </dev/null 2>&1 | grep -E '^(New|Reused)'
New, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-CHACHA20-POLY1305

Relevé le 22 octobre 2026 vers 9 h UTC, avec OpenSSL 3.5. Comment lire ces lignes :

• New : une session complète a été négociée, avec tous les échanges de clés.
• Reused : le client a présenté sa session précédente et le serveur l'a acceptée, la poignée de main a été abrégée.
• TLSv1.2 et la suite ECDHE-ECDSA-CHACHA20-POLY1305 : la version du protocole et les algorithmes de chiffrement retenus.

Pourquoi -tls1_2 ? Sans cette option, la commande affichait six lignes New, TLSv1.3. Ce n'est pas un défaut du serveur : en TLS 1.3, le ticket arrive après la poignée de main et s_client se déconnecte avant de le lire. En lui faisant d'abord envoyer une requête HTTP, il a reçu deux tickets (durée de vie annoncée : 64 800 secondes, soit 18 heures), et la connexion suivante a affiché Reused, TLSv1.3.

Précision : sur websource.fr, le chiffrement côté visiteur est assuré par Cloudflare, placé en frontal ; c'est lui qui émet et accepte ces tickets.

Bon à savoir : TLS 1.3 permet aussi d'envoyer des données dès la reprise, avant la fin de la poignée de main (le mode « 0-RTT »). C'est plus rapide, mais la RFC 8446 prévient que ces données peuvent être rejouées par un attaquant : à réserver aux requêtes sans effet, comme lire une page, jamais à un paiement.

📌 Ce qu'il faut retenir pour votre site#

La couche 5 est surtout une grille de lecture pour diagnostiquer : la connexion est-elle coupée (couches 1 à 4, voir la couche 1, la couche 2 et la couche 3) ? La session sécurisée doit-elle être renégociée ? Ou la session applicative a-t-elle expiré ?

• Un visiteur déconnecté trop souvent : regardez la durée de vie du cookie de session et le stockage des sessions côté serveur.
• Un panier qui se vide sur un site à plusieurs serveurs : les sessions applicatives ne sont pas partagées.
• Des gros fichiers à proposer en téléchargement : vérifiez que le serveur accepte les requêtes Range.

Websource héberge un grand nombre de sites et accompagne ses clients dès la commande. Nos offres d'hébergement web démarrent dès 4,99 € HT/mois, avec le premier mois offert.

Prochaine étape de la série : la couche 6, la couche présentation, qui s'occupe de la forme des données, de leur encodage et de leur chiffrement.

❓ Questions fréquentes#

📄 À quoi sert la couche 5 du modèle OSI ?#

Elle organise le dialogue entre deux applications : elle ouvre la session, gère les tours de parole, pose des points de synchronisation pour reprendre un échange interrompu, puis ferme la session proprement.

📌 Quels protocoles appartiennent à la couche session ?#

Aucun protocole courant d'Internet n'est purement de couche 5. On cite souvent NetBIOS, RPC, SIP ou la reprise de session TLS, mais ce sont des rapprochements pédagogiques : dans le modèle TCP/IP, ces fonctions relèvent de la couche application ou de protocoles hybrides.

📌 Quelle différence entre une session TLS et une session PHP ?#

La session TLS est le dialogue chiffré entre le navigateur et le serveur. La session PHP est la mémoire que le site garde de vous grâce au cookie PHPSESSID, par exemple votre panier ou votre connexion à l'espace client. L'une peut continuer sans l'autre.

📌 Que signifient New et Reused dans openssl s_client ?#

New indique qu'une session TLS complète a été négociée. Reused indique que le client a présenté une session précédente et que le serveur l'a acceptée, avec une poignée de main abrégée.

📌 Comment un téléchargement peut-il reprendre après une coupure ?#

Le client demande seulement la partie manquante du fichier avec l'en-tête HTTP Range. Si le serveur l'accepte, il répond par le code 206 Partial Content et n'envoie que les octets demandés.

Article publié le 04/11/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.