Data controller vs processor en IA : qui décide, qui exécute ?

Le RGPD pose cette distinction à ses articles 24 à 28, et la nLPD suisse retient le même partage fonctionnel à ses articles 5 et 9. Dans les deux cadres, la responsabilité de conformité reste principalement chez le responsable, même lorsqu'il délègue le traitement technique à un prestataire, y compris une plateforme d'intelligence artificielle.

En bref:

• La responsabilité de conformité demeure principalement sur le responsable du traitement, même lorsqu'il délègue des tâches à un prestataire ou une plateforme d'IA.
• Un acteur est considéré comme responsable s'il décide des finalités ou dispose d'une autonomie d'exécution dans le traitement des données.
• Le responsable doit documenter chaque traitement, réaliser une analyse d'impact en cas de risque élevé, et contrôler régulièrement la sécurité et la conformité des sous-traitants.
• Le sous-traitant doit respecter strictement les instructions et ne jamais réutiliser ou détourner les données sans autorisation explicite du responsable.
• La localisation géographique des données ne garantit pas leur souveraineté, un contrôle rigoureux des flux et des garanties contractuelles reste essentiel.

Table des matières

• Définitions juridiques détaillées : controller et processor face au RGPD et à la nLPD
• Obligations principales du responsable du traitement
• Obligations du sous-traitant et limites de son rôle
• Traitements conjoints et situations hybrides entre responsable et sous-traitant
• Exigences contractuelles : l'annexe de traitement et l'article 28
• Flux internationaux, localisation et souveraineté des données pour les traitements IA
• Checklist pratique pour décider et contrôler un fournisseur IA
• Exemples et cas d'usage courts illustrant les décisions de rôle
• Ce que la souveraineté des données change vraiment pour la conformité
• Sources
• Questions fréquentes

Définitions juridiques détaillées : controller et processor face au RGPD et à la nLPD

Le RGPD définit le responsable du traitement comme l'entité qui détermine les finalités et les moyens du traitement de données personnelles, tandis que le sous-traitant agit pour le compte du responsable et selon ses instructions écrites, comme le rappelle l'analyse de Legal 500 sur les rôles controller et processor. Cette distinction n'est pas qu'une formalité administrative : elle conditionne qui répond devant une autorité de contrôle en cas de manquement.

La nLPD suisse retient une architecture comparable, même si le vocabulaire diffère légèrement. Le responsable du traitement décide des finalités et des moyens, tandis que le sous-traitant traite des données pour le compte du responsable, sans marge de décision propre sur ces finalités. Un fournisseur suisse qui héberge des données ne devient pas automatiquement responsable du seul fait qu'il les stocke : ce qui compte, c'est qui décide de ce qui est fait avec ces données, et pourquoi.

Trois critères permettent, en pratique, de qualifier un acteur :

• La décision sur les finalités : qui fixe l'objectif du traitement, par exemple analyser des CV pour présélectionner des candidats.
• L'autonomie d'exécution : le prestataire peut-il choisir librement ses méthodes techniques, ou reste-t-il cadré par des instructions précises.
• La prise d'instructions documentées : un contrat, une annexe ou une politique définit-elle explicitement le périmètre d'action du prestataire.

Trois exemples éclairent la mécanique. Une entreprise de recrutement qui utilise une plateforme d'IA pour trier des candidatures reste responsable du traitement, puisqu'elle fixe l'objectif du tri et les critères retenus, tandis que l'éditeur de la plateforme agit comme sous-traitant. Un cabinet d'avocats qui confie la transcription de ses réunions à un service tiers demeure responsable des données échangées, le prestataire n'ayant qu'un rôle d'exécution technique. Un éditeur de logiciel qui décide seul d'enrichir son modèle d'IA générative à partir des données de ses clients, sans instruction explicite de ces derniers, bascule alors vers le statut de responsable pour cet usage précis, ce qui change entièrement l'équilibre contractuel.

Obligations principales du responsable du traitement

Le responsable porte la charge de la preuve de conformité, ce que le RGPD nomme le principe d'accountability. Cette obligation ne se limite pas à respecter la loi : il faut pouvoir démontrer, documents à l'appui, que chaque exigence a été remplie. Le chapitre 4 du RGPD détaille précisément ces obligations, des articles 24 à 31, qui couvrent la sécurité, la tenue de registres et les relations avec les sous-traitants.

Quatre familles d'obligations structurent le rôle du responsable :

1. Tenue de registres et analyses d'impact : documenter chaque traitement et réaliser une analyse d'impact (AIPD ou DPIA) dès qu'un système d'IA présente un risque élevé pour les personnes concernées, notamment lorsqu'il implique un profilage automatisé.
2. Base juridique et information des personnes concernées : identifier la base légale de chaque traitement, consentement, intérêt légitime ou obligation contractuelle, et informer clairement les personnes sur l'usage fait de leurs données.
3. Sécurité technique et organisationnelle : mettre en place des mesures proportionnées au risque, chiffrement, contrôle d'accès, journalisation, et les faire évoluer avec les menaces.
4. Surveillance des sous-traitants : vérifier, par des audits et des clauses contractuelles, que chaque prestataire respecte ses engagements de sécurité et de licéité.

Cette dernière obligation est souvent sous-estimée. Le responsable ne peut pas se contenter de signer un contrat puis d'oublier le sujet : il doit exercer un contrôle réel, ce que confirment les recommandations des autorités de protection des données, qui attendent des audits périodiques et des preuves techniques tangibles, pas de simples déclarations d'intention.

Conseil de pro : avant de choisir un fournisseur IA, demandez systématiquement une copie de sa dernière analyse d'impact ou de son rapport d'audit externe, plutôt qu'une attestation générique de conformité.

Un point mérite une attention particulière pour les traitements d'IA à risque élevé, comme le tri automatisé de candidatures ou l'octroi de crédit. Dans ces cas, l'analyse d'impact n'est pas une option mais une étape préalable obligatoire, et son absence expose directement le responsable, jamais le sous-traitant, à une sanction. Cette asymétrie explique pourquoi tant de directions juridiques exigent désormais une documentation technique détaillée avant même de tester un outil d'IA en interne.

Obligations du sous-traitant et limites de son rôle

Cette contrainte structure l'ensemble de ses obligations, qui restent opérationnelles plutôt que décisionnelles.

Les obligations concrètes du sous-traitant se déclinent ainsi :

• Respect strict des instructions : traiter les données seulement dans le cadre défini par le contrat, sans extension d'usage de sa propre initiative.
• Sécurité et tenue de registres : appliquer des mesures de sécurité adaptées et documenter les traitements effectués pour le compte du responsable.
• Coopération et notification d'incidents : signaler sans délai toute violation de données et assister le responsable dans ses obligations envers les personnes concernées.
• Interdiction de réutilisation : ne jamais exploiter les données à des fins propres, par exemple pour entraîner un modèle d'IA générique, sans autorisation explicite.
• Encadrement de la sous-sous-traitance : ne recourir à un autre prestataire qu'avec l'autorisation préalable du responsable, et lui transmettre les mêmes obligations contractuelles.

Cette dernière règle est souvent le point faible des relations contractuelles mal négociées. Un sous-traitant qui fait appel, sans en informer le responsable, à un hébergeur situé dans un pays tiers ou à un service cloud étranger crée une chaîne de sous-traitance non maîtrisée. Le responsable, qui reste juridiquement exposé, découvre parfois cette situation trop tard, lors d'un audit ou d'un incident de sécurité.

La frontière entre les deux rôles n'est jamais figée définitivement. Un prestataire qui commence à décider unilatéralement de nouvelles finalités, par exemple en réutilisant des journaux de conversation pour améliorer son propre modèle sans mandat explicite, sort du rôle de sous-traitant et devient responsable pour cet usage spécifique. Cette requalification a des conséquences directes : elle transfère sur lui les obligations d'information, de base légale et de tenue de registre qu'il n'assumait pas jusque-là. C'est précisément ce type de dérive que les clauses contractuelles doivent anticiper et bloquer.

Traitements conjoints et situations hybrides entre responsable et sous-traitant

Deux entités peuvent devenir responsables conjoints d'un même traitement lorsqu'elles décident ensemble des finalités et des moyens, même si leurs contributions respectives diffèrent en intensité. Le RGPD prévoit cette configuration à son article 26, qui impose de répartir clairement les obligations entre les parties, notamment celle d'informer les personnes concernées.

La répartition ne peut pas rester implicite. Un accord de responsabilité conjointe doit préciser qui répond aux demandes d'exercice de droits, qui gère les violations de données, et quel point de contact est communiqué aux personnes concernées. En pratique :

• Le partenariat de données IA illustre bien cette hybridité, lorsque deux entreprises croisent leurs bases de données pour entraîner un modèle commun, chacune fixant en partie les finalités du traitement.
• L'intégration d'un module tiers dans un outil d'IA peut faire basculer l'éditeur principal du statut de simple sous-traitant vers celui de responsable conjoint, s'il décide d'orienter les résultats à des fins qui lui sont propres, par exemple à des fins publicitaires.
• La double casquette existe aussi pour un même acteur, qui agit comme sous-traitant pour certains traitements et comme responsable pour d'autres, au sein d'une même relation contractuelle.

Chaque flux de données doit être qualifié séparément, car un contrat unique et générique risque de masquer des zones grises où personne n'assume clairement la responsabilité.

Exigences contractuelles : l'annexe de traitement et l'article 28

L'article 28 du RGPD impose un contrat écrit entre responsable et sous-traitant, et cette exigence contractuelle constitue le socle documentaire de toute relation de sous-traitance IA. Le chapitre 4 du RGPD y consacre une attention spécifique, précisément parce que ce document sert de preuve en cas de contrôle.

Le contrat, ou son annexe de traitement, doit couvrir au minimum les points suivants :

1. L'objet et la durée du traitement, avec une description précise des finalités et des types de données concernées.
2. Les mesures de sécurité techniques et organisationnelles, incluant chiffrement, contrôle d'accès et journalisation des opérations.
3. L'assistance pour l'exercice des droits, le sous-traitant devant aider le responsable à répondre aux demandes des personnes concernées.
4. Les conditions de sous-sous-traitance, avec autorisation préalable écrite et transmission des mêmes obligations contractuelles.
5. Le droit d'audit du responsable, incluant l'accès aux résultats d'audits externes et aux journaux d'activité pertinents.

La qualité de la documentation contractuelle fait souvent la différence lors d'un contrôle réel. Les analyses de l'industrie sur la distinction entre controllers et processors montrent que les législations récentes insistent précisément sur cette capacité à prouver, contrat en main, qui fait quoi et sous quelles conditions.

Conseil de pro : exigez que l'annexe de traitement mentionne explicitement un SLA de sécurité chiffré, par exemple un délai maximal de notification d'incident, plutôt qu'une formule vague du type « dans les meilleurs délais ».

La preuve ne s'arrête pas à la signature du contrat. Un responsable doit pouvoir accéder, sur demande raisonnable, aux journaux d'audit du sous-traitant, ou à défaut à un résumé certifié de ces contrôles. Sans cette capacité de vérification continue, l'annexe de traitement reste un document déclaratif sans valeur probante réelle en cas de litige.

Flux internationaux, localisation et souveraineté des données pour les traitements IA

La souveraineté des données ne se résume pas à l'emplacement d'un serveur : c'est une question de flux, qui exige de connaître le pays du siège du fournisseur, les lieux effectifs de traitement, et l'ensemble de la chaîne de sous-traitants ultérieurs. Un serveur situé en Suisse ne garantit rien si les données transitent ensuite vers un sous-traitant établi ailleurs, sans garantie équivalente.

Trois vérifications structurent une évaluation sérieuse :

• Le siège juridique du fournisseur et sa soumission éventuelle à des législations extraterritoriales, qui peuvent créer des obligations de communication de données indépendantes du lieu d'hébergement.
• Les lieux effectifs de traitement, souvent différents du lieu commercial affiché, et qu'il faut faire préciser contractuellement.
• La chaîne de sous-traitants ultérieurs, chacun devant offrir des garanties de protection équivalentes à celles exigées du responsable.

Un contrôle documenté du siège et des lieux de traitement d'un fournisseur reste la vérification la plus fiable avant toute signature. Les recommandations des autorités de protection des données insistent sur ce point précis, en demandant d'évaluer systématiquement le niveau de protection du pays destinataire avant tout transfert de données à l'étranger.

Concrètement, lorsqu'un transfert transfrontalier s'avère nécessaire, des garanties appropriées doivent être mises en place : clauses contractuelles types, mesures techniques supplémentaires comme le chiffrement de bout en bout, ou certification reconnue. La page consacrée à la souveraineté suisse détaille les preuves techniques et contractuelles qu'un responsable peut exiger pour vérifier qu'aucune donnée ne quitte le territoire sans son autorisation explicite.

Checklist pratique pour décider et contrôler un fournisseur IA

Avant de signer avec un fournisseur d'IA, une vérification structurée limite les mauvaises surprises et facilite la preuve de diligence en cas de contrôle ultérieur.

1. Poser les questions contractuelles préalables : qui décide des finalités, où sont hébergées les données, et quelle est la chaîne complète de sous-traitance.
2. Vérifier les preuves techniques : demander les résultats d'un audit de sécurité récent, d'un test d'intrusion, ou d'une certification comme l'ISO 27001.
3. Contrôler les journaux d'audit : s'assurer qu'un accès aux logs d'activité est prévu contractuellement, pas seulement promis verbalement.
4. Clarifier le processus d'incident : exiger un délai précis de notification et un point de contact identifié en cas de violation de données.
5. Vérifier les conditions de réversibilité : s'assurer que la suppression des données et la portabilité en fin de contrat sont explicitement prévues.

Un audit structuré de la présence documentaire et des schémas de données d'un fournisseur, à l'image des méthodes proposées par des outils comme l'audit de données structurées de BabyLoveGrowth, peut aussi aider à repérer les incohérences entre ce qu'un fournisseur affiche publiquement et ce qu'il documente réellement dans ses contrats.

Conseil de pro : conservez une trace écrite de chaque échange précontractuel avec un fournisseur IA : ces courriels deviennent souvent la seule preuve disponible en cas de litige sur ce qui avait été promis.

Exemples et cas d'usage courts illustrant les décisions de rôle

Trois situations résument bien la mécanique controller et processor appliquée à l'IA.

• L'analyse de CV via une plateforme IA : l'entreprise qui recrute reste responsable, puisqu'elle décide des critères de tri, tandis que l'éditeur de la plateforme exécute selon ces paramètres.
• Un service de transcription de réunions : le client demeure responsable du contenu échangé, et le SLA doit préciser la durée de conservation des enregistrements et les conditions de suppression.
• L'intégration d'un modèle tiers dans un outil métier : cette configuration crée un risque de sous-sous-traitance non maîtrisée si l'éditeur principal ne documente pas explicitement ce recours.

Ce que la souveraineté des données change vraiment pour la conformité

L'hébergement local et une infrastructure transparente réduisent certains vecteurs de risque, notamment ceux liés aux transferts transfrontaliers et à l'exposition à des législations étrangères. Un service souverain garantit que les données sont hébergées et traitées exclusivement sur des serveurs situés en Suisse, conformément à la nLPD.

Mais la localisation ne remplace jamais la gouvernance : un responsable doit toujours exiger logs, audits, annexes de traitement et politique de transferts documentée, quel que soit le pays d'hébergement retenu.

— Adopt.

Cet article constitue une information générale et ne remplace pas l'avis d'un avocat qualifié. Consultez un professionnel du droit qualifié à propos de votre cas personnel avant d'agir sur la base de ce contenu.

Sources

• GDPR: Who Are Data Controllers And Processors?
• Distinguishing Between Controllers and Processors

Questions fréquentes

Quelle est la différence entre un responsable et un sous-traitant ?

Cette distinction, posée par le RGPD, se retrouve aussi dans la nLPD suisse, avec un partage fonctionnel équivalent.

Un responsable peut-il aussi être sous-traitant ?

C'est fréquent lorsqu'un éditeur de logiciel agit comme sous-traitant pour certaines fonctionnalités et comme responsable pour d'autres, par exemple ses propres analyses statistiques internes.

Quel est un exemple concret de responsable du traitement ?

Une entreprise qui utilise une plateforme d'IA pour trier des candidatures reste responsable du traitement, puisqu'elle fixe les critères de sélection et l'objectif du tri. L'éditeur de la plateforme, lui, agit comme sous-traitant tant qu'il n'utilise pas ces données pour ses propres finalités.

Qui n'est jamais considéré comme responsable du traitement ?

Un prestataire qui se limite strictement aux instructions documentées de son client, sans décider des finalités ni réutiliser les données à ses propres fins, reste sous-traitant. Dès qu'il dépasse ce cadre, par exemple en exploitant des données pour entraîner un modèle générique sans mandat explicite, il bascule vers un statut de responsable pour cet usage précis.