| Entreprises - PME : Répondre aux marchés publics (DC1, DC2, ATTRI1, DC4, mémoire technique, ...) | Acheteurs publics | |||||
| DATES | J01 Fondamentaux | J02 Répondre aux AO | J03 Réponse électronique | J04 Mémoire technique | Formations | Assistance |
| Répondre | Formations "Répondre aux AO pour les entreprises" - INTER, INTRA, sur site ou FOAD (Fondamentaux, réponse, formulaires, dématérialisation, mémoire technique) |
HTTPS, pour Hypertext Transfer Protocol Secure, désigne l’utilisation de HTTP au moyen d’une connexion sécurisée.
HTTPS permet à un client, généralement un navigateur ou une application, d’échanger des données avec un serveur tout en protégeant la communication contre l’interception et la modification des informations transmises.
La sécurisation repose aujourd’hui sur TLS, pour Transport Layer Security.
Lorsqu’une ressource est identifiée par une adresse commençant par https://, le client doit établir une communication sécurisée avant d’échanger les données HTTP.
TLS assure notamment trois fonctions. Il protège la confidentialité des données, permet de vérifier leur intégrité pendant le transport et contribue à authentifier le serveur auquel le client se connecte.
Le serveur présente généralement un certificat électronique permettant au client de vérifier que le certificat correspond au nom du serveur et qu’il est rattaché à une chaîne de confiance reconnue.
Une adresse HTTPS peut prendre la forme suivante.
https://www.exemple.fr/repertoire/document.html
Le port par défaut associé au schéma HTTPS est le port 443. L’adresse n’a donc pas besoin d’indiquer explicitement ce numéro lorsque ce port est utilisé.
HTTPS peut aussi fonctionner dans des architectures utilisant d’autres mécanismes de transport, notamment avec HTTP/3 et QUIC. Le port 443 reste le port habituel associé au service HTTPS.
Une adresse commençant par http:// et une adresse commençant par https:// correspondent à des origines distinctes au sens du protocole HTTP.
Avec HTTPS, le client doit s’assurer que la communication est sécurisée avant d’envoyer la requête HTTP et ne doit accepter que des réponses provenant d’une communication sécurisée.
HTTPS protège le transport des informations entre le client et le serveur. Il ne garantit pas à lui seul la fiabilité du site, la sécurité de l’ensemble de l’application, l’absence de logiciel malveillant ou la conformité juridique du service utilisé.
Les anciennes documentations présentent parfois HTTPS comme « HTTP over SSL » ou « HTTP/SSL ». Cette terminologie est désormais obsolète.
SSL a précédé TLS. Les communications Web sécurisées actuelles reposent sur TLS.
La version actuelle de TLS 1.3 est définie par la RFC 9846 publiée en juillet 2026. Cette RFC remplace la RFC 8446 ainsi que plusieurs spécifications antérieures relatives à TLS 1.2.
Le certificat utilisé lors d’une connexion HTTPS permet notamment au client de vérifier l’identité technique du serveur auquel il se connecte.
Il contient des informations permettant de rattacher une clé cryptographique à un ou plusieurs noms de domaine. Le navigateur ou l’application vérifie notamment la validité du certificat et la chaîne de certification.
Le certificat utilisé pour sécuriser un site Web doit être distingué d’un certificat de signature électronique utilisé pour signer électroniquement un document ou un acte.
Les profils d’acheteur utilisent des moyens de communication électronique pour publier les documents de la consultation et recevoir les candidatures et les offres.
L’article R2132-9 du code de la commande publique impose à l’acheteur d’assurer la confidentialité et la sécurité des transactions sur un réseau informatique. Les communications, les échanges et le stockage doivent préserver l’intégrité des données et la confidentialité des candidatures, des offres et des demandes de participation.
L’arrêté du 22 mars 2019 relatif aux fonctionnalités et exigences minimales des profils d’acheteurs prévoit également des exigences de sécurité, d’interopérabilité, d’accessibilité, d’intégrité et de confidentialité.
L’utilisation de HTTPS participe à la sécurisation des transmissions entre l’utilisateur et le profil d’acheteur. Elle ne suffit pas à elle seule à répondre à l’ensemble des exigences prévues par le code de la commande publique et par l’arrêté du 22 mars 2019.
L’expression « protocole d’échange sécurisé » était utilisée dans les anciens textes relatifs à la dématérialisation des marchés publics pour désigner notamment les échanges protégés par des mécanismes de chiffrement.
L’arrêté du 28 août 2006 relatif à la dématérialisation des procédures de passation des marchés publics formalisés appartient désormais au cadre juridique historique. Il est abrogé depuis le 1er octobre 2012.
Voir également
protocole, HTTP, chiffrement, certificat électronique, certificat de signature électronique, dématérialisation, dématérialisation des marchés publics, plate-forme de dématérialisation, profil d'acheteur, signature électronique
Textes et références
Article R2132-9 du code de la commande publique .
Arrêté du 22 mars 2019 relatif aux fonctionnalités et exigences minimales des profils d’acheteurs .
RFC 9846 - The Transport Layer Security Protocol Version 1.3 .
(c) F. Makowski 2001/2023