HTTP/HTTPS : définition, protocoles de transfert de données et chiffrement TLS

Que sont HTTP et HTTPS ?

HTTP (HyperText Transfer Protocol) est un protocole de couche application du modèle OSI conçu pour transférer des documents hypertexte et d'autres données sur le World Wide Web. Développé par Tim Berners-Lee en 1989, HTTP a connu plusieurs versions : de HTTP/0.9 (uniquement des requêtes GET et des réponses HTML) aux modernes HTTP/2 et HTTP/3. Le protocole fonctionne selon le modèle requête-réponse : le client envoie une requête au serveur, le serveur la traite et renvoie une réponse.

HTTPS (HTTP Secure) est une extension du protocole HTTP qui ajoute une couche de chiffrement via TLS (Transport Layer Security). HTTPS n'est pas un protocole séparé — c'est une combinaison de HTTP et TLS. Les données transmises via HTTPS sont chiffrées côté client et déchiffrées sur le serveur, les rendant inaccessibles à l'interception et à la falsification. HTTPS assure également l'authentification du serveur via des certificats SSL/TLS, garantissant que le client se connecte au vrai serveur et non à un attaquant.

La différence clé entre HTTP et HTTPS est la sécurité. HTTP transmet les données en texte clair : tout nœud réseau entre le client et le serveur peut lire le contenu d'une requête ou d'une réponse. HTTPS chiffre tout le contenu, y compris l'URL, les en-têtes et le corps de la requête, ne laissant visibles que l'adresse IP du serveur et le port de connexion. Pour les applications mobiles fonctionnant sur des réseaux Wi-Fi publics, HTTPS est une exigence de sécurité obligatoire.

Comment fonctionne HTTP

HTTP est un protocole sans état (stateless) fonctionnant sur TCP/IP. Le client établit une connexion TCP avec le serveur (généralement sur le port 80 pour HTTP ou 443 pour HTTPS), envoie une requête HTTP, reçoit une réponse HTTP et ferme la connexion (dans HTTP/1.1, la connexion peut être réutilisée). Chaque interaction entre le client et le serveur consiste en une requête et une réponse. L'absence d'état signifie que le serveur ne stocke pas d'informations sur les requêtes précédentes du client — chaque requête est traitée indépendamment.

Le processus d'interaction HTTP comprend les étapes suivantes :

• Résolution DNS — le navigateur ou le client résout le nom de domaine en adresse IP via DNS
• Handshake TCP — une connexion TCP est établie via une poignée de main à trois étapes (SYN, SYN-ACK, ACK)
• Handshake TLS — pour HTTPS, une connexion chiffrée est en plus établie (échange de certificats et de clés)
• Requête HTTP — le client envoie la méthode, l'URL, les en-têtes et optionnellement le corps de la requête
• Réponse HTTP — le serveur renvoie un code d'état, des en-têtes et le corps de la réponse

Une caractéristique importante de HTTP est l'idempotence des méthodes. GET, HEAD, PUT, DELETE et OPTIONS sont idempotents : l'exécution répétée de la même requête ne modifie pas l'état du serveur après la première exécution. POST, PATCH et CONNECT ne sont pas idempotents — chaque appel peut créer une nouvelle ressource ou modifier l'état. Pour le développement mobile, comprendre l'idempotence est crucial : lors de la renvoi d'une requête en raison d'une erreur réseau, le client doit savoir s'il est sûr de répéter la requête.

HTTPS et chiffrement TLS

HTTPS utilise le protocole cryptographique TLS (Transport Layer Security) pour protéger les données transmises. TLS est le successeur de SSL (Secure Sockets Layer), développé par Netscape en 1995. Les versions SSL 2.0 et 3.0 sont considérées comme obsolètes et non sécurisées ; les versions modernes TLS 1.2 (publiée en 2008) et TLS 1.3 (publiée en 2018) sont utilisées partout. TLS 1.3, en particulier, réduit le temps d'établissement de connexion de 2 allers-retours à 1, accélérant considérablement le chargement sur les appareils mobiles.

Le processus de handshake TLS comprend les étapes suivantes :

• Client Hello — le client envoie une liste des versions TLS et des suites de chiffrement prises en charge
• Server Hello — le serveur sélectionne la version TLS et la suite de chiffrement, envoie son certificat SSL/TLS
• Vérification du certificat — le client vérifie le certificat du serveur via une chaîne de confiance jusqu'à l'autorité de certification racine
• Échange de clés — le client et le serveur génèrent une clé secrète partagée (clé de session)
• Changement de chiffrement — les deux parties confirment le passage à la communication chiffrée

La vérification du certificat SSL/TLS est une étape critique pour la sécurité. Le client vérifie que le certificat : n'a pas expiré, est signé par une autorité de certification (CA) de confiance, correspond au domaine dans l'URL et n'a pas été révoqué (via CRL ou OCSP). Dans les applications mobiles, il est recommandé d'utiliser l'épinglege de certificat (Certificate Pinning) — la liaison à un certificat spécifique du serveur ou à une clé publique. Cela prévient les attaques MITM même en cas de compromission d'une CA. Cependant, l'épinglege nécessite de la prudence : lorsque le certificat change, l'application doit être mise à jour au préalable.

Structure d'une requête et réponse HTTP

Une requête HTTP se compose de trois parties : la ligne de requête, les en-têtes et un corps optionnel. La ligne de requête contient la méthode HTTP, l'URL de la requête et la version HTTP. Les en-têtes transmettent des méta-informations : type de contenu, jetons d'authentification, paramètres de cache. Le corps est présent uniquement dans les méthodes qui transmettent des données (POST, PUT, PATCH) et est absent dans GET et DELETE.

Exemple d'une requête HTTP vers une API REST :

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

Une réponse HTTP a une structure similaire : une ligne d'état avec la version HTTP et le code d'état, des en-têtes et un corps. Le code d'état est un nombre à trois chiffres qui détermine le résultat du traitement de la requête. Les en-têtes de réponse incluent Content-Type, Content-Length, Cache-Control, Set-Cookie et d'autres. Le corps de la réponse contient les données demandées dans le format spécifié dans Content-Type (généralement JSON pour les API, HTML pour les pages Web, images pour le contenu multimédia).

Les en-têtes jouent un rôle critique dans le fonctionnement de HTTP. Content-Type et Accept contrôlent le format des données. Authorization transmet les jetons d'accès. Cache-Control gère la mise en cache. Les en-têtes CORS (Access-Control-Allow-Origin) contrôlent l'accès depuis d'autres domaines dans les navigateurs. User-Agent identifie l'application cliente. Pour les applications mobiles, les en-têtes de contrôle de cache sont particulièrement importants — ils aident à réduire la quantité de données transmises et à améliorer les performances sur signal faible.

Codes d'état HTTP

Les codes d'état HTTP sont regroupés en cinq classes, indiquées par le premier chiffre : 1xx (information), 2xx (succès), 3xx (redirection), 4xx (erreur client), 5xx (erreur serveur). Comprendre ces codes est nécessaire pour traiter correctement les réponses dans une application mobile : 2xx signifie succès et les données peuvent être affichées, 4xx indique un problème dans la requête (afficher une erreur à l'utilisateur), 5xx indique un problème serveur (réessayer la requête plus tard).

Pour les applications mobiles, la gestion du code 401 Unauthorized est particulièrement importante. Lors de la réception de ce code, le client doit tenter de rafraîchir le jeton d'accès via un Refresh Token et réessayer la requête originale. Si le rafraîchissement du jeton renvoie également 401, l'utilisateur doit être redirigé vers l'écran de connexion. Cette logique est généralement implémentée dans un Interceptor (OkHttp) ou dans la couche middleware du client réseau.

HTTP/1.1, HTTP/2 et HTTP/3

HTTP/1.1, publié en 1999, est encore une version largement utilisée du protocole. Son principal inconvénient est le head-of-line blocking : les requêtes vers le même serveur sont exécutées séquentiellement, chacune attendant la fin de la précédente. Pour contourner cette limitation, les navigateurs ouvrent 6 à 8 connexions TCP parallèles vers le même domaine, augmentant la charge du serveur et la consommation mémoire. HTTP/1.1 transmet également les en-têtes en texte clair et ne prend pas en charge le server push.

HTTP/2 (2015) résout le problème de blocage grâce au multiplexage — plusieurs flux de données sont transmis simultanément sur une seule connexion TCP. Le serveur peut envoyer des ressources au client avant que celui-ci ne les demande (server push). HTTP/2 comprime également les en-têtes via HPACK, réduisant la quantité de données transmises. Pour les applications mobiles, HTTP/2 est particulièrement utile : une connexion en remplace plusieurs, réduisant le temps de handshake TLS et la consommation de batterie.

HTTP/3 (2022) est la dernière version du protocole, qui utilise QUIC (Quick UDP Internet Connections) au lieu de TCP. QUIC fonctionne sur UDP, éliminant le problème de head-of-line blocking au niveau du protocole de transport. HTTP/3 réduit le temps d'établissement de connexion à 0 aller-retour dans le meilleur des cas (sur les connexions répétées) et à 1 aller-retour lors de la première connexion, ce qui est nettement plus rapide que HTTP/2 avec ses 2 à 3 allers-retours. Pour les appareils mobiles, HTTP/3 est particulièrement efficace lors du changement entre Wi-Fi et réseaux mobiles — la connexion n'est pas interrompue car QUIC utilise un identifiant de connexion plutôt qu'une adresse IP.

HTTPS dans le développement mobile

L'utilisation de HTTPS dans les applications mobiles n'est pas une recommandation mais une exigence obligatoire. À partir d'Android 9 (API 28) et iOS 9 (ATS — App Transport Security), toutes les requêtes réseau doivent utiliser HTTPS par défaut. Les requêtes HTTP sont bloquées par le système, et les autoriser nécessite une exception explicite dans la configuration de l'application. Google Play Store et App Store rejettent les applications qui transmettent des données sensibles via HTTP, y compris les mots de passe, les jetons et les données personnelles.

La configuration HTTPS dans une application Android inclut :

<!-- AndroidManifest.xml — autorisation de requête réseau -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — configuration HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Sur iOS, une configuration similaire est effectuée via Info.plist avec la clé NSAppTransportSecurity. Pour déboguer le trafic HTTPS dans les applications mobiles, des outils proxy sont utilisés : Charles Proxy, Proxyman ou mitmproxy. Ils nécessitent l'installation d'un certificat SSL de confiance sur l'appareil. Dans les versions de production, les capacités de débogage doivent être désactivées et l'épinglege de certificat doit être vérifié comme correctement configuré. L'utilisation d'OkHttp sur Android avec son CertificatePinner ou TrustManager sur iOS avec SecTrustEvaluate sont des approches standard pour implémenter l'épinglege.

Un aspect important de la sécurité HTTPS dans le développement mobile est l'épinglege SSL (SSL Pinning). Sans épinglege, l'application fait confiance à tout certificat signé par une CA connue. Si la CA est compromise, un attaquant pourrait intercepter le trafic de l'application. L'épinglege lie l'application à un certificat serveur spécifique ou à une clé publique. Lorsque le certificat du serveur change, une mise à jour de l'application doit être publiée, donc l'épinglege est planifié avec une marge — liaison à un certificat CA supérieur ou utilisation de plusieurs clés de secours.