Contrat de sous-traitance RGPD pour agences web (art. 28)
Quand une agence web doit-elle signer un contrat de sous-traitance (RGPD, art. 28) ? Annexe sécurité, sous-traitants ultérieurs, incidents et fin de contrat.
Aussi en : English Deutsch Español Italiano Polski Português Türkçe
Si votre agence peut se connecter au tableau de bord WordPress d'un client, héberge le site ou conserve ses sauvegardes, vous traitez presque certainement des données personnelles pour le compte de ce client. Vous avez alors besoin d'un contrat de sous-traitance avec lui. La taille de l'équipe n'y change rien : une agence de cinq personnes et un freelance indépendant sont dans la même situation.
Cet article examine le contrat du point de vue de l'agence. Il précise lesquels des services que vous vendez font de vous un sous-traitant, ce que l'annexe de sécurité doit contenir, et comment gérer les points qui posent problème en pratique : sous-traitants ultérieurs, incidents et fin de contrat.
Quand une agence web a besoin d'un contrat de sous-traitance
Presque tous les sites WordPress d'entreprise contiennent des données personnelles. Exemples courants : les messages d'un formulaire de contact qu'un plugin enregistre en base de données, les commandes WooCommerce avec noms et adresses, les comptes clients, les inscriptions à la newsletter. Si un accès administrateur, un accès à l'hébergement, une connexion à la base de données ou un fichier de sauvegarde vous donne accès à ces données, vous pouvez les traiter.
Au sens du RGPD, le client est le responsable de traitement : il décide pourquoi et comment les données sont traitées. Vous êtes le sous-traitant lorsque vous manipulez ces données sur ses instructions, par exemple en tenant son site à jour ou en gérant son hébergement. L'art. 28 impose un contrat entre vous deux : le contrat de sous-traitance (DPA, pour data processing agreement). Il fixe ce que vous avez le droit de faire des données et comment vous les protégez.
Quels services d'agence relèvent en général d'un traitement
Ce qui compte, c'est que vous puissiez accéder aux données, pas que vous les consultiez réellement. Voici des cas typiques, pas des règles figées :
| Prestation | Statut habituel |
|---|---|
| Contrat de maintenance avec accès administrateur | Sous-traitant |
| Hébergement infogéré | Sous-traitant |
| Stockage externe de sauvegardes | Sous-traitant |
| Assistance à distance avec accès administrateur | Sous-traitant |
| Design sur environnement de test, sans données réelles | Souvent non |
| Audit ponctuel avec accès | À examiner au cas par cas |
Deux points sont souvent négligés. D'abord, un projet « design uniquement » cesse de l'être dès que vous copiez la base de production vers l'environnement de test pour essayer un thème : cette copie contient de vraies données clients. Ensuite, vos propres formulaires de contact, votre CRM et votre facturation ne relèvent pas d'un traitement pour un client. Pour ces données, c'est votre agence le responsable de traitement, avec sa propre information des personnes et ses propres mesures.
Pour commencer, dressez la liste de tous les sites clients et notez les accès que vous détenez sur chacun. Vous trouverez probablement des comptes dont personne ne se souvient de l'ouverture. Le guide de nettoyage des rôles utilisateurs explique comment les supprimer.
Le volet sécurité : décrire vos mesures techniques et organisationnelles
La plupart des contrats comportent une annexe sur les mesures techniques et organisationnelles (TOM). Les agences y recopient souvent une liste générique. Mieux vaut décrire ce que vous faites réellement, en termes simples :
- Connexions : authentification à deux facteurs sur chaque compte administrateur que vous utilisez sur les sites clients.
- Comptes nominatifs : un compte personnel par collaborateur, jamais un compte administrateur « agence » partagé. Vous savez ainsi qui a fait quoi, et vous pouvez retirer l'accès d'une personne sans toucher à celui du reste de l'équipe.
- Identifiants : conservés dans un gestionnaire de mots de passe d'équipe, avec des droits par client, pas dans des tableurs ni des fils de discussion.
- Moindre privilège : un rôle Éditeur ou un rôle personnalisé là où l'accès administrateur complet n'est pas nécessaire.
- Sauvegardes : où elles sont stockées, si elles sont chiffrées, et quelles personnes nommément désignées peuvent les restaurer ou les télécharger.
- Mises à jour : à quelle fréquence vous appliquez celles du cœur, des plugins et des thèmes, et avec quelle rapidité vous traitez les correctifs de sécurité critiques.
- Journalisation : quelles activités vous enregistrez et combien de temps vous conservez ces traces.
- Personnel : obligations de confidentialité pour les salariés et les freelances, et procédure écrite de départ lorsqu'une personne quitte l'équipe.
L'annexe doit correspondre à la réalité. Si elle promet une supervision 24 h/24 et 7 j/7 ou des tests d'intrusion trimestriels que vous ne réalisez pas, vous fournissez une preuve écrite contre vous-même le jour où quelque chose tourne mal. Restez bref et exact, et mettez le document à jour quand votre organisation change.
Ces mesures s'alignent sur l'art. 32, par. 1, points a) à d) : pseudonymisation et chiffrement ; confidentialité, intégrité, disponibilité et résilience permanentes ; rétablissement rapide après un incident ; tests réguliers des mesures. Le guide sur l'article 32 du RGPD détaille chaque point.
Sous-traitants ultérieurs : hébergement, stockage des sauvegardes et outils
Les données d'un client restent rarement chez vous seul. Elles transitent en général par d'autres services :
- l'hébergeur ou la plateforme serveur que vous revendez ou gérez
- le stockage des sauvegardes, par exemple un bucket de type S3 ou le cloud propre à un plugin de sauvegarde
- les services de disponibilité ou de supervision qui détiennent des identifiants ou peuvent voir le contenu du site
- les environnements de test sur une plateforme distincte
- les outils d'assistance et de tickets où les clients collent des détails de commandes ou des e-mails de clients
Chacun de ces prestataires est un sous-traitant ultérieur. Tenez par écrit, pour chaque client, la liste des prestataires que vous utilisez pour lui et des lieux où ils stockent les données. Prévenez le client avant d'ajouter ou de changer un prestataire, et veillez à avoir votre propre contrat de sous-traitance avec chacun d'eux. Si un prestataire stocke des données hors de l'UE ou y accède depuis un pays tiers, vérifiez la base juridique du transfert avant de vous y fier, et indiquez-le sur la liste. Le client ne devrait jamais apprendre, à la lecture d'un rapport de violation, que ses sauvegardes se trouvaient chez un service dont il ignorait tout.
Signaler un incident : comment et quand prévenir le client
Le client, en tant que responsable de traitement, doit notifier l'autorité de contrôle (en France, la CNIL) dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, lorsqu'une violation de données à caractère personnel survient (art. 33). Il doit aussi documenter toute violation, y compris celles qu'il ne notifie pas (art. 33, par. 5). Il ne peut le faire que si vous le prévenez vite et lui donnez des éléments exploitables.
Convenez des points suivants dans le contrat ou dans une annexe opérationnelle :
- Un délai interne qui laisse au client une marge confortable. Par exemple : signaler une violation suspectée dans les 24 heures suivant sa découverte, même si l'enquête n'est pas terminée.
- Un interlocuteur désigné de chaque côté, avec un suppléant.
- Un canal d'alerte qui fonctionne hors des heures de bureau. L'e-mail seul est un choix fragile.
- Les informations minimales à transmettre : ce qui s'est passé, quand vous l'avez constaté, quels systèmes et quelles données sont concernés, et ce que vous avez déjà fait.
Les démarches du client après votre signalement, notamment l'évaluation et le contenu de la notification, sont décrites dans le guide de la notification en 72 heures.
Fin de contrat : retrait des accès, restitution et suppression des données
Les accès d'agence qui ne sont jamais supprimés sont une porte d'entrée classique vers d'anciens sites clients. C'est aussi un risque pour vous : si l'un de ces comptes est détourné, le client demandera pourquoi il existait encore. Utilisez cette liste à la fin d'un contrat :
- Supprimer tous les comptes administrateurs de l'agence, après avoir réattribué leurs contenus à un compte du client
- Révoquer les mots de passe d'application créés pour vos outils
- Retirer vos clés SFTP/SSH et vos accès au panneau de contrôle de l'hébergement
- Remettre ou supprimer les sauvegardes que vous détenez, selon les instructions du client
- Supprimer les copies locales de la base de données, les exports et les sites de test
- Retirer les entrées du client de votre gestionnaire de mots de passe et de vos outils de supervision
- Confirmer par écrit au client que ces étapes sont terminées
Sur les sites où vous disposez de WP-CLI, cette commande liste les administrateurs restants avant la remise :
wp user list --role=administrator --fields=ID,user_login,user_email
Garder le contrat fidèle à la réalité : preuves et questions NIS 2 des clients
Selon l'art. 5, par. 2, le responsable de traitement doit pouvoir démontrer sa conformité. En pratique, le client vous demandera de prouver que votre annexe reflète ce que vous faites vraiment. Parmi les preuves utiles : l'état de l'authentification à deux facteurs sur les comptes de vos collaborateurs, des revues d'accès datées, des tests de restauration de sauvegardes et des rapports d'audit de sécurité récents. Le guide sur la documentation d'audit explique quoi conserver.
Les clients soumis à la directive NIS 2 doivent gérer la sécurité de leurs fournisseurs (art. 21, par. 2, point d)). Ils vous enverront des questionnaires même si la directive ne vous vise pas directement. Une agence de taille moyenne, c'est-à-dire de 50 salariés ou plus, ou de plus de 10 millions d'euros de chiffre d'affaires annuel et de total de bilan, qui gère les systèmes de ses clients peut elle-même entrer dans le champ en tant que fournisseur de services gérés. Consultez la loi nationale de transposition de votre pays ; le guide sur le champ d'application de NIS 2 détaille la vérification.
Le plugin secaudit.eu exporte un rapport d'audit rattaché à l'art. 32 du RGPD et à l'art. 21 de NIS 2, ainsi qu'un brouillon de notification d'incident. Les deux peuvent étayer ces preuves. Aucun des deux ne rend votre agence ni votre client conformes.
Les violations des articles 25 à 39 du RGPD, dont les art. 28 et 32, peuvent entraîner des amendes pouvant aller jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial (art. 83, par. 4, point a)). Pour la plupart des agences, le risque le plus immédiat est pourtant de perdre un client après un incident parce que le contrat ne reflétait pas la réalité.
Prochaine étape : dressez la liste de tous les sites clients auxquels vous avez accès. Pour chacun, notez s'il existe un contrat de sous-traitance en vigueur et si son annexe TOM décrit ce que vous faites aujourd'hui. Corrigez en premier les sites où l'une des deux réponses est « non ».
FAQ
Je travaille seul, en freelance. Ai-je quand même besoin d'un contrat de sous-traitance ?
Oui, si vous traitez des données personnelles pour le client. Le RGPD n'exempte pas les sous-traitants en fonction de leur taille.
Qui rédige le contrat : le client ou l'agence ?
L'un ou l'autre. Beaucoup d'agences proposent un contrat type avec leurs offres de maintenance, ce qui fait gagner du temps avec de nombreux clients. Faites-le relire une fois par un juriste et adaptez l'annexe TOM à chaque prestation.
Le contrat de mon hébergeur ne couvre-t-il pas déjà cela ?
Non. Ce contrat encadre votre relation avec l'hébergeur. Votre relation avec le client exige son propre contrat.
Cet article est une information générale et ne constitue pas un avis juridique.
Vérifiez votre propre site
Security Audit & Compliance est l’extension WordPress de secaudit.eu : elle recherche les logiciels malveillants, le spam caché, les fichiers du cœur modifiés et le code vulnérable, et rattache ses constats à l’article 32 du RGPD, à l’article 21 de NIS2 et à l’OWASP Top 10.
Voir ce que vérifie l’extension