Table des matières :
- Article 28 RGPD : ce que le contrat de sous-traitance encadre vraiment
- Clauses de cadrage : décrire le traitement pour qu’il soit contrôlable
- Instructions, confidentialité et séparation des rôles, avec des cas d’usage IA
- Mesures de sécurité et preuve : de l’annexe technique à l’auditabilité
- Sous-traitants ultérieurs et transferts internationaux : contrôler la chaîne sans illusion
- Assistance, incidents, droits des personnes : clauses qui réduisent le temps de crise
Article 28 RGPD : ce que le contrat de sous-traitance encadre vraiment
L’article 28 du RGPD (Règlement (UE) 2016/679) fixe les exigences minimales du contrat de sous-traitance, aussi appelé accord de traitement des données (Data Processing Agreement, DPA). Son objectif est opérationnel : rendre vérifiables les responsabilités et les moyens mis en place quand un prestataire traite des données personnelles pour votre compte. Pour une DSI, un RSSI ou des achats, c’est le texte qui transforme une promesse commerciale en obligations opposables — et qui permet de passer d’un discours marketing à des preuves (annexes, procédures, rapports, journaux, SLA).
Un responsable de traitement est l’organisation qui décide des finalités et des moyens du traitement. Un sous-traitant est l’organisation qui traite des données personnelles pour le compte du responsable, sur instruction. Cette qualification dépend des faits, pas des labels. Le contrat visé à l’article 28 ne “rend” pas un fournisseur conforme, il organise une relation de traitement, avec des garde-fous et des preuves. En pratique, c’est aussi un texte “pont” entre plusieurs obligations RGPD : registre (art. 30), sécurité (art. 32), notification des violations (art. 33/34), gestion des droits (art. 12 à 22), et documentation (art. 5(2), principe d’accountability).
Quatre notions sont souvent confondues et doivent être distinguées. L’hébergement est le lieu où sont stockées et traitées les données (centres de données, régions cloud). La juridiction applicable est le droit qui régit le contrat et les tribunaux compétents, distincte des lois susceptibles de s’appliquer au fournisseur. La maîtrise du modèle est la capacité à contrôler l’entraînement, le réglage fin et la réutilisation d’un modèle d’IA, notamment l’usage des données clients. La réversibilité est la capacité à sortir du service avec des données exploitables, dans des délais et à un coût maîtrisés.
Le RGPD est explicite sur l’exigence de formalisation : « Le traitement par un sous-traitant est régi par un contrat ou un autre acte juridique (…) qui lie le sous-traitant à l’égard du responsable du traitement » (RGPD, art. 28(3), JOUE L119 du 27/04/2016, version consolidée (EUR-Lex)). Le considérant 81 rappelle aussi le principe de sélection : « Le responsable du traitement ne devrait recourir qu’à des sous-traitants présentant des garanties suffisantes… » (RGPD, considérant 81, même source). Le contrat est donc un outil de preuve, autant qu’un outil d’exécution.
Une conséquence très concrète côté Europe/France : en cas de contrôle ou d’incident, les autorités (dont la CNIL en France) attendent généralement une traçabilité : DPA signé, annexes à jour, liste des sous-traitants ultérieurs, et capacité à démontrer “qui fait quoi, où, pendant combien de temps, avec quelles mesures”.
Clauses de cadrage : décrire le traitement pour qu’il soit contrôlable
La première faiblesse des DPA “standard” tient rarement aux grandes phrases, mais à l’imprécision des annexes. L’article 28 exige de documenter au minimum l’objet, la durée, la nature et la finalité du traitement, ainsi que les types de données personnelles et les catégories de personnes concernées. Sans ces éléments, vous ne pouvez ni contrôler la sous-traitance ultérieure, ni dimensionner la sécurité, ni piloter la réversibilité.
Concrètement, visez une annexe de traitement exploitable par des équipes. Elle doit préciser les fonctions utilisées (collecte, stockage, indexation, inférence IA, support), les environnements (prod, préprod, bac à sable), et les frontières techniques (API, connecteurs, exports). Ajoutez les contraintes structurantes : données sensibles au sens RGPD (catégories particulières, art. 9), données de mineurs, ou données à forte criticité métier même si elles ne sont pas “sensibles” juridiquement.
Pour rendre l’annexe actionnable, une structure simple (et facile à maintenir) consiste à documenter, pour chaque “brique” du service, les éléments suivants :
- Jeu de données (source / système amont), catégories de personnes, types de données
- Opérations (collecter, stocker, analyser, enrichir, déduire, exporter)
- Durées de conservation (par type : contenu, métadonnées, journaux)
- Localisation(s) (régions, options de résidence, sauvegardes)
- Accès (rôles, support, accès d’urgence, journaux)
- Données dérivées (index, embeddings, scores, “features”, résumés)
Vous pouvez même l’exprimer sous forme de mini-tableau (souvent plus lisible qu’une annexe narrative) :
| Élément | Contenu attendu dans l’annexe | Pourquoi c’est utile |
|---|---|---|
| Finalité | Ex. “recherche interne” / “support client” / “détection fraude” | Évite les usages secondaires implicites |
| Types de données | Ex. identifiants, emails pro, tickets, logs | Sert à calibrer chiffrement, accès, rétention |
| Données dérivées IA | Ex. embeddings, scores, résumés, index | Clarifie ce qui doit être restitué/supprimé |
| Environnements | prod / préprod / sandbox (données réelles ou masquées) | Évite la “fuite” de données en test |
| Rétention | durées par catégorie + gestion des sauvegardes | Rend possible une suppression crédible |
| Transferts | accès hors UE, support, administration | Alimente la conformité transferts |
Exemple réaliste : une ETI déploie un assistant de recherche interne basé sur des documents RH et des tickets support. L’annexe doit distinguer : (1) les documents sources (PDF, mails), (2) les métadonnées (auteur, horodatage), (3) les journaux techniques (adresses IP, identifiants), (4) les données dérivées (embeddings, résumés). Sans cette granularité, vous ne savez pas ce qui doit être supprimé en fin de contrat, ni ce qui part en sous-traitance (moteur d’indexation, outil de télémétrie, service de modération).
Cette précision contractuelle se prépare avec une cartographie des flux et des accès. Si vous avez déjà engagé un travail de cartographie pour l’IA, réutilisez-le pour alimenter les annexes article 28, plutôt que de les “remplir” a posteriori. Sur ce point, une méthode pratique est détaillée dans : Gouvernance IA : cartographie des flux et accès pour données sensibles.
Instructions, confidentialité et séparation des rôles, avec des cas d’usage IA
L’obligation centrale du sous-traitant est de ne traiter les données que sur instruction documentée du responsable. Dans un contrat, cela se traduit par un mécanisme clair : qui peut donner instruction (DSI, produit, DPO), comment elle est transmise (ticket, bon de commande, annexe), et comment les changements sont tracés. Sans ce mécanisme, vous vous exposez à une “zone grise” où des paramètres de service (rétention, options de partage, activation de journaux) deviennent des décisions implicites.
Une bonne pratique consiste à contractualiser un canal d’instruction et une preuve d’exécution, par exemple :
- canal : portail client / ticketing / email nominatif autorisé ;
- preuve : historique des changements (audit trail), exportable sur demande ;
- règle : “pas d’activation par défaut” sur les options à impact données (partage, conservation étendue, entraînement).
La confidentialité ne se limite pas à une clause générale. Elle doit couvrir les personnes habilitées chez le sous-traitant (support, SRE, ingénierie), les conditions d’accès (accès justifié, à durée limitée, journalisé), et les engagements de formation. Pour des données sensibles, demandez un modèle d’habilitation basé sur le moindre privilège, des revues d’accès périodiques et une séparation des environnements. Ces éléments sont techniques, mais ils ont un impact direct sur la capacité à défendre votre analyse de risques.
Avec l’IA, le point de rupture fréquent concerne l’usage secondaire des données. Le contrat doit dire explicitement si les prompts, fichiers, ou sorties sont (a) utilisés pour fournir le service uniquement, (b) utilisés pour améliorer un modèle mutualisé, ou (c) conservés à des fins de débogage. Une formulation contractuelle utile (sans “sur-promettre”) est de rendre binaire ce qui doit l’être : opt-in explicite pour l’amélioration de modèle, et défaut “service-only”. Si le prestataire commence à décider “pour lui-même” des finalités, le RGPD rappelle le basculement de rôle : « Si un sous-traitant détermine les finalités et les moyens du traitement, il est considéré comme un responsable du traitement » (RGPD, art. 28(10), source EUR-Lex ci-dessus). C’est un enjeu de gouvernance autant que de conformité.
Mini-scénario fréquent (et évitable) : l’équipe produit active une option “améliorer le service” dans la console IA, pensant gagner en qualité. Or cette option implique la conservation élargie des entrées/sorties, potentiellement réutilisées pour entraîner un composant mutualisé. Sans gouvernance des instructions, l’activation devient une décision de finalité “au fil de l’eau” — difficile à justifier ensuite. Une annexe “instructions et options” (qui liste les options autorisées/interdites et qui peut les changer) règle souvent le problème à moindre coût.
Pour sécuriser la négociation, partez de questions structurées plutôt que d’un débat de principes. Une grille de questions, utilisable en appel d’offres ou en revue fournisseur, est proposée ici : Questions à poser pour choisir un fournisseur IA et maîtriser les risques. Elle aide à obtenir des réponses “contrat + annexes + preuves”, au lieu de déclarations générales.
Mesures de sécurité et preuve : de l’annexe technique à l’auditabilité
L’article 28 impose que le sous-traitant prenne « toutes les mesures requises en vertu de l’article 32 » (sécurité du traitement). Une mesure technique et organisationnelle est un contrôle concret, vérifiable, qui réduit un risque (ex. chiffrement, segmentation réseau, procédure de gestion des incidents). L’erreur courante est de se contenter d’une annexe de sécurité générique, non liée à votre cas d’usage.
Pour éviter l’annexe “catalogue”, vous pouvez demander au sous-traitant de présenter les mesures sous l’angle risque → contrôle → preuve. Exemple de grille (à adapter) :
| Risque | Mesure attendue | Exemple de preuve demandable |
|---|---|---|
| Accès support non maîtrisé | Accès JIT/JEA, approbation, journalisation | Extrait de procédure + exemples de logs |
| Exfiltration via export/API | Contrôles d’export, limites, alertes | Paramétrage + rapports d’alerting |
| Compromission compte admin | MFA, PAM, séparation des rôles | Politique IAM + résultats de revues d’accès |
| Fuite dans les logs | Minimisation + masquage + rétention courte | Politique de logging + durées par type |
| Incident de sécurité | Runbook + notification + post-mortem | Exemple de rapport d’incident anonymisé |
Pour les services cloud et IA, le chiffrement et la gestion des clés sont des points structurants. Une clé de chiffrement est un secret cryptographique permettant de chiffrer et déchiffrer des données. Selon vos contraintes, vous pouvez exiger une gestion de clés dédiée, des rotations planifiées, et des preuves de destruction. Si vous utilisez des clés gérées côté client (CMEK), l’enjeu devient la gouvernance : qui crée la clé, qui peut la révoquer, que se passe-t-il en cas de litige. Pour approfondir, voir : Cloud KMS : gouvernance des CMEK, rotation, destruction et audit.
La preuve de sécurité passe aussi par l’observabilité. Exigez des engagements sur la journalisation (accès administrateur, exports, opérations sensibles), la conservation des logs, et la fourniture d’éléments en cas d’enquête. Demandez une politique de gestion des vulnérabilités (délais de correction, publication, scanners), et des tests réguliers (revues de configuration, tests d’intrusion encadrés). Les attestations (ISO/IEC 27001, SOC 2) sont utiles, mais elles ne remplacent pas une annexe alignée sur vos traitements : elles couvrent un périmètre et une période, pas forcément votre configuration, vos options activées, ni vos flux.
Si vous opérez des données très sensibles, une qualification comme SecNumCloud peut être un indicateur de maturité sur des exigences d’hébergement et d’exploitation, sans être un substitut au RGPD. Il est utile de comprendre ce que ces exigences changent concrètement dans l’offre (support, administration, séparation, localisation des opérations). Un décryptage des impacts côté services est disponible ici : SecNumCloud 3.2 : impacts sur les services cloud de données sensibles.
Sous-traitants ultérieurs et transferts internationaux : contrôler la chaîne sans illusion
L’article 28 encadre strictement le recours à des sous-traitants ultérieurs (sous-traitants du sous-traitant). Le contrat doit prévoir une autorisation spécifique ou générale, et surtout un mécanisme de notification des changements. Dans un service IA moderne, les sous-traitants ultérieurs peuvent inclure l’hébergeur, un outil de support, un service de supervision, ou un composant de filtrage de contenus. Sans visibilité sur cette chaîne, vous perdez la maîtrise de vos risques.
Deux points font la différence en négociation. D’abord, une liste à jour des sous-traitants ultérieurs, avec leurs rôles, leurs localisations d’hébergement, et les traitements réalisés. Ensuite, un délai de préavis réaliste en cas d’ajout ou de remplacement, avec un droit d’objection organisé (processus, conséquences, option de résiliation). Cela évite l’objection “théorique” impossible à exercer quand le changement est effectif du jour au lendemain.
Dans les faits, un dispositif robuste ressemble à ceci :
- registre des sous-traitants ultérieurs accessible (portail, annexe dynamique) ;
- notification avec préavis (ex. 30 jours quand c’est possible opérationnellement) ;
- informations minimales : identité, rôle, pays d’accès/hébergement, catégories de données, mesures de sécurité ;
- back-to-back : obligation contractuelle que chaque sous-traitant ultérieur respecte des exigences au moins équivalentes (confidentialité, sécurité, assistance, suppression/restitution).
Sur les transferts internationaux, l’enjeu n’est pas seulement “où sont les serveurs”, mais si des données peuvent être accessibles depuis un pays tiers (support, administration, obligations légales). Le contrat doit documenter les flux, les bases de transfert le cas échéant (par exemple, clauses contractuelles types), et les mesures complémentaires si nécessaires. Un repère utile est la doctrine européenne sur les mesures supplémentaires post-Schrems II : EDPB, Recommendations 01/2020 (version finale 18/06/2021) — EDPB Recommendations 01/2020.
Sur le plan opérationnel, la “bonne” question à poser est souvent : quels accès humains et techniques existent hors UE, et quels moyens de réduction sont réellement en place (chiffrement avec clés sous contrôle du client, cloisonnement, procédures d’accès support, transparence). C’est aussi là que la distinction hébergement / juridiction / gouvernance des clés devient concrète.
Enfin, gardez la distinction entre hébergement et juridiction applicable. Choisir un hébergement dans l’UE réduit certains risques techniques et opérationnels, mais ne répond pas à toutes les questions d’accès potentiel, de chaîne de sous-traitance et de gouvernance des clés. L’article 28 est l’endroit où vous rendez ces arbitrages explicites, y compris quand vous acceptez une part de risque pour aller plus vite.
Assistance, incidents, droits des personnes : clauses qui réduisent le temps de crise
L’article 28 impose au sous-traitant d’assister le responsable, notamment pour répondre aux demandes d’exercice de droits. Une demande d’exercice de droits (accès, effacement, opposition, etc.) est une sollicitation d’une personne concernée visant à contrôler l’usage de ses données. En pratique, l’assistance doit préciser des délais, des canaux, et des limites techniques (par exemple, suppression dans les sauvegardes avec délai). Sans cela, le responsable promet aux personnes ce que le fournisseur ne peut pas exécuter.
Sur des services IA, ajoutez un point souvent oublié : la capacité à retrouver une donnée dans des structures dérivées. Si des documents ont été indexés, vectorisés (embeddings) ou résumés, l’assistance doit couvrir :
- comment identifier les éléments à supprimer (références, IDs, mapping) ;
- quelles composantes sont affectées (index texte, index vectoriel, cache, logs) ;
- quels délais réalistes (immédiat en production vs cycle de purge des sauvegardes).
La gestion des incidents doit être contractualisée au-delà de « dans les meilleurs délais ». Le RGPD impose au responsable de notifier l’autorité sous 72 heures dans certains cas, donc le sous-traitant doit fournir rapidement les éléments factuels. Le texte de référence côté responsable est explicite : « Le responsable du traitement notifie la violation de données à caractère personnel à l’autorité de contrôle compétente (…) dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance » (RGPD, art. 33(1), source EUR-Lex ci-dessus). Fixez un objectif de notification au responsable (ex. 24 heures après détection, à adapter), la structure du rapport (périmètre, catégories de données, causes, mesures correctives), et un point de contact 24/7. Ajoutez une obligation de conservation des preuves (journaux, images) pour permettre l’analyse.
Une clause “utile en crise” précise aussi le minimum d’informations attendu dans la première notification du sous-traitant (même si tout n’est pas connu) :
- horodatage de détection et, si possible, de début d’incident ;
- périmètre (services/tenants concernés) ;
- types de données potentiellement impactés ;
- mesures immédiates (confinement, révocation, patch) ;
- prochaines étapes et heure de mise à jour.
La fin de contrat est un test de réalité. Le sous-traitant doit, au choix du responsable, supprimer ou restituer les données et détruire les copies, sauf obligation légale. Pour rendre cela actionnable, précisez les formats de restitution (export brut, API, dumps), les dépendances (index, embeddings, configurations), et le calendrier. La réversibilité doit être traitée comme un mini-projet : plan, responsabilités, coûts, et critères de succès (données complètes, lisibles, utilisables). Pour les services IA, pensez aussi à la restitution de ce qui “fait fonctionner” l’usage côté client : dictionnaires, schémas, configurations de connecteurs, règles de filtrage, et paramètres de rétention.
L’audit est souvent conflictuel car mal cadré. L’article 28 prévoit la mise à disposition d’informations et la possibilité d’audits. Pour concilier sécurité et praticité, prévoyez une hiérarchie : rapports tiers récents (SOC, ISO), questionnaires de contrôle, puis audit sur site ou à distance en dernier recours. Spécifiez la confidentialité, le préavis, les plages horaires, et la possibilité de mutualiser des audits entre clients, ce qui réduit la charge des deux côtés. Un point pragmatique à contractualiser est la capacité de “preuve à la demande” : par exemple, fournir sous X jours un extrait de procédure, un état de configuration, ou un échantillon de logs (anonymisé) lié à un contrôle précis.
Action concrète (effort : moyen, 0,5 à 2 jours) : prenez votre DPA actuel et passez-le à la “check-list article 28” suivante, en exigeant une réponse sous forme d’addendum et d’annexes.
1) Effort faible : compléter l’annexe de traitement (données, finalités, environnements, données dérivées IA) et aligner les instructions documentées.
2) Effort moyen : verrouiller sous-traitants ultérieurs, délais de notification incident, et annexes de sécurité (chiffrement, gestion des accès, logs, preuves).
3) Effort élevé : formaliser un plan de réversibilité testé (extraction, restauration ailleurs, délais), et organiser un dispositif d’audit proportionné. Faites valider les points juridiques par votre DPO ou conseil, mais gardez la main sur les exigences techniques et les preuves attendues.
