7 signes que votre créateur de formulaires en ligne n'est pas sûr pour les données sensibles

La plupart des créateurs de formulaires se ressemblent de l’extérieur. Un éditeur par glisser-déposer, un bouton de publication, des notifications par e-mail lors de la soumission. Rien dans cette interface ne vous indique si les données sont chiffrées, qui peut y accéder, ou où elles vont après la collecte.

Les défaillances de sécurité dans les créateurs de formulaires sont rarement visibles avant de devenir un problème. Elles apparaissent dans les notifications de violation, les audits de conformité, ou les demandes des utilisateurs qui veulent savoir ce qu’il est advenu de leurs données.

Les signes d’avertissement, cependant, sont principalement visibles à l’avance, dans la documentation, dans les ensembles de fonctionnalités, et dans les réponses à des questions spécifiques. Cet article en couvre sept.

Cet article est à titre informatif uniquement et ne constitue pas un conseil juridique. Consultez un professionnel qualifié de la protection des données pour des conseils spécifiques à votre organisation.

Signe 1 : Aucun Accord de Traitement des Données disponible

Un Accord de Traitement des Données (DPA) est un contrat juridiquement contraignant entre l’organisation collectant les données (le contrôleur) et la plateforme les traitant (le processeur). Lorsque le RGPD s’applique et qu’un contrôleur utilise un processeur tiers, l’article 28 exige un Accord de Traitement des Données conforme avant que le processeur ne traite les données personnelles pour le compte du contrôleur.

Le contrat doit définir, au minimum : l’objet et la durée du traitement, le type de données et les catégories de personnes concernées, les instructions du contrôleur au processeur, les obligations de sécurité, la divulgation des sous-traitants, les procédures de traitement des demandes de droits des personnes concernées, les délais de notification des violations, et la suppression ou le retour des données à la fin du contrat.

Ce n’est pas une case à cocher. L’article 28(3) spécifie chacun de ces éléments explicitement. Une politique de confidentialité n’est pas un DPA. Les conditions d’utilisation ne sont pas un DPA. Un DPA est un instrument bilatéral distinct signé par les deux parties.

Le signe : Le site web du créateur de formulaires n’a pas de DPA téléchargeable. La recherche de “DPA” ou “Accord de Traitement des Données” ne donne rien, ou redirige vers une politique de confidentialité générale.

Ce que cela signifie en pratique : Sans DPA signé, utiliser la plateforme pour collecter des données personnelles d’individus dans l’UE crée une exposition légale pour votre organisation, pas pour la plateforme. En vertu du RGPD, le contrôleur (vous) est principalement responsable de s’assurer qu’un accord conforme à l’article 28 est en place. Ne pas avoir un accord de traitement conforme à l’article 28 est en soi un problème de conformité, qu’une violation de données personnelles se produise ou non.

Des principes de responsabilité similaires existent dans d’autres cadres de confidentialité. Le CCPA/CPRA, la LGPD du Brésil, et la PIPEDA du Canada attendent tous des organisations qu’elles utilisent des garanties contractuelles appropriées lorsqu’elles font appel à des prestataires de services tiers, bien que les mécanismes juridiques diffèrent de l’article 28 du RGPD.

Ce qu’il faut rechercher : Un DPA disponible publiquement, téléchargeable, qui peut être signé sans nécessiter de négociation d’entreprise. Pour les organisations sous le RGPD, le DPA devrait également aborder les sous-traitants, les tiers sur lesquels le créateur de formulaires lui-même s’appuie pour l’infrastructure, le stockage ou le traitement. Le centre de confiance d’un fournisseur est généralement l’endroit idéal pour trouver cette documentation. Pour une liste de contrôle complète de la mise en œuvre du RGPD, voir Conformité RGPD pour les formulaires en ligne : Une liste de contrôle pratique.

Signe 2 : Des scripts tiers s’exécutent sur les pages de formulaire sans divulgation

Lorsque un utilisateur ouvre votre formulaire, il peut partager ses données avec plus que vous.

La plupart des applications web, y compris les créateurs de formulaires, chargent des JavaScript tiers pour l’analyse, la publicité, l’enregistrement de session, la surveillance des erreurs, et les tests A/B. Certains de ces scripts ont accès aux valeurs des champs de formulaire au fur et à mesure que les utilisateurs tapent. Cela signifie qu’un nom, une adresse e-mail ou un numéro de téléphone peut quitter l’appareil de l’utilisateur avant qu’il n’ait cliqué sur “Soumettre”.

C’est un comportement documenté. Une étude de 2022 par des chercheurs de l’Université Radboud, de KU Leuven, et de l’Université de Lausanne, intitulée “Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission”, a trouvé que 1 844 sites web dans un échantillon de 100 000 collectaient les adresses e-mail des utilisateurs avant la soumission du formulaire via des scripts de suivi tiers, sans le consentement de l’utilisateur. Les données étaient exfiltrées silencieusement, avant que tout événement de soumission ne se produise.

Le mécanisme est simple : les scripts d’analyse et de marketing attachent des écouteurs d’événements aux champs de saisie et transmettent le contenu à des points de collecte distants. Le créateur de formulaires lui-même peut ne pas avoir l’intention de ce comportement, mais si des scripts tiers sont chargés sur la même page, les données leur sont transmises de toute façon.

Le signe : Le créateur de formulaires ne documente pas quels scripts tiers s’exécutent sur les pages de formulaires publiées. Leur politique de confidentialité décrit leur propre collecte de données, pas le comportement de collecte des scripts s’exécutant sur vos formulaires.

Ce que cela signifie en pratique : Si votre formulaire charge un pixel d’analyse tiers ou un outil d’enregistrement de session, les données que vos utilisateurs saisissent peuvent être transmises à ce tiers sans consentement. Cela affecte l’exactitude de votre politique de confidentialité, votre conformité au RGPD (base légale pour le traitement), et dans les contextes de santé, potentiellement vos obligations HIPAA.

Ce qu’il faut rechercher : Une documentation explicite des scripts chargés sur les pages de formulaires publiées. Une plateforme manipulant des données sensibles devrait être capable de préciser quels services reçoivent des données des soumissions de formulaire et sous quelle forme. Les formulaires servis sur des domaines isolés, de première partie, sans scripts de publicité ou d’analyse, sont la solution la plus solide.

Signe 3 : Les affirmations de chiffrement sont vagues ou absentes

“Vos données sont sécurisées” est une déclaration marketing. Elle ne décrit pas un contrôle technique. Deux affirmations spécifiques comptent pour les données de formulaire :

Chiffrement en transit signifie que les données sont chiffrées lorsqu’elles voyagent entre le navigateur de l’utilisateur et le serveur. La norme actuelle est TLS 1.2 ou supérieur. C’est largement standard sur le web, mais cela devrait être indiqué explicitement, avec la version du protocole.

Chiffrement au repos signifie que les données stockées, les soumissions de formulaire dans une base de données, sont chiffrées. La norme actuelle pour les données sensibles est AES-256. C’est là que les plateformes diffèrent. Certaines chiffrent les données de soumission au repos, beaucoup ne le font pas. Une plateforme peut avoir un excellent chiffrement en transit tout en stockant vos données en clair.

La distinction est importante car les modèles de menace sont différents. Le chiffrement en transit protège contre l’interception pendant la transmission. Le chiffrement au repos protège contre l’accès non autorisé aux données stockées, qui est la menace pertinente dans la plupart des scénarios de violation. Selon le rapport 2025 d’IBM sur le coût d’une violation de données, la violation moyenne prend 158 jours pour être identifiée et 83 jours pour être contenue, un cycle de vie total de 241 jours, le plus bas en neuf ans, selon IBM Security. Pendant cette période, les données stockées sont l’exposition principale.

Le Top 10 d’OWASP (2025) liste “Les échecs cryptographiques” comme A04, l’un des risques de sécurité des applications web les plus critiques, incluant spécifiquement “les données stockées en clair” comme un mode d’échec principal.

Le signe : La documentation de sécurité de la plateforme utilise des phrases comme “nous utilisons une sécurité standard de l’industrie” sans spécifier l’algorithme de chiffrement, la version du protocole, ou la portée de la couverture. Aucune mention de AES-256 ou TLS 1.2+.

Ce que cela signifie en pratique : Les affirmations de chiffrement vagues ne fournissent aucune assurance vérifiable. Pour les données réglementées, santé, finance, juridique, le chiffrement au repos est souvent une exigence de conformité, pas une préférence. La règle de sécurité de l’HIPAA (45 CFR § 164.312) aborde spécifiquement le chiffrement comme une mesure de sécurité “adressable”, ce qui signifie que les entités couvertes doivent soit le mettre en œuvre, soit documenter pourquoi une alternative équivalente offre la même protection.

Ce qu’il faut rechercher : Une déclaration technique claire : “Les données de soumission sont chiffrées au repos en utilisant AES-256 et en transit en utilisant TLS 1.2+.” Si cela ne peut être trouvé dans la documentation publique, généralement dans le centre de confiance ou la page de sécurité d’un fournisseur, demandez directement. Une plateforme manipulant des données sensibles devrait répondre sans ambiguïté. Pour une répartition complète de ce à quoi la pile de sécurité devrait ressembler, voir Sécurité des données pour les formulaires en ligne : Ce que chaque entreprise devrait savoir.

Signe 4 : Aucune rétention de données configurable

Combien de temps la plateforme stocke-t-elle vos données de soumission ? Si la réponse est “indéfiniment, sauf si vous les supprimez manuellement”, c’est un problème.

Le principe de limitation de la conservation du RGPD (article 5(1)(e)) exige que les données personnelles soient “conservées sous une forme permettant l’identification des personnes concernées pendant une durée n’excédant pas celle nécessaire aux finalités pour lesquelles les données personnelles sont traitées”. Stocker les soumissions de formulaire pour toujours, même celles d’il y a des années, n’est presque jamais conforme à cette exigence.

Il y a aussi un risque pratique : plus l’ensemble de données détenu par une plateforme est grand, plus il devient précieux en tant que cible de violation. Les soumissions de formulaire d’il y a trois ans, toujours sur un serveur, sont toujours à risque. La suppression automatisée réduit cette exposition.

Différents flux de travail ont des besoins de rétention légitimes différents :

Le signe : La plateforme stocke les soumissions indéfiniment par défaut. Il n’y a pas de paramètres pour configurer un calendrier de suppression automatique. La seule option est la suppression manuelle.

Ce que cela signifie en pratique : La conformité aux exigences de rétention des données dépend de l’action humaine. Les politiques automatisées non. Une organisation qui s’appuie sur le personnel pour supprimer manuellement les anciennes soumissions de formulaire finira par manquer un cycle de suppression, en particulier lors des transitions de personnel ou des périodes de fort volume.

Ce qu’il faut rechercher : Des périodes de rétention configurables au niveau du compte ou du formulaire. La gamme devrait permettre à la fois une rétention courte (pour les flux de travail à haute confidentialité) et une rétention prolongée (pour la conservation des dossiers requise par la conformité). Des options comme “supprimer immédiatement après l’exportation vers le stockage en nuage” représentent les meilleures pratiques pour les flux de travail critiques pour la confidentialité.

Signe 5 : Aucun journal d’audit pour l’accès aux soumissions

Quand une soumission est ouverte, qui l’a ouverte ? Quand ? Quelqu’un l’a-t-il exportée ? A-t-elle été partagée via un lien ? A-t-elle été supprimée, et par qui ?

En l’absence d’un journal d’audit, aucune de ces questions ne peut être répondue. Cela crée un écart de responsabilité significatif, qui devient visible lors des audits réglementaires, des demandes d’accès des personnes concernées, ou des enquêtes internes.

La règle de sécurité de l’HIPAA aborde explicitement cela. La norme des contrôles d’audit (45 CFR § 164.312(b)) exige que les entités couvertes “mettent en œuvre des mécanismes matériels, logiciels et/ou procéduraux qui enregistrent et examinent l’activité dans les systèmes d’information qui contiennent ou utilisent des informations de santé protégées électroniques”. La journalisation de qui a vu une soumission, et quand, est une mise en œuvre directe de cette exigence.

Au-delà de la santé : l’article 5(2) du RGPD établit le principe de responsabilité, les contrôleurs doivent être capables de “démontrer la conformité” avec les principes de protection des données. Un journal d’audit est un composant fondamental de cette démonstration. Sans lui, “nous n’avons pas accédé à ces données” est une affirmation que vous ne pouvez pas vérifier.

Le Top 10 d’OWASP (2025) inclut “Les échecs de journalisation et d’alerte de sécurité” (A09) comme un risque critique pour les applications web, spécifiquement : “Les événements audités, tels que les connexions, les échecs de connexion, et les transactions de grande valeur, ne sont pas journalisés.”

Le signe : La plateforme n’a pas de journal d’activité. Les administrateurs peuvent voir les soumissions mais ne peuvent pas voir l’historique d’accès, l’historique d’exportation, ou l’activité de partage.

Ce que cela signifie en pratique : Vous ne pouvez pas répondre aux questions sur qui a accédé à des soumissions spécifiques. Si une personne concernée exerce son droit d’accès en vertu de l’article 15 du RGPD, elle peut demander des informations sur les destinataires ou les catégories de destinataires avec lesquels ses données personnelles ont été partagées, une question à laquelle un journal d’audit aide à répondre. Bien que l’article 15 n’exige pas que les contrôleurs maintiennent des journaux d’audit, de tels journaux peuvent grandement aider à démontrer la conformité et à répondre avec précision aux demandes d’accès.

Ce qu’il faut rechercher : Un journal d’audit au niveau de l’équipe accessible aux administrateurs, enregistrant au minimum : les événements d’accès aux soumissions, les événements d’exportation, la création de liens de partage, et les événements de suppression. Les journaux devraient être conservés pour une période compatible avec vos exigences de conformité.

Signe 6 : Aucun BAA disponible pour les cas d’utilisation dans le secteur de la santé

Aux États-Unis, toute organisation qui traite des Informations de Santé Protégées (PHI) pour le compte d’une entité couverte, y compris un créateur de formulaires traitant des formulaires d’admission de patients, est légalement un Partenaire Commercial en vertu de l’HIPAA (45 CFR § 160.103).

Avant que toute PHI ne circule à travers un outil tiers, un Accord de Partenariat Commercial (BAA) signé doit être en place. Le BAA n’est pas simplement une formalité : il établit les obligations du Partenaire Commercial en matière de protection de la PHI, les délais de notification des violations, et les utilisations de données permises. Sans cela, l’entité couverte porte la responsabilité des violations HIPAA découlant de la gestion de la PHI par le Partenaire Commercial, indépendamment des contrôles de sécurité réels de la plateforme.

L’OCR a constamment appliqué cette exigence. Des règlements ont été conclus contre des organisations de santé pour avoir utilisé des outils tiers non autorisés pour traiter la PHI, même en l’absence de violation. La violation est l’accord manquant, pas la violation.

Pour les mesures de sécurité techniques spécifiques que l’HIPAA exige, qu’un créateur de formulaires doit mettre en œuvre pour signer valablement un BAA, voir ce que l’HIPAA exige réellement des outils de formulaires en ligne.

Le signe : La plateforme n’offre pas de BAA, ou en offre un uniquement à des niveaux de tarification d’entreprise inaccessibles à la plupart des organisations de santé. Les petites cliniques, les thérapeutes indépendants, et les startups de santé se retrouvent à collecter des PHI sans relation de traitement conforme.

Ce que cela signifie en pratique : Utiliser un créateur de formulaires sans BAA pour collecter des données de patients, formulaires d’admission, formulaires de consentement, demandes de rendez-vous, détails d’assurance liés à des informations de santé, est une violation de l’HIPAA. Ce n’est pas une zone grise.

Ce qu’il faut rechercher : Un BAA disponible sur un plan de marché intermédiaire, signé automatiquement (ou avec un minimum de friction) lorsque le mode HIPAA est activé. Le BAA signé devrait être remis à l’administrateur du compte en tant que document qu’il peut conserver et produire lors d’un audit.

Signe 7 : Les soumissions individuelles ne peuvent pas être supprimées sur demande

L’article 17 du RGPD établit le droit à l’effacement. Lorsqu’une personne concernée demande la suppression de ses données personnelles, le contrôleur doit se conformer sans retard excessif et en tout état de cause dans un délai d’un mois, sous réserve d’exceptions limitées (obligation légale, intérêt public, etc.). La demande s’applique aux données spécifiques de l’individu, pas aux archives en vrac.

Cela crée une exigence technique : vous devez être capable d’identifier la soumission d’un individu spécifique et de la supprimer proprement. De nombreuses plateformes rendent cela difficile. La suppression en vrac est souvent disponible, la recherche et la suppression ciblées par répondant ne le sont pas.

Le même problème affecte la conformité proactive. Si votre politique de rétention spécifie la suppression après 90 jours, vous avez besoin que la plateforme applique cela au niveau de l’enregistrement, pas seulement fournisse un bouton “effacer tout” qui efface tout.

Le signe : L’interface de soumission n’a pas de recherche par identifiant de répondant (e-mail, nom). La suppression est uniquement en vrac. Il n’y a aucun moyen d’identifier toutes les soumissions d’un individu spécifique sur plusieurs formulaires.

Ce que cela signifie en pratique : Lorsqu’un utilisateur soumet une demande de suppression, que le RGPD lui donne le droit de faire, y répondre devient un processus manuel sujet à erreur. Si les soumissions s’étendent sur plusieurs formulaires ou périodes, trouver et supprimer tous les enregistrements pertinents devient difficile sur le plan opérationnel.

Ce qu’il faut rechercher : Recherche de soumission par valeur de champ, y compris l’adresse e-mail, le nom, ou tout champ d’identification. Suppression d’enregistrement individuel depuis l’interface de soumission. Pour les organisations sous le RGPD, la capacité de lancer une requête inter-formulaire par répondant est précieuse.

Une liste de contrôle

Avant de publier tout formulaire collectant des données sensibles :

• Un DPA téléchargeable et signable est disponible depuis la plateforme
• La plateforme documente quels scripts tiers s’exécutent sur les pages de formulaires publiées
• Le chiffrement au repos (AES-256) et en transit (TLS 1.2+) sont explicitement indiqués
• La rétention des données est configurable, avec des options de suppression automatique
• Un journal d’audit enregistre l’accès aux soumissions et les événements d’exportation
• Si vous collectez des PHI, un BAA signé est en place avant toute collecte de données
• Les soumissions individuelles peuvent être trouvées et supprimées par répondant

Références

• Parlement européen et Conseil, Article 28 du RGPD — Obligations du sous-traitant et exigences de la DPA, gdpr-info.eu/art-28-gdpr/
• Parlement européen et Conseil, Article 15 du RGPD — Droit d’accès de la personne concernée, gdpr-info.eu/art-15-gdpr/
• Parlement européen et Conseil, Article 17 du RGPD — Droit à l’effacement, gdpr-info.eu/art-17-gdpr/
• Bureau des droits civils de la HHS, 45 CFR § 160.103 — Définitions (Associé d’affaires), ecfr.gov
• Bureau des droits civils de la HHS, 45 CFR § 164.312 — Mesures de protection techniques, ecfr.gov
• Bureau des droits civils de la HHS, Contrats d’associé d’affaires, hhs.gov
• Acar, G. et al., Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission, Université Radboud / KU Leuven / Université de Lausanne, présenté à USENIX Security 2023
• OWASP, OWASP Top 10 2025, owasp.org/Top10 — A04 Échecs cryptographiques; A09 Échecs de journalisation et d’alerte de sécurité
• IBM Security, Rapport sur le coût d’une violation de données 2025, ibm.com/reports/data-breach — cycle de vie moyen d’une violation 241 jours (158 pour identifier, 83 pour contenir)

Lecture connexe : Conformité RGPD pour les formulaires en ligne : Une checklist pratique · Formulaires en ligne conformes à la HIPAA : Guide 2026 · Sécurité des données pour les formulaires en ligne : Ce que chaque entreprise doit savoir