TCP/IP : le TCP Internet Protocol qui structure les échanges dans les réseaux informatiques

Le TCP Internet Protocol, qu’on appelle presque toujours TCP/IP, reste le socle invisible de pratiquement tout ce qui circule dans nos réseaux. Que ce soit un simple clic sur un lien, l’envoi d’un mail ou la synchronisation d’une base de données entre deux sites, tout passe par ce duo de protocoles. TCP s’occupe de rendre la livraison fiable, IP se charge de faire voyager les paquets à travers des réseaux qui ne se connaissent pas forcément. Sans eux, Internet tel qu’on le connaît n’existerait tout simplement pas.

En fait, ce n’est pas un seul protocole mais une suite organisée en couches. Et cette organisation, née dans les années 70 pour interconnecter des réseaux différents, a si bien marché qu’on continue à s’appuyer dessus en 2026, même si des alternatives plus récentes commencent à grignoter certains usages web.

TCP et IP : deux rôles bien distincts qui ne fonctionnent que ensemble

TCP, Transmission Control Protocol, vit dans la couche transport. Il établit une connexion réelle entre deux machines, découpe les données en segments numérotés, vérifie qu’ils arrivent dans l’ordre et sans erreur, et renvoie ce qui manque. IP, de son côté, s’occupe seulement de l’acheminement : il met une adresse source et destination sur chaque paquet et laisse les routeurs décider du chemin. IP ne garantit rien. Un paquet peut se perdre, arriver en double ou dans le désordre. C’est TCP qui rattrape.

Le truc, c’est que les deux se complètent parfaitement. IP joue le rôle du facteur qui livre n’importe où sans garantie de lecture, TCP joue le rôle du service qui s’assure que toutes les pages d’une lettre arrivent complètes et dans le bon ordre, avec accusés de réception. Cette séparation est ce qui a permis au modèle de scaler aussi bien.

D’ailleurs, l’idée date de 1974 avec Vint Cerf et Bob Kahn. Le protocole a été déployé sur l’Arpanet en 1983 et sa spécification de base (RFC 793) n’a quasiment pas bougé dans ses fondations. On a juste ajouté des raffinements au fil des décennies.

Les quatre couches du modèle TCP/IP

Le modèle TCP/IP découpe la communication en quatre couches. C’est plus pragmatique que le modèle OSI à sept couches parce qu’il est né des protocoles qui existaient déjà et qui marchaient vraiment.

Couche d’accès réseau

C’est le niveau le plus bas. Elle gère le média physique et la liaison locale : Ethernet, Wi-Fi, les drivers réseau, la mise en forme des données en frames. Tout ce qui touche au câble, à l’onde radio ou au commutateur local se passe ici. Pas de routage, juste la transmission sur un segment de réseau.

Couche Internet

Ici arrive IP. Il ajoute les adresses logiques, fragmente si besoin, et laisse les routeurs trouver un chemin vers la destination, même si elle est à l’autre bout de la planète. C’est aussi dans cette couche qu’on trouve ICMP (pour les pings et les messages d’erreur) et ARP (qui associe une IP à une adresse MAC sur le réseau local).

Couche de transport

C’est le domaine de TCP et de UDP. TCP crée la connexion, contrôle le débit pour ne pas saturer le receveur, détecte la congestion et ajuste sa vitesse d’envoi. UDP, lui, n’établit rien : il envoie et basta. Plus rapide, moins fiable. Le choix entre les deux dépend vraiment de ce qu’on veut privilégier.

Couche application

C’est là que vivent les protocoles que les utilisateurs voient : HTTP et HTTPS pour le web, SMTP/IMAP pour les mails, FTP ou SFTP pour les fichiers, SSH pour l’administration distante, DNS pour traduire les noms en adresses. Les données de l’application descendent les couches en s’habillant d’en-têtes à chaque étape, puis remontent dans l’autre sens à l’arrivée.

Quand tu télécharges un fichier, les octets de l’application deviennent un segment TCP, puis un paquet IP, puis une frame sur le lien physique. À l’autre bout, tout se dépile proprement.

Comment TCP établit une connexion fiable

Avant d’envoyer la moindre donnée utile, TCP fait un petit ballet à trois temps, le fameux three-way handshake. Le client envoie un SYN avec un numéro de séquence initial. Le serveur répond par un SYN-ACK qui accuse réception et propose son propre numéro de séquence. Le client confirme avec un ACK. À ce moment précis, les deux côtés sont synchronisés et savent exactement quel octet ils doivent recevoir ensuite.

Une fois la connexion ouverte, chaque segment porte un numéro de séquence et un accusé de réception cumulatif. Si le receveur détecte un trou (trois accusés dupliqués ou expiration du timer), TCP retransmet. Il ajuste aussi sa fenêtre d’envoi selon ce que l’autre côté peut absorber et selon la congestion qu’il perçoit sur le chemin. C’est ce mécanisme qui empêche le réseau de s’effondrer quand tout le monde envoie en même temps.

La fermeture se fait en quatre temps, chaque côté envoyant son FIN et attendant l’ACK correspondant. Simple, mais diablement efficace.

TCP versus UDP : choisir le bon outil

Beaucoup d’applications critiques ont besoin de TCP : navigation web classique, téléchargement de fichiers, envoi de mails, accès distant SSH, transactions. Perdre un octet ou le recevoir dans le mauvais ordre n’est pas acceptable.

D’autres, en revanche, préfèrent UDP : appels vidéo, jeux en ligne, streaming live, DNS pour les requêtes courtes. Là, un paquet perdu de temps en temps passe mieux qu’un délai causé par une retransmission. DNS utilise d’ailleurs UDP en premier et bascule sur TCP seulement quand la réponse est trop grosse.

Le point c’est que ce n’est pas une guerre, c’est une question de compromis entre fiabilité et latence.

TCP, TLS et les évolutions récentes

Pour la sécurité, on ajoute presque toujours TLS au-dessus de TCP. C’est ce qui transforme HTTP en HTTPS : le chiffrement et l’authentification se font après que TCP a établi sa connexion fiable. Sans TLS, les données voyagent en clair et n’importe qui sur le chemin peut les lire.

Une alternative plus récente, QUIC (qui tourne sur UDP), gagne du terrain pour le web. Elle combine transport et chiffrement dès le premier paquet et réduit le nombre d’allers-retours initiaux. En 2025, une part significative du trafic web passe déjà par HTTP/3 sur QUIC, surtout sur mobile et pour les services de streaming. Mais dans les environnements d’entreprise, les applis legacy et tout ce qui exige une compatibilité maximale, TCP reste le choix par défaut. Il est mature, ses implémentations sont partout, et ses mécanismes de fiabilité ont fait leurs preuves depuis des décennies.

TCP/IP en 2026 : toujours le pilier, mais pas figé

Franchement, c’est impressionnant qu’un modèle conçu il y a plus de cinquante ans tienne encore la quasi-totalité du trafic fiable sur Internet. IPv6 a élargi l’espace d’adressage, les algorithmes de contrôle de congestion se sont améliorés (slow start, fast recovery, et des approches plus récentes comme BBR qui exploitent mieux les liens haut débit), mais la structure en quatre couches et les rôles de TCP et IP n’ont pas changé.

Dans un réseau d’entreprise concret, comprendre TCP/IP aide tous les jours. Quand un lien paraît saturé, souvent c’est TCP qui a détecté des pertes et qui a réduit son débit. Quand une appli devient lente après un firewall mal configuré, c’est souvent un problème de ports ou de sessions TCP qui ne s’établissent plus correctement. Savoir comment ça marche permet de diagnostiquer plus vite et de dimensionner plus justement.

Au bout du compte, le TCP Internet Protocol n’est pas juste une vieille relique technique. C’est l’outil qui permet à des millions d’appareils hétérogènes de communiquer de manière prévisible et fiable. Et tant que des données critiques devront arriver intactes, il restera au centre de nos réseaux.