Quand vous ouvrez un navigateur et tapez une adresse web, vous déclenchez une cascade d’échanges invisibles entre des dizaines de serveurs dans le monde. Ces échanges sont rendus possibles par des protocoles — des langages communs, des règles de communication que tous les équipements internet acceptent de respecter. Sans protocoles, votre ordinateur ne pourrait pas plus “parler” à un serveur qu’un Français et un Japonais ne peuvent se comprendre sans langue commune.
Ce guide vous explique les protocoles fondamentaux d’internet en langage clair. Pas besoin d’être ingénieur réseau : des analogies du quotidien illustrent chaque concept.
Qu’est-ce qu’un protocole réseau ?
Un protocole réseau est un ensemble de règles formelles qui définissent comment deux machines communiquent. Il précise le format des messages, l’ordre des échanges, les mécanismes de détection d’erreurs et les procédures de reconnexion.
Imaginez le protocole comme la politesse téléphonique : vous ne commencez pas par crier votre message avant que l’autre personne ait décroché. Vous attendez le “allô”, vous vous présentez, l’autre confirme qu’il entend bien, puis la conversation commence. En réseau, c’est la même chose, mais codifié en bits et en octets.
Les protocoles internet sont organisés en couches (le modèle OSI à 7 couches, ou le modèle TCP/IP à 4 couches, plus pragmatique). Chaque couche a une responsabilité précise et communique avec les couches adjacentes via des interfaces définies. Cette organisation permet à chaque couche d’évoluer indépendamment des autres.
TCP et UDP : les deux moteurs du transport
Au cœur de l’internet se trouvent deux protocoles de transport fondamentaux, qui opèrent à la couche 4 du modèle OSI. Ils transportent les données entre deux points mais avec des philosophies radicalement différentes.
TCP : la fiabilité avant tout
Le TCP (Transmission Control Protocol) est le protocole fiable d’internet. Il décompose vos données en paquets numérotés, les envoie au destinataire, et attend une confirmation de réception (ACK) pour chaque paquet. Si un paquet est perdu en chemin, TCP le retransmet automatiquement. Si des paquets arrivent dans le désordre, TCP les réassemble dans le bon ordre.
Avant d’envoyer la moindre donnée, TCP établit une connexion via la poignée de main en trois temps (three-way handshake) :
- Le client envoie un paquet SYN (synchronize) au serveur.
- Le serveur répond avec un SYN-ACK (synchronize-acknowledge).
- Le client confirme avec un ACK (acknowledge).
Ce mécanisme garantit que les deux parties sont prêtes à communiquer avant le premier octet de données. Le revers de la médaille : cette fiabilité a un coût en latence. TCP est utilisé pour le web (HTTP/HTTPS), les emails (SMTP, IMAP), les transferts de fichiers (FTP, SFTP) — tous les usages où perdre des données est inacceptable.
UDP : la vitesse avant tout
L’UDP (User Datagram Protocol) est le protocole sans état, sans connexion et sans garantie. Il envoie des paquets (datagrammes) sans confirmation de réception, sans numérotation, sans réassemblage. Si un paquet est perdu, il est perdu — UDP ne le retransmet pas.
Pourquoi utiliser UDP dans ces conditions ? Parce que dans certains contextes, la vitesse prime sur la fiabilité. Pour un jeu en ligne en temps réel, mieux vaut perdre une frame de mouvement que d’attendre la retransmission et provoquer un gel. Pour un appel vidéo (VoIP), un paquet perdu crée un bref artefact sonore bien moins gênant qu’un blocage complet.
UDP est utilisé pour : streaming vidéo en direct, jeux en ligne, DNS (les requêtes courtes bénéficient de la rapidité d’UDP), VPN modernes (WireGuard utilise UDP). Pour en savoir plus sur les VPN et leur utilisation des protocoles réseau, consultez notre guide VPN complet.
Le DNS : l’annuaire téléphonique d’internet
Le DNS (Domain Name System) est peut-être le protocole le plus crucial et le moins visible d’internet. Il traduit les noms de domaine lisibles par les humains (winmx-france.com) en adresses IP numériques que les machines utilisent (104.21.45.87).
La résolution DNS étape par étape
Voici ce qui se passe exactement quand votre navigateur résout un nom de domaine :
Étape 1 — Le cache local : votre ordinateur vérifie d’abord son propre cache DNS (les réponses récentes mémorisées) et le fichier hosts local. Si la réponse y est, la résolution s’arrête là.
Étape 2 — Le résolveur récursif : si le cache local ne contient pas la réponse, la requête est transmise au résolveur DNS de votre FAI (ou au résolveur que vous avez configuré manuellement : 1.1.1.1 pour Cloudflare, 8.8.8.8 pour Google, 9.9.9.9 pour Quad9). Ce résolveur va interroger la hiérarchie DNS à votre place.
Étape 3 — Les serveurs racine : le résolveur interroge l’un des 13 serveurs racine DNS (A à M) qui connaissent les serveurs autoritaires pour chaque TLD.
Étape 4 — Le serveur TLD : le serveur racine renvoie l’adresse du serveur autoritaire pour .com. Le résolveur l’interroge, qui retourne l’adresse des serveurs de noms (nameservers) de votre domaine.
Étape 5 — Le serveur autoritaire : le résolveur interroge les nameservers de votre domaine, qui retournent l’enregistrement A (adresse IP) demandé.
Tout ce processus prend généralement moins de 50 millisecondes, et les réponses sont mises en cache à chaque étape selon le TTL (Time To Live) défini dans les enregistrements.
La configuration des enregistrements DNS (A, AAAA, CNAME, MX, TXT) est détaillée dans notre guide hébergement web et noms de domaine.
HTTP et HTTPS : le langage du web
Le HTTP (HyperText Transfer Protocol) est le protocole de la couche applicative qui permet aux navigateurs de demander des pages web aux serveurs et de recevoir leurs réponses. Pour les développeurs qui souhaitent mettre ces protocoles en pratique et créer leurs premiers projets web, Code Your Web propose des tutoriels HTML, CSS et JavaScript qui partent des fondamentaux du protocole HTTP jusqu’à la création d’applications interactives.
Structure d’une requête HTTP
Une requête HTTP est un message texte structuré. La plus simple ressemble à :
GET /index.html HTTP/1.1
Host: winmx-france.com
Accept: text/html
User-Agent: Mozilla/5.0...
La première ligne précise la méthode (GET pour récupérer, POST pour envoyer des données, PUT pour mettre à jour, DELETE pour supprimer), l’URL de la ressource et la version HTTP. Les lignes suivantes sont des en-têtes qui transmettent des informations supplémentaires.
Le serveur répond avec un code de statut (200 OK, 404 Not Found, 301 Moved Permanently, 500 Internal Server Error…) suivi du contenu demandé.
HTTPS : HTTP + chiffrement TLS
HTTPS n’est pas un protocole distinct mais HTTP encapsulé dans une couche TLS (Transport Layer Security). TLS ajoute deux garanties fondamentales : l’authentification (le certificat SSL prouve que vous communiquez bien avec le bon serveur) et le chiffrement (les données échangées sont illisibles pour quiconque intercepte le trafic).
La négociation TLS (handshake TLS) se produit avant la première requête HTTP et implique un échange de clés cryptographiques, la vérification du certificat et l’accord sur les algorithmes de chiffrement à utiliser. Ce processus ajoute quelques dizaines de millisecondes à la première connexion — les connexions suivantes réutilisent la session TLS établie.
Les implications de sécurité du HTTPS sont approfondies dans notre guide sécurité réseau.
HTTP/2 et HTTP/3 : l’évolution du protocole web
HTTP/1.1 (1997) souffre d’une limitation majeure : il ne peut traiter qu’une seule requête à la fois par connexion TCP. Pour une page moderne avec 80 ressources (fichiers CSS, JavaScript, images), le navigateur ouvre jusqu’à 6 connexions TCP parallèles par domaine — une limitation qui crée des goulots d’étranglement.
HTTP/2 (2015) résout ce problème avec le multiplexage : plusieurs requêtes et réponses transitent simultanément sur une seule connexion TCP, entrelacées sous forme de frames binaires. Il ajoute la compression des en-têtes HPACK (les en-têtes répétitifs ne sont plus retransmis intégralement) et le Server Push (le serveur envoie des ressources avant que le navigateur ne les demande explicitement).
HTTP/3 (standardisé en 2022) va plus loin en remplaçant TCP par QUIC (Quick UDP Internet Connections), un protocole basé sur UDP développé par Google. QUIC intègre nativement le multiplexage, la reprise de connexion et le chiffrement TLS 1.3. Son avantage clé : pas de head-of-line blocking — en HTTP/2 sur TCP, la perte d’un paquet bloque toutes les requêtes en attente. QUIC traite chaque flux indépendamment, de sorte qu’un paquet perdu n’affecte qu’une seule requête.
FTP héritage vs SFTP et SCP : les protocoles de transfert de fichiers
Le FTP (File Transfer Protocol) est l’un des plus anciens protocoles internet, conçu en 1971. Il permet de transférer des fichiers entre un client et un serveur.
La faille fondamentale du FTP classique
Le FTP transmettait historiquement toutes les données — y compris les identifiants de connexion — en texte clair. N’importe qui capable d’intercepter le trafic réseau pouvait lire votre nom d’utilisateur et votre mot de passe. Cette lacune est rédhibitoire pour tout usage sur internet public.
Le FTP utilise deux connexions TCP séparées : le canal de contrôle (port 21) pour les commandes et le canal de données (port 20 ou un port aléatoire en mode passif) pour les transferts. Ce mode de fonctionnement pose des problèmes avec les firewalls et les NAT, qui doivent intercepter le contenu du canal de contrôle pour identifier et autoriser le canal de données — ce qu’on appelle le FTP ALG (Application Layer Gateway).
SFTP : FTP dans le tunnel SSH
Le SFTP (SSH File Transfer Protocol) n’a de “FTP” que le nom : c’est un protocole entièrement distinct, conçu pour fonctionner à l’intérieur d’une session SSH. Il bénéficie donc de toutes les protections de SSH : chiffrement intégral, authentification par clé cryptographique, intégrité des données.
SFTP utilise une seule connexion (port 22 par défaut), ce qui élimine les problèmes de firewall liés au double canal FTP. C’est le protocole de référence pour les transferts de fichiers sécurisés en 2026.
FTPS : FTP + TLS
Le FTPS (FTP Secure) ajoute une couche TLS au FTP traditionnel, protégeant ainsi les données en transit. Il est distinct du SFTP et conserve la complexité du double canal FTP. Certains hébergeurs web traditionnels le proposent comme alternative au FTP classique, mais SFTP reste préférable quand le serveur le supporte.
SSH : le couteau suisse de l’administration distante
Le SSH (Secure Shell) est le protocole standard pour accéder à distance à un serveur en ligne de commande de manière sécurisée. Conçu en 1995 pour remplacer Telnet (qui transmettait tout en clair), SSH est devenu indispensable pour tout administrateur système ou développeur.
Comment fonctionne l’authentification SSH
SSH propose deux méthodes d’authentification principales :
Par mot de passe : le client envoie son identifiant et son mot de passe au serveur, qui les vérifie. Simple mais vulnérable aux attaques par force brute — un serveur SSH exposé sur internet reçoit des milliers de tentatives de connexion automatisées par jour. Des outils comme fail2ban bloquent automatiquement les IP après plusieurs échecs.
Par clé cryptographique (la méthode recommandée) : une paire de clés est générée — une clé privée (que vous gardez secrète sur votre machine) et une clé publique (que vous déposez sur le serveur). Lors de la connexion, le serveur challenge le client avec un message chiffré avec la clé publique, que seul le détenteur de la clé privée peut déchiffrer. Aucun secret ne transite sur le réseau — même si l’échange est intercepté, il est inutilisable.
La génération de clés SSH se fait en une seule commande : ssh-keygen -t ed25519 génère une paire de clés utilisant l’algorithme Edwards-curve Digital Signature Algorithm, considéré comme plus sûr et plus compact que RSA en 2026.
SSH au-delà de l’accès distant
SSH offre des fonctionnalités bien au-delà du simple accès à un terminal :
Le tunnel SSH redirige du trafic réseau à travers la connexion SSH chiffrée. Utile pour accéder à un service interne d’un serveur (une interface web d’administration, une base de données) sans l’exposer publiquement.
Le transfert d’agent (agent forwarding) permet d’utiliser vos clés SSH locales pour vous authentifier sur des serveurs distants, sans copier vos clés privées sur ces serveurs.
Mosh (Mobile Shell) est une alternative à SSH optimisée pour les connexions mobiles et instables : il maintient la session lors des changements de réseau et des déconnexions temporaires.
SMTP, IMAP et POP3 : les protocoles de messagerie
L’email repose sur trois protocoles distincts, chacun ayant un rôle précis dans la chaîne de communication. Pour les entreprises qui configurent leur messagerie sur un réseau d’entreprise, notre guide réseau d’entreprise pour les PME couvre la mise en place des enregistrements SPF, DKIM et MX dans un contexte professionnel.
SMTP : l’envoi des emails
Le SMTP (Simple Mail Transfer Protocol) est le protocole d’envoi des emails, utilisé à deux moments : quand votre client de messagerie (Thunderbird, Outlook) envoie un email à votre serveur de messagerie, et quand ce serveur transmet l’email au serveur du destinataire.
SMTP fonctionne via des échanges textuels simples entre serveurs. L’envoi d’un email ressemble à une conversation formelle : le serveur expéditeur se présente (commande EHLO), annonce l’expéditeur (MAIL FROM), les destinataires (RCPT TO), puis transmet le contenu (DATA). Les serveurs SMTP modernes utilisent STARTTLS pour chiffrer ces échanges.
Les filtres anti-spam (SPF, DKIM, DMARC) s’appuient sur des enregistrements DNS pour vérifier que le serveur expéditeur est autorisé à envoyer au nom du domaine déclaré — une couche d’authentification essentielle pour la délivrabilité.
IMAP vs POP3 : récupérer ses emails
IMAP (Internet Message Access Protocol) est le protocole moderne de réception des emails. Il synchronise vos emails en laissant les messages sur le serveur. Tous vos appareils (ordinateur, smartphone, tablette) voient exactement la même boîte mail, les mêmes dossiers, les mêmes statuts de lecture. IMAP est le protocole par défaut de Gmail, Outlook et tous les services modernes.
POP3 (Post Office Protocol version 3) est l’ancienne méthode : il télécharge et supprime les emails du serveur. Une fois récupérés, les messages n’existent que sur l’appareil qui les a téléchargés. POP3 était approprié quand on n’avait qu’un seul ordinateur. En 2026, il est pratiquement abandonné pour les usages personnels.
Les protocoles de messagerie s’appuient sur l’infrastructure DNS pour la résolution des serveurs MX et sur TLS pour le chiffrement des connexions — des concepts développés dans notre guide sécurité réseau.
Les protocoles internet forment ainsi un édifice cohérent où chaque brique s’appuie sur les précédentes. TCP/IP et UDP constituent les fondations du transport. DNS traduit les adresses. TLS chiffre les échanges. HTTP, SMTP, SSH et FTP construisent les services applicatifs sur ces fondations. Comprendre chaque couche vous donne une vision claire de ce qui se passe réellement quand vous naviguez, envoyez un email ou transférez un fichier.