Enjeux et pratique
Le DPA est obligatoire dès qu’un prestataire traite des données personnelles pour le compte de l’entreprise : hébergeur, éditeur SaaS, agence marketing, paie externalisée, support client. Son contenu imposé couvre l’objet et la durée du traitement, sa nature et sa finalité, les types de données et catégories de personnes, et les obligations du sous-traitant : traiter sur instructions documentées, garantir la confidentialité des personnels, assurer la sécurité, encadrer la sous-traitance ultérieure (autorisation préalable, répercussion des obligations), assister le responsable (droits des personnes, violations, analyses d’impact), supprimer ou restituer les données en fin de contrat, et se soumettre aux audits.
Trois pièges récurrents méritent l’attention. Le DPA standard de l’éditeur : la plupart des prestataires imposent leur propre DPA, souvent équilibré à leur avantage (sous-traitants ultérieurs autorisés en bloc avec simple information, plafonds de responsabilité du contrat principal étendus aux manquements données, audits réduits à la fourniture de certifications) ; ces points se négocient selon le rapport de force, mais doivent au moins être identifiés et acceptés en connaissance. La dérive du périmètre : le traitement réel évolue (nouvelles fonctionnalités, nouveaux sous-traitants, IA ajoutée par mise à jour) sans que le DPA suive ; un DPA exact à la signature devient faux silencieusement. L’articulation avec le contrat principal : hiérarchie entre les deux documents, cohérence des responsabilités et des durées, sort du DPA en cas de cession du contrat.
Un point mérite une attention particulière : les transferts hors Union européenne. Dès qu’un sous-traitant, ou l’un de ses propres sous-traitants, héberge ou consulte les données depuis un pays tiers, le DPA doit s’accompagner d’un mécanisme d’encadrement (clauses contractuelles types, décision d’adéquation) et, souvent, d’une analyse d’impact des transferts. Une chaîne de sous-traitance mal cartographiée fait facilement sortir des données du territoire prévu sans que le responsable en ait conscience.
À l’échelle du portefeuille, le DPA est un objet de gestion comme un autre : savoir quels contrats en ont un, en quelle version, avec quels sous-traitants ultérieurs déclarés, et lesquels n’en ont pas alors qu’ils le devraient. C’est la requête que tout contrôle CNIL déclenche.
Points de vigilance
Tenir ses DPA à jour relève autant de l’organisation que du droit. Quelques réflexes limitent l’exposition.
Recensez les traitements avant de rédiger les clauses. On ne peut sécuriser que ce que l’on a cartographié : lister les prestataires qui traitent des données personnelles, en distinguant ceux qui ont un DPA, ceux dont la version est périmée et ceux qui n’en ont aucun, est le point de départ.
Surveillez la liste des sous-traitants ultérieurs. C’est le maillon qui bouge le plus : un éditeur ajoute un service tiers, change d’hébergeur, intègre une nouvelle brique. Exiger une information préalable et un droit d’opposition, puis suivre ces évolutions, évite la dérive silencieuse.
Vérifiez la localisation des données et des accès. Un DPA conforme sur le fond mais muet sur les transferts hors UE laisse un risque ouvert. Rapprochez chaque DPA de la réalité de l’hébergement et du support.
Traitez le parc de DPA comme un état pilotable. Versions, dates, sous-traitants déclarés et clauses de transfert gagnent à être extraits en données depuis un référentiel central, afin de répondre à un contrôle sans reconstitution manuelle.
Exemple concret
Une entreprise recense ses DPA : sur 60 prestataires identifiés comme traitant des données personnelles, 38 ont un DPA signé, dont 11 dans des versions antérieures aux clauses types actuelles, et 22 n’en ont aucun, principalement des outils SaaS souscrits en ligne. Le plan de remédiation priorise par sensibilité des données : paie et RH d’abord, marketing ensuite. Six mois de travail pour un état que le référentiel aurait dû fournir en continu.
À ne pas confondre avec
Le DPA de l’article 28 encadre la relation entre un responsable de traitement et son sous-traitant. Il se distingue de l’accord entre responsables conjoints (article 26), qui répartit les rôles entre deux entités décidant ensemble des finalités. Il ne se confond pas non plus avec les clauses contractuelles types, qui encadrent spécifiquement les transferts internationaux et viennent compléter le DPA plutôt que le remplacer. Enfin, la politique de confidentialité informe les personnes concernées ; elle relève d’une obligation distincte de transparence, sans valeur de contrat entre professionnels.
Questions fréquentes
Le DPA doit-il être un document séparé du contrat principal ?
Non, la forme est libre : annexe du contrat principal, document autonome ou clauses intégrées, pourvu que le contenu de l’article 28 y soit et que l’articulation avec le reste du contrat soit claire (hiérarchie, responsabilité, durée). En pratique, l’annexe dédiée facilite la mise à jour et la production en cas de contrôle.
Le DPA est-il obligatoire même pour un petit prestataire SaaS ?
Oui, dès qu’un prestataire traite des données personnelles pour le compte de l’entreprise, un DPA conforme à l’article 28 est obligatoire, quelle que soit sa taille. Un outil SaaS souscrit en ligne sans DPA place le responsable de traitement en manquement, même si l’usage paraît anodin. C’est précisément ce type d’outils, souscrits hors circuit contractuel, qui manque le plus souvent à l’appel lors d’un recensement.
Qui est responsable en cas de violation de données chez le sous-traitant ?
La responsabilité est partagée mais reste d’abord celle du responsable de traitement vis-à-vis des personnes et de l’autorité. Le sous-traitant répond de ses propres manquements et des instructions qu’il n’a pas respectées, ce que le DPA précise. Un DPA bien rédigé organise la notification rapide des violations, la coopération et la répartition des charges, mais ne transfère pas au sous-traitant la responsabilité de principe du donneur d’ordre.
Sur le même thème
D'autres notions et pages du territoire proches de ce terme.