HTTP vs HTTPS : ce que le chiffrement change vraiment
9 min · Intermédiaire · 7 août 2026
Le même protocole, une couche en plus
HTTPS n’est pas un protocole différent de HTTP : c’est HTTP transporté à l’intérieur d’une connexion chiffrée (TLS). Tout ce qui a été vu dans ce cours (méthodes, codes de statut, en-têtes, cookies) fonctionne à l’identique des deux côtés. Ce que TLS ajoute se limite à trois garanties, apportées avant même que la première requête HTTP ne parte :
1. Confidentialité : le contenu de l'échange est chiffré, illisible en transit
2. Intégrité : toute modification du trafic en transit devient détectable
3. Authentification : un certificat garantit que le serveur est bien celui qu'il prétend êtreCe que ça change concrètement
Sans HTTPS, n’importe quel intermédiaire technique sur le trajet (un réseau Wi-Fi public non fiable, par exemple) peut lire ou modifier une requête en clair, y compris un mot de passe envoyé en POST. Avec HTTPS, ce même intermédiaire ne voit qu’un flux chiffré illisible.
Info
L’authentification du serveur, via son certificat, répond à une question précise : « est-ce que je parle bien à cybercursus.fr, ou à un serveur qui usurpe son adresse ? » Elle ne dit rien de la fiabilité du contenu que ce serveur choisit d’envoyer.
Ce que HTTPS ne protège pas
C’est le point le plus souvent mal compris, et la raison pour laquelle ce chapitre clôt ce cours : HTTPS sécurise le trajet d’une requête, pas ce que le serveur en fait une fois qu’elle est arrivée.
Une application qui construit ses requêtes SQL par concaténation, comme vu en détail dans le cours sur les injections SQL, reste exactement aussi vulnérable derrière HTTPS que derrière HTTP. Le chiffrement protège la conversation ; il ne corrige rien dans la façon dont le serveur traite ce qu’il reçoit.