Un hébergement RGPD repose sur un contrat signé avec l'hébergeur, qui traite les données du site pour le compte de l'éditeur : localisation des serveurs, mesures de sécurité, sort des données en fin de contrat et alerte en cas d'incident. Le responsable du traitement reste l'éditeur, et les personnes dont il conserve les données gardent leurs droits.
- Le rôle de chacun
- L'éditeur du site décide des finalités, l'hébergeur exécute ses instructions comme sous-traitant (article 28 du RGPD).
- La localisation des données
- Aucune obligation de stockage en France, mais tout transfert vers un pays tiers exige une base juridique.
- La sécurité
- L'obligation de sécurité pèse sur les deux parties ; une violation se notifie à la CNIL sous 72 heures.
Qui fait quoi : responsable de traitement et hébergeur sous-traitant
Le RGPD, règlement (UE) 2016/679 appliqué depuis le 25 mai 2018, répartit les obligations entre deux acteurs. Le responsable de traitement est la personne physique ou morale qui détermine pourquoi et comment des données personnelles sont traitées : pour un site internet, c'est l'entreprise, l'association ou le particulier qui l'édite. Le sous-traitant traite ces données pour son compte et sur ses instructions : l'hébergeur qui conserve la base de données, les fichiers envoyés par les visiteurs et les journaux du serveur entre dans cette catégorie.
Le texte définit les données à caractère personnel de façon large : toute information se rapportant à une personne identifiée ou identifiable, directement ou indirectement. Une adresse électronique, un nom dans un formulaire de contact, une adresse IP dans les journaux d'accès, un historique de commandes ou un cookie de mesure d'audience entrent dans ce périmètre. Un site vitrine sans formulaire traite donc déjà des données, ne serait-ce que dans les logs de son serveur web.
Le choix du prestataire n'est pas libre au sens du RGPD : l'article 28 impose au responsable de ne recourir qu'à des sous-traitants qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées. L'éditeur doit pouvoir démontrer qu'il a vérifié ces garanties avant de confier ses données, ce que la CNIL appelle le principe de responsabilité (« accountability »). Garder une trace écrite de cette vérification, même brève, fait partie de la conformité.
La qualification n'est pas figée. Un hébergeur qui réutilise les données de ses clients pour ses propres fins, par exemple pour entraîner un outil d'analyse ou pour sa prospection commerciale, devient responsable de traitement pour cette partie de l'activité, avec toutes les obligations qui l'accompagnent. Pour l'infrastructure qu'il fournit, il reste en revanche tenu de suivre les instructions documentées de l'éditeur et de ne rien faire d'autre avec les informations stockées.
Le contrat de l'article 28 : les clauses à lire dans le DPA de l'hébergeur
Le contrat de sous-traitance prévu par l'article 28 du RGPD est la pièce centrale d'un hébergement conforme. La plupart des hébergeurs le publient sous le nom d'accord de traitement des données, ou DPA (Data Processing Agreement), en annexe de leurs conditions générales. L'éditeur l'accepte en souscrivant l'offre, sans toujours l'avoir lu : c'est pourtant ce document qui fixe ce que le prestataire peut faire des données.
L'article 28 énumère le contenu minimal de ce contrat. Le DPA doit préciser l'objet, la durée, la nature et la finalité du traitement, le type de données et les catégories de personnes concernées. Il doit aussi engager l'hébergeur sur plusieurs obligations :
- ne traiter les données que sur instruction documentée du client, y compris pour un transfert hors de l'Espace économique européen ;
- soumettre son personnel à une obligation de confidentialité ;
- appliquer les mesures de sécurité exigées par l'article 32 ;
- ne recourir à un autre sous-traitant qu'avec l'autorisation préalable du client et lui imposer les mêmes obligations ;
- aider le client à répondre aux demandes d'exercice des droits et à remplir ses obligations de sécurité, de notification et d'analyse d'impact ;
- supprimer ou restituer les données au terme de la prestation ;
- mettre à disposition les informations nécessaires pour démontrer sa conformité et permettre des audits.
Deux clauses méritent une lecture attentive. La première concerne la liste des sous-traitants ultérieurs : un hébergeur confie souvent une partie du service à d'autres sociétés (centre de données, support technique, envoi d'e-mails, stockage des sauvegardes). Le DPA doit renvoyer à cette liste et prévoir l'information du client avant tout changement, avec la possibilité de s'y opposer. La seconde porte sur les audits : certains contrats remplacent le droit d'audit par la communication de certifications comme ISO/IEC 27001, ce qui reste admissible si le client peut obtenir les rapports.
Un contrat qui ne mentionne ni la localisation des données ni la liste des prestataires secondaires ne permet pas au responsable de vérifier où partent les informations de ses clients. Dans ce cas, une demande écrite au service commercial de l'hébergeur, conservée avec le contrat, documente au moins la réponse obtenue.
Hébergement en France, dans l'UE ou hors d'Europe : ce que le RGPD autorise
Le RGPD n'impose pas de stocker les données en France ni même dans l'UE. Il encadre en revanche strictement leur transfert vers un pays tiers, c'est-à-dire hors de l'Espace économique européen (les États membres plus l'Islande, le Liechtenstein et la Norvège). Les articles 44 à 49 exigent une base juridique pour chaque transfert, comme le rappelle la CNIL dans sa page sur les transferts hors UE. Un accès à distance depuis un pays tiers, par exemple par l'équipe de support d'un hébergeur, compte aussi comme un transfert.
| Lieu de stockage ou d'accès | Base juridique du transfert | Travail du responsable |
|---|---|---|
| France ou autre pays de l'EEE | Aucune : la donnée ne quitte pas l'espace du RGPD | Vérifier que sauvegardes et support restent aussi dans l'EEE |
| Pays tiers reconnu adéquat (Suisse, Royaume-Uni, Japon...) | Décision d'adéquation de la Commission européenne (article 45) | Suivre la validité de la décision |
| Société américaine certifiée au Data Privacy Framework | Décision d'adéquation du 10 juillet 2023 | Contrôler la certification de la société sur la liste officielle |
| Autre pays tiers | Clauses contractuelles types (article 46) ou autre garantie appropriée | Évaluer le droit local et ajouter des mesures comme le chiffrement |
Le cas le plus courant pour un petit site reste le plus simple : un centre de données situé en France ou dans l'EEE, chez un prestataire européen, avec des sauvegardes et une assistance technique qui ne sortent pas de cet espace. Chez les grands fournisseurs d'hébergement cloud, la région se choisit à la création de chaque ressource ; la noter dans la documentation du site évite de la découvrir lors d'un contrôle.
Cloud Act et prestataires américains
Le Cloud Act, loi américaine de 2018, permet aux autorités des États-Unis d'exiger d'un fournisseur soumis à leur juridiction les données qu'il contrôle, même stockées dans un centre de données européen. Choisir la région « Europe » d'un prestataire américain règle donc la localisation physique, pas l'exposition juridique. La Cour de justice de l'UE a invalidé le Privacy Shield le 16 juillet 2020 (arrêt Schrems II) pour cette raison d'accès des services de renseignement ; le Data Privacy Framework l'a remplacé en 2023, et le Tribunal de l'UE a rejeté en septembre 2025 un recours qui le contestait. Ce cadre reste valable aujourd'hui, mais il dépend d'engagements américains qui peuvent évoluer.
Cloud souverain et qualification SecNumCloud
Le cloud souverain désigne une offre opérée par une entreprise soumise au seul droit européen, sans actionnaire ni maison mère capable de l'obliger à répondre à une loi extra-européenne. La qualification SecNumCloud de l'ANSSI en donne la version la plus exigeante : depuis la version 3.2 de son référentiel, elle ajoute aux critères de sécurité informatique des exigences de protection contre les lois extraterritoriales. Peu de sites d'entreprise en ont besoin, mais une administration, un opérateur d'importance vitale ou un éditeur qui traite des informations sensibles s'y réfèrent de plus en plus.
Hébergeur RGPD : DPA, sauvegardes et prestataire américain en trois réponses
Les demandes adressées aux hébergeurs par les éditeurs de sites tournent souvent autour des mêmes trois cas, qui touchent au contrat, aux copies de sécurité et au droit américain.
Faut-il signer un contrat distinct avec son hébergeur ?
Un contrat distinct n'est pas nécessaire si le DPA de l'hébergeur, annexé à ses conditions générales, reprend les clauses de l'article 28. Accepter ces conditions lors de la commande vaut signature. L'éditeur doit en revanche conserver une copie datée du document, car le prestataire peut le modifier ensuite.
Les sauvegardes du site relèvent-elles du RGPD ?
Les sauvegardes relèvent du RGPD au même titre que le site, puisqu'elles contiennent les mêmes données. Leur durée de conservation doit rester limitée, leur stockage protégé, et le contrat doit dire où l'hébergeur les place, y compris quand il confie ce stockage à un autre prestataire.
Un hébergeur américain est-il interdit par le RGPD ?
Aucun article du RGPD n'interdit un hébergeur américain. Le transfert doit s'appuyer sur une base juridique valable, aujourd'hui le Data Privacy Framework pour les sociétés certifiées, ou des clauses contractuelles types accompagnées d'une évaluation des risques liés au Cloud Act.
Quelles mesures de sécurité exiger de l'hébergeur et appliquer soi-même ?
La sécurité des données hébergées est une obligation partagée : l'article 32 du RGPD l'impose au responsable du traitement comme au sous-traitant, chacun pour ce qu'il maîtrise. Les mesures doivent être adaptées au risque, compte tenu de l'état des connaissances, du coût de mise en œuvre et de la nature des informations traitées. Le texte cite la pseudonymisation, le chiffrement, la capacité à garantir la confidentialité, l'intégrité et la disponibilité des systèmes, la restauration rapide après un incident et le test régulier des mesures prises.
Côté hébergeur, la sécurité couvre la protection physique des salles (accès contrôlé, alimentation secourue, détection d'incendie), l'isolation entre clients sur un même serveur, l'application des correctifs du système, la surveillance du réseau et la journalisation des accès d'administration. Une certification ISO/IEC 27001 du centre de données ou du service acheté donne une indication sérieuse, à condition que son périmètre couvre bien l'offre souscrite et pas seulement le siège de la société.
Côté éditeur, la sécurité porte sur le site lui-même :
- mises à jour du CMS, du thème et des extensions dès leur publication ;
- comptes d'administration nominatifs, limités en nombre, protégés par des mots de passe robustes et une double authentification ;
- chiffrement des échanges par un certificat SSL sur toutes les pages, formulaires compris ;
- suppression des comptes et des données dont le site n'a plus l'usage ;
- protocole chiffré pour l'envoi des fichiers sur le serveur, jamais de FTP en clair.
La CNIL détaille ces recommandations dans ses pages consacrées à la sécurité des données, avec un guide destiné aux petites structures. Les sauvegardes du site font partie des mesures attendues : elles permettent la restauration exigée par l'article 32, mais elles contiennent les mêmes données que la base en ligne et doivent être chiffrées, stockées hors du serveur principal et conservées pour une durée définie.
Un réseau de diffusion de contenu ajoute un maillon à cette chaîne. Un CDN placé devant le site copie les pages et les fichiers dans des points de présence répartis dans le monde et voit passer l'adresse IP de chaque visiteur : son fournisseur devient un sous-traitant de plus, à inscrire au registre et à couvrir par un DPA.
Données de santé : la certification HDS en plus du RGPD
Un site qui conserve des données de santé à caractère personnel, comme un service de prise de rendez-vous médicaux, un portail de suivi de patients ou une plateforme de téléconsultation, ne peut pas choisir n'importe quel hébergeur. En France, l'article L.1111-8 du code de la santé publique impose de confier ces données à un hébergeur certifié HDS (hébergeur de données de santé). La certification, délivrée par un organisme accrédité et présentée par l'Agence du numérique en santé sur esante.gouv.fr, a remplacé en 2018 l'ancien agrément ministériel.
Le référentiel HDS, révisé en 2024, renforce les exigences de sécurité et impose que les données de santé restent hébergées dans l'Espace économique européen, avec une information du client sur les risques d'accès par des autorités de pays tiers. La certification distingue deux niveaux : l'hébergeur d'infrastructure physique (locaux, matériel, réseau) et l'hébergeur infogéreur (systèmes, sauvegardes, exploitation). L'éditeur doit vérifier que le certificat couvre précisément l'activité achetée, et pas seulement une autre offre du même prestataire.
Les données de santé appartiennent aux catégories particulières de l'article 9 du RGPD, dont le traitement est interdit sauf exceptions. La certification HDS ne remplace donc pas les autres obligations : base légale, information des patients, registre, analyse d'impact quand le traitement présente un risque élevé pour les droits des personnes. Un professionnel de santé libéral qui ajoute un formulaire de pré-consultation à son site entre dans ce cadre, même pour quelques dizaines de patients.
Un projet qui traite des données de santé, ou qui prévoit un transfert vers un pays tiers sans décision d'adéquation, justifie l'avis d'un délégué à la protection des données ou d'un avocat en droit du numérique avant le choix de l'architecture : corriger un contrat ou déplacer une base après la mise en ligne coûte bien plus que de le prévoir.
Quels risques pour un site hébergé sans garanties suffisantes ?
Le premier risque d'un hébergement non conforme au RGPD est la violation de données : intrusion dans la base, sauvegarde exposée sur internet, disque perdu, erreur de configuration qui rend un répertoire public. L'article 33 impose au responsable de notifier la violation à la CNIL dans les 72 heures après en avoir pris connaissance, sauf si elle ne présente pas de risque pour les droits des personnes. Si le risque est élevé, l'article 34 impose aussi de prévenir les personnes concernées. Le sous-traitant, de son côté, doit avertir le responsable dans les meilleurs délais.
Cette chaîne d'alerte ne fonctionne que si le contrat la prévoit : un hébergeur qui découvre une faille sur un serveur partagé doit savoir qui contacter chez chaque client, et l'éditeur doit savoir quelles informations il recevra pour remplir sa notification. Tenir un registre interne des violations, y compris celles qui ne justifient pas de notification, démontre que chaque incident a fait l'objet d'une évaluation.
Le deuxième risque est la sanction. L'article 83 prévoit des amendes administratives jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial pour un manquement aux obligations de sécurité ou de sous-traitance, et jusqu'à 20 millions d'euros ou 4 % pour une atteinte aux principes, aux droits des personnes ou aux règles de transfert. La CNIL prononce aussi des mises en demeure et des sanctions publiques qui pèsent sur la confiance des clients. L'hébergeur n'est pas à l'abri : il engage sa propre responsabilité s'il agit hors des instructions reçues ou manque à ses obligations de sous-traitant.
Le troisième risque est civil. L'article 82 ouvre aux personnes un droit à réparation du dommage matériel ou moral subi, contre le responsable ou contre le sous-traitant fautif. Pour une entreprise, ce risque s'ajoute à la perte d'activité pendant l'indisponibilité du site et au coût de la remise en état technique.
Droits des personnes, registre et analyse d'impact : ce que l'hébergement doit permettre
Les droits des personnes s'exercent auprès de l'éditeur, mais leur mise en œuvre dépend souvent des outils de l'hébergeur. Une demande d'accès, de rectification ou d'effacement doit recevoir une réponse dans un délai d'un mois, prolongeable de deux mois pour une demande complexe. Effacer un client de la base en ligne ne suffit pas toujours : l'information figure aussi dans les sauvegardes, les journaux et parfois chez un prestataire d'envoi d'e-mails. Le DPA doit préciser comment l'hébergeur aide le responsable à traiter ces demandes.
Le registre des traitements
L'article 30 impose au responsable de tenir un registre des activités de traitement, et au sous-traitant de tenir le sien pour les traitements réalisés pour ses clients. Pour un site, le registre décrit chaque finalité (gestion des commandes, formulaire de contact, lettre d'information), les catégories de données, les durées de conservation, les destinataires et les éventuels transferts. L'hébergeur, le CDN et l'outil d'e-mailing y figurent comme destinataires, avec leur localisation. La CNIL propose un modèle de registre simplifié pour les petites structures.
L'analyse d'impact
L'analyse d'impact relative à la protection des données (AIPD), prévue par l'article 35, devient obligatoire quand un traitement présente un risque élevé : données de santé à grande échelle, surveillance systématique, croisement de fichiers. La CNIL publie la liste des traitements pour lesquels elle l'exige. L'analyse évalue notamment les mesures de sécurité de l'hébergement et le niveau de risque des transferts ; elle se prépare avant le lancement du service, pas après.
Changer d'hébergeur sans perdre la trace des données
La fin d'un contrat d'hébergement est un moment que peu d'éditeurs anticipent, alors que le RGPD l'encadre : l'article 28 impose au sous-traitant de supprimer ou de restituer toutes les données au terme de la prestation, au choix du responsable, et d'en détruire les copies existantes sauf obligation légale de conservation. Lors d'une migration, l'éditeur doit donc obtenir deux choses de l'ancien prestataire : un export complet et lisible de la base et des fichiers, puis une confirmation écrite de leur suppression, sauvegardes comprises.
Le nouveau contrat se vérifie avec la même grille que le premier : DPA conforme à l'article 28, localisation des serveurs et des sauvegardes, liste des prestataires secondaires, mesures de sécurité, procédure d'alerte en cas d'incident. La migration elle-même transporte des données : le transfert doit passer par une connexion chiffrée (SFTP, SSH), et les copies temporaires faites sur un poste de travail ou un espace de stockage partagé doivent disparaître une fois le site en ligne chez le nouveau prestataire.
Le registre des traitements se met à jour à cette occasion, avec le nom du nouvel hébergeur, sa localisation et la date du changement. Garder l'attestation de suppression de l'ancien prestataire avec le contrat clos permet de répondre à une question de la CNIL ou d'un client des années plus tard. Une entreprise qui change de solution tous les trois ou quatre ans accumule ainsi un dossier complet, qui documente pour chaque période où se trouvaient les données et sous quelles garanties.




