Audit sous-traitant RGPD : les contrats que vous n'avez pas

La semaine dernière, j'audite une startup SaaS. Le fondateur me dit : "On a trois prestataires tech — Stripe, OVH et Mailchimp." J'ouvre le code. J'en compte onze. Sentry, Google Analytics, Hotjar, Intercom, Cloudflare, SendGrid, Mixpanel, AWS S3 — tous reçoivent des données utilisateurs. Nombre de DPA signés avec ces onze sous-traitants : zéro.

Ce fondateur n'est pas négligent. Il ne savait pas que chaque outil qui touche les données de ses utilisateurs est, au sens du RGPD, un sous-traitant — et qu'un contrat spécifique est obligatoire avec chacun d'eux. C'est ce que révèle systématiquement un audit sous-traitant RGPD : l'écart entre ce qu'on croit avoir et ce qu'on a vraiment.

Chaque outil SaaS est un sous-traitant RGPD

Quand vous utilisez Stripe pour les paiements, Stripe traite les données bancaires et personnelles de vos clients. Quand vous envoyez vos newsletters via Mailchimp, Mailchimp stocke les adresses email de vos utilisateurs. Quand Sentry capture une erreur dans votre application, le rapport d'erreur contient souvent le nom, l'email ou l'identifiant de l'utilisateur concerné.

Chacun de ces services est un sous-traitant au sens de l'article 28 du RGPD. Vous, vous êtes le responsable de traitement. La distinction ? C'est vous qui décidez pourquoi et comment les données sont collectées. Le sous-traitant les traite pour votre compte. Mais aux yeux de la CNIL, c'est vous qui portez la responsabilité.

Le piège : personne ne vous présente Stripe ou Sentry comme des "sous-traitants RGPD". Ce sont des outils. Vous les intégrez, ça marche, vous passez à la suite. Sauf que juridiquement, chaque intégration crée une relation de sous-traitance de données personnelles.

Le DPA : le contrat que personne ne vous a expliqué

Un DPA — Data Processing Agreement — c'est le contrat qui encadre ce que votre sous-traitant fait avec les données de vos utilisateurs.

Ce que ça couvre :

• Quelles données sont transmises (emails, données de paiement, logs d'usage...)
• Pourquoi le sous-traitant y accède (pour rendre son service, rien d'autre)
• Où les données sont stockées (et si elles quittent l'Europe)
• Que se passe-t-il en cas de fuite (obligation de vous prévenir sous 72h)
• Que devient la donnée quand vous arrêtez le service (suppression ou restitution)
• Qui est responsable de quoi en cas de problème

L'article 28 du RGPD impose ce contrat. Pas une recommandation — une obligation légale.

La bonne nouvelle : pour la plupart des services que vous utilisez, ce DPA existe déjà. Vous n'avez pas à le rédiger. Il suffit de le récupérer et de l'activer.

Pourquoi vous n'en avez probablement aucun

Personne ne vous l'a dit. Quand vous créez un compte Stripe ou que vous intégrez Sentry, pas de popup "Signez le DPA avant de continuer." Le DPA est planqué dans les paramètres juridiques. Chez Stripe, il faut aller dans Dashboard > Settings > Compliance. Chez AWS, c'est un addendum dans la console. Chez Google, c'est enterré dans l'admin console.

Un de mes clients utilisait Stripe depuis deux ans. Le DPA était disponible depuis le premier jour. Un clic. Il ne l'avait jamais activé. En cas de fuite de données côté Stripe, il n'aurait eu aucune protection contractuelle. Il pensait que payer le service suffisait.

Vous ne savez pas qui sont vos vrais sous-traitants. Le fondateur connaît ses outils principaux : paiement, hébergement, emailing. Mais il oublie les SDK de monitoring, les services d'analytics, le CDN, le support client. Sur mes audits, l'écart moyen est de 3x : le fondateur déclare 4 sous-traitants, le code en utilise 12.

Vous pensez que c'est un projet. L'idée de "signer un contrat avec chaque prestataire" semble titanesque. En réalité, pour les grands SaaS, c'est l'affaire de quelques clics. Le DPA est pré-rédigé, standardisé. Vous le téléchargez ou vous l'activez en ligne.

Les risques concrets sans DPA

Oubliez l'amende théorique de 20 millions. Voici ce qui arrive en pratique.

Premier réflexe de la CNIL : vos sous-traitants. J'ai accompagné un client lors d'un contrôle CNIL l'an dernier. Première demande : le registre des traitements, la liste des sous-traitants, les DPA. Mon client n'avait pas de liste formalisée. Il a dû tout reconstituer en trois jours. Deux sous-traitants n'avaient pas de DPA en libre-service — facture d'avocat pour en rédiger un sur mesure.

Deal-breaker en B2B. Un client a perdu un contrat annuel de 120 000 € avec un grand groupe. La DSI a demandé la liste des sous-traitants avec DPA. Impossible de fournir le dossier en 48 heures. Le deal est passé au concurrent qui avait tout prêt. Ce scénario se répète : grands comptes et investisseurs exigent cette documentation. Si vous visez du B2B ou une levée, c'est un pré-requis.

En cas de fuite, vous êtes seul. Sans DPA, votre sous-traitant n'a aucune obligation contractuelle envers vous. Pas de notification. Pas de coopération. Pas de recours. C'est vous qui devez prévenir la CNIL et assumer les conséquences. Avec un DPA, le sous-traitant est tenu de vous alerter sous 72 heures et de collaborer. La différence est immense.

Audit de vos sous-traitants RGPD : comment trouver la vraie liste

C'est l'étape que tout le monde bâcle. On pense connaître ses outils, mais on ne voit que la partie émergée.

Les sous-traitants évidents : votre hébergeur (OVH, AWS, Google Cloud), votre solution de paiement (Stripe, Mollie), votre outil d'emailing (Mailchimp, SendGrid, Brevo).

Les sous-traitants oubliés : monitoring (Sentry, Datadog), analytics (Google Analytics, Mixpanel, Amplitude), support client (Intercom, Crisp, Zendesk), CDN (Cloudflare), stockage objet (AWS S3), CRM et marketing (HubSpot, ActiveCampaign). Chacun reçoit des données de vos utilisateurs.

Et il y a un troisième niveau, plus sournois : les SDK et librairies tierces. J'ai audité une app mobile qui utilisait une librairie analytics open source, présentée comme "respectueuse de la vie privée". En analysant le code source, j'ai découvert que les données transitaient par un serveur en Chine avant d'arriver sur les serveurs européens du service. Le fondateur n'en avait aucune idée. Ce "sous-traitant" fantôme n'apparaissait dans aucun document.

La seule façon fiable d'identifier tous vos sous-traitants : analyser le code. Pas ce que vous pensez utiliser — ce que votre application envoie réellement. C'est ce que je fais dans chaque audit RGPD : je croise la liste déclarée avec ce que le code révèle. L'écart est systématique.

Si vous n'avez pas les compétences techniques, demandez à votre développeur de lister toutes les requêtes HTTP sortantes de votre application. Chaque domaine externe qui reçoit des données = un sous-traitant potentiel.

Checklist : obtenir vos DPA en 48 heures

Ce n'est pas un projet de six mois. C'est un week-end.

1. Lister tous vos outils (2h)

Parcourez votre stack et listez tout ce qui touche des données utilisateurs : paiement, emailing, analytics, monitoring, hébergement, support client, CDN, stockage. Demandez à votre développeur de vérifier dans le code les appels vers des services tiers. Visez l'exhaustivité.

2. Récupérer chaque DPA (4h)

Pour chaque service, cherchez "DPA" ou "Data Processing Agreement" dans la documentation juridique ou les paramètres du compte.

Pour les services plus petits sans DPA en libre-service, un email suffit : "Conformément à l'article 28 du RGPD, nous avons besoin d'un accord de traitement des données. Pouvez-vous nous fournir le vôtre ?"

3. Archiver et documenter (1h)

Créez un dossier "Sous-traitants RGPD" avec un sous-dossier par service. Archivez chaque DPA signé ou activé. Mettez à jour votre registre des traitements avec la liste complète des sous-traitants, leur rôle et la localisation des données.

4. Instaurer la règle (15 min)

À partir de maintenant : chaque nouvel outil qui touche des données utilisateurs → récupérer le DPA avant l'intégration. Une ligne dans votre process, et le problème ne se repose plus.

Ce que ça change

La section sous-traitants est celle qui surprend le plus les fondateurs lors d'un audit — et celle qui se résout le plus vite. Identifier vos sous-traitants et collecter les DPA, c'est quelques heures de travail. Pas de juriste nécessaire pour les grands SaaS. Pas de budget conséquent. De la rigueur, c'est tout.

Le jour où un grand compte vous demande votre dossier, le jour où un investisseur veut voir votre conformité RGPD avant de signer, ou le jour où la CNIL vous contacte : 48 heures de travail feront la différence entre "on est prêt" et "on est dans la panique".