Où vont les données de vos formulaires ?

Une auto-école de Bulle a un formulaire d’inscription sur son site : nom, adresse, date de naissance, numéro de téléphone, catégorie, et une zone de remarques dans laquelle on mentionne parfois le port de lunettes. Le formulaire fonctionne depuis des années. Un jour, une cliente téléphone et demande où ces indications sont effectivement enregistrées.

La question est simple à poser et étonnamment difficile à trancher si personne dans l’entreprise n’a jamais regardé. Elle reste pourtant vérifiable sans compétence technique particulière : la réponse se trouve dans une poignée de documents qui existent déjà, et le trajet des données compte moins d’étapes qu’on ne l’imagine.

La chaîne, étape par étape

Entre le clic sur «envoyer» et le moment où quelqu’un lit la réponse dans l’entreprise, les étapes sont presque toujours les mêmes.

Étape	Ce qui s’y passe
Navigateur	Les saisies sont assemblées en une requête HTTP
Adresse cible du formulaire	La requête part vers le serveur indiqué dans le formulaire
Application du prestataire	La réponse est vérifiée, enregistrée, journalisée
Stockage et sauvegardes	Base de données, dépôt de fichiers, sauvegardes
Notification	Un courriel contenant la réponse arrive dans l’entreprise
Raccordements	Export, tableur, comptabilité, outil d’infolettre, webhook

Chacune de ces étapes est un lieu, et un lieu se nomme. Les quatre distinctions qui se cachent derrière — lieu de stockage, ordre juridique, accès et sous-traitants ultérieurs — sont détaillées dans un billet séparé ; ici, il s’agit du trajet concret d’une seule réponse de formulaire.

Étape 1 : où le formulaire envoie

Un formulaire HTML possède un attribut nommé action. C’est lui qui détermine où vont les données. Les MDN Web Docs le formulent ainsi : l’attribut action définit l’endroit où les données sont envoyées, et sa valeur doit être une URL valable, relative ou absolue ; en l’absence de cet attribut, les données sont envoyées à l’URL de la page qui contient le formulaire.

Cette seule ligne décide davantage que tout le reste de la page. Si elle contient une adresse de votre propre domaine, la réponse reste d’abord chez votre hébergeur. Si elle contient l’adresse d’un service de formulaires, la réponse quitte votre site au moment même où quelqu’un presse «envoyer» — même lorsque le formulaire est intégré visuellement et que la visiteuse n’a jamais eu l’impression de quitter le site.

Le chiffrement du transfert dépend du protocole de cette adresse. Avec une adresse HTTPS, les données sont chiffrées avec le reste de la requête ; si le formulaire se trouve sur une page sécurisée mais pointe vers une adresse HTTP non chiffrée, MDN relève que tous les navigateurs affichent un avertissement de sécurité au moment de l’envoi.

Il vaut la peine de distinguer ce que le chiffrement du transport fait et ne fait pas. Il protège le trajet. Il ne dit rien du lieu où la réponse est déposée ensuite, ni de qui peut l’y lire.

Étape 2 : ce que dit la documentation du prestataire

Au bout de cette adresse se trouve un service, et la plupart des services documentent publiquement où ils enregistrent. Deux exemples, tirés de la documentation des prestataires eux-mêmes.

Microsoft Forms. Microsoft classe Forms parmi les «Additional Microsoft 365 Services» — ces services pour lesquels, sauf disposition contraire des conditions produit, il n’existe pas d’engagement spécifique de résidence des données. Le tableau indique ensuite le lieu de stockage prévu selon la géographie par défaut du client : pour les clients situés dans un pays de l’UE ou de l’AELE, il s’agit de la «Macro Region Geography 4 — European Union/EFTA», et pour tous les autres emplacements, des États-Unis. La Suisse est un pays de l’AELE. À côté de cela existe l’option Advanced Data Residency, qui prend des engagements pour des régions nationales ; Microsoft y mentionne la Suisse parmi les régions locales possibles et énumère les services couverts un à un — Exchange Online en fait partie, Forms non.

Google Forms. Google propose pour Google Workspace des régions de données : les données couvertes peuvent être stockées dans un emplacement géographique choisi, à savoir les États-Unis ou l’Europe. Pour Forms, Google désigne comme données couvertes «Text, embedded images, responses, and draft responses». Deux limites figurent sur la même page : selon l’abonnement, la couverture porte sur les données au repos et pas nécessairement sur le traitement, et les régions de données ne s’appliquent pas aux types de données qui n’y sont pas expressément cités — les journaux et les contenus mis en cache, par exemple.

Les deux exemples montrent le même schéma, et il est utile : une indication de lieu de stockage vaut pour certaines données, dans une certaine version du produit, dans une certaine région. «Où sont les données» n’a donc presque jamais une réponse en un mot, mais presque toujours une réponse consultable.

Étape 3 : qui d’autre intervient

Rares sont les prestataires qui exploitent tout eux-mêmes. Derrière un service de formulaires, on trouve habituellement un centre de calcul, un expéditeur pour les notifications, un journal d’erreurs, un outil de support. Ces prestataires sont des sous-traitants ultérieurs, et beaucoup de fournisseurs les publient dans une liste.

Google Workspace montre ce qu’une telle liste peut contenir. Pour chaque entrée, Google indique la société, les services concernés, l’activité — «Technical Support» ou «Security Risk Detection», par exemple —, les pays dans lesquels le traitement a lieu, l’adresse inscrite, le pays d’enregistrement et la société mère ultime. Les versions antérieures de la liste restent accessibles sur la même page, ce qui permet de suivre les changements.

Juridiquement, cette chaîne n’est pas un détail : le sous-traitant ne peut confier le traitement à un tiers qu’avec l’autorisation préalable du responsable du traitement (art. 9 al. 3 LPD). L’absence de liste publique est elle aussi une information — et elle se demande par courriel.

Étape 4 : la deuxième copie que personne ne compte

La plupart des services de formulaires envoient un courriel de notification à chaque nouvelle réponse, et dans bien des configurations, ce courriel contient l’intégralité de la réponse. Dès cet instant, la réponse existe à deux endroits au moins : dans le stockage du service et dans la boîte de réception de l’entreprise.

La boîte aux lettres est une étape à part entière, avec ses propres réponses. Exchange Online, par exemple, relève des engagements de l’offre Advanced Data Residency de Microsoft, qui n’inclut pas Forms — même groupe, même connexion, deux réponses différentes à la même question. S’y ajoutent les raccordements : l’export dans un tableur, la transmission à un outil de comptabilité ou d’infolettre, un webhook vers un système tiers. Chacun est une copie de plus dans un lieu de plus, et chacun est visible dans les réglages du formulaire, parce que quelqu’un l’y a configuré un jour.

Pour l’auto-école, cela signifie très concrètement : l’inscription d’une cliente ne se trouve pas «dans le formulaire». Elle se trouve dans le service, dans la boîte de réception, dans le tableur téléchargé sur l’ordinateur du bureau et, le cas échéant, dans l’agenda.

Ce que le contrat ajoute

Pour l’entreprise, la chaîne technique est une moitié, le contrat est l’autre. Le PFPDT pose le principe sans détour : même lorsque le traitement de données personnelles est confié à un sous-traitant, le mandant reste responsable de la protection des données et doit choisir son sous-traitant avec soin, l’instruire de manière appropriée et le surveiller dans la mesure nécessaire. Parmi les points que le PFPDT énumère figurent le traitement uniquement selon les instructions, des mesures appropriées de sécurité des données et l’accord préalable au recours à d’autres prestataires.

Chez de nombreux fournisseurs, ce contrat est disponible en téléchargement comme document standard, souvent sous l’appellation «Data Processing Agreement» ou contrat de sous-traitance. Il répond à ce que la documentation technique laisse ouvert : quelles instructions s’appliquent, comment les nouveaux sous-traitants sont annoncés, ce qui se passe en cas de violation de la sécurité et ce que deviennent les réponses à la fin du contrat.

Et du point de vue de la personne qui a rempli le formulaire

Quiconque collecte des données personnelles informe la personne concernée de manière adéquate et lui communique au minimum l’identité et les coordonnées du responsable du traitement, la finalité du traitement et, le cas échéant, les destinataires ou les catégories de destinataires (art. 19 al. 1 et 2 LPD). Lorsque des données sont communiquées à l’étranger, l’information porte aussi sur l’État concerné et, le cas échéant, sur les garanties de l’art. 16 al. 2 LPD ou sur l’exception de l’art. 17 LPD (art. 19 al. 4 LPD).

C’est la raison pour laquelle la chaîne intéresse : ce qui figure au bout du compte dans une déclaration de protection des données, c’est exactement la liste des étapes que quelqu’un a réunies une fois. Avec cette liste, la question de la cliente au téléphone tient en une phrase — et sans elle, la liste se reconstitue en une heure ou deux : code source, documentation du prestataire, liste des sous-traitants, contrat, boîte de réception, raccordements.

L’application de formulaires en ligne que nous développons prend cette chaîne par l’autre bout : les réponses seront chiffrées dans le navigateur de la personne qui répond, et l’exploitation comme le stockage se situeront en Suisse. La chaîne ne disparaît pas pour autant — elle raccourcit, au point de tenir en une phrase. C’est de toute façon la mesure la plus utile : non pas qu’il existe une réponse à la question, mais qu’elle tienne en une phrase.