RGPD et hébergement dans l'UE : ce à quoi les équipes doivent veiller pour les outils de développement

Lorsqu'une entreprise veut adopter un nouvel outil de mesure d'audience, la procédure est désormais rodée : le délégué à la protection des données réclame le contrat de sous-traitance, quelqu'un vérifie l'emplacement du serveur, la politique de confidentialité est complétée. Pour la boîte à outils du service de développement, cela se passe souvent autrement : un membre de l'équipe trouve un outil utile, crée un compte, et trois mois plus tard celui-ci fait silencieusement partie du quotidien de travail. Cette inégalité de traitement n'a aucune raison objective — les outils de développement traitent eux aussi des données, et certains davantage que leurs utilisateurs ne s'en rendent compte.

Les services de test en sont un bon objet d'observation. Un service de captures d'écran, par exemple, photographie des pages web — et la photo d'une page web contient tout ce que cette page montre. Sur une page marketing publique, c'est sans risque. Cela devient intéressant sur les bords : les environnements de préproduction remplis de copies de véritables données de production. Les pages qui affichent des commentaires d'utilisateurs, des avis ou des photos de profil. Les adresses dont les paramètres d'URL recèlent des marqueurs de session ou des identifiants. Qui confie de telles pages à un service externe transmet le cas échéant des données à caractère personnel — même si, dans sa tête, il ne se passe que « nous testons la mise en page ».

Le RGPD, le règlement général sur la protection des données, ordonne clairement une telle configuration : l'entreprise qui utilise le service reste responsable du traitement des données ; le service agit en règle générale comme sous-traitant. Cette répartition des rôles n'est pas une formalité, elle a une conséquence pratique : il faut un contrat de sous-traitance conforme à l'article 28 — habituellement le document standard du fournisseur —, et la responsabilité de la licéité globale du traitement ne migre pas vers le prestataire avec les données. Elle reste chez l'entreprise.

La deuxième question standard porte sur le lieu du traitement. À l'intérieur de l'UE, le RGPD s'applique directement ; chez les fournisseurs qui traitent des données dans des pays tiers commence en revanche un chapitre d'examen à part : décisions d'adéquation, clauses contractuelles types, analyses d'impact des transferts. Pour les transferts vers les États-Unis, il existe certes une décision d'adéquation, mais ses devancières ont déjà été annulées deux fois en justice, et le cadre actuel reste lui aussi juridiquement contesté. Rien de tout cela ne rend les services américains inutilisables — mais chacune de ces constructions représente un travail d'examen qui, avec un site en Europe, disparaît tout simplement. L'hébergement dans l'UE est en ce sens moins un label de qualité qu'un raccourci : il rend l'évaluation plus courte, pas superflue.

ScanU, un service de tests de régression visuelle et de captures d'écran de navigateurs, se prête ici d'exemple concret, parce que le fournisseur explicite le lieu des données : selon ses indications, les données sont hébergées à Francfort, et le service se positionne expressément au regard du RGPD — à lire sur la page d'entrée française de ScanU. Pour une entreprise allemande, cela signifie : la question du pays tiers ne se pose d'abord pas pour le service principal, et l'examen peut se concentrer sur les points habituels — contrat, durées de conservation, effacement, sous-traitants ultérieurs.

Et c'est précisément ici qu'a sa place une phrase honnête, valable pour tout fournisseur, y compris celui examiné ici : les affirmations d'un site produit sont le point de départ de l'examen, non son résultat. « Hébergé à Francfort » et « orienté RGPD » sont des déclarations du fournisseur sur lui-même — qui veut employer le service à titre professionnel lit le contrat de sous-traitance, contrôle la liste des sous-traitants ultérieurs et clarifie ce qu'il advient des données en cas de résiliation. Un fournisseur qui remet volontiers de tels documents fait ainsi davantage pour la confiance que n'importe quelle formule marketing ; celui chez qui on ne les trouve pas a déjà répondu à la question la plus importante.

Qui lit pour la première fois un contrat de sous-traitance peut se repérer à quatre endroits. Premièrement, l'objet : le contrat décrit-il concrètement quelles données sont traitées et à quelle fin, ou reste-t-il générique et interchangeable ? Deuxièmement, les mesures techniques et organisationnelles, le plus souvent en annexe : y trouve-t-on des indications vérifiables sur le chiffrement, le contrôle des accès et l'emplacement — ou des lieux communs ? Troisièmement, la clause sur les sous-traitants ultérieurs : le client est-il informé des changements, et peut-il s'y opposer ? Quatrièmement, la restitution et l'effacement des données à la fin du contrat. Aucune de ces questions ne suppose des études de droit — ce sont des questions de compréhension auxquelles toute personne au fait de la technique peut répondre. Et là où le contrat se tait, la question ciblée au fournisseur est le test le plus honnête de sa disposition à renseigner.

Un point de contrôle souvent négligé, ce sont les durées de conservation — alors qu'elles constituent, en droit de la protection des données, un sujet central, sous le mot d'ordre de la minimisation : les données ne doivent pas être conservées plus longtemps que la finalité ne l'exige. Chez les services de captures d'écran, la conservation de l'historique de contrôle détermine combien de temps les images de ses propres pages restent chez le fournisseur. ScanU échelonne cet historique selon le palier tarifaire — de trois jours dans la formule gratuite à 15 puis 30 jours, jusqu'à 90 jours dans le plus grand palier, comme l'indiquent les paliers tarifaires de ScanU. Ce qui est remarquable : du point de vue de la protection des données, le plus petit palier est le plus sobre. Qui a besoin de longs historiques, par exemple pour circonscrire des régressions sur plusieurs mois, choisit sciemment la durée plus longue — mais ce doit être un choix conscient, non un réglage par défaut auquel personne n'a jamais réfléchi.

Au moins aussi important que l'examen du fournisseur est son propre comportement d'usage — car la mesure de protection des données la plus efficace consiste à ne pas confier de données sensibles au service, tout simplement. Pour les services de test, cela signifie concrètement : remplir les environnements de contrôle de données d'exemple synthétiques plutôt que de copies de la base de production. Tester des pages et des mises en page publiques plutôt que des vues authentifiées avec de vraies données clients. Veiller à ce que les URL testées ne recèlent ni jeton de session ni identifiant à caractère personnel. Ces règles coûtent peu, valent pour tout outil fondé sur des URL — et elles désamorcent la question de la protection des données plus efficacement que n'importe quelle clause contractuelle.

À quoi de telles règles d'usage peuvent ressembler tient en trois phrases pour le wiki d'équipe. Premièrement : n'entrent dans le service que des adresses de pages publiques ou d'environnements de préproduction alimentés en données synthétiques — jamais des vues qui montrent de vraies données clients. Deuxièmement : avant la création d'un nouveau projet de contrôle, l'URL est passée une fois en revue sciemment quant à ses paramètres ; les jetons de session et les identifiants à caractère personnel n'y ont rien à faire. Troisièmement : les rapports partagés sont traités comme des documents internes — transmission aux seules personnes concernées, liens hors des canaux publics. De telles règles se formulent en dix minutes et se transmettent vite lors de l'intégration de nouvelles collègues et de nouveaux collègues. Leur valeur tient moins à leur formulation qu'au fait que le sujet a été énoncé une fois : les incidents de protection des données liés à l'usage d'outils naissent rarement d'une intention — le plus souvent d'une routine dans laquelle personne n'a jamais posé la question.

Les rapports partagés méritent eux aussi une pensée. Les rapports de contrôle partageables sont extrêmement pratiques pour la collaboration — raison précise pour laquelle il devrait être clair qui peut ouvrir un rapport partagé et combien de temps il reste disponible. Ce n'est pas une particularité des services de test : pour les rapports vaut la même chose que pour les documents partagés dans n'importe quel outil en ligne. Un rapport contenant des captures d'une page produit non publiée est un matériel confidentiel et devrait être traité comme tel.

Jusqu'où l'examen doit-il aller ? Le RGPD lui-même donne la réponse : selon le risque. Un service de captures qui photographie des pages marketing publiques est d'un autre calibre qu'un logiciel de paie contenant des données de salaire. Il serait disproportionné d'accabler les deux du même questionnaire — mais tout aussi faux de ne pas regarder du tout le cas le plus modeste. Une voie médiane pragmatique pour les outils de développement : clarifier le rôle (sous-traitant ?), rassembler le contrat, noter le lieu des données et les sous-traitants ultérieurs, consigner les durées de conservation et d'effacement, formuler des règles d'usage pour l'équipe. Cela s'expédie en un temps raisonnable et couvre les obligations essentielles.

Joué de bout en bout sur l'exemple d'un service de captures d'écran, ce catalogue se présente ainsi. Rôle : le service traite les contenus de pages transmis pour le compte de l'entreprise — sous-traitant, donc, et par conséquent contrat au titre de l'article 28 à rassembler et à archiver. Lieu des données : à lire chez le fournisseur et à noter ; chez ScanU, Francfort est indiqué, ce qui fait tomber l'examen du pays tiers pour le service principal. Sous-traitants ultérieurs : extraire la liste des pièces contractuelles ou la demander — un fournisseur européen peut lui aussi recourir à des prestataires en aval, et c'est seulement cette liste qui rend la chaîne complète. Durées de conservation : le palier tarifaire choisi détermine combien de temps l'historique de contrôle, et donc les captures, sont conservés ; comparer la durée au besoin réel et motiver la décision en une phrase. Effacement : clarifier ce qu'il advient des rapports et des historiques en cas de résiliation. Qui documente ces cinq points sur une page a fait l'essentiel pour un outil de cette classe de risque — et dispose du même coup d'un modèle réutilisable pour l'outil suivant. Le fournisseur regroupe les réponses aux questions courantes sur le service lui-même dans les questions fréquemment posées sur ScanU.

En fait également partie une inscription au registre des activités de traitement — cette documentation obligatoire dans laquelle une entreprise consigne quels services traitent quelles données et à quelle fin. Cela sonne plus bureaucratique que ce ne l'est : pour un outil de développement, ce sont quelques lignes. La valeur réelle est ailleurs : qui rédige l'inscription doit avoir répondu aux questions. La documentation impose l'examen qui, sinon, se dissout dans le quotidien.

Une objection venue de la pratique mérite ici une réponse honnête : si l'examen devient trop lourd, il n'a pas lieu plus soigneusement, il n'a pas lieu du tout. Si six semaines et trois responsabilités séparent « outil trouvé » de « outil validé », les développeuses et développeurs finissent par créer le compte à titre privé — et un service contrôlable devient de l'informatique fantôme dont plus personne n'a connaissance. La conséquence à en tirer n'est pas de renoncer à l'examen, mais de l'ajuster au risque : un contrôle court, rapide et documenté pour les outils faiblement liés aux données, l'examen complet pour tout ce qui approche des données de production ou des systèmes clients. Une équipe qui sait que le contrôle court prend quelques jours et se termine le plus souvent par un oui n'a aucune raison de le contourner. L'organisation de la protection des données la plus solide est finalement celle dont la voie officielle est plus rapide que le détour.

Reste la mise en perspective d'ensemble. Le choix d'outils sobres en données et hébergés de façon transparente n'est pas une subtilité juridique, mais fait partie du soin artisanal que les équipes trouvent depuis longtemps évident ailleurs — personne n'exploiterait une base de données sans plan de sauvegarde. L'hébergement dans l'UE, des durées de conservation claires et un contrat de sous-traitance propre sont ici trois bons critères parmi d'autres, non un substitut à son propre examen : un service hébergé à Francfort peut lui aussi être mal configuré, mal utilisé ou alimenté avec les mauvaises données. La responsabilité n'en incombe pas au fournisseur, mais à l'entreprise qui l'emploie.

La bonne nouvelle pour finir : l'effort est ponctuel et mesuré. Une heure d'examen structuré par outil, une courte inscription dans la documentation, deux règles d'usage pour l'équipe — pour la plupart des outils de développement, il n'en faut pas davantage. Comparé à l'effort qu'il faut fournir pour expliquer après coup une transmission de données irréfléchie, c'est un très bon échange.