Hébergeur ou sous-traitant ? La double casquette qui vous expose

Beaucoup d'hébergeurs d'applications web raisonnent comme si leur métier se limitait à louer de la puissance machine : un serveur, une adresse IP, un SLA, et l'affaire serait dans le sac. Cette vision rassurante est juridiquement fausse. Dès l'instant où vous mettez à disposition une infrastructure qui stocke le site, l'application et surtout les données des utilisateurs finaux de votre client, vous entrez simultanément dans deux régimes de responsabilité qui n'ont ni le même fondement, ni le même juge, ni les mêmes sanctions.

Le premier régime est celui de la Loi pour la confiance dans l'économie numérique (LCEN) de 2004, qui définit l'hébergeur comme un intermédiaire technique. Le second est celui du RGPD, qui vous qualifie de sous-traitant de traitement dès lors que vous opérez des données personnelles pour le compte d'autrui. La plupart des hébergeurs ignorent qu'ils relèvent des deux à la fois, et c'est précisément cette double casquette qui crée les zones d'exposition les plus coûteuses.

L'article 6 de la LCEN organise une responsabilité atténuée de l'hébergeur sur les contenus qu'il stocke. Concrètement, vous n'êtes pas tenu de surveiller a priori les contenus de vos clients, et vous n'engagez votre responsabilité civile ou pénale que si, ayant eu connaissance d'un contenu manifestement illicite (signalé dans les formes), vous n'avez pas agi promptement pour le retirer ou en bloquer l'accès.

Cette protection est précieuse, mais elle est strictement conditionnelle. Elle suppose que vous restiez dans un rôle passif et neutre. Trois écueils la font sauter :

• Le rôle actif : si vous éditorialisez, sélectionnez ou organisez les contenus, vous glissez du statut d'hébergeur vers celui d'éditeur, qui répond de tout.
• L'inaction après signalement : un contenu illicite notifié et laissé en ligne engage votre responsabilité pleine.
• Les obligations de conservation : vous devez conserver les données d'identification de vos clients (créateurs de contenu) et être en mesure de les communiquer à l'autorité judiciaire.

Autrement dit, le statut LCEN vous protège contre les fautes de vos clients, pas contre les vôtres. Une panne d'infrastructure, une faute d'exploitation ou une fuite de données n'entrent absolument pas dans ce parapluie.

Là où la LCEN vous protège, le RGPD vous expose. Son article 28 fait de vous un sous-traitant de traitement dès que vous hébergez et opérez des données personnelles pour le compte d'un client (le responsable de traitement). Cette qualification emporte des obligations qui pèsent sur vous, et sur vous seul :

• Conclure un contrat de sous-traitance conforme (les fameuses clauses de l'article 28) avec chacun de vos clients.
• Mettre en œuvre des mesures de sécurité techniques et organisationnelles adaptées (chiffrement, cloisonnement, journalisation, sauvegardes testées).
• Notifier le responsable de traitement sans délai en cas de violation de données.
• Tenir un registre des activités de traitement et encadrer vos propres sous-traitants ultérieurs (cloud providers en cascade).

Point clé : depuis le RGPD, la CNIL peut sanctionner directement le sous-traitant, sans passer par le responsable de traitement. Un hébergeur dont l'infrastructure mal sécurisée a permis une fuite peut être condamné en son nom propre.

La nuance est lourde de conséquences : un client peut vous reprocher la fuite sur le terrain contractuel (votre RC Pro est alors en première ligne) tandis que la CNIL vous poursuit en parallèle sur le terrain administratif. Deux procédures, deux logiques, un seul sinistre.

Prenons un cas concret. Une faille dans un composant que vous administrez sur votre infrastructure mutualisée permet à un attaquant d'exfiltrer la base utilisateurs d'un site e-commerce hébergé. Trois fronts s'ouvrent simultanément :

1. Front LCEN ? Non. La fuite ne concerne pas un contenu illicite que vous auriez dû retirer : c'est une défaillance de votre propre sécurité d'exploitation. Le bouclier LCEN ne joue pas.
2. Front RGPD. En tant que sous-traitant, votre responsabilité est engagée pour défaut de sécurité (article 32). Frais de notification, instruction CNIL, sanction possible.
3. Front contractuel. Votre client invoque le manquement à votre obligation de sécurité et réclame réparation de son préjudice (perte de chiffre d'affaires, perte de clientèle, atteinte à l'image).

C'est cette superposition qui rend l'analyse de statut indispensable. Croire qu'on est « protégé par la LCEN » conduit à sous-assurer un risque qui, lui, relève intégralement du RGPD et du contrat. La combinaison RC Pro + garantie Cyber est précisément calibrée pour traiter ces fronts en parallèle : défense, frais de notification et indemnisation du client.

Une dimension échappe à la plupart des hébergeurs : la cascade de sous-traitance. Si vous opérez votre infrastructure non pas sur vos propres machines mais via un cloud provider (AWS, OVH, Scaleway, Azure), vous devenez sous-traitant de votre client tout en étant vous-même donneur d'ordre vis-à-vis du cloud provider, qui devient sous-traitant ultérieur.

L'article 28.2 du RGPD encadre strictement ce schéma : vous ne pouvez recruter un sous-traitant ultérieur qu'avec l'autorisation préalable (générale ou spécifique) de votre client, et vous restez pleinement responsable devant lui de l'exécution par ce sous-traitant de ses obligations. Autrement dit, si le datacenter de votre cloud provider connaît un incident, votre client ne se retourne pas contre AWS ou OVH : il se retourne contre vous, son cocontractant direct.

Trois réflexes s'imposent :

• Documenter la chaîne : tenir à jour la liste de vos sous-traitants ultérieurs et la communiquer à vos clients.
• Répercuter les obligations : vos contrats avec les cloud providers doivent reprendre, en cascade, les exigences de sécurité que vous devez à vos clients.
• Mesurer la responsabilité résiduelle : un recours contre le cloud provider est possible, mais il est souvent plafonné par ses propres CGU. La part non recouvrable reste à votre charge — et c'est elle que votre assurance doit absorber.

Cette mécanique de cascade est l'une des raisons pour lesquelles un hébergeur ne peut jamais se reposer sur la solidité de son fournisseur d'infrastructure : la responsabilité juridique remonte toujours jusqu'à lui.

La meilleure protection consiste à savoir, prestation par prestation, sous quel régime vous opérez. Posez-vous trois questions pour chaque client :

• Suis-je passif ou actif ? Si je touche au contenu (mise en page, modération, sélection), je perds le bouclier LCEN et je glisse vers la responsabilité d'éditeur.
• Est-ce que j'opère des données personnelles ? Si oui, je suis sous-traitant RGPD, point. Un contrat article 28 est obligatoire, ainsi que des mesures de sécurité documentées.
• Mes engagements contractuels dépassent-ils ma protection légale ? Un SLA ambitieux ou une clause de garantie de sécurité crée une responsabilité contractuelle que ni la LCEN ni le RGPD ne plafonnent.

Cette cartographie n'est pas un exercice théorique : elle détermine directement le périmètre que votre assurance doit couvrir. Un hébergeur qui pense être simple intermédiaire technique souscrit trop peu ; un hébergeur lucide sur sa double casquette dimensionne sa RC Pro et sa cyber en fonction du risque réel. La logique est simple : chaque régime de responsabilité que vous avez identifié doit trouver une réponse dans une garantie. La responsabilité contractuelle et la faute d'exploitation relèvent de la RC Pro ; le risque de violation de données et les frais de notification relèvent de la cyber. Aucun des deux ne doit rester à découvert. Pour aller plus loin sur les spécificités de votre activité, consultez notre page dédiée à l'assurance de l'hébergement d'application web.