DPA fournisseur IA générative, clauses de sécurité RGPD

Un accord de traitement des données, ou DPA (Data Processing Agreement), fixe ce que le fournisseur d’un service d’intelligence artificielle (IA) générative a le droit de faire des données qu’on lui envoie, et ce qu’il doit faire quand elles fuient. Le RGPD (Règlement général sur la protection des données) en impose le socle ; la sécurité réelle se joue dans ce que le socle laisse ouvert. La position défendue ici : le DPA se lit comme une annexe d’architecture, pas comme une pièce jointe au bon de commande.

→ Lire l’explication complète de la marmotte

Ce que l’article 28 du RGPD impose, et ce qu’il laisse ouvert

Quand une organisation envoie des données personnelles à une API (Application Programming Interface) de modèle de langage pour son propre compte, le fournisseur agit en principe comme sous-traitant, et l’article 28 du RGPD exige un contrat. Son paragraphe 3 en liste le contenu minimal : traitement uniquement sur instruction documentée du client, confidentialité des personnes habilitées, mesures de sécurité de l’article 32, conditions de recours à d’autres sous-traitants, assistance pour les droits des personnes et les obligations de sécurité, suppression ou restitution en fin de contrat, mise à disposition des informations et possibilité d’audit.

Le texte impose ces clauses, pas leur précision : « mesures techniques et organisationnelles appropriées » sans annexe détaillée ne vaut rien en revue d’architecture. À faire préciser par écrit :

Chiffrement : algorithmes et gestion des clés au repos, version minimale de TLS (Transport Layer Security) en transit, et qui détient les clés.
Accès du personnel : conditions dans lesquelles un employé du fournisseur voit un prompt (modération, abus, support), journalisation de ces accès, possibilité de les exclure.
Durée de conservation : délai de purge des requêtes et réponses, y compris dans les journaux de modération et les sauvegardes (la question de la rétention côté API a sa propre page dans cette rubrique).
Isolation : séparation logique entre clients, et interdiction que les données d’un client servent à répondre à un autre.

Le piège le plus coûteux se trouve au paragraphe 10 du même article : un sous-traitant qui détermine lui-même les finalités d’un traitement devient responsable de traitement pour celui-ci. Un fournisseur qui réutilise les prompts pour entraîner ses modèles poursuit sa propre finalité. Le DPA doit donc soit l’exclure explicitement, soit l’encadrer comme un traitement distinct, avec sa propre base légale. Un DPA muet sur ce point laisse la question aux conditions générales, modifiables sans négociation.

Sous-traitants ultérieurs, localisation et transferts

Un service d’IA générative empile plusieurs couches : éditeur du modèle, hébergeur de calcul, souvent prestataire de modération ou de support. L’article 28 permet une autorisation générale de recours à des sous-traitants ultérieurs, à condition que le client soit informé de tout changement et puisse s’y opposer. En pratique, ce droit d’opposition se résume souvent à résilier ; il ne sert à rien si personne ne surveille la liste.

Trois exigences à poser :

Liste nominative des sous-traitants ultérieurs, avec pays de traitement et nature de l’accès (données en clair ou non).
Notification active d’un changement (courriel, flux) avec un préavis chiffré en jours, pas une mise à jour silencieuse d’une page web.
Répercussion des obligations : chaque sous-traitant ultérieur est tenu par des obligations équivalentes, et le fournisseur reste responsable envers le client.

Pour la localisation, distinguer lieu de stockage et lieu de traitement : une région européenne pour le stockage n’empêche pas un traitement d’inférence ou un support à distance depuis un pays tiers. Tout accès depuis hors de l’Espace économique européen est un transfert au sens du chapitre V du RGPD, qui exige un fondement (décision d’adéquation, clauses contractuelles types de la Commission). La question distincte de l’accès des autorités étrangères au fournisseur relève de la souveraineté, pas du contrat, et se traite à part.

Vingt ans de contrats d’infogérance apprennent que la liste des sous-traitants est le document le plus souvent annexé et le moins souvent relu, juste derrière les conditions générales du parking.

Surveiller la liste des sous-traitants ultérieurs

Quand le fournisseur publie sa liste sur une page web, un relevé périodique transforme le droit d’opposition théorique en alerte exploitable. Prérequis : curl, diff, une tâche planifiée, et l’adresse de la page indiquée dans le DPA.

#!/usr/bin/env bash
# Relevé quotidien de la page des sous-traitants ultérieurs d'un fournisseur
set -euo pipefail

URL="https://fournisseur.example/legal/sous-traitants"   # adresse indiquée dans le DPA
DIR="/var/lib/veille-dpa/fournisseur"
mkdir -p "$DIR"

# Récupère la page, retire les balises HTML et les lignes vides pour ne comparer que le texte
curl -fsSL "$URL" | sed -e 's/<[^>]*>//g' -e '/^[[:space:]]*$/d' > "$DIR/courant.txt"

# Compare au dernier relevé ; toute différence part vers la boîte de l'équipe conformité
if [ -f "$DIR/precedent.txt" ] && ! diff -u "$DIR/precedent.txt" "$DIR/courant.txt" > "$DIR/diff.txt"; then
  mail -s "DPA : liste des sous-traitants modifiée" [email protected] < "$DIR/diff.txt"
fi
mv "$DIR/courant.txt" "$DIR/precedent.txt"

L’alerte ouvre le délai d’opposition : il faut alors vérifier le pays, la nature de l’accès et le fondement du transfert pour le nouveau venu.

Notification d’incident, audit et réversibilité

L’article 33 impose au responsable de traitement de notifier l’autorité de contrôle d’une violation, si possible 72 heures au plus tard après en avoir pris connaissance, et au sous-traitant de prévenir le responsable « dans les meilleurs délais ». Cette formule est inexploitable : si le fournisseur prévient au bout de 60 heures, il reste 12 heures pour qualifier. Le DPA doit fixer un délai en heures, un point de contact nommé des deux côtés, et le contenu minimal de la notification (nature des données, périmètre de clients touchés, journaux disponibles).

Le droit d’audit se négocie rarement en audit sur place avec un fournisseur de cette taille ; on accepte en général des rapports tiers (certification ISO/IEC 27001 de management de la sécurité de l’information, rapport SOC 2 pour System and Organization Controls). Exiger alors le périmètre exact du rapport : un certificat qui couvre l’hébergement mais pas la chaîne d’inférence ne prouve rien sur les prompts. Pour la fin de contrat, exiger une attestation de suppression incluant sauvegardes et journaux, avec délai.

Ce que le DPA ne garantit pas : il crée une responsabilité, pas une impossibilité technique. Une donnée envoyée reste lisible par le fournisseur au moment du traitement, quel que soit le contrat. La classification de ce qui peut partir chez un tiers reste à faire en amont (voir la rubrique Données), et la cartographie contractuelle des tiers relève de la gouvernance. Pour le reste de la rubrique, la page d’entrée est IA.

🐝 Ce qui arrive si on s’en passe

Sans DPA conforme à l’article 28, le client ne peut pas démontrer qu’il a choisi un sous-traitant présentant des garanties suffisantes ; en cas de violation chez le fournisseur, l’autorité de contrôle examine aussi ce choix et ce contrat. Sans clause de suppression en fin de contrat, les données déjà envoyées survivent à la résiliation dans les journaux et les sauvegardes du fournisseur, sans délai opposable. Sans délai de notification chiffré, la fenêtre de 72 heures s’ouvre au moment où le client apprend l’incident, parfois par la presse, et la qualification se fait sans journaux. Sans liste nominative des sous-traitants, un registre des traitements complet est impossible à tenir, et une demande d’accès d’une personne concernée ne peut pas recevoir de réponse exacte sur les destinataires.

🦫 Explication de la marmotte 🍫

Quand une entreprise utilise un assistant d’intelligence artificielle proposé par une autre société, elle lui envoie des textes qui contiennent parfois des informations sur des personnes. La loi européenne sur la protection des données oblige alors à signer un contrat spécial avec cette société. Ce contrat dit ce qu’elle a le droit de faire avec ces textes : seulement ce que le client demande, rien d’autre. Si la société se sert des textes pour améliorer son propre programme, elle poursuit son propre but : la loi la rend alors directement responsable de cet usage, avec des obligations supplémentaires. Le contrat liste aussi les autres entreprises qu’elle fait travailler pour elle, par exemple celle qui fournit les ordinateurs. Chaque ajout à cette liste doit être annoncé, et le client peut refuser, à condition de surveiller la liste. En cas de fuite, le client a 72 heures pour prévenir l’autorité chargée de la protection des données. Si le fournisseur tarde à le prévenir, ce délai devient intenable : il faut donc écrire dans le contrat un délai précis en heures. Enfin, le contrat dit ce qui est effacé à la fin, sauvegardes comprises. Un contrat crée une obligation, il n’empêche pas techniquement la société de lire ce qu’on lui envoie.

Pages voisines

La citent

DPA fournisseur IA générative, clauses de sécurité RGPD

Elle cite

: les deux pages se citent l’une l’autre.

DPA fournisseur IA générative, clauses de sécurité RGPD

DPA fournisseur IA générative, clauses de sécurité RGPD

Ce que l’article 28 du RGPD impose, et ce qu’il laisse ouvert

Sous-traitants ultérieurs, localisation et transferts

Surveiller la liste des sous-traitants ultérieurs

Notification d’incident, audit et réversibilité

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines