Cinquième et sixième étages. Après le câble, les adresses MAC, l’IP et TCP, on devrait logiquement parler de la couche session, puis de la couche présentation.

Sauf qu’il faut être honnête : ces deux couches n’existent presque pas.

Pas au sens où elles seraient inutiles — au sens où, dans le réseau que vous administrez tous les jours, personne ne les implémente en tant que telles. Il n’y a pas de « protocole de couche 6 » comme il y a un protocole de couche 3 (IP) ou de couche 4 (TCP). Ce sont deux étages que le modèle OSI a prévus, que la théorie décrit soigneusement, et que la réalité a purement et simplement absorbés ailleurs.

D’où le titre. Cet article n’explique pas comment configurer les couches 5 et 6 — on ne configure rien. Il explique ce qu’elles étaient censées faire, pourquoi elles ont disparu, et où sont passées leurs fonctions. C’est un article de culture réseau, pas de manipulation. Mais c’est exactement le genre de nuance qui sépare celui qui a appris OSI par cœur de celui qui l’a compris.

L’essentiel en 30 secondes

  • OSI a 7 couches. TCP/IP, ce qui tourne réellement, en a 4. Les couches 5 et 6 d’OSI n’ont pas d’équivalent dans TCP/IP — elles sont fondues dans « application ».
  • Couche 5 (session) : censée gérer l’ouverture, le maintien et la reprise d’un dialogue. En pratique, ces fonctions vivent dans TCP ou dans l’application.
  • Couche 6 (présentation) : censée gérer le format des données — encodage, chiffrement, compression. En pratique : TLS, UTF-8, JSON, gzip… tous portés par l’application.
  • On ne configure jamais une couche 5 ou 6. Il n’existe pas de service à démarrer, pas de port à ouvrir.
  • Savoir qu’elles sont théoriques vous évite de les chercher là où elles ne sont pas — et de répondre à côté en entretien.

Le malentendu de départ : OSI n’est pas TCP/IP

Pour comprendre pourquoi deux couches entières sont « fantômes », il faut revenir à une confusion qu’on traîne depuis le début de la série et qu’il est temps de régler franchement.

Il existe deux modèles, et ils n’ont pas le même nombre de couches.

Le modèle OSI (7 couches) est un modèle théorique, conçu par l’ISO dans les années 1980 comme référence universelle. Il découpe la communication en sept fonctions distinctes, proprement séparées. C’est un modèle de description : il sert à parler, à enseigner, à situer un problème.

Le modèle TCP/IP (4 couches) est le modèle réel, celui qui fait tourner Internet. Il est né de l’implémentation, pas de la théorie. Il fusionne plusieurs couches OSI parce que, en pratique, personne n’avait besoin de les séparer.

Voici la correspondance, et c’est elle qui explique tout :

OSI (théorie) TCP/IP (réalité)
7 — Application
6 — Présentation Application
5 — Session
4 — Transport Transport
3 — Réseau Internet
2 — Liaison
1 — Physique Accès réseau

Regardez la colonne de droite : les couches 5, 6 et 7 d’OSI sont écrasées en une seule couche « Application » dans TCP/IP. Ce n’est pas un oubli. C’est un constat d’ingénieur : dans la vraie vie, ce qui relève de la session, du format et de l’application est géré au même endroit — dans le programme lui-même.

C’est exactement le même phénomène qu’on a vu tout en bas de la pile, où OSI sépare le physique (1) et la liaison (2) alors que TCP/IP les fusionne en « accès réseau ». Le modèle réel simplifie aux deux extrémités.

Couche 5 — Session : le dialogue

Ce qu’elle est censée faire, en théorie.

La couche session gère la conversation entre deux applications : l’ouvrir, la maintenir, la refermer proprement, et surtout la synchroniser. Trois fonctions lui sont attribuées dans les manuels :

  • L’établissement et la libération de la session — décider quand le dialogue commence et quand il finit.
  • Le dialogue — gérer qui parle quand (半-duplex, full-duplex).
  • La synchronisation — poser des points de reprise (checkpoints) dans un transfert long, pour ne pas tout recommencer en cas de coupure. L’exemple classique : un transfert de 2 Go qui coupe à 1,9 Go reprend au dernier checkpoint plutôt qu’à zéro.

Ce qui se passe réellement.

Aucune de ces fonctions n’a de protocole dédié en TCP/IP. Elles existent — mais ailleurs :

  • L’établissement et la fin de session, c’est le three-way handshake et la fermeture de TCP. La « session » au sens réseau, c’est la connexion TCP elle-même. Elle vit en couche 4.
  • La reprise sur point de contrôle, quand elle existe, est gérée par l’application. Un rsync qui reprend un transfert interrompu, un téléchargement HTTP avec en-tête Range qui reprend où il s’était arrêté, un client de sauvegarde qui reprend son job : c’est du code applicatif, pas une couche réseau.

Les rares protocoles qu’on cite comme « couche 5 » en formation — NetBIOS, RPC, PPTP, les sockets — sont soit des interfaces de programmation, soit des protocoles anciens, soit des choses qui chevauchent plusieurs couches sans en habiter vraiment une. Aucun n’est « le protocole de la couche session » comme IP est le protocole de la couche réseau.

En une phrase : la couche 5 décrit une fonction réelle — gérer un dialogue — mais cette fonction est assurée par TCP en dessous et par l’application au-dessus. Il n’y a rien entre les deux.

Couche 6 — Présentation : le format

Ce qu’elle est censée faire, en théorie.

La couche présentation s’occupe de la forme des données, indépendamment de leur sens. Son rôle : garantir que ce qu’une machine envoie, l’autre sait le lire, même si elles n’ont pas la même architecture interne. Trois missions :

  • L’encodage des caractères — se mettre d’accord sur la façon de représenter du texte (ASCII, UTF-8, EBCDIC autrefois).
  • Le chiffrement — transformer les données pour qu’un tiers ne puisse pas les lire.
  • La compression — réduire le volume avant transport.

C’est, sur le papier, la couche du « traducteur » : elle prend les données dans le format interne de l’application et les met dans un format neutre, transportable, compris des deux côtés.

Ce qui se passe réellement.

Ces trois fonctions sont omniprésentes dans le réseau moderne — mais aucune n’est une couche. Toutes sont portées par l’application ou par des bibliothèques qu’elle appelle :

  • L’encodage : UTF-8 s’est imposé comme standard de fait. Quand votre navigateur lit Content-Type: text/html; charset=utf-8, c’est une négociation de « couche présentation »… gérée par HTTP, un protocole applicatif.
  • Le chiffrement : c’est TLS, et c’est le cas le plus intéressant — on y revient juste après, parce qu’il mérite une section à lui seul.
  • La compression : gzip, brotli, deflate. Quand un serveur web renvoie Content-Encoding: gzip, il fait du travail de « couche 6 »… via un en-tête HTTP, donc en couche 7.

Les formats de données eux-mêmes — JSON, XML, JPEG, ASCII, UTF-8 — sont les exemples qu’on donne pour illustrer la couche 6. Mais remarquez : ce sont des formats, pas des protocoles réseau. Personne ne « configure la couche présentation ». On choisit un format dans son code, et voilà.

Le cas TLS : la couche fantôme la plus visible

S’il y a un endroit où la couche 6 semble reprendre vie, c’est TLS (Transport Layer Security), le chiffrement derrière le petit cadenas de HTTPS. C’est l’exemple parfait, parce qu’il montre à quel point le modèle en couches devient flou dès qu’on quitte la théorie.

TLS fait clairement un travail de couche présentation : il chiffre les données (mission n°2 de la couche 6). Mais regardez où il se situe réellement :

  • son nom dit « Transport Layer Security » — il se présente comme de la couche 4 ;
  • il s’appuie sur TCP (couche 4), donc il est au-dessus ;
  • il sert HTTP (couche 7), donc il est en dessous ;
  • il chiffre, ce qui est une fonction de couche 6.

Alors, TLS, c’est quelle couche ? La question n’a pas de bonne réponse, et c’est précisément l’enseignement. On le situe généralement « entre la 4 et la 7 », ou on dit qu’il occupe « la 5 et la 6 » à lui seul. La vérité, c’est que TLS ne respecte pas le découpage OSI parce que le découpage OSI n’a jamais été fait pour être implémenté — seulement pour décrire.

TLS est la preuve vivante que les couches 5 et 6 correspondent à des fonctions réelles (gérer une session sécurisée, chiffrer le contenu) qui, dans le monde réel, sont assurées par un composant qui refuse de rentrer dans une case. C’est une couche fantôme parce qu’elle fait le travail des couches 5-6 sans en être une.

Pourquoi ça compte quand même

À ce stade, on pourrait se dire : si ces couches n’existent pas en pratique, pourquoi s’embêter ? Trois raisons, très concrètes.

Pour ne pas les chercher là où elles ne sont pas. Un débutant qui débogue un problème de chiffrement va « chercher la couche 6 ». Il n’y en a pas. Le problème est dans TLS, dans la config du serveur web, dans un certificat — des endroits applicatifs. Savoir que la couche 6 est fantôme, c’est regarder au bon endroit du premier coup. Pour l’examen et l’entretien. La question « à quelle couche se situe TLS ? » est un grand classique — et c’est un piège. La mauvaise réponse est de balancer un chiffre avec assurance. La bonne réponse est de dire que TLS chevauche plusieurs couches, qu’il fait un travail de présentation (chiffrement) tout en s’appuyant sur le transport, et que le modèle OSI montre ici ses limites. Cette réponse-là distingue immédiatement celui qui a compris de celui qui a récité.

Pour comprendre la vraie architecture. Le réseau moderne n’a pas sept étages bien rangés. Il a un bas de pile très structuré (couches 1 à 4, où chaque protocole a sa place nette) et un haut de pile flou (5 à 7), où tout se joue dans l’application et ses bibliothèques. Accepter ce flou, c’est arrêter de plaquer un modèle théorique sur une réalité qui ne lui obéit pas.

Les erreurs classiques

  • Chercher un « protocole de couche 5 ou 6 » comme il en existe en couche 3 ou 4. Il n’y en a pas. Ce sont des fonctions, pas des protocoles.
  • Vouloir configurer la couche présentation. Il n’y a rien à configurer : pas de service, pas de port. Le chiffrement se règle dans TLS, l’encodage dans l’application.
  • Répondre « couche 6 » sans nuance à la question TLS. TLS chevauche plusieurs couches ; l’affirmation péremptoire est le piège.
  • Confondre format et protocole. JSON, UTF-8, JPEG sont des formats de données, pas des protocoles réseau. Ils illustrent la couche 6 sans en être des implémentations.
  • Croire qu’OSI décrit la réalité. OSI décrit ; TCP/IP implémente. Les deux ne se superposent pas au sommet.

Ce que je retiens

  1. OSI a 7 couches, TCP/IP en a 4. Les couches 5, 6 et 7 d’OSI sont fondues dans l’unique couche « Application » de TCP/IP. Ce n’est pas un raccourci, c’est le constat de l’ingénierie réelle.
  2. La couche 5 (session) décrit une vraie fonction — gérer un dialogue — assurée en pratique par TCP en dessous et l’application au-dessus. Pas de protocole dédié.
  3. La couche 6 (présentation) décrit trois fonctions bien réelles — encodage, chiffrement, compression — toutes portées aujourd’hui par l’application (UTF-8, TLS, gzip).
  4. On ne configure jamais ces couches. Aucun service, aucun port. Si vous cherchez à « régler la couche 6 », vous cherchez au mauvais endroit.
  5. TLS est la couche fantôme incarnée : il fait le travail des couches 5-6 sans rentrer dans aucune case. C’est la meilleure démonstration que le modèle OSI décrit sans implémenter.
  6. Le haut de la pile est flou, et c’est normal. Bas de pile structuré, sommet applicatif. Accepter ce flou, c’est avoir compris le modèle plutôt que de l’avoir récité.

Les couches 5 et 6 étaient les fantômes du modèle. La couche 7, elle, est tout l’inverse : c’est la plus vivante, la plus riche, celle où vivent HTTP, DNS, TLS et DHCP — tout ce que vous manipulez chaque jour. C’est le dernier étage, et le plus peuplé.

Prochain article.