Votre liste de sous-traitants est plus longue que vous ne le pensez

Une petite confession avant de commencer. Dans les articles précédents de cette série, je suis délibérément resté à l'écart des détails techniques d'implémentation, car en matière d'ingénierie réelle, je suis aussi utile qu'un fer à souder en chocolat. Je peux vous dire pourquoi quelque chose est important. Le comment, je le laisse aux personnes qui ont réellement suivi les bonnes formations.

Cet article est différent. Les sous-traitants et les flux de données sont l'un des rares domaines techniques où je sais vraiment de quoi je parle. J'ai passé des années à auditer ces choses, à en discuter avec les fournisseurs et à les expliquer aux régulateurs. Alors pour une fois, considérez-moi brièvement compétent.

Bien. Passons aux choses sérieuses.

À un moment donné au cours de la dernière année, quelqu'un de votre équipe a ajouté un SDK. Puis un autre. Un webhook vers un service tiers. Un agent de surveillance des erreurs. Un outil d'enregistrement de session. Une API d'IA où vous envoyez une entrée utilisateur et recevez une sortie.

Chacune de ces actions a été perçue comme une décision d'outil. Chacune d'entre elles est également une décision de gouvernance des données. Et les deux choses se sont rarement produites dans la même conversation.

Voici le problème : en vertu du RGPD, tout tiers qui traite vos données personnelles de vos utilisateurs en votre nom est un sous-traitant. Vous êtes légalement responsable d'eux. Vous avez besoin d'un contrat avec eux qui stipule des choses précises. S'ils sont basés en dehors de l'UE, vous avez besoin d'un mécanisme juridique pour y envoyer des données. Et si quelque chose tourne mal, les régulateurs vous demanderont de rendre compte de toute la chaîne, pas seulement de votre propre code.

La plupart des équipes ne peuvent pas le faire. Pas parce qu'elles sont négligentes, mais parce que les intégrations se sont accumulées plus vite que la documentation. Voici comment y remédier.

Étape un : trouver tout ce qui touche aux données personnelles

Ne commencez pas par une feuille de calcul. Commencez par votre trafic réseau.

Extrayez toutes les destinations sortantes auxquelles votre application se connecte. Les journaux réseau de votre fournisseur de cloud, votre pare-feu de sortie, votre outil de surveillance s'il dispose d'une visibilité réseau. C'est la vérité terrain. Tout le reste est de la documentation qui peut ou non correspondre à ce qui est réellement en cours d'exécution.

Ensuite, parcourez le code source. Chaque SDK tiers initialisé au démarrage. Chaque clé API dans votre configuration. Chaque point de terminaison webhook enregistré quelque part. Chaque endroit où vous appelez un service externe avec une charge utile contenant un identifiant utilisateur, une adresse e-mail, du contenu généré par l'utilisateur, un nom, un identifiant d'appareil, un jeton de session, une adresse IP, ou quoi que ce soit qui pourrait être lié à une personne spécifique.

Faites une liste. Vous y trouverez des choses que vous aviez oubliées. Tout le monde le fait.

Endroits courants que les développeurs manquent :

• Votre outil de surveillance des erreurs. Les traces de pile contiennent souvent des données personnelles identifiables (PII) - adresses e-mail dans les messages d'exception, identifiants utilisateur, corps de requête enregistrés lors d'une erreur. Sentry, Datadog, Rollbar, tous. Vérifiez ce que vous envoyez.
• Votre API de modèle d'IA. Si vous transmettez des entrées utilisateur à OpenAI, Anthropic ou à tout autre fournisseur de modèle, cette entrée contient probablement des données personnelles. Les conditions de leur accord de traitement des données (DPA) ont considérablement évolué au cours des deux dernières années. La version que vous avez acceptée lors de l'inscription peut ne pas refléter les conditions actuelles. Vérifiez à nouveau.
• Environnements de staging et de développement. Ils sont souvent connectés aux mêmes outils tiers que la production, parfois avec moins de surveillance. Les données en staging sont parfois copiées de la production. Les deux sont importants.
• Bibliothèques avec analyses intégrées. Certains SDK communiquent par défaut. Lisez le journal des modifications lorsque vous mettez à jour. Ce n'est pas de la paranoïa ; cela s'est produit avec des packages largement utilisés, et "nous ne savions pas que la bibliothèque faisait cela" n'est pas une phrase qui sonne bien devant un régulateur.

Étape deux : pour chaque intégration, posez trois questions

Une fois que vous avez la liste, parcourez-la systématiquement.

Cette intégration reçoit-elle des données personnelles ?

Si oui, elle est concernée. Si elle ne reçoit que des données anonymisées et agrégées sans lien avec des individus, vous pouvez la déprioriser. En cas de doute, traitez-la comme étant concernée.

Avez-vous un accord de traitement des données (DPA) avec ce fournisseur ?

Un DPA est un contrat qui établit les règles : le fournisseur ne peut traiter les données que selon vos instructions, il ne peut pas les utiliser à ses propres fins (y compris la formation de modèles, sauf si vous l'avez accepté), il doit vous informer d'une violation suffisamment rapidement pour que vous puissiez respecter votre propre délai de notification de 72 heures, et il doit supprimer vos données à la fin du contrat. La plupart des grands fournisseurs ont un DPA standard que vous pouvez signer ou accepter par clic. Trouvez-le, signez-le, conservez une copie.

Deux points à lire réellement dans le DPA avant de l'accepter : si le fournisseur peut utiliser vos données pour améliorer son propre produit ou entraîner ses modèles, et ce qu'il fait de vos données lorsque vous arrêtez de payer. Les deux sont fréquemment pires que ce que vous pourriez supposer d'après le texte marketing.

Où les données sont-elles traitées ?

Si le fournisseur est basé en dehors de l'UE, ou s'il utilise une infrastructure en dehors de l'UE, vous avez un transfert transfrontalier. Pour les fournisseurs américains, vérifiez s'ils sont certifiés selon le Cadre de protection de la vie privée UE-États-Unis (EU-US Data Privacy Framework) - la plupart des grands le sont, et il est consultable sur la liste du DPF. Le DPF a survécu à un recours juridique devant le Tribunal de l'Union européenne en septembre 2025 et est actuellement valide, bien qu'un appel devant la Cour de justice soit en attente. Si vous traitez des catégories de données sensibles, conserver des Clauses Contractuelles Types (SCC) dans votre DPA parallèlement à la certification DPF est judicieux compte tenu de l'historique de ce cadre particulier. Pour les fournisseurs non américains non couverts par une décision d'adéquation, les SCC sont le mécanisme standard. La vérification pratique : existe-t-il un mécanisme de transfert documenté dans le DPA, et est-il actuel ? Les SCC antérieures à 2021 sont invalides depuis décembre 2022. Si votre DPA est suffisamment ancien pour y faire référence, il doit être mis à jour.

Étape trois : trier ce que vous trouvez

Vous ne résoudrez pas tout d'un coup. Ce n'est pas grave. Personne n'a jamais tout résolu d'un coup. Certaines de ces personnes essaient encore. Ce qui compte, c'est de savoir ce que vous avez.

Haute priorité : intégrations recevant des noms, des adresses e-mail, du contenu généré par l'utilisateur, des données comportementales, ou quoi que ce soit d'une catégorie spéciale comme des données de santé, financières ou de localisation. Celles-ci nécessitent un DPA actuel et un mécanisme de transfert documenté avant tout le reste.

Moyenne priorité : intégrations recevant des identifiants pseudonymisés comme des identifiants utilisateur internes, des jetons de session ou des empreintes d'appareil. Toujours concernées, mais moins urgentes s'il n'y a pas de lien direct avec un individu sans données supplémentaires.

Hors champ pour l'instant : intégrations ne recevant que des données agrégées entièrement anonymisées sans risque de ré-identification. Documentez que vous les avez évaluées et pourquoi elles sont hors champ.

Pour tout élément de haute priorité pour lequel vous n'avez pas de DPA, trouvez-le aujourd'hui. La plupart des fournisseurs les publient dans leur section juridique ou de confidentialité. Si un fournisseur refuse de signer un DPA, c'est un signal d'alarme important. Des données personnelles transitant vers un sous-traitant sans DPA constituent une violation du RGPD, pas une lacune que vous pouvez combler plus tard.

Étape quatre : mettez-le par écrit

Le RGPD exige que la plupart des organisations maintiennent un Registre des activités de traitement. Ce que vous venez de construire est la base de ce registre. Pour chaque intégration : quelles données y transitent, pourquoi, selon quelle base juridique, où elles sont traitées et quelles sont les garanties.

Ce document a deux publics. Le premier est un régulateur, si vous avez besoin de démontrer votre posture de conformité. Le second est vos clients d'entreprise, qui demanderont votre liste de sous-traitants dans le cadre de la diligence raisonnable des fournisseurs. Chaque entreprise vendant dans des secteurs réglementés recevra cette demande. Avoir la réponse prête fait la différence entre un processus d'approvisionnement fluide et un processus retardé.

Maintenez-le à jour. Ajoutez une étape à votre checklist d'intégration : chaque fois qu'un nouvel outil tiers est installé, la revue des sous-traitants l'accompagne. Cela prend vingt minutes par intégration lorsque vous le faites au moment opportun. Cela prend considérablement plus de temps lorsque vous le faites rétrospectivement sur trois ans d'outils accumulés sous pression temporelle.

La version honnête de pourquoi cela importe

Les régulateurs n'auditent pas la plupart des startups. Le risque d'application immédiate pour une petite entreprise est réel, mais ce n'est pas la raison principale de faire cela.

La raison principale est qu'une violation impliquant des données dont vous ignoriez qu'elles étaient traitées par un fournisseur que vous n'aviez pas cartographié est une catégorie de problème différente d'une violation dont vous pouvez rendre compte intégralement. L'une est un incident. L'autre est la preuve que votre gouvernance des données n'existe pas. Les régulateurs, les avocats et les clients d'entreprise traitent ces deux situations très différemment.

Faites l'audit. C'est quelques jours de découverte inconfortable, et ensuite vous saurez ce que vous avez réellement. Cela vaut considérablement plus qu'une politique de confidentialité que personne ne lit.